I heard that before but i wonder how much is survivorship bias :D it reads just so awkward to me as a programming language, even though i 100% dig the beauty and everything that it allows.

It's just a different paradigm than what most developers are familiar with so there is a learning bump, same as functional programming if all you've done is object-oriented stuff. The awkwardness is only temporary. If you can already see the beauty of Lisp code, then you just need to build a little project in it to make the awkwardness fade away.

I recommend Clojure/ClojureScript. It's quite practical for web development and also an excellent gateway into functional programming.

I used Common Lisp as my main language for about 6 years (long time ago now) - yes for the first few days the syntax is a bit jarring but I've found that any new language is fundamentally different in approach to what you are used to has that effect (pretty much the same happened the first time I saw C, Lisp, PostScript etc.)

> i wonder how much is survivorship bias

Here is one anecdata. When my daughter was 14 I taught her a Lisp and then a traditional programming language. She found the random syntax of the trad formatted language bizarre.

I used Java for 10+ years, including now, and I worked briefly in Clojure for less than 1 year. I think the Clojure syntax is way more reasonable, although I appreciate the maturity of tools used with Java.

Two things were important to make it "click" for me:

1) I realized that "Lisp has many parentheses" actually has it backwards. A Lisp code has about as many parentheses as an equivalent Java code; there is almost a 1:1 relation. It just has less of... unnecessary things. Which results in more "parentheses per square meter", but from this perspective that is a good thing!

2) Some people complain that dense code is more difficult to read. But you don't have to turn everything into one-liners! You can format it into just as many lines as the Java code would have, except the lines will be much shorter now, and therefore easier to read. In Java, you don't have much freedom with formatting, because a typical statement takes more that half of the screen width, so you are stuck with one long column. Lisp with shorter statements gives you more freedom. You can abuse it to write hard-to-read code. You can also use it to design beautiful code that is easy to read. Also, there is a huge difference in legibility of a code that fits in one screen (so you can see it whole at once) and one that does not; and the Lisp functions are shorter on average.

I can only speak about Clojure, since it’s the only lisp I know. After just a few days of playing with it though, I started to see the parentheses as a warm and friendly hug, wrapping everything inside of them in its own scope that doesn’t affect its parents. Reading JavaScript, my main driver, became harder in comparison.

  function doSomething(a, b) {/* something! */}

is okay, since the “function” keyword is a simple indicator, and it’s clear that it’s a function declaration. The kids these days often use

  const doSomething = (a, b) => {/* whatever */}

and that is awful for readability. It’s much harder to scan for function definitions amidst value declarations. I’m nearly 20 chars in before I even know it’s a function. Worse yet is something like

  const doSomething = (a, b) => b => “some closure”;

This threatens to stretch my capability to understand the context I’m in when reading it. “b” is just kinda floating there amongst the infixed arrows, and I have to read on to know it’s an argument, and I have to run through the calculation of what “b” is every time. Compare:

  (defn do-something [a b] (fn [b] “some clojure”))

I can count the parens, there is no implicit scoping of the function body. My editor can too, which means I often don’t have to. It’s obvious that it returns a function. This part is Clojure-specific, but I also have strong guarantees that the returned function cannot pull the rug out from under me with whatever I pass to it by arbitrarily mutating some argument.

To me at least, (fn-name args) was both more readable and makes more sense than fnName(args) after a few days, and I never learned a lisp until I was 37. Maybe I just found a style preference later in life, marking me as a lisp survivor. Maybe we’ve just been doing it wrong for decades and have grown accustomed to it. I can’t say. But the power of the language itself coupled with the code editing features it enables makes me think that the whole field has been on the wrong track, or maybe even off the rails, for decades.

The JS code I write now is more flexible, more resilient, more testable, and more maintainable as a result of learning Clojure. I doubt anyone can say the opposite: that a C-style language improved their understanding of lisp. (Not addressing you with this part, dear poster, since your gripe is rooted in the syntax.)

[NaN] “kids these days“ is just friendly ribbing. I’ve got the grey beard now, so I‘m free to play the part. Language maintainers tend to be older, and we cause more problems.

I have experience with tons of languages, lisps and non-lisps.

I don't really get this argument. It's not any harder to read `(if foo` than it is to read `if (foo)`. It's purely a matter of what you've gotten used. I don't think it's an objective measure, it's purely about what you've already trained your brain to pattern-match on.

> and has much more focus on text over symbols than other languages

Funny how you get the exact opposite complaint about languages like Perl.

Let’s talk about text over symbols and readability.

Return the maximum value of the array “numbers”. The languages are listed in descending order of text > symbol.

Clojure:

  (apply max numbers)

JavaScript:

  Math.max(...numbers);

APL (I couldn't find how to apply this to an arbitrary array):

   ⌈/ 4 3 2 7 5 1 3

Here’s a guess:

  ⌈ numbers

The most aymbol-focused is the least readable to me, and Clojure is the only one that returned good results from a Google search to figure out what was going on. Both “JavaScript ...” and “APL ⌈” gave me irrelevant results.

Furthermore, how is this

  (if a
      true-cond
      false-cond)

harder to read than this, aside from familiarity?

  if (a) {
    trueCond
  } else {
    falseCond
  }

In the latter case, the if/else requires a special syntactical structure. And since it cannot be used as an expression, the common desire to conditionally assign a result spawned the ternary operator: a whole separate syntax that only applies when you want to assign a result to something. In lisps, you just use “if” wherever you need a binary conditional.

People saying that Lisp is as easy to read since you get used to it is like people saying that salad is as tasty as cake since you get used to it. Sure someone eating cake for the first time after having only eaten non sugary stuff for a long time will find it a bit jarring, but anyone eating both will find cake so much tastier, which is why people overeat cake so much.

Yet many people will still adamantly say that they find salad tastier. And still go on and eat cake and get fat. They are just lying to themselves, I'm not sure why. Lispers are the same way, its just a reality distortion field.

Why say lispers are "reality destorted"? Maybe they have learned something you have yet to understand?

Have you ever programmed a decently sized lisp program using an editor that allowed you to work at the AST level?

Until then, there's just a large probability, regardless of how tasty cake is, that your displaying classic ignorance.