You know your brain adapts so you can read something easier/faster the more you are exposed to it. For me, Lisp code couldn't be easier/faster to read and comprehend.

I'm convinced most of the people making jokes about parentheses or Lisp code being hard to read are superficially dismissing it without putting in even a minimal effort of working with it.

Things that don't immediately click are discarded. Individual curiosity ("Really smart people say great things about this, I wonder why that is..") leading to individual effort leading to deep understanding is not the prevailing attitude.

Sad state of affairs.

I think that the syntax has some hurdles, but it's not the parentheses: It's to mentally understand when lists and symbols are data and when they are code. That's a problem not found in other programming languages and at the same time it is an interesting feature. Lisp is not alone to have such hurdles - another example would be Haskell which is also more difficult to learn than the average programming language (lazy evaluation, type system, monads, ...).

Often Lisp had been used as a teaching language for computer science concepts (recursion, evaluation models, algorithms, etc.) and thus it was associated by students with novel concepts they struggle with and not with solving practical problems. A typical example is the SICP book. It's great, but mostly CS and mathematics oriented -> the result is that the feedback is mixed.

> Lisp won't do this because it's then harder to blur/merge/change the distinction between code and data, which is the very power of Lisp.

Though it has tried a bunch of times.

> Some people have a certain kind of eye and/or brain that allows them to read Lisp quickly

Could be that or that one just needs a bit of practice - as it is the case with many thing: riding a bike, driving a car, learning a foreign language, mastering a new dance, ...

> 60 odd years without catching on in the mainstream is evidence of this

That you observe two things does not mean that they are necessarily in a causal relation.

> I also personally find them difficult to debug

One just introduces variables like in your imperative example:

  (let* ((a (af param))
         (b (bf a))
         (c (cf b)))
    c)

Now you'd see the variables and their bindings in a debugger.

Re: Though [separating in Lisp] has tried a bunch of times.

I haven't seen it done well. The attempts kind of end up with the worse of both worlds.

Re: Could be that or that one just needs a bit of practice

But the key is how much, and how long does it vary per individual. There is no solid research that I know of, so it's just opinion and anecdotes either way.

I tried to get used to it and read it fast, but it just felt progress was really slow. Most Algol-derived languages use punctuation and symbols that seem to make them stand out better than words alone. I'm not quite sure how to describe it, but standardizing the meaning of "funny symbols" help my particular eyes work faster. My head parses words too slow, and I have been reading words since kindergarten. Similar discussions:

https://wiki.c2.com/?LispLacksVisualCues

https://wiki.c2.com/?ChallengeSixLispVersionDiscussion

One can make that claim about any tool I should note, even COBOL. Some seasoned COBOLer's can crank out and read COBOL code really quick, I'd note. The top COBOLer can probably out-code an average Lisper I'd bet.

Re: That you observe two things does not mean that they are necessarily in a causal relation.

True, but per lack of formal studies per above, speculative observations are all any of us have. It should be a curiosity why after 60 years it never caught on mainstream. Almost nothing else in IT has had that many shots at it.

Re: One just introduces variables like in your imperative example:

Yes, but the Algol-derived languages (like C, Python, etc.) do that "style" in an easier-to-read and more consistent way, at least in my opinion.

Side note: why am I getting a rotten score? What did I do bad? I don't want bad scores. I'm just expressing my opinion openly. I don't feel I deserve punishment.

> Most Algol-derived languages use punctuation and symbols that seem to make them stand out better than words alone.

If we read a long novel, then we read mostly words without much visual structure. The only thing that guides us are occasional marks of sentences, paragraphs and chapters. Still many can read Lord of the Rings without much problem.

Lisp is slightly unusual, since the code is written as nested lists (trees). To make Lisp code readable there are a few things follow: speaking symbols, standardized code layout and familiar code structures. After a while the reader/writer of Lisp code will recognize the symbolic hints and the usual visual patterns of the layouted code.

> The top COBOLer can probably out-code an average Lisper I'd bet.

