> 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.
>
Hmm, here's the problem I've got with this. Rebol is a fantastic language, and
makes many of the kinds of programming tasks one faces (esp. in Web development) a
whole lot easier. Rebol can either be positioned primarily as an adjunct to the
Web --- a valuable addition to the Web developer's toolkit --- or as an
alternative to it. We can either co-opt the trend, or try to buck it. I know
lots of folks that are somewhat pained by the constraints of the Web as a UI
medium, but IMHO from a success / strategy standpoint, it seems redundant at best
/ foolish at worst to focus on providing an alternative to the Web. "Something
better" doesn't necessarily imply good survival characteristics.
>From an adoption standpoint, it's going to be a lot easier to get scripters to
throw Rebol into their toolkit for backend scripting than it is to get developers
to write custom UIs that users then have to DL and run outside of the browser.
(Fact: between 80% and 90% of all new PC purchasers never purchase / download /
install another nonbundled software title or application on their new machine
beyond games and educational / other multimedia.)
>
> Another argument is that alot of what I have to do as a programmer today is
> not limited to the Internet.
While I certainly can't dispute your own experience here, let me just point out
that this is probably an "edge" case. The mainstream trend is and continues to be
in the direction of browser-based UIs, with server-hosted app logic. The browser
has become the universal UI engine for several very good reasons.
But I'm not arguing against /View in general; I'm just trying to make the case
for other functionality (ability to launch external apps, database connectivity,
platform reach, etc.) as being more important for a very important, more
mainstream majority of programmers in Rebol's target audience.
> 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!
>
Not, IMHO, for most Web application developers.
> Standalone GUIs? Why STANDALONE GUIs? REBOL is about to introduce the new
> GUI interface to the Internet and you are talking about STANDALONE?
>
My, sorry, I seem to have hit a nerve. By "standalone" I mean that each Rebol app
is something relatively independent, which will have to be downloaded / installed
/ configured separately. The only way around that is to build some kind of
browser-like "bootstrap app," and then you're reinventing key pieces of Web
infrastructure. Why waste the effort? 80/20 rule.
> Smalltalk?
> Ask yourself, how would Tcl and Java rank today if they did not support GUIs?
As for Tcl, I *hope* we're not striving for the rather underwhelming level of
popularity it has. As for Java, I'd argue (based on having started one of the
first Java software shops back in 1995, having used it since it was called Oak,
having worked at Sun, and having built --- yes --- a standalone client application
in Java) that Java would've been better off if Sun had *entirely ignored* the UI
problem and made Java the best backend Web development language it could have.
There are painfully few examples of successful standalone Java applications ---
and there's a good reason for that. Believe me, one of the biggest problems we
faced at Activerse --- one of the worst decisions I made as its CTO --- was the
use of Java in a "standalone" client application that people had to download and
install.
>
> 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?
See above. Again, I didn't mean to imply nondistributed, noncommunicating
application by "standalone." Yes, the browser is a standalone app --- and it's
one of the few standalone apps that most consumers are motivated enough to
"manage."
I've got one major concern here... I've spent a large amount of my career picking
at technology that, while excellent technically, didn't focus on the things that
would make it most survivable / successful in the market: NeXTStep / Objective C,
NewtonScript, Magic Cap, and client-side Java to name a few. Based on those
experiences, I've pretty much decided not to take "flyers" on tech that's not
firmly grounded in reality. Frankly, this uncertainty is the primary reason I sat
out most of this year -wrt- Rebol, taking a "wait and see" approach. I like Rebol
a whole lot --- it comes very close to languages I've imagined as being "ideal."
I'd like to see it win; I'd like it to be the "last" language I have to invest my
heart, soul, and time in. (I'd rather focus on the apps than the tools, but if
the tools keep obsoleting themselves I can't do that very effectively.) If it's
going to win, decisions about things like this are going to have to be made with a
hard eye on the market. There's going to be some hard calls. Sure, the Web's
ugly --- but inertia, history, and the 80/20 rule suggest that that game has
already been won. We should hitch ourselves to that wagon. And doggone it, we
need database connectivity more than we need a GUI widget toolkit in order to do
that.
$0.02,
jb
>
>
> ;- Elan >> [: - )]
