I do love ruby and feel that it's metaprogramming techniques to allow you to easily emulated many features of Lisp's macros. That said the author missing an ob

I do love ruby and feel that it's metaprogramming techniques to allow you to easily emulated many features of Lisp's macros. That said the author missing an obvious thing here. They key with macros is that they allow you to alter syntax (not calculate values as many who try initially misunderstand them), and s-exps are essential to being able to do this (because they are effectively an abstract syntax tree). I say this is obvious because the example itself demonstrates this. The lisp code in the end looks very much like the ruby. Being able to extend syntax means that if you like ruby you can make your lisp work more like it. Now try to reverse this example, make a ruby library that emulates a lisp style, I think you'd find it much more difficult, and expensive. The other important thing to not forget is that this syntax transformation happens at compile time. One of the reasons that Ruby has a reputation for being slow is it has to keep track of a lot of metadata and all sorts of look-ups to do a lot of the metaprogramming (which is why people should make better use of it, you've already paid for it). In Common Lisp all this transformation is free during runtime. Think of a common issue with JavaScript: no implicit return. If Lisp did not have implicit return you could define a macro 'defr' which allowed you to define functions like you normally do, but always know they return a value. Instead you need to use CoffeeScript. Finally people do still write plenty of Common Lisp, they're just a smaller community. Not long ago I wrote myself a very practical tool to process a specific file format, with it's own mini-dsl, an order of magnitude faster than similar libraries (albeit with intentionally less functionality) and all in 200 lines of Common Lisp.