Russell Turpin wrote:
[snip]
>
> So here's the question that has been tickling my dura mater: Is
> this really the right way to do things? In the previous century,
> the outside world, from a program's perspective, was varied and
> narrow. A Lisp program might not need to do much I/O, and what
> was needed depended on the kind of devices attached to the now-
> archaic computers. Best just to leave that to a library developed
> machine by machine. Today, programs run on the Internet.
> Communications is key. More, there is some stability. Relational
> databases, HTTP, and XML are not going away any time soon. The
> languages that are exciting today are the "glue" languages that
> best bridge that chasm, such as Python, where any piece of XML
> can be objectified instanter. But even these rely largely on
> modules and dynamicity to more closely integrate with the "world
> out there." Their core abstractions are still those that define
> an internal world. Is this really the right way to do things for
> the next two decades of software development? Is it time for a
> computer language that deals directly with the "world out there"?
> And how would we define such a language?
(Arguing, as devil's advocate, for the status quo, though I'm actually
quite intrigued by the idea...)
The distinction between inner and outer worlds is the distinction
between what's part of the language and what isn't. Things that are part
of the language fall under the control of the language's designers while
everything else is unconstrained (certainly from the language's PoV).
Perl regular expressions are part of the language -- HTTP is not. While
it's fair to assume that HTTP, XML and chums will be around for the
foreseeable you have also to allow for future developments, which means
you have to allow the language to be extended which, at the moment,
usually means libraries. From the language designers point of view a
mechanism for invoking library functionality is a way of putting the
whole of the rest of the world in a box marked 'Everything Else'.
I'm sure it's not what you have in mind, but recall that the Basic
interpreters that shipped with various 8 bit micros used to have
knowledge about their hardware environment built into them. For example
they'd might have commands for playing sounds that were specific to the
sound hardware of their host, and graphics commands that hard clipped
(i.e. raised errors if you transgressed) to the physical resolution of
the display. I'm assuming you're not advocating a return to those dark
days ;-)
-- Andy Armstrong, Tagish
This archive was generated by hypermail 2b29 : Sun May 06 2001 - 08:04:37 PDT