[virgil_disgr4ce]

> - syntax is hard to read unless you spend a lot time getting used to it

This is only true if you assume C-like syntax is the "default."

But regardless of that, I'd argue that there's much less syntax to learn in LISPy languages. The core of it is really just one single syntactic concept.

[gorjusborg]

This guy gets it.

The syntax argument is such a tired argument. With LISPy language there is almost zero syntax, it's pretty much executable AST.

Because of this, formatting matters a lot, but I don't think that's too different than other languages.

If you think LISP is hard to read, you are someone who could most benefit from branching out to a non-Algol lineage language.

Also, the little syntax present is pretty much timeless. Learn once and its yours for the next 50 years.

[ux266478]

> With LISPy language there is almost zero syntax

To be pedantic, this isn't quite correct. Syntax isn't countable like that. What S-expressions are light on is production rules. At their most basic they have IIRC 7 production rules but there are absolutely 0 languages based on s-expressions which are that simple, since it doesn't give you anything like quasiquotes, vectors, Lisp 2 function resolution, etc. Reader macros make matters much worse.

What we can say is that they are constructively simple, but not particularly unique in that. Once you get into real sexpr languages they aren't simpler than horn clauses, and are constructively more complex than languages like Brainfuck and Forth.

[thunky]

> The syntax argument is such a tired argument.

It's repeated a lot because it's true. The collective developer world has decided that LISP syntax is not the preference. Good if you prefer it, but you're the in the overwhelming minority.

Random example i just found via github explore: https://github.com/replikativ/datahike/blob/main/src/datahik...

You probably love it but to me it looks like a wall of text. Sure I can figure out what it does, but it gives me a headache.

[epgui]

It’s not true, unless you have an unusual definition of “syntax”. Lisp basically has the most minimal syntax possible, by design.

To use the right words: it’s not a syntax issue, it just looks unfamiliar to you.

[jz391]

The key issue is that Lisp's minimal uniform syntax has less variation to help with visual pattern matching, which we humans are good at (compared to richer syntax).

The meta-programming power of Lisp may be largely due to being homoiconic, although Dylan/Julia etc achieve similar without it. However Lisp's minimal syntax is not a prerequisite for homoiconicity: S-Plus/R has a more conventional syntax while retaining "code is a list" representation.

[epgui]

But S-Plus/R is not homoiconic in any way.

[tancop]

minimal and simple is not the same thing as easy to use and natural/obvious. what looks easier to read:

  (if (< a b)
    (let [x (long-function-name a b)]
      (another-long-function (+ x c)))
    (+ a b))

or

  if a < b {
    let x = long_function_name(a, b);
    another_long_function(x + c)
  } else {
    a + b
  }

to me the first one is way more noisy and confusing. and you really need a text editor with auto close and rainbow brackets to be productive, of course thats a non issue today with vscode and zed/neovim/helix but still something to think about. now rust might not be the best example for "easy to read syntax" but theres also python, lua, kotlin, even js if you ignore strict/loose equals and weird casts. all of them use more procedural/c like syntax because its the natural way humans think about running an algorithm. theres a reason why pseudocode in every textbook looks like that.

[epgui]

> minimal and simple is not the same thing as easy to use and natural/obvious

You are right about that.

I value "minimal and simple" more than "familiar" because it makes my growth trajectory less arbitrary and more about intrinsic properties of the code. I don't care about learning how to do things the same way as everyone else nearly as much as I care about learning how code can be improved generally.

I know that code is written for humans, and that you can't remove the human from the equation. But I'm more interested in the future of code than in present-day code culture.

[gorjusborg]

> what looks easier to read

> to me

> theres a reason why pseudocode in every textbook looks like that

The reason is history, inertia, and limited exposure. Preference is self-reinforcing for those reasons. That doesn't make it better, or irreversible.

[jolt42]

I think by the same reasoning Qwerty keyboard is better than Dvorak. People are just used to Qwerty, although they would type faster on Dvorak, or in the case of s-expressions use structural editing.

[iLemming]