In terms of lines of code I would think that's true.

> It should be a curiosity why after 60 years it never caught on mainstream

Why should it be in the mainstream? Why should a programming language originally designed for certain types of meta-programming (remember: the symbolic computation and code as data ideas, which are central to Lisp) be especially popular among programmers and their customers?

> easier-to-read

Now you are shifting the goal. You originally claimed that functional code is hard to debug, because there are no variables you can inspect. But that's what we do in Lisp too: we use variables for that purpose.

> Still many can read [novels] without much problem.

Compared to what? I didn't say reading of Lisp comes to a stand-still, only that it's slower than block-type-indicator symbols. Maybe it is indeed possible to refactor written English for speed reading. I haven't surveyed the tests. Does anyone here want to claim English is optimized for quick reading?

It's kind of off topic, but I can envision using various symbols and block-markers to delineate parts of English sentences such as subject, verb, object, etc.: "(subject..) $verb {object...}" I think it would quicken MY reading, but I can't vouch for other humans. Maybe I'll patent it, or did Oracle beat me to it ;-)

But that's the idea: commonly occurring features are marked or surrounded with different symbols. You can't really do that in Lisp because nouns are verbs and verbs are nouns depending on the context/usage of the libraries or deeper code, while with Algol-derived languages mostly hard-wire the difference up front. You instantly know and don't have to stop and think or dig.

Indirection/abstraction can and does slow reading in many cases. I'm just the messenger. If YOU can read and process textual words fast, that's great but may NOT be universal across most humans.

> In terms of lines of code I would think that's true.

No, I meant features-per-hour, at least for business-oriented coding [in COBOL].

> Why should it be in the mainstream?

The standing implication, as I interpret it, is that functional programming is inherently superior in general, for a price of a slightly longer learning curve.

> Now you are shifting the goal. You originally claimed that functional code is hard to debug, because there are no variables you can inspect. But that's what we do in Lisp too: we use variables for that purpose.

I'm addressing TWO goals: easier-to-read and easier-to-debug.

> But that's what we do in Lisp too: we use variables for that purpose.

You add them just for debugging? Imperative style typically does that as in regular course. Thus, one doesn't have to alter the code as often just for debugging.

> After a while the reader/writer of Lisp code will recognize the symbolic hints and the usual visual patterns of the layouted code.

Indentation is not a difference maker in comparisons because both candidates can use it.

> I didn't say reading of Lisp comes to a stand-still, only that it's slower than block-type-indicator symbols.

That's an assumption of yours.

> No, I meant features-per-hour, at least for business-oriented coding [in COBOL].

Another assumption, for which you assume justifications.

> The standing implication, as I interpret it, is that functional programming is inherently superior in general, for a price of a slightly longer learning curve.

I think of 'functional programming' as a tool. 'superior' is an attribute that you use.

Implication of what? 'functional programming'? Lisp is not 'functional programming'. Lisp in its root is a mix of full imperative programming (mutable variables + imperative control flow) with functional programming (first class functions, higher-order functions, ...).

> You add them just for debugging? Imperative style typically does that as in regular course.

Imperative code uses operators (which are functions) and functions.

  a = 2 * b + 3 ^ b
  c = 4 * a
  r = c * pi * sin(a)

It's basically arbitrary which variables one introduces. We could write the thing down as one expression, add more variables, etc. Using variables has two purposes: save intermediate results for multiple use and naming intermediate results for documentation/code readability purposes.

+, ^, sin, ... are basically functions. An operator is a function with an infix notation. Thus any imperative code which uses functions and operators is ALREADY a mix of imperative elements (mutable variables and imperative control flow) and calling functions.

In Lisp one might introduce the variables first and then set them:

  (prog (a c r)
    (setf a (+ (expt 3 b) (* 2 q)))
    (setf c (* 4 a))
    (setf r (* c pi (sin a)))
    ...)

or use LET*

  (let ((a (+ (expr 3 b) (* 2 q)))
        (c (* 4 a)))
        (r (* c pi (sin a))))
    ...)

