[smabie]

In my experience, it's just not that good? I programmed professionally in Lisp (Racket to be specific) for a couple years and while I was initially enthusiastic about it, my enthusiasm for it diminished over time.

The heavy line noise in service of an easy to understand macro system just isn't worth it (moreover, a lot of languages have advanced macros these days without S-expressions).

Looking back, I think I was so into Lisp because I just wanted to feel superior and better than the dirty Java or Python programmers?

[ashton314]

> easy to use macro system

Just curious: what macro system were you using with Racket? There are, like, 3 big ways to build macros in Racket:

1. Macros by example with `syntax-rules`. This was taken from Scheme and is the original hygienic-by-construction system. Limited in power though.

2. `syntax-case`, which gives you full procedural macros but is a little unwieldy at times.

3. `syntax-parse`, the glorious, most powerful macro system of the three.

I know, it’s confusing.

[behnamoh]

> Looking back, I think I was so into Lisp because I just wanted to feel superior and better than the dirty Java or Python programmers?

tbh, Paul Graham's articles on Lisp have done more harm than good to programmers. Calling Lisp a "secret weapon" that supercharges your startup and gives you immense competitive advantage is unrealistic and lacks concrete evidence.

[nequo]

The problem is that those essays were written right after the 1990s when Common Lisp was much more ahead of other languages and when static typing hadn’t yet taken the form that is popular today. Back then, your alternatives were C/C++/Java/Pascal/Perl, and Python and Ruby were the novelties that were still much slower than CL and as I understand it had inferior tooling.

Since then, the landscape has changed.

[behnamoh]

I agree with this. But CL programmers seem to think Lisp is timeless and its best days are ahead of it still. I wonder if they're already awesome programmers and that's why they pick Lisp for maximum freedom (macros?). Most people aren't wizards, and can't (nor do they want to) invent small DSLs on the go.

With great power comes great responsibility, and most people don't want that responsibility.

[reikonomusha]

I can assure you that most people are not considering Lisp and thinking, "huh, this is too much responsibility, so not for me."

Lisp has a higher barrier to entry compared to Python or Rust or other languages available. For that simple reason alone, it's not used. None of these imagined reasons about the theoretical power or anti-power of macros, or being a wizard, or whatever are part of the calculus of choosing a language.

[hollerith]

Learning Lisp has a tricky part, and one of my classmates in undergrad despaired of ever learning it, but surely Rust is harder to learn than Lisp, which makes me wonder what you mean by "Lisp has a higher barrier to entry".

[reikonomusha]

You have to first install a Lisp compiler whose REPL is so spartan than even using arrow keys causes errors in your terminal. You have to learn Emacs. Figure out wtf SLIME and Paredit are from docs written in piecemeal plaintext READMEs. Then learn from a book that's older than you that makes no reference to any of the tools you just labored over installing. Then get a bunch of conflicting information about proper Lisp style from random patches of internet.

Who has time for that these days, except for the very determined and dedicated?

I think Lisp is a superlative language with excellent tools—once learned. But it hasn't had its UI revolution from anybody who cares enough to do the work.

[lispm]

Lisp early on exposes its dual nature of code and data. Even in interactive environments. This ever-present meta-level is unusual.