The Dylan Resource Guide

I started learning more about Dylan by reading the material listed in the Dylan Resource Guide in comp.lang.dylan. It is true what they say; Dylan and Scheme seem to be very similar. When you take into account what Dylan purports to offer, it sounds very interesting!

Here are some links from the resource guide:

  • #dylan on Freenode. Channel logs are supposed to be available here; but were not as of this posting.
  • comp.lang.dylan
  • The Dylan Language Reference Manual: The “DRM” defines the Dylan language and standard library.
  • Dylan Programming: Dylan Programming is a book that teaches how to program in Dylan.
  • Gwydion Dylan: Gwydion Dylan is an open source command-line compiler originally developed by Carnegie Melon University as part of their Gwydion project. It is available on several platforms.
  • Open Dylan: Open Dylan is an open source IDE originally developed by Harlequin and, later, Functional Objects. The IDE is available for Windows, and the compiler is available as a command-line program for other platforms.

3 thoughts on “The Dylan Resource Guide”

  1. I first discovered Dylan years ago, around when Functional Objects first release their IDE, and I loved the language right away. It was my first encounter with multimethods, and I couldn’t understand why this great concept had failed to work its way into more languages.

    If Apple hadn’t killed the Dylan project, I think it could have become a powerful force in programming, bringing the spirit of Common Lisp to the mainstream. But Functional Objects went out of business, and the Dylan community has dwindled. The Dylan language hasn’t evolved, which means it lacks things like comprehension syntax, which are now considered to be fairly fundamental in similar languages.

    Fortunately, Dylan’s LISP-y things like multimethods and macros, and its promise of dynamic behavior with improved performance from type hinting, live on in Clojure. So if you like what you see in Dylan, but are disappointed that the language doesn’t seem to be going anywhere, check out the new kid on the block. The main downside of Clojure relative to Dylan is that Clojure uses prefix/parentheses/Lisp-style syntax, whereas Dylan wrapped Lisp concepts in a more mainstream syntax. But if Lisp syntax doesn’t bother you, Clojure is the way to go.

  2. Hi Mark:

    One the most intriguing things about Dylan (in addition everything else you touched upon) is indeed that it is a non-infix Lisp. Big impact or small, how interesting it would have been to see how an extensible language would have been utilized by non-prefix-friendly programmers.

    I hadn’t looked closely at Clojure because I am not yet familiar with the problems that it solves. Consequently I was never quite sure of Clojure was more about providing a Lisp on the JVM that folks would then find “acceptable” or instead solving problems in prior Lisps. Of course ‘both’ could be an answer, too.

    Thanks for your thoughts.

  3. Yes, Clojure has both goals in mind.

    Clojure’s major billing points (runs on the JVM and software transactional memory) are the things I care about the least. For me, it’s about the ways that Clojure improves upon things that have always bugged me in Scheme/Lisp.

    The big bullet points for me are:

    1. Lots of built-in support for a versatile set of immutable data structures. Not just lists (and lazy lists), but vectors, hash tables, sets.
    2. The way all of these data structures share common interfaces. For example, you can use first/rest to write algorithms that are portable across all collections.
    3. The most versatile multimethod system I’ve seen.

Leave a Reply

Your email address will not be published. Required fields are marked *