[REBOL] The day before, the day after, time to leave? ... Re:(3)
From: mjmalpha:localnet at: 22-Sep-2000 17:05
> I think that in Carl's mind (well, I really don't know what's going in
> Carl's mind other than what I conclude from his design of REBOL) REBOL
> intended as a tool to do NEW things in a new way. Things that have not
> done because before, because the OLD tools did not inspire doing these
> things, because the old tools are too clumsy to even begin to think
> doing NEW things.
> I think RT should continue to remain focused on REBOL as a tool to do
> things. They should encourage a visionary approach to using REBOL.
> should not get caught up in trying to make REBOL the more convenient
> for doing OLD things. Why? Because if they are going to compete with
> established tools (some of which have been around 10 - 20 years), they
> too much catching up to do, not only in terms of specialized support
> legacy technologies, but also in terms of breaking through the
> people who are set in their ways and have been solving the exact same
> of problems in the exact same way for ten, twenty or thirty years.
I can't agree w/ the idea that employing REBOL to do
OLD things is less valuable than NEW things. In my company,
we're very interested in using REBOL for both OLD and NEW
applications, and *especially* old ones. We have the need to
acquire data from the Internet in many different forms/formats
and parse it into more strategically organized forms. While
some would argue that Perl or Python may be the best tools
for the parsing aspect, I feel that REBOL has great potential
for expressing automated processes in a far more cohesive,
understandable manner --- and that has great value for
purposes of software design collaboration and maintenance.
I want our company's software to be readable with the least
amount of "religious content". And while that may mean that
I can't hire from a burgeoning pool of REBOL experts in the
same way that I might in the Perl or Python world, so what?
Anyone schooled in Perl or Python worth their salt can learn
REBOL, and do so fairly effectively, IMHO.
There are, after all, many OLD problems that need to be solved
again and again as a matter of practicality -- why not employ
innovative technologies like REBOL if they provide advantages
such as readability, or economy of expression, or dialecting
that serves a company's problem domain in an elegant,
By the way, I try to make it a practice not to hire lethargic
programmers that have done the same things the same way
for the last ten, twenty, or thirty years, but hey, that's just
(Uh oh ... my soapbox is coming apart under the weight of
this argument ...... :)