This post originated from an RSS feed registered with Java Buzz by Bill de hÓra. Original Post: Language Commitment Feed Title: Bill de hÓra Feed URL: http://www.dehora.net/journal/atom.xml Feed Description: FD85 1117 1888 1681 7689 B5DF E696 885C 20D8 21F8 Latest Java Buzz Posts Latest Java Buzz Posts by Bill de hÓra Latest Posts From Bill de hÓra

Hugh Winkler: "S-expressions give Lisp powerful ways to build code in code. But writing programs using S-expressions seems cumbersome compared to Ruby's syntax. The syntax of Ruby shortens the code you have to write to do everyday tasks. It's like a domain specific language for, er, writing computer programs."

Here's Hugh's example in Python:

PEOPLE = [{'first':'scott', 'last':'guthrie', 'age':32},
              {'first':'susanne', 'last':'guthrie', 'age':32},
              {'first':'bill', 'last':'gates', 'age':50}]

def avg_age(lastname):
  people = [person for person in PEOPLE if person['last'] is lastname ]
  return sum([person['age'] for person in people]) / len(people)

Perfectly readable? Yes, if you know enough Python. And as much can be said for Hugh's Lisp/Ruby examples. For what it's worth, I don't think the Python, Lisp or Ruby examples are essentially more readable than the other. In terms of pure technical elegance, Lisp wins because it's has the more internally consistent syntax - which is arguably what marks out Lisp as being the most 'different' for these kinds of small examples. All those parens stop becoming a negative when you want to manipulate the language itself in a deeper way than either Ruby's open classes or Python metaclass hacking. [But if that was the main criterion, we'd all be using Lisp, and Ruby/Python would never have been invented.]

Here's Peter Norvig on Python: "Python can be seen as a dialect of Lisp with "traditional" syntax (what Lisp people call "infix" or "m-lisp" syntax). One message on comp.lang.python said "I never understood why LISP was a good idea until I started playing with python." Python supports all of Lisp's essential features except macros, and you don't miss macros all that much because it does have eval, and operator overloading, and regular expression parsing, so you can create custom languages that way."

I suspect DSLs, or what used to be called little languages, are a red-herring. DSLs are not a language commitment. I'd be inclined to look at what's fundamentally different and interesting with Ruby, be they transient issues such as the runtimes, unicode, decent libraries, and IDE support, or essential issues such as blocks, optional functional call parens, and open classes. Those are the things that are going to sway you to the language or away from it insofar as you're going to be committed to dealing with them.