Mon Mar 24 13:45:31 CET 2003
[some random thoughts, triggered by your message:-]
> I have been thinking mainly about processes, streams and
> how they fit together. User input arrives from the Universal
> Serial Bus nowadays, so it is expected to be a stream of
> actions. Monitors are also a serial device, but they use
> 2 dimensions to allow random access of data more easily.
> Why not view the UI as a pool of data that is streamed out?
Functional languages, especially non-strict ones, have had a long
history of using networks of mutually recursive stream processors to
model operating systems, IO and GUIs. It kind of worked, but never
seemed to be a satisfactory solution, and functional IO approaches
have moved on to focus on more modular compositions of single
message/activation/response-structures instead of whole streams. But
that's probably what you mean anyway.
were a fairly recent functional GUI approach based on
stream-processors, so their publications should have references to
most earlier approaches. (for the general process/stream-model,
dataflow languages and Petri nets may be useful search keywords).
Btw: I've often thought that high-level Petri nets (with functional
inscription languages) would make a good modeling language for
functional programs, especially when concurrency is so central as
it is in Erlang. Is there anyone out here who's using both Erlang
and Petri nets? Or at least knows about Petri nets and thinks this
combination would have some merit?-)
[for those who haven't come accross Petri nets, see:
> My biggest problem with OO and applications is that they
> rigidly impose _one_ interpretation and force the user to
> deal with that model. As a user I would rather restructure
> my display based on the tasks I need to accomplish, not
> based on the applications that I have installed. If the computer
> is a general-purpose machine why are the programs not
OO is perhaps not as bad as some of its fans make it seem:
"The early history of Smalltalk", Alan C Kay (in: History of
Programming Languages II, 1996)
"..[dynabook vs mainframe].. ; millions of potential users meant that
the user interface would have to become a learning environment along
the lines of Montessori and Bruner; and needs for large scope, reduction
in complexity, and end-user literacy would require that data and
control structures be done away with in favor of a more biological
scheme of protected universal cells interacting only through
messages that could mimic any desired behavior. Early Smalltalk was
the first complete realization of these new points of view as
parented by its many predecessors in hardware, language and user
"Smalltalk's design -and existence- is due to the insight that
everything we can describe can be represented by the recursive
composition of a single kind of behavioural building block that
hides its combination of state and process inside itself and can be
dealt with only through the exchange of messages."
"In computer terms, Smalltalk is a recursion on the notion of
computer itself. Instead of dividing 'computer stuff' into things
each less than the whole -such as data structures, procedures, and
functions that are the usual paraphernalia of programming languages-
each Smalltalk object is a recursion of the entire posssibilities of
the computer. Thus its semantics are a bit like having thousands and
thousands of computers all hooked together by a very fast network."
Sounds pretty general-purpose (and concurrent) to me.
"I made up the term 'object-oriented', and I can tell you I didn't
have C++ in mind" - Alan Kay, OOPSLA '97
Was he thinking of Erlang instead?-) Well, almost. But Smalltalk
also addressed what I call the "applications considered harmful"
aspect, which your messages also seem to refer to: in Smalltalk, you
didn't take a programming language and implemented lots of
stand-alone applications, to be shipped to customers in isolation;
instead, you evolved and extended your favourite general-purpose
programming environment to be able to express the things you wanted
to say in your favourite problem domains.
Another way I like to phrase it: users are not dummies, they are
domain experts (though their domain is usually not computers or
software); they don't want computer experts to give them lots of
words (applications), they need a tailor-made language in which they
can express their domain knowledge to tackle their daily problems.
Hope that wasn't too far off topic,
More information about the erlang-questions