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.
At 08:28 AM 9/22/00 +0200, you wrote:
>> Hi,
>>
>> the day before I left for my business trip, I answered to Bo's email
>> sent to Phoenix ml asking why evyryone talks MS C# but not REBOL/View,
>> so let's start with it:
>...
>> ... Time to leave after four years of loyality?
>...
>>
>> Sadly,
>> -pekr-
>
>Very nicely written Pekr! I guess I can only agree.
>
>REBoL is very cool, it even changing (evolving) very fast (although it's
>been four years now, as Pekr says), but it does it as if it was a RT's
>_toy_ and not a product. Actually I can see no REAL _product_.
>Many things can be done with REBoL, very easily... but many things can't
>be done, because of thing Pekr described. You know what these things
>are. We did (not particullary I did...) asked for them starting on the
>early days (execution of external programs, libraries etc.) which have
>finally appeared in /Command, but are actually needed in the very heart of
>REBoL, /Core. And many other things that have distracted many, I believe.
>
>Always a REBEL, Jano
>
>
>
>
;- Elan [ : - ) ]
author of REBOL: THE OFFICIAL GUIDE
REBOL Press: The Official Source for REBOL Books
http://www.REBOLpress.com
visit me at http://www.TechScribe.com