Honestly it's so exhausting. Every time Clojure gets mentioned on a broader forum, there's always some ridiculous claim that the Lispy syntax is "un-natural". Other Lisp dialects mostly pass unnoticed, but Clojure being more popular always causes some ruckus and I never get it - do people think that Clojurists stumble on it and be like: "holy mother of Alan Turing, this is so much more 'natural' to me than everything else..." Both choices are in the same sense "natural" as skiing and sledding. None of it is "natural" - reading prose in English, Thai or Katakana - all that is "unnatural". Nobody stumbles on the language and immediately thinks the syntax is just better - the majority of Clojurists come to it after years, often decades of using other PLs and they have to struggle at first.

Comparison with sledding is apt here, because both methods let you achieve the same goal - going down to the base of the mountain. Of course, skiing is more difficult to start with, it's more expensive, it requires deliberate effort and dedication. But the practical, learned experience far exceeds initial expectations. Do you realize how ridiculous it looks when inexperienced people try to convince them it's not worth it? Well, you may say, "the point is not to convince 'them', but to show the wider public..." And that's even more imbecilic. Imagine trying to point at people zigzagging 70 miles down from the peak, having enormous fun and telling the observers not to even try that? I'd dare anyone to argue with an experienced skier that sledding is more fun.

> theres a reason why pseudocode in every textbook looks like that.

Like I said, most - the absolute majority of Clojure programmers come to it after many years of programming in other languages (see the surveys). They are using it as a real instrument to achieve real goals, to solve practical problems. It's not an educational tool, not a "hello world app" incubator, not a "good for the resume" kind of a thing for them. If you (not you personally, but some proverbial programmer) are arguing just for the sake of it, well, with all respect, then "fuck you" (for wasting people's time). If you're sincerely trying to make a choice - nobody can "make a skier" out of you - that is something you must do on your own. No theory, no books, no videos can ever convey to you the enormous joy you may get out of it later - there's too much nontransferable tacit knowledge there. Just keep in mind, people in this community didn't make the choice because "their brains are wired differently" or something, not because "they are oblivious", no. Unlike you - they have seen, walked and lived through both of these worlds. Most of them have to switch between them, sometimes multiple times a day. And yes, the wider majority can often be wrong. In fact, history shows us that it makes wrong choices all the time. Lispers don't care about popular choices - they prioritize pragmatism above all.

[joshlemer]

I think this is kind of misleading. Yes s-expressions have very simple syntax in and of themselves. But s-expressions are not all that's required to get all the control structures in Clojure. You need to memorize all the special forms and all the standard macros that people use on a day to day basis. And they're just as hard (actually IME harder) to memorize as any other syntax. let, cond, record, if, condp, let-if, fn, def, defn, loop, recur, if-some, when-let, for, ->, ->>, as->>, cond-> ...

To this day I have to look up whenever I get back into clojure what the "syntax" is of ns, require, import, etc.

[epgui]

Remembering macros is much more like remembering functions than syntax.

[midnight_eclair]

i can link you similarly undecipherable walls of text in rust and zig and c

but i bet if you sat down a junior developer not yet entrenched in any style yet, they'd be able to grok lisp code MUCH faster than the intricacies of syntax of the other alternatives ¯\_(ツ)_/¯

[gorjusborg]

To me, it's the uniformity and limited rules that make lispy languages attractive.

Javascript's destructuring syntax can look almost indecipherable, and it is mostly because the language syntax is not uniform in its meaning.

  const f = ({a: {b: [x, , z] = [], c: {d: w} = {}} = {}, e: [, y] = []} = {}) => ({x, y, z, w});

This is a function written in one of the most popularly used programming languages in the world.

[baranul]

My opinion about this, is that it appears to depend on how a particular person's brain is wired, as to which language(s) they will understand faster and like. There can be a "winner" in terms of which language more people gravitate towards, but then that is very relative to many factors, including corporate influence.

People also put themselves into bubbles. Once in, they can filter out other languages (with all kinds of excuses), and be overly focused on certain families or only specific languages.

[regularfry]

But that's exactly the root of the complaint. Because there's (for the sake of argument) only one syntactic concept, there's no bandwidth for structural concepts to be visible in the syntax. If you're used to a wide variety of symbols carrying the structural meaning (and we're humans, we can cope with that) then `)))))))` has such low information density as to be a problematic road bump. It's not that the syntax is hard to learn, it's that everything else you need to build a program gets flattened and harder to understand as a result.

Even among lisps this has been problematic, you can look at common lisp's LOOP macro as an attempt to squeeze more structural meaning into a non-S-expression format.