[bunderbunder]

Expressiveness can mean several subtly different things. The one I'm most interested in is, bringing the way things are expressed in the programming language as close as possible to the way you'd describe the process in a natural language. Any definition of "expressive" that permits code golf is not one I want to use. For "expressive" to be a useful concept, its opposite needs to be "unreadable."

[bunderbunder]

Just to pile onto that a little bit more - the Lisp family of languages is not unambiguously more expressive than other languages. I think that, when Lispers claim that Lisp is really expressive, what they really mean is that it has macros, and the supporting features that make macros work so well in Lisp.

The problem is, most dialects also have some horribly unexpressive things, too. Dynamic scope, cadadr, fifty bajillion words for "equals", stuff like that. My least favorite is that, in most Lisps, code and data look exactly the same. No M-expressions means that you can't reliably understand the basic structure of a blob of code by simply skimming. You've always got to be carefully reading it. Which gets exhausting if you're working in an unfamiliar codebase. Perhaps that's why Lispers have less of a tendency to travel in packs.

There's really just one Lisp dialect that gets to unironically wear an "I'm super-duper expressive!" t-shirt, in my book, and it's a young one: Clojure.

[lispm]

> the Lisp family of languages is not unambiguously more expressive than other languages

Common Lisp is a local maximum in language programmability (code as data, macros, programmable reader, EVAL, COMPILE, Meta-object Protocol, etc.).

> The problem is, most dialects also have some horribly unexpressive things, too. Dynamic scope, cadadr, fifty bajillion words for "equals", stuff like that.

The opposite is true. Common Lisp is its own code generation target - as such it has both low-level (blocks, go to, basic data structures, ...), mid-level (structures, streams, ...) and high-level (CLOS + MOP, macros, ...) programming constructs. Something like the additional dynamic scope expands the expressiveness of the language.

> No M-expressions means that you can't reliably understand the basic structure of a blob of code by simply skimming.

That's unrelated. You can easily read s-expression code as a human. It may only be unfamiliar to you - just like riding a bicycle is unfamiliar when you have never done it. Once you learn it, it's no issue.

   (defun foo (a)
     (+ a 10))

is no less readable than

   defun foo (a)
     a + 10

It's only a matter of a bit training. Humans are actually very good at adapting to different sign systems (think about the differences between English, Arabic and Japanese) - each speaker of the various language groups think that the other language is difficult and the own one is natural.

There is a bit of fear against Lisp code - this is partly justified, because of the extensible syntax - but that's unrelated ti s-expressions - one can have extensible syntax in M-expression based variants -> this creates the same problem of unlimited syntactic structures.

M-Expressions are not easier to reliably understand once you have macros in M-Expressions - which current versions of syntaxes similar to M-expressions actually support. See for example the RLISP of REDUCE.