[enduser]

CL allows us to write code the way we think about a problem--and then bring life to that way of framing the problem. We can come up with an ideal way of describing a solution and then make a language work that way. I say a language because the target of our code might be C or JavaScript (these days that is more often the case for me than targeting CL itself, cf. 4500 recent lines of Lisp that turns into 8000 lines of terse JavaScript).

Our ability to reason correctly about systems directly corresponds to how complex they are. And I posit that complexity in code is best measured in number of symbols (because lines can be arbitrarily long, and longer symbol names can actually be helpful). So a system that reduces the number of symbols necessary to express a solution increases the size of a solution about which we can successfully reason. Just as computers are a "bicycle for the mind", homoiconicity+macros (of which I posit CL is still the best practical implementation) is a "bicycle for the programmer's mind".

Lisp provides an optimal solution for thinking of programs as nested sequences of arbitrary symbols. Sequences that can be transformed (and must be, for a computer to evaluate them, unless we hand-write machine code!). Common Lisp provides an optimal set of built-in operators for composing operations and transformations on its fundamental data types (atoms/cells/lists/trees). Other languages might provide better implementations of particular paradigms or whatever, but CL is the best language for implementing macros. Other Lisps make macros "safer" and miss the point.

As Vladimir Sedach wrote earlier on Hacker News[1]:

"The entire point of programming is automation. The question that immediately comes to mind after you learn this fact is - why not program a computer to program itself? Macros are a simple mechanism for generating code, in other words, automating programming. Unless your system includes a better mechanism for automating programming (so far, I have not seen any such mechanisms), _not_ having macros means that you basically don't understand _why_ you are writing code.

This is why it is not surprising that most software sucks - a lot of programmers only have a very shallow understanding of why they are programming. Even many hackers just hack because it's fun. So is masturbation.

This is also the reason why functional programming languages ignore macros. The people behind them are not interested in programming automation. Wadler created ML to help automate proofs. The Haskell gang is primarily interested in advancing applied type theory.

Which brings me to my last point: as you probably know, the reputation of the functional programming people as intelligent is not baseless. You don't need macros if you know what you are doing (your domain), and your system is already targeted at your domain. Adding macros to ML will have no impact on its usefulness for building theorem provers. You can't make APL or Matlab better languages for working with arrays by adding macros. But as soon as you need to express new domain concepts in a language that does not natively support them, macros become essential to maintaining good, concise code. This IMO is the largest missing piece in most projects based around domain-driven design."

[1] https://news.ycombinator.com/item?id=645338

[armitron]

Excellent points.

Unfortunately, those people that only treat programming as a way to pay the bills - with a six figure salary - which would be the vast majority of professional programmers working today, do not want to understand _why_ they are writing code. The commoditization of software engineering that companies like Google [1] enthusiastically support and promote is also directly responsible for the obliteration of the entire field.

In a world where geniuses like Alan Kay are almost unheard of and Tim Berners-Lee ends up receiving the Turing award (next: Stroustrup/Rob Pike) there really isn't a lot of hope for languages like Common Lisp to proliferate. They're simply too meta and require a lot more from you than just settling for whatever makes one feel good about him/herself in an immediate-rewards sense.

[1] http://www.flownet.com/gat/jpl-lisp.html

[dataangel]

I think you're massively overstating your case when you say "optimal." There is no evidence anything CL provides is optimal according to any rigorous metric. I could very easily claim Scheme is "more optimal" since it's a much more minimal implementation with the same capabilities. Also I think you are mistaken to equate fewer symbols with easier to reason about symbols, e.g. I find it much easier to reason about complex programs when they are written in a strong static type system, which CL lacks. The type system lets me leverage the computer to help me reason about the program, by type checking.

[enduser]

Then the computer is doing the reasoning, not (just) you. Static typing will certainly help you reason about a larger system, I do not dispute that. I am talking about increasing the capability of the largest symbol system you operate on in your mind without relying on the computer. If the meaning-density of the symbols is higher, your effective intelligence goes up.

[procparam]

> these days that is more often the case for me than targeting CL itself, cf. 4500 recent lines of Lisp that turns into 8000 lines of terse JavaScript

I'm very interested by this. Can you say more about the project? Or, even better, share some code?