or I could use local functions.

  (flet ((e1 (b q)
           (* (expr 3 b) (* 2 q)))
         (e2 (a)
           (* 4 a))
         (e3 (c a)
           (* c pi (sin a))))
    (let* ((a (e1 b q))
           (c (e2 a))
           (r (e3 c a))
     ...)

etc...

Or I could write the code in some infix notation, since one can add infix syntax:

  CL-USER 8 > (ql:quickload "infix")
  To load "infix":
    Load 1 ASDF system:
      infix
  ; Loading "infix"

  ("infix")

  CL-USER 9 > #I( a = 3 , b = 5 , c = a * b, c)
  15

  CL-USER 10 > #I( a = 3 ,
                   b = 5 ,
                   c = a * b,
                   c)
  15

We can write Lisp code any way we want. We can write it in an basic imperative style in s-expression syntax and also in infix syntax. We can also write it in slightly more functional styles.

Every function introduces variables and LET / LET* are nothing else then binding constructs which are function calls:

   (let ((a 10))
     (* a 4))

is basically the same as

   ((lambda (a) (* a 4))     ; anonymous function
    10)

The more functional style of variable free calls is not the general way to write down code in Lisp. The extreme style variant is so-called 'point-free' where functions are combinated is also not very much used.

So when you think that one does use a strict functional and variable-free style of programming in Lisp, then this has no base in reality. Lisp is very much an imperative language.

> Indentation is not a difference maker in comparisons because both candidates can use it.

Layout of code is more than indentation.

> That's an assumption of yours.

So is the opposite viewpoint. Neither of us has a solid study that's directly relevant such that anecdotal info is all we have here either way. A good study would probably require millions of dollars. Yours is NOT the default position given the lack of such studies.

> Layout of code is more than indentation.

Same issue: both can do it so it's not a difference maker in comparisons.

> We can write Lisp code any way we want...one might introduce the variables first and then set them...or use LET*...or I could use local functions...etc...

But that's part of the "lack of standardization" that contributes to Lisp being more difficult to read. Standards and conventions are somewhat counter to "flexibility". We typically don't want overly-detailed standards (hard to remember) nor want excessive flexibility because then everybody and every spot may do things different.

There is an optimum balancing point in the standards vs. flexibility spectrum. Goldilocks. And the balancing point probably varies per individual.

One of the problems to learn a new programming language syntax is a mental block. One looks for all kinds of excuses. It's actually not that Lisp syntax is overly difficult, it's the pain of learning something new.

> Yours is NOT the default position given the lack of such studies.

Your view would be more interesting to me if you'd have spent some time learning to read and write Lisp code. Much of what you claim is just guessing.

> Standards and conventions

There are standards and conventions in Lisp code. You just don't know them.

You are just guessing how difficult it might be to fly an airplane. It might be more difficult than a car, but how difficult it actually is not visible to you. You just guess that there are much fewer aircraft pilots than car drivers, and guess that flying a plane must be extremely difficult...

> Much of what you claim is just guessing.

Same with you. It's not statistically safe to say that because some people do better with Lisp that everybody will given enough time. That doesn't tell us whether it's a personal fit or something more general.

Your line of reasoning appears to be "I did X and got result Y, therefore if everybody else does X, they will also likely get result Y". You hopefully should recognize the statistical fallacy in that pattern.

Anyhow, we are going in circles. There are no solid studies to back either of our viewpoints so we just have "anecdote fights" that don't get anywhere, which is quite common in Lisp-related debates. BeenThereDoneThat.

> There are standards and conventions in Lisp code. You just don't know them.

But they mostly rely on "parsing" words. I personally believe in the power of symbols. My eyes/head process most symbols much faster than words. I can't explain it, they just do. That's just my brain, although others have told me similar. If YOUR brain can process textual words as fast as symbols, that's wonderful, but may be specific to you (and other Lisp fans). Your head is NOT my head.

It's not like I'm new to words such that after reading a billion words I'll finally get better. People's textual reading usually plateaus after about 5 years as adults. Throwing time at the problem won't significantly change this. Why should Lisp be different? Words are words.

And sure there are standards/conventions in Lisp, but the competition also has standards/conventions such that it's not a difference maker in comparisons. The difference maker is WORDS alone versus words + symbols. (Well, Lisp has parentheses, but mostly only parentheses, unless you "invent" something custom, which makes it non-standard by definition.)

And I'm not against new things, but if they don't seem to be making sufficient progress after a reasonable amount of time, I abandon them. If Lisp is unique in that it has a hockey-stick shaped benefits curve (flat for long stretches, then goes up), then it stands out from most tools. It's hard to know if it has a weird learning curve up front since there are no decent studies on it. Often fans of tools claim "just try it long enough". That's not sufficient because it's a fan habit to claim that.

> But they mostly rely on "parsing" words.

And structure.

> If YOUR brain can process textual words as fast as symbols, that's wonderful, but may be specific to you

Most people can do that. Most text people read just consists of words. Actually reading text with special symbols is quite complex - especially if the meaning depends on a mix of prefix, infix, postfix with different operator precedence.

> And sure there are standards/conventions in Lisp, but the competition also has standards/conventions such that it's not a difference maker in comparisons.

You claim a difference. I claim, you are just unfamiliar with Lisp.

> The difference maker is WORDS alone versus words + symbols.

No, the difference is words and structure.

Take for example the usual imperative code:

  a := 3;
  b := a*4;
  if a > b
   print a
  else
   print b
  ...

That's just a vertical sequence without much structure. You can add more { and }, but the shape largely stays the same.

Lisp code would look like this:

  (let* ((a 3)
         (b (* a 4)))
    (if (> a b)
      (print a)
      (print b)))

That's much more tree-like:

  LET*
       binding
       binding
   BODY
   BODY
   BODY

From that we can easily see that this is a new scope, what modifies the scope and what extent the scope has.

Lisp users learn to parse these visual and structural blocks & patterns. Once one has learned the vocabulary of basic code patterns, it's getting much easier to read Lisp.

> And structure.

They both have structure so it's not a difference maker in comparisons.

> Most people can do that. Most text people read just consists of words.

Yes, but "do" and "do better than alternatives" are different things. I already gave examples of possible alternatives/enhancements to typical English text that would help at least my brain. I won't reinvent that sub-discussion here.

> That's much more tree-like:

Being tree-like and being easier to read are not necessarily the same thing.

> I claim, you are just unfamiliar with Lisp.

How long do you believe it's realistic to keep at it if the benefits come slow? For example, if I keep coding in Lisp heavily for 2 years and STILL find it sluggish to read, is it realistic to then give up in your book?

> From that we can easily see that...

Who is this "we"?

I've been reading words and symbols for multiple decades in various contexts (programming, regular books, etc.). I've concluding after these decades that if used in the right spots, symbols GREATLY ENHANCE my ability to parse/grok/absorb written material IRREGARDLESS of the domain or the specific language.

For example, one thing I like from C# over VB.net is that C# uses square brackets for array indexes instead of parenthesis like VB does. It improved my head's groking speed of array-related code because parentheses have multiple meanings in VB. (I'm not claiming C# is overall better, this is just one aspect.)

Symbols MIXED with words (well) enhance the absorption of words. It's a ying-yang kind of thing. They COMPLIMENT each other. I truly doubt a billion years of using mostly just one OR the other will prove better than using them both.

Sorry, I believe Lisp is just plain lacking there. I want my ying-yang MTV. Go play your Wordy Gurdy in Jennifer's juniper garden.

> They both have structure so it's not a difference maker in comparisons.

Why not? structure can be different, example: shallow vers. deep. That both have some structure, that in both it's the same structure and that it is expressed in the same way.

> Being tree-like and being easier to read are not necessarily the same thing.

I did not claim that it is the same thing.

> How long do you believe it's realistic to keep at it if the benefits come slow?

You look for reasons not to learn it. You already KNOW that it will take years and will show no result.

> I've concluding after these decades

That makes little sense. After long and intense training lots of things look easy: juggling, flying a helicopter, ...

Unfortunately you haven programmed in Lisp and thus you have no idea about how difficult it would be to learn it.

I have also learned first to code in hex codes, assemblers, BASIC, Pascal, Modula, etc. Still I can read Lisp code just fine.

> I believe Lisp is just plain lacking there

You believe it, before even tried to learn Lisp and understand the difference.

You believe that a hammer is difficult to use, but you have only seen one, not hammered with it.

> I did not claim that [tree-like and easy-to-read] is the same thing.

Your example implied it. If you meant something different, it wasn't explicitly stated. There are multiple factors that play into "easy to read", and they often differ per person. Tree-ness helps in some cases, but not others, or can be over-done.

> After long and intense training lots of things look easy

But reading words PLATEAUS in most people. You can't throw time at it to speed it up much. "Speed reading" courses don't improve comprehension of details, only summary skimming speed.

> I have also learned first to code in hex codes, assemblers, BASIC, Pascal, Modula, etc. Still I can read Lisp code just fine.

I'm not sure what point you are trying to make here.

> Unfortunately you haven programmed in Lisp and thus you have no idea about how difficult it would be to learn it.

I dabbled it in many years ago, and just found it hard to read and didn't see that exposure time was paying off in the speed compared to learning/reading other tools/languages. Groking it faster either has a long learning curve, or is the "hockey stick curve" I mentioned earlier.

You haven't explained why it has that comparatively slow ramp up and why I should accept the slow grok start compared to other tools. If it does have the hockey stick grok curve, it stands out unique in that regard and there should be a good reason behind that, yet strangely nobody knows why. You appear to be avoiding these key questions/puzzles. I don't understand why. If you want to promote Lisp, you better start caring about this decades-old conundrum: it's not going away. "Just keep it at forever" is NOT a good answer.

> You believe that a hammer is difficult to use, but you have only seen one, not hammered with it.

After many decades I have a pretty good feel for what kinds of tools, symbols, layouts, and UI's work best for MY eyes and brain. I'm not going to force things for 10+ years to see if my assessment rules of thumb are actually wrong for specific tools. That's not a rational use of anybody's time.

And MANY others have said the same about Lisp, and it has yet to catch on in the mainstream despite being around 60 years and tried in many projects. It does fine in certain niches and continues to do fine in those niches. But if you keep failing mainstream beauty pageants for 60 years, common sense should tell you that the public just plain finds you ugly. Get a clue already! Lisp has buck teeth and a big nose. You may have a thing for buck teeth, but your brain is not a representative specimen of humanity.

Further, there's nothing to force people to use good Lisp style and formatting. If it did go mainstream, more would probably abuse and misuse it. Fans treat their prized possession with care, others don't. Nice things that happen in Nicheville don't scale to big cities.

> Not so with functional.

Sure you can, if you have an editor and REPL worth their salt. Select af(param)and evaluate it. There's what you're calling "a". Select bf(af(param) and evaluate it. There's what you're calling "b". How one carries out "select and evaluate" varies depending on the language, REPL, and editor in use, but there's almost always (always, in my experience) an easy way to do it.

Bonus: if it's a pure functional language (no side-effects) you can do it as many times as you like without messing anything up, and you didn't have to invent any otherwise-useless variables.

> In a debugger and/or Write statements I can readily examine intermediate values "a" and "b". Not so with functional.

You clearly have no idea. Lisp has a REPL. True REPL. No, it's not a thing where you type something into it and it blurts out something in return like in most other languages. And it's better than so much praised Jupyter notebooks.

Lisp REPL is connected to your editor, and from your editor or IDE you can not only examine and evaluate any expression and sub-expression, you can do it on the fly, it gives you immediate feedback. You don't even need to think about a debugger (which Lisps do have too). You can try things while writing them.

Imagine a landscape artist that changes the entire landscape in real-time with every stroke of his brush. That's how it feels to be programming in a Lisp.

Usually real-world code has a lot of context and references such that stand-alone expression evaluation is often of limited value. Maybe there are tricks of the trade to solve this, but they are not obvious to newbies.

It sounds like one has to throw away years of "imperative habits" and just do everything different: reading, debugging, structuring, etc. For us non-Sheldons, it's hard to overhaul our head in a month.

This may be a meme, but it's also very true (like all good comedy). It's truly represents how you start to look at Lisp code after a while:

https://www.thejach.com/imgs/lisp_parens.png

> they are not obvious to newbies

Modern Lisps like Racket and Clojure are not that difficult to pick up. I think Clojure might be easier to learn than Python or Javascript. I'm serious.

Look, I understand the sentiment because I was on the same side relatively not too long ago. I never had a formal introduction into a Lisp. I thought Lisp is a dying language, something like Fortran, COBOL, or Pascal. On a whim, out of the blue, I tried learning it. I don't remember exactly why. I was bored or something. I started reading a book on Clojure. Then I found a conference that supposed to happen in a week. It was the first Clojure/Remote conf. I thought: "Well, it's remote. It's cheap. Let me try it out. What do I have to lose?" That conference has changed my life. Quite literally. I was fascinated by seeing awesome things people building. After the conf, I sat in my chair, staring into the void of my blank screen for several minutes. The next day, I went to the office and told them that I'm leaving. Without writing a single program in a language I did not know, I decided to find a job with a tech stack focused on Clojure.

There are lots of misconceptions circling Lisp. People look at Lisp code, and it just doesn't look "sexy" to them. And they immediately dismiss it, claiming it is hard to read. That's not true.

They say - it's dynamically typed mess. Without ever knowing that Clojure has a type system called Spec, which can do things, most other type systems cannot. There's a ton of research happening around type systems in Racket. "Little Typer" book teaches dependent types using a Lisp.

They say Lisp codebases don't scale - that's not true at all. The truth is - programming in Lisp makes people so productive, you don't need large teams to maintain a massive amount of work. And there are companies with large Lisp ecosystems, one example: NuBank in Brazil has over 400 engineers, and their primary language is Clojure.

People say Lisp is not popular. Sure, Clojure's popularity might look dwarfed in comparison with massively popular Python, Javascript, C++, Java, etc. However, Clojure, compared to other "esoteric" languages, is quite popular - today, it has more books, podcasts, conferences, and meetups. More than languages like Haskell, OCaml, Rust, Elm, Purescript, ReasonML, F#.

Learning Clojure has opened a world of possibilities for me personally. My only regret that I haven't gotten into Lisps earlier. Please, don't negatively take my advice. My intentions are sincere. I wish someone would've convinced me to try Lisp early in my career. Please, do sometimes try to get your head out of your shell and give it a try. I promise, if you give Lisp an honest and heartfelt try, you will find something unique. Even if you end up not using it, you will never regret learning it.

You should stop oversellling things. Spec is not a type system.

Just because you can't do a rigorous static analysis (which to certain degree is possible, check out Spectrum) it doesn't mean that Spec is not a type system.

That's misleading. Spec is a contract system. Read the page on the spec rationale: https://clojure.org/about/spec . It even mentions that spec is not a type system and that spec is similar to contracts in Racket, etc.

If we look at programming languages like Java, Typescript, C++, Haskell, etc., then we see that their type systems are completely different and have an entirely different purpose. Claiming to those users that spec is a type system, is just misleading them.

Semantics. Spec is very close to dependent types. "Entirely different purpose" is kinda vague. If the end result is the correctness of the program, the purpose is the same. If someone can perform Vivaldi's Four Seasons on Ukelele, it's cool. It doesn't make Ukelele less of an instrument.

So, spec is the ukulele in the vast domain of Type Systems?