It's just fun to program in. You write something, see that your code is getting repetitive, write an elaborate macro that generates the repetitive parts, suddenly your program is 50% shorter. CLOS is ridiculously powerful. I love that I can connect to my live server's REPL and hotswap any code or basically do anything.
Speaking of REPL, it's basically your new shell: you almost never have to restart it and you can load all your projects into it, and get access to all sorts of tools that you wrote specifically to be used from REPL.
For me the Eureka moment with Common Lisp came when I read 'The Art of the Meta Object Protocol' (Kiczales) [1], which made me rethink OOP, the power of macro's and the power of Lisp.
Lisp is an extremely fundamental and deep language, but although it is conceptually interesting, I find it rather unpractical. A language needs some syntactic structure to help in pattern matching.
We read code more like a map than a book: scanning, skipping between files, functions and expressions. And, like a good map, it should guide our eyes: highways and byways are differently coloured and a quick glance tells us whether we are seeing a forest or a city. Code should be similar and due to the syntax of LISP, we have little to no guidance on what we are scanning, except by manually reading the code.
I don't think Lisp is the only language suffering from this. There are similar problems at the deeper end of the functional programming scene: we have to read map, flatMap, fold, apply, etc. in order to make sense of the code. We cannot 'scan' the code to understand its structure. It does not help that, for a syntax highlighter, these methods all get the same formatting.
The solution? Personally, I think we should seriously consider enhancing our editors to project our code based on the type-classes it participates in to enhance guidance.
I program in Common Lisp professionally on a sizable team of other Common Lisp programmers, and I find Lisp to be much easier to explore and navigate than other languages, by a huge margin. Why? Lisp IDE’s don’t need to build indexes of your projects that go out of date or anything like that. IDE’s participate by interacting with the running Lisp image itself.
I’m not sure what you’re missing about syntax. Indentation by default gives an excellent view of what’s going on, and most editors color important symbols as needed.
I find the lack of syntactic noise makes you focus on the important aspects of the program in the big picture.
Lisp has actually lots of structure, but it is expressed in lists. You need to see past the list, guided by symbols, blocks and indentation.
It's a bit like bicycle riding or learning to drive a car: while you are starting out and still thinking too much, it feels difficult. Once one has trained enough, one can read Lisp code quite fluently.
But there are pitfalls: the code might need to stay in the typical standard conventions for style. One CAN go in Lisp way be beyond standard code, reprogram the language -> it can get arbitrarily difficult to understand the code and may require learning new ways to program... but there are some expressive languages which have the same problem.
If you want to have a thriving community around your software and have bazaar-style development process, you better go with mainstream languages (C, C++, Go, Rust, Python, Java, etc.) The community is a great thing as projects like Linux and Kubernetes can show us. Yet there can be situations where you're the single developer on the project, or there are just 2-3 devoted hackers doing all the coding and for a variety of reasons there are little chances of inviting more people to join (niche projects ... closed projects w/o too much funding ... or maybe you're just not a good community builder). From my experience, Common Lisp with all its power is a perfect language for the latter situation. For me, it's also "thinking" language, as you can do exploratory programming easily compared to other modern languages. Source: I've built a control system for industrial electron accelerators using Common Lisp.
I held off learning LISP for many years, always thinking "one day I'll get to it". Because the syntax looked funky (even though I used other languages such as Haskell which has a "non-traditional" syntax).
Eventually I just dove in, and grew to appreciate the language. The homoiconicity (the code is data, and thus data can be used as code) is something that did excite me.
Unfortunately, I never got good with LISP. Whenever I wanted to do a 'real-world' thing, I ended up fighting with the package manager. Having outdated dependencies, not managing my deps correctly or just not finding deps for things that I wanted to use.
Which also deepened my believe that programming is more about the ecosystem than the language. I love functional programming, I really enjoy Haskell and I'll solve small things (Advent of Code) in LISP. But once I need a library I'll use Go, Python or Java, or _any_ other common lang.
I'd recommend learning it though!
EDIT: I just said LISP here, but I always used the CL (Common Lisp) implementation. And I run it with SBCL (Steel Bank Common Lisp)
I find the package manager actually great. Quicklisp works with monthly "distributions" that are tested to load together, rather than libs that must be strictly pinned and updated separately like everywhere else. I can understand the ecosystem problem, but it might be way better than one thinks: https://github.com/CodyReichert/awesome-cl
Also, Quicklisp can be completed with http://ultralisp.org/, a distribution that builds every 5 minutes and to which it is trivial to add a library. There's also Qlot for local dependencies, and more.
I'm here too. Niche languages are great when you're a solo developer or own your own company.
If you have to work in a large company, you have to deal with other technologies and people you'd normally avoid. That usually necessitates a larger ecosystem.
The secret of lisp is it's an abstract syntax tree (AST). When you compile a C or Java program it is first converted to an AST. With lisp you are already there. It's kind of a big deal and amazing it was invented in the 1950's. It's hard to "get it" without guided hand holding and a lot of deep thinking.
The structured nature of the code allows structured edits. Via tools like lispy. These ideas are floated for other languages but never get implemented due to difficulty and it's not an itch most people have.
Coding is against a live image. This allows really nice workflows. Other language users consider it an anti feature or incorrectly assume that means you can't use source control or do a full rebuild.
There tons of little niceties with lisp that add up to a sum greater than the parts. But the AST is the big one that no one understands.
It's usually the homoiconic syntax that you "get." Your mind is usually blown once you start taking advantage of that.
Keep in mind that this applies to all Lisps--not just Common Lisp. I never even bother with CL myself because I find it ugly and full of cruft. Most Scheme implementations will blow your mind just fine.
That depends on what other languages you have programmed in. The "get it" and "mind-blowing" hyperbole comes from a time when people had perhaps only programmed in Basic or C. Especially people the latter group would have issues with how easy Lisp makes programming.
If you have the time, I'd recommend reading SICP and working the exercises. It was a great experience for me. (If you are experienced with other Lisps or Schemes then ignore this comment.)
I think they're asking what makes CL noteworthy among all the other PLs such that it keeps getting brought up, even though it's not new and shiny or widely popular these days. Same sort of question you'd get about Smalltalk or Haskell.
Lisp evangelists always talk about a moment of profound clarity where the beauty and utility of Lisp just clicks in their brain somehow. I've done a little functional programming here and there so I know what it is, but I just can't fathom why Lisp is so beloved. I can't help but wonder if I knew Lisp (or some other functional language) intimately if I would approach problem solving completely differently.
Objectively, I felt the "power" when I learned macros. You can create any programming construct you like which will be executed at compile time / load time, and usable at runtime.
You will see the magic when you actually try it. No other language family that I know of (except forth or prolog maybe) can do this. Lisp still has the best macro system of all.
