Hi all.
I understand that different constituencies
will favor a different order that Rebol /CORE,
/COMMAND, and /view should be developed,
enhanced and released. In that regard,
you can't satisfy everyone.
My own preference is to get /COMMAND
as soon as possible. I use the Thompson
Toolkit (Unix shell and utilities) and AWK
compiler a lot in a Windows
environment for many tasks, especially
reformatting data from many external
sources for import to relational databases.
Increasingly, this external data is retrieved
from the Internet. I've considered investing
serious time becoming a proficient Perl
programmer, but what a great thing it
would be to accomplish most of what I
need with Rebol /X's . The prospect of
/VIEW (for me) is also appealing in that
we could do some serious toolsmithing
to empower the non-programmer types
in our company as well.
I would really be interested in knowing
how many people interested in Rebol
are *truly* interested in an alternative
to Perl, Tcl, or say Python out of the
gate, vs. say Java / C++ / VB with a
primary focus on Internet programming ?
Regards,
Mike
-----Original Message-----
From: [EMAIL PROTECTED] <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED] <[EMAIL PROTECTED]>
Date: Wednesday, January 19, 2000 1:48 PM
Subject: [REBOL] Openletter to Rebol HQ. Re:(2)
>Hi jb,
>
>>I
>>agree with Robert: the priority should be on /Core, with /Command a
close
>>second.
>
>Shucks.
>
>>While /View sounds very interesting to me, it's relatively easy to
>>observe that most of the "interesting stuff" going on out there today
uses
>HTML
>>and Javascript etc. as its GUI toolkit (yeah, I know, ICK!) That's
not a
>value
>>judgement, it's just a fact.
>
>I have a big problem with this argument. Look:
>It's true that most of the "interesting stuff" going on out there today
>uses Perl. No reason to giving on providing something that's better,
namely
>REBOL.
>It's true that most of the "interesting stuff" going on out there today
>uses JavaScript (grmpf) or HTML (grmpf grmpf). No reaon to giving op on
>providing something better: REBOL/View.
>
>Another argument is that alot of what I have to do as a programmer
today is
>not limited to the Internet. Many things I work on have to do with
>integrating Internet resources with sophisticated client-side
>postprocessing. Therefore
>
>1. JavaScript and HTML don't cut it. I do not have the necessary
control
>over the user interface and the seamless interaction between user
interface
>and REBOL/Core scripts that I need. I have to use Tcl/Tk for GUI
purposes
>and - while Tcl/Tk for GUI in a Tcl only environment is useful,
interfacing
>Tcl/Tk with REBOL/Core is not as easy and seamless, as I imagine
REBOL/View
>will be.
>
>2. Therefore I can't wait to throw away Tcl/Tk and provide my users
with
>REBOL/View GUI interfaces to REBOL/Core scripts that roam the Internet
for
>them.
>
>>If our goal as a community is to make sure that
>>Rebol propagates as widely as possible, becomes entrenched as a
defacto
>>standard, and succeeds where others have failed, we should recognize
that
>Rebol
>>will succeed because it will be because it is an *Internet*
programming
>>language.
>
>Internet includes Graphical User Interfaces. Therefore when you point
out
>that REBOL should be Internet oriented, you have not excluded
REBOL/View.
>
>>Focusing on /Core, /Command, and platform reach (esp. to limited
>>devices) does more to further the cause than /View will in the short
term.
>
>In the short term? In the short term REBOL/View will got you a good
>percentage of the millions of programmers that are still using Visual
Basic
>or Delphi or Visual C++ (and Tcl/Tk, Perk/Tk ...) to implement Internet
>related applications, because they need the added capabilities of a
real
>GUI to interact with their users.
>
>>/Core and /Command solve significant problems for Web developers.
>
>How can you make an argument that /Command solves "significant"
problems
>for Web developers ... and at the same time ignore the need for /View?
If
>you are looking to make use of system resources that are not supported
by
>REBOL/Core, the systems GUI resources are an important subset!
>
>>/View on the
>>other hand, while it will be nice to have, is going to be just another
way to
>>build standalone GUIs, which isn't where the action is anyway. ;-)
>
>Standalone GUIs? Why STANDALONE GUIs? REBOL is about to introduce the
new
>GUI interface to the Internet and you are talking about STANDALONE?
>
>>
>>IMHO, of course, but based on having seen firsthand the miserable
failures
>and
>>limited successes of Tcl, Smalltalk, and Java at solving the portable
GUI
>>problem, and having become disenchanted with standalone apps in
general...
>
>Smalltalk?
>Ask yourself, how would Tcl and Java rank today if they did not support
GUIs?
>STANDALONE Apps? How about distributed, interconntect Apps with GUI
>abilities? BTW, what exactly do you mean by standlong apps? Is a Web
>browser a standalong app?
>
>;- Elan >> [: - )]
>
