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 >> [: - )]
