|
Scott E. Fahlman
|
A programming language can be thought of as
- a kind of universal glue for sticking things together,
- plus a set of basic built-in data types
(and, in some cases, a way to extend this set),
- plus some built-in operations for working on those datatypes.
In some languages you can't see this structure because everything
is hopelessly muddled together, but it's there at some level. The
more general and flexible you make the basic glue and data types,
the fewer awful kludges you have to add in later.
In Dylan
In Dylan the object-oriented function call is the basic piece of
semantic glue, supported by
- the class inheritance machinery,
- the module system,
- the condition system, and
- the basic built-in control structures.
Dylan's function call has a few complex things built in from the start
- multiple inheritance,
- multiple arg dispatch,
- keyword args,
- multiple-value returns
but that's because experience has shown that these are very useful
for writing clear, efficient code. It's better to put them in now than
have to graft them on in some ugly and poorly integrated way later.
Even with all these things, you have a single central mechanism that
is reasonably simple and elegant -- a very small part of the total
language.
On top of that, you've got the built-in datatypes. In an object-
oriented language, you only need a few well thought-out fundamental
types: vectors, characters, a few types of numbers, and so on.
Everything else can be added in a clean simple way using the object
system. It's relatively easy to break chunks of the language off into
libraries, because the library can define both new classes and new
methods to work on them. You don't have to decide in advance
whether the + operator should be overloaded to support vector
arithmetic, for example, because a library can define both the
necessary classes and the methods that extend the arithmetic
operations to cover these.
[...]
Dylan's syntax is more complex than Common Lisp's, but that's
because Dylan's designers thought it would make Dylan easier to
learn and more familiar to programmers who have worked in other
programming languages or who are already comfortable with infix
notation for arithmetic.
Dylan's macro system will be more complex than Common Lisp's,
but the goal is to make it easier and safer for average programmers
to do simple things. Lisp macros are very elegant and powerful, but
often require very deep thinking on the part of the programmer to
keep all the levels straight and make everything work reliably.
|
