Short summary: As a user, I'd rather see REBOL development resources
focused on higher-level tasks (protocols, reflective programming, and
documentation, for examples) than lower-level tasks (platform-specific
and low-level hardware control). Given that one can't do everything at
once, I believe that there's more bang for the buck at the top of the
stacks.
[EMAIL PROTECTED] wrote:
>
> TCP/IP is only one form of messaging, squirting data down the serial
> port is just as valid.
>
I've always understood "messaging" to imply "communicating between
peer systems" as opposed to "peripheral control". Having said that,
I believe those two are simply opposite ends of a continuous spectrum
instead of being binary states.
>
> Raw I/O is someting that any system should have almost from day one.
>
Why? [not to be argumentative, but just to understand] REBOL (along
with most languages I use) presents the programmer with mass-storage
capabilities cast in terms of files, not in terms of "raw" disk I/O.
I think that's a good thing!
C gives me the ability (with suitable authority over the system!) to
drop down and twiddle individual bits in a packet header, but REBOL
allows me to use standard protocols without even having to know that
such a thing as a "packet" exists. I think that's a good thing!
>
> My other point was that Robol seems to be forging ahead with all sorts
> of wizz bang features, but with very little being done on the basics
> (or so it seems)
>
I'd suggest that the issue here is levels of abstraction. In my
experience, languages (or language designers) that try to live at too
many levels of abstraction at once end up doing one (or more) of the
following Bad Things:
1) Failing to do so (ever try to write a compiler in COBOL?, remember
all the attempts to extend Pascal into "systems programming"?),
2) Complicating the language syntax unreasonably (remember PL/1?),
3) Bloating the extensions or class libraries (how many GUI toolkit
libraries have there been? how many classes are in the Java
"standard library" this week? how about CPAN?)
4) Becoming too biased toward one environment (remember ClasCal,
Burroughs SDL, Lisp Machine Lisp, BLISS, etc.?)
I suggest that "the basics" are relative to what one is trying to do.
The basics for creating client-server information networks are very
different from the basics of real-time process control (for example).
Given the number of companies making embedded systems with TCP/IP (or
even web servers) built in, it won't be long before the simplest way
to do device control is to buy a little box for $50 to $200 that does
the low-level, device-specific stuff out one side, and talks to a
TCP/IP network out the other. The controller code would be written in
whatever the embedded folks support, and all of the rest (control,
multiple read-only clients, etc.) could be written in a TCP/IP-aware
language (e.g., REBOL!) to produce a platform independent "manager"
application which controls and coordinates multiple devices via the
exchange of messages in standard protocols.
Not to sound (too much ;-) like a curmudgeon, but after 25+ years in
the computing field, I've abandoned the notion of a "one size fits all"
language in favor of smaller, cleaner, manageable languages, each of
which "does one thing, but does it exceeding well".
-jn-
