What's Special About Lisp?

Ruby is a denser functional language than LISP. This is just not true! Sure sometimes you have syntax suger in Ruby that makes something smaller but othertimes you don't in lisp I can always make everything smaller with macros. I would bet that Ruby is not shorter for most programmes.

His hole argument is based around that in lisp you have wo write (lambda ....) and in Ruby you don't.

Ruby gives you about 80% of what you want from macros Ruby may give you some of the power but there is a lot you cant do in ruby and its much, much harder to do those things.

Ruby’s libraries, community, and momentum are good Thats nice but has nothing to do with being lisp.

Not saying anthing against ruby but this article is just very strange.

Making Python or Scala talk to Oracle (for example) is so trivial you can write that bit of your program in no time at all, then get onto the interesting stuff. In Lisp, you have to spend significant time on this trivial stuff. So if you are writing a program on your own PC for your own use, then Lisp is fine. If you are programming anything that is going to run on existing infrastructure or interoperate with other programs, it's very difficult to justify the additional effort of using Lisp.

And I know a bit about this: I wrote Oracle bindings for OCaml! It was fun, sure, but can I justify it when there are already Python bindings? Hmm.

  def COND(*args)
      args.each_slice(2){ |s| return s[1].call if s[0].call }
  end

  COND(lambda{ false }, lambda{ "not this"}, lambda{ true }, lambda{ "this" })

Secondly, Lisp macros are every bit as big a security risk as using eval... That is what the E in REPL stands for, after all. In both cases, if you are taking input from source code, and not from outside sources, there is no security risk.

Thirdly, yes, my example is messy. But it is still doable, and I just have a hard time believing that this kind of programming is a major percentage of the code of a Lisp program. To be clear on that comment, I can easily believe that you end up invoking macros a lot, but I don't believe that a large percentage of the code written for a project is actually macros. What percentage of code in a typical project is macros? And how many of those macros can be easily reproduced by using specialised syntax of a language such as ruby (optional parantheses, blocks, re-opening classes, method_missing, etc)?

This is an important point, because if you only have a few hundred lines of this stuff in a typical Lisp program, and it can be reproduced by using a parser in another (dynamic) language, then the advantage just isn't that big. For argument's sake, imagine having a module available in Javascript that provides the Jison parser along with the Javascript grammar, which just re-emits the original Javascript source. In addition, it has a nice API to allow you to modify the grammar (adding / modifying rules). So far so easy, this stuff already exists in CoffeeScript, go copy it from there. Now, having loaded such a module, is Lisp really in a much better position than this modified Javascript?

This. The ability to easily reason about the code and manipulate it because its syntax is simple and predictable is the big deal to me.

I think this is analog to switching from Roman to Arabic numerals. The syntax is regular. No matter how big the number is the rules are the same. There are no exceptions. Hence doing calculations with the former is a lot clumsier than with the latter.

That's the ideal scenario at least. I do realize that math might not be as simple as it could be, but I'm not really qualified to argue about that. But what if we were still using Roman numerals today? Would we be at the level of understanding we are at right now? It seems to me that it's more or less the same thing when you start understanding Lisp and why it is the way it is.

This is just too big of a tradeoff to be ignored. In my experience choosing the simple and regular solutions paves the way to progress, in which useful things that look trivial now would be rightly discarded or would be viewed as too complex if our mental model were grounded on the previous clumsy framework.

Now, I'm not saying "just drop all your clumsy languages right now, because today we have a better idea, and start using Lisp". I certainly don't do that. I don't even work with Lisp. But my point is that not realizing that Lisp has some properties that make it special is perhaps hindering yourself of being able to see that some things can be a lot simpler than you thought they could be.