Dylan Language

Dylan is an advanced, object-oriented, dynamic language which supports the RapidDevelopment of programs. When needed, the programmer can later optimize [his or her] programs for more efficient execution by supplying type information to the compiler. Nearly all entities in Dylan (including functions, classes, and basic data types such as integers) are first class objects. Additionally Dylan supports MultipleInheritance, PolyMorphism, MultipleDispatch, KeywordParameterPassing, object introspection, and many other advanced features which make programming a more productive and enjoyable experience.

Think CommonLisp with more mainstream syntax (closer to C, Pascal, Python, etc.), and a few warts removed, and you'll be close.

Two implementations of Dylan are currently being maintained (2001/09):



Apple's implementation of Dylan for the Mac OS was abandoned in 1995 soon after its first public release.

Other Dylan links:

The following are BrokenLinks.

Q: I have a question about Dylan's lack of MessagePassing. How do you deal with situations where you want to pass a message, such as distributed objects or any situation where objects are in a different computer, memory space, or thread? MessagePassing seems really good for this, so what do you do in Dylan?

A: Since MessagePassing is equivalent to SingleDispatch, and thus a subset of MultipleDispatch, there's nothing you can't do in Dylan that you can with a message-passing paradigm. And access to objects is using getters and setters exclusively. Calls to these functions can happen transparently over whatever lower-layer implementation. There exist implementations of CORBA, XmlRpc and DOM.

Someone else's comments seems to have disappeared--do you mean MessagePassing as in MessageBasedConcurrency? (a means of communication between two different processes), or MessagePassing as in what Smalltalkers call method calls?). SingleDispatch is equivalent to the latter; it certainly is not equivalent to the former.

I recently took a close look at Dylan, and was very impressed. Only two things keep me from trying to adopt it for ongoing work:

Other than that, I think the language designers made exactly the right choices: MultiMethods, a packaging scheme that is not based on classes, powerful integrated template/macro system, flexibility between early and late typing to facilitate tradeoffs between quick programming versus efficient compiled code.

Some very weak concerns: The lexical syntax could be a little simpler by omitting funky characters from identifiers, the use of angle brackets in predefined types is kind of annoying, and the unnecessarily long keywords make the language a bit more verbose than necessary. -- DanMuller

Even if I didn't want identifiers to contain funky characters, I'd allow that just to make everybody put spaces around their operators. I also like type names to look different (it's easier to talk about Gizmo or <gizmo> than gizmo), and I think <foo-bar> beats FooBar on a few points, like case sensitivity and extensibility (type names are capitalized, macro names in uppercase -- what about instance variables?).


EditText of this page (last edited February 15, 2012) or FindPage with title or text search