[Prev][Next][Index][Thread]

Re: A question

Followups set to comp.lang.dylan only, since I don't think this 
is of general interest to Smalltalkers.

Stephen J. Guthrie <steve.guthrie@mantissa.com> wrote:
>
> I purchased the Dylan Professional from Harlequin about a year ago and
> stopped using it entirely after the recent events with FO.  I'm 
> considering picking the language back up but I would like an objective 
> evaluation as to why I should.

This is always tough to do without starting a flame war. I'll try to
stick to measurable, obvious language features -- and also bear in
mind that I think Smalltalk is a fine language to program in!
 
> I recently began programming in Squeak (Smalltalk).  Give me a reason 
> to come back to Dylan.

Here are the reasons I like Dylan more than Smalltalk:

o Multiple dispatch and generic functions.

  This is hugely helpful in writing well-structured programs. Whole
  categories of problematic areas in OO magically disappear. Now that
  I have it I can't imagine living without it; only pattern-matching
  from the strongly-typed FPLs is of comparable power.

o Better support for the functional style. 

  Much of Dylan is basically Scheme blessed by the magic infix-syntax
  fairy. This means that you don't have to fight the language whenever
  the natural solution to a problem is functional. With respect to
  Squeak in particular, I don't think its blocks are true closures
  yet. (That's due to be added in the next few months, I think?)
  But in any event it's annoying to write programs that express
  themselves naturally as a set of nested functions in ST, or as
  higher-order functions. 

  Of particular note is the interaction of generic functions and
  higher-order functions: it's very powerful. A simple example might
  be sorting a list of objects of varying types; this works far more
  elegantly in Dylan than in ST, since Dylan can take a generic
  function as an order test, where ST must use a regular block.

  (Try sorting a list of strings, integers, and lists of strings
  and integers to see what I mean.)

o Optional type annotations.

  When I'm writing quick prototype code, I can use dynamic typing,
  *and* I can add type annotations as needed to help document the
  code for myself. The additional speed that the compiler can extract
  from these annotations doesn't hurt either.

o The hygienic macro system.

  As a small project, I tried adding lazy evaluation to Dylan. It took
  me 15 lines of code to write something that was as much part of the
  language as the if statement or the for-loop. (That was a project
  that finished a lot sooner than I expected!) The ability to extend 
  a languge's syntactic constructs as needed is surprisingly useful.


Neel
Follow-Ups: References: