----- Original Message -----
From: <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Friday, September 22, 2000 8:47 PM
Subject: [REBOL] The day before, the day after, time to leave? ... Re:(2)
> Hi Petr, Hi Jano,
>
> I believe that many things Petr said make a lot of sense ... to a degree.
> There are two competing, equally valid views of REBOL:
>
> - REBOL as a new tool to do NEW things.
> - REBOL as a new tool to do OLD things.
>
> Your criticism of RT's approach is based on the view of REBOL as a new
tool
> do OLD things. I.e., how well does REBOL replace the tools we have been
> using all along (shell scripts, PERL, Tcl/TK, Visual Basic ... ) to do OLD
> things, such as integrate different applications, use OS services,
> conditionally launch applications, etc. This demand is natural. REBOL is
> such a well-designed tool to DO THINGS that - having invested the effort
of
> learning REBOL - one immediately wishes one were able to use REBOL to do
> all those OLD things that one has to do all day.
>
> 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 is
> intended as a tool to do NEW things in a new way. Things that have not
been
> done because before, because the OLD tools did not inspire doing these new
> things, because the old tools are too clumsy to even begin to think about
> doing NEW things.
>
> I think RT should continue to remain focused on REBOL as a tool to do NEW
> things. They should encourage a visionary approach to using REBOL. They
> should not get caught up in trying to make REBOL the more convenient tool
> 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
have
> too much catching up to do, not only in terms of specialized support for
> legacy technologies, but also in terms of breaking through the lethargy of
> people who are set in their ways and have been solving the exact same type
> of problems in the exact same way for ten, twenty or thirty years.
>
> And to the degree that we enjoy using REBOL and desire to make REBOL a
tool
> we can use daily in our professional life, we should be brainstorming
about
> the new things that can be done with REBOL instead of complaining about
how
> well REBOL manages to replace the old tools we have been using all along.
>
> How can we, for instance, use REBOL to improve the way we continue to OLD
> things using OLD tools? Can we implement a meta dialect in REBOL that will
> enable us to use REBOL to compile high-level task descriptions into
> executable PERL, Tcl/TK, Java or C++ scripts and programs?
>
> Which problems in a corporate context are not being tackled with existing
> technologies because of the limitation inherent in these technologies? Can
> REBOL be used as a basis to provide solutions to problems that are not
> being tackled because it is not feasible to attempt to solve them using
> anything but REBOL?
>
> More about that shortly.
OK, pressed for the time too now. Very nicely written, you should continue
in writing books :-)
But, to the topic, just one point:
Even REBOL is based upon OLD technologies - it uses old TCP/IP at lower
level, it uses whole OS infrastructure, it is written in old good C. You
know, I know many managers coming to our big company stating - hey, I will
show you, how things should work and will change it. But just after some
time they always recognize, some things are as they are, because praxe shows
us it's just the best state for that things to be in.
And so - what about another technologies? Are they all old in comparison
with REBOL? I thought RT wants to survive, and that's I thought they need to
introduce something competitive. Do you find Command in form of CGI
competitive or NEW aproach? Or do you want to suggest me replacing my Apache
and let /Command become my new web server? It would make sense for certain
(new kind of) services probably, but ...
OK, later, have to leave now ...
-pekr-
