> >
> > 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!
Conversly I would say that it's a very bad thing. There is no such
thing as a 'standard' protocol, there are protocols that have been
standardised, but you need the I/O access to be able to interface to
other devices.
There is no excuse for not providing such access, it's simple to do
and opens up a whole world of control applicatons.l
>
> 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:
>
I don't think this is an issue here, the language is ok, even if it
does seem to be getting rather complex to use. What we are talking
about is the ability to access common devices, (Rebol can't even
access a simple printer!) The commands are already boult into the
language /port etc but it just does not work.
> 1) Failing to do so (ever try to write a compiler in COBOL?,
remember
> all the attempts to extend Pascal into "systems programming"?),
Well Pascall was never intended to be anything other than a teaching
language so it's hardly surprising that it fell flat on it's face.
How many attempts has NW had at producing a workable language now?
must be about 5 or 6 to date :-)
> 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?)
Doess not matter, providing libraries don't mess with the core you can
choose not to use them.
> 4) Becoming too biased toward one environment (remember ClasCal,
> Burroughs SDL, Lisp Machine Lisp, BLISS, etc.?)
More of a sign of the times rather than a bias, most platforms were
custom designed and ended up with custom code to suit.
>
> I suggest that "the basics" are relative to what one is trying to
do.
The basics are always down at the hardware level, that's the
foundation that everything is built up from, rebol is sitting well
above that level, and makes use of the system resources, with the
execption of a couple of very common resources - the I/O ports
> The basics for creating client-server information networks are very
> different from the basics of real-time process control (for
example).
>
Not really, it's all about chucking data backwards and forwards, there
is no difference in creating a SQL query, directing it at a database
and getting a result back, than creating a command message directing
it at a control device and getting a response message back. It's the
same process, just a different application.
> 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.
So you have a a TCP/IP stack that fits into a 1000 byte space on a
PIC microcontrollerand still leaves enough space to control the device
- I think not.
(Also why pay $ 50-200 when you can do the job for 1$)
However you can write a very comprehensive messaging sytem in that
space and still have plenty of room for the actual control functions.
You just need something to sent it messages via.
>language in favor of smaller, cleaner, manageable languages, each of
> which "does one thing, but does it exceeding well".
Good I'm glad you agree with me, in that we should forget all this TCP
rubbish and provide the facilties that will enable rebol to do real
work :-)
seriously, rebol does one thing very well, and that is messaging, what
it does not do is provide the enviroment where you can use that
ability effectivly via external devices.
Andy
