Item — HN Reader

> What does Dylan do?

I'm totally unfair here, because I really don't know much about Dylan, but my view maybe explains a bit why Dylan does not even "win" with people like me, who really like those strange languages like Lisp or ML.

To me, Dylan was never about creating something new and great. It was taking Common Lisp and "fixing" its syntax.

Unfortunately, I can't stand Lisp without prefix notation and lots of parentheses. And people who hate prefix notation and lots of parentheses aren't interested too much in Common Lisp.

The resulting set of people interested in Dylan was... well, I've heard of Bruce. Andreas Bogk was doing some heavy advocacy in Germany, to the point where people just didn't want to listen anymore.

Let's say about ten people in the world cared. And I just don't see how that set could grow by orders of magnitude.

2 comments

Dylan started out with a prefix syntax; the infix syntax was added on late in its development at Apple, because it was believed the market wasn't willing to adopt a prefix-syntaxed language. Turns out it didn't matter very much.

Dylan also standardized and simplified a lot of the dark, twisty corners of Common Lisp. Generic functions became a core part of the language, rather than something bolted on by ad-hoc macro packages. The collections API was unified to use generic functions (so no more mapc/mapcar/mapcan/mapl/maplist/mapcon mess), and the language syntax's infix operators were all defined in terms of generic functions as well, so you could eg. define a matrix type and have + and * work on it as expected. The superclass linearization was fixed to be monotonic. Macros are hygienic. It's a Lisp-1, and everything in the language is an object bound to a name.

Honestly, I think its lack of success came down to a Worse-is-Better problem. Dylan is a really nice language, designed by a committee with a combined total of over 2 centuries of Common Lisp experience. But it doesn't excel in any one domain. It's a large language, fairly complicated, which tried to mainstream a number of features with complex interactions and limited applicability. To an outsider, who doesn't understand those features or how they might be useful, it's too hard to pick up in a weekend. And so simpler languages like Scheme, Go, Python, or Erlang steal its thunder - they lack the total power of Dylan, but you can point to Scheme and say "Small composable building blocks", or Go and "Fast concurrency with quick, simple deployment", or Python and "Prototype anything, with batteries included", or Erlang and "Reliable message-passing concurrency." If you point to Dylan and try to describe it in one sentence, you get "Generic functions all the way down", which means nothing to the average programmer.

It's much the same problem that Scala faces, except that Scala features JVM interop and so Scala advocates can say "Tomorrow's language features with yesterday's Java code."

Dylan was not designed for Lisp, Scheme or Smalltalk users. It took ideas from there, but it was developed as a replacement for C, C++ for application development. If Apple had actually used it, stuff like Keynote, Logic, iPhoto, iTunes, Xcode, ... would have been written an Dylan.

Apple used Objective-C for that then.