The above post is almost 14 or 15 years old and that time there was no Clojure, Scala or Elixir.
So how strong(er) or weak(er) Clojure or Elixir are comparing to common LISP?

LISP is well-liked language for a variety of reasons. Certainly Macros play a role in that because it makes it practical to write Domain Specific Languages that are homoiconic with the language itself. Elixir’s macro structure can be used for similar reasons and if you get into Elixir macros you will find that the language is structured from homoiconic three-element tuples that one could potentially write in just like LISP.

In either case you have a turing complete language that offers you the ability to write useful programs. Elixir, and more specifically the underlying runtime system, has some built-in mechanisms directly supportive of concurrency and parallelism that makes it convenient to use when solving problems that involve those topics. One can (and Robert Virding has LFE (programming language) - Wikipedia written a LISP language on top of that runtime.

In short it depends on how you define “stronger”. Stronger at solving a set of problems involving concurrency and parallelism? I might give Elixir the edge there. But trying to compare programming languages rarely produces cut and dried results.

And more importantly, will learning common LIPS [sic] make someone a better Clojure or a better Elixir programmer?

Learning another programming language will usually make one a better programmer. One of the things I did which I personally felt enriched by was following the MIT Open courseware videos on the Structure and Interpretation of Computer Programs. It uses a LISP variant (Scheme in this case) to present some fundamental concepts of the theory of computation. Having those ideas in my head has allowed me to approach problems in new ways, regardless of programming language, and that has made me a better programmer. Swift and Scala gave me similar insights about types and type systems. Common patterns one finds in Objective-C thought me about Delegation and dynamic dispatch systems. Each language, and each environment, can teach you something if you let it. So “Yes” I believe that studying Common Lisp and Clojure could help you be a better Elixir programmer.

Heh, I remember an interview with Andrei Alexandrescu (C++ meta-programming wizard) who said that he’d learned valuable things from every programming language he’d ever used. Except Java, that there was absolutely nothing new or insightful to learn there…

I’ve also written a Lisp on top of elixir, lisp is dead-simple to create. But how about this for an example of it’s power:

First, Elixir has an AST, you cannot create or invent new forms, you can only make function-like things and parse already ‘formed’ expressions within those calls. Second, in Elixir you can parse a string at compile time (which is what I do with my elixir lisp), but the string is delimited, thankfully Elixir has a way around it by using things like ~L{lispy code} or so, but if you end up using } anywhere in the string then it dies, same regardless of the identifiers you use.

In comparison, I’ll use my elixir lisp as an example since it is more Elixir’y than normal lisp, there is no real form, there are just lists and symbols. A list is delimited by (/) (unless escaped via \), and everything else is a symbol, separated by whitespace (again, unless escaped). So if you want to define a number just doing 42 will not work, you’ve gotta do (integer 42) for example, or (atom blah) or (list a (integer 42) (float 6.28)) or (string This\ is\ a\ string), nasty painful and such. So you can simplify some things via macro’s, so like the above list one you could write a macro so you could just do something like (mymacro blah 42 6.28) and it expands it to the above list. However that is just like defining new functions, just like you can do in elixir, it is not really making new syntax, for that you need read-macro’s, which my lisp also supports in spades. I have a few built-in read-macro’s, like one triggers on : at the start of an expression, it then parses the next symbol (or fails if a list) and just wraps it in the (atom ...) list. I have one that reads based on " and reads characters until it hits an unescaped " (it supports a few other escapes as well) then just wraps that all up as a (string ...) as a single symbol. I have one that starts with a [ and reads sexpr’s until it hits a matching unescaped ] (since it reads sexpr’s it recurses back into the parser so you can have embedded [ no problem as one example) and wraps that up in the (list ...). And one that reads a { and is like list but wraps it up in (tuple ...). And one for %{ that wraps it up in a (map ...). I could actually quite easily (and it is planned) to make some kind of elixir read-macro that then passes the stream to the elixir parser to get the elixir ast back (essentially an elixir quote). The ‘magic’ of Lisp is that you can make domain specific languages for any problem you could possibly ever experience, able to add any functionality that any other language has or could ever have, and thanks to it’s macros and read-macro’s both then it can be as succinct and readable (even parenthesis-less if you really want) as you can imagine. You can embed Elixir in lisp, or python in lisp, and it all just compiles down to lisp.

Lisp itself is not so much a language to write programs in, but rather it is a language to write languages in which to write programs.

And yes, Lisp is one of those languages you should definitely learn and keep learning until you finally get that *click* moment when everything becomes clear about why it is used, and I’m not just talking about treating code as data and data as code, I mean the way you can define any problem in it in a way that is natural to that problem.