Re: Dylan (was: ARC)

["Oliver Steele" <address@hidden>]

Drew Whitehouse <Drew.Whitehouse@anu.edu.au> writes:

> 1. Syntax!!!
>
> Syntax matters. Language designers are finally beginning to realize
> they are designing languages for people, rather than to impress the
> Gods. And that means syntax is *extremely important*. The first Dylan
> syntax was prefix/parens and hence was doomed to a cool reception, for
> reasons that will debated endlessly, but only a supreme optimist would
> think that the programmers of the world are about to have an infix
> epiphany any time soon (evidence - the success of Java). The second
> Dylan syntax was puzzling to say the least, who on earth wants all
> that begin/end verbiage. It was like the designers were trying to
> punish the unwashed masses who reject prefix/parens syntax, knowing
> that the Gods program with complex macros and (((...)))((()))()))).

I believe that Mike Kahl, who designed the infix syntax (and implemented the
parser and indenter for it), was trying to make it look like Pascal.  At the
time (1991?), that probably looked like a better bet than it does today in
the world of languages that have mostly converged on the use of punctuation
marks as punctuation.

I had actually implemented a more C-like (that is, braces) syntax for Dylan,
but dropped it when we hired Mike in order to work on the IDE (and therefore
can be blamed for the next, omitted, item in your list of "what went
wrong"s).

> So what could be done to make a new lisp that addresses these problems ?
>
> 1. Design *two* new syntaxes for Dylan. One for humans (simple,
> concise and clean). I suggest anyone who hasn't tried it to program in
> Python for a couple of weeks, then tell me that they still hate
> indentation syntax. See http://www.norvig.com/python-lisp.html for
> inspiration though use the new Python v2.2b2 from www.python.org
> (great new features and no serious stability problems) rather than the
> Java implemented Jython. Then a second syntax that is prefix s-expr
> based and is a straightforward transformation from the infix, so straight
> forward that a human, an emacs lisp function, a compiler, can
> convert/write/read between them interchangeably. Don't like reading
> s-exprs, just C-x C-E the expression in your favorite editor and you
> infix syntx, perfectly indented :-) This allows for a macro system to
> be s-expr based which I think people think is generally easier to both
> implement and write for ?

I can tell you why we dropped the idea of supporting two syntaxes from the
Apple Dylan project.  It was because (1) it would have been almost twice as
much work to design, implement, test, and document two syntaxes (and their
parsers and indenters) at product quality, and (2) we feared that having a
fragmented user community, and halving the number of tutorials and textbooks
available to either dialect (or doing worse to one of the dialects) would
push the number of Dylan users and support materials below the critical mass
that it never ended up reaching anyway.

There's still something to (1), but less so now that machines are so fast
and resource-laden and programs are so much easier to write.  I think (2) is
just as much an issue as ever.

Of course we'd all like a system that let each of us view everything in our
favorite syntax, but I'm convinced that Apple Dylan sank because the
development team tried to cram all our favorite features into it (mine had
to do with the IDE) --- is syntax switching a feature that should be a
prerequisite to the success of a Dylan (or ARC) revival?

> 2. Make it easy to use, simple REPL and a build/module system that
> stays out of your face until you need or want it.

Yes.  At the time we thought we needed to compete with Think C and other
emerging Windows/MacOS development environments.  (We also thought we needed
to rival C's efficiency; this took some IDE smarts to minimize
excruciatingly slow recompilations.)  But the majority of UN*X programmers
never used such environments, and none of the languages introduced
subsequent to Dylan has been accompanied by much in the way of an IDE, so
it's obviously not necessary.

> 3. Make libraries part of the standard distribution. They should be
> powerful and well written. A language without a decent set of powerful
> stable libraries is not complete. So sockets aren't a part of the
> language but they are part of the standard libraries in the
> distribution. If you've developed a readable syntax the libraries
> source code will be better for learning how to program well in ARC
> than a truck load of "ARC in 24 hours", "ARC for Idiots", "Patterns to
> circumvent the hairy non-dynamic nature of ARC and make it approximate
> lisp" books.

Better, I think, is to make use of libraries written in other languages.
.NET/Mono is a path to this; Minotaur and the various Python/Java
interoperability libraries (which support cross-language calls, exceptions,
and subclassing --- as David Moon planned to eventually do for the Apple
Cambridge languages and implementations and C++) are some language-specific
success stories.

Common Lisp has been playing (and losing) the catch-up game with writing its
own libraries for a long time now.  There's a certain level below which the
increased productivity of the user community can't compensate for the
zillions of Java or Perl programmers out there, and there comes a point
where it makes sense, for many tasks, to use a worse programming language if
it comes with better libraries.

That said, a language+implementation can make it easy to use libraries,
through language-level facilities such as support for
namespaces/packages/modules, through library or environment support for
creating, publishing, downloading, and installing distributions, and through
community support for software repositories.  Various languages have already
done this to varying degrees.

> I know there are Dylan developers on this list, what do you think ?

An interesting exercise.  But I wonder whether the assets of Dylan could be
handed back to Scheme in a way that would satisfy users of both
languages --- not by merging the languages, but by factoring the non-Scheme
features of Dylan into libraries that would jointly define an embedded Dylan
but could be used separately too, along the lines of Olin Shivers'
awk-in-Scheme talk.  It seems a shame to maintain duplication of effort in
such similar languages.

-- Oliver "I'm a uniter, not a divider" Steele