gumby@mit-eddie.UUCP (David Vinayak Wallace) (12/18/83)
Date: Wed, 7-Dec-83 12:29:26 EST
From: kurt@fluke.UUCP (Kurt Guntheroth)
I was a little concerned to sport my ignorance of what an 'actor'
language is. Now (having heard another braver than I profess their
ignorance) I think I know. Actor languages are what we used to call
object oriented languages, right? Like Smalltalk?
Essentially.
Well... There is not all that much difference between languages like
CLU and languages like Smalltalk. Sure CLU tries to do most of its work
at compile time and Smalltalk does everything at run time (so far). But
the way you write programs in CLU and Smalltalk is similar. Look at
Simula, the grandaddy of object oriented languages, and the language
from which they all descend; Simula did all the type checking it could
at compile time, but knew when to do run time type checking too. Isn't
this the best of both worlds? Why not tell the language enough so it
can do compile type checking when this is possible, and provide
facilities at run time to take care of all other situations?
There is a huge difference between the actor model and an applicative
language. You should read some of Hewitt's early papers on actor
languages. The main difference is the programmer's computational model.
The actors recieve and dispatch on messages at runtime. They aren't
constrained to be on the same processor, or even to share address space;
all they have to do is send and recieve messages. So actor programs
more easily adapt to (for instance) dataflow architectures.
But anyway, a CLU cluster isn't a first-class object; it's a compiler
contruct. There's no way for a language that claims to be "statically"
typed to allow any sort of extensibility or threading of code, for there
would be no way for the compiler to enforce type-checking. Part of the
beauty of languages like LISP is the ability to dynamically extend the
language. Why should the addition of a new numerical type force a
rewrite of the FACTORIAL function?
And let us burn at the stake all programmers who complain about strong
typing because it slows them down by making them type more words and
correct more errors detected by the compiler. Who wants to maintain
code written by these people anyway.
So I doubt this is really the reason people don't want strong
compile-time checking; it's just that it interferes with the
programmer's model of what's going on. In FORTRAN you don't mind the
compiler type-check because the language definition is so weak. But
when you have varibles that can hold any of a number of arbitrary
typed-objects, do you want to do through the hair of exhaustively
defining a huge union type for this one case (assuming, of course, that
your language is smart enough to handle this case)? The compiler should
be doing all the hard work; that's what it's there for. Certainly,
untyped code isn't necessarily unclear; I've read thousands of lines of
code which prove that fact.
Anyway, if you're going to burn them, at least heat the buildings with
them!
david wallace, MIT AI lab.
PS: a good introduction to actor languages is Carl Hewitt's "Actors and
Continuous Functionals."