On what makes it easy to do little languages.

Double plus agreement on the "little language" explaination.

Ruby "makes it easy" because you can override almost any primitive (even builtin types) to create the behavior that you want. Python doesn't allow you to override builtin types; you have to subclass them.

I've done several "little languages" in Ruby and although the primitive thing can help, the biggest aid in doing a little language in Ruby is its ability to control the execution of a block of code. I've used Ruby to define mini-languages to (1) control build processes ([link|http://rake.rubyforge.org|http://rake.rubyforge.org]), (2) define data base schemas, (3) define FSM state transitions ([link|http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-talk/118962|http://blade.nagaoka.../ruby-talk/118962]) and (4) build XML structures ([link|http://onestepback.org/index.cgi/Tech/Ruby/BuilderObjects.rdoc|http://onestepback.o...ilderObjects.rdoc]). In all cases it was the Ruby block that made the resulting mini-language natural and easy to use.

The builder example (#4 above) is particularly telling. The idea came from Groovy (another language that supports code block) and was insanely easy to implement in Ruby. I can imagine that doing it in Lisp would also be easy. But I've seen attempts to reproduce it in languages that don't support code blocks (e.g. Python at [link|http://users.binary.net/thehaas/cgi-haas/blosxom.cgi/comp/python/xmlbuilder.html|http://users.binary....n/xmlbuilder.html]) and the results have always been less than the original.

Python comes closest to that by having first-class functions (meaning, you can pass them around as objects). But Ruby's blocks are still miles ahead. Of course, LISP macros take the cake in that department. ;)

Something else I thought of in the shower: dynamic languages win in the little language department because they allow the developer to express a concept in the most appropriate syntax/semantics. For example, you're not stuck implementing go_around(person, community.get_block(13)). By dynamically adding/trapping attributes, and by overriding/subclassing builtins, you can write (Python examples):

go_around(person, community.block[13]), or even

go_around(person, community[13])

person.go_around(community[13])

blocks(13, person)

community.blocks.13.tour(person)

person.morning_walk += blocks[13]

...etc., any of which "does the same thing". This allows the designer to make a "little language" which is easier to use and extend. If you like TIMTOWTDI, you could implement them all simultaneously (but you probably shouldn't).

Welcome to IWETHEY!