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.
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.
[1] https://en.wikipedia.org/wiki/The_Art_of_the_Metaobject_Prot...