3 ms·

> - 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 th

> - 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 6mo ago
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.
- thunky 6mo ago
  > 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/datahike/db/transaction.cljc 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.
  - midnight_eclair 6mo ago
    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 6mo ago
      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 6mo ago
      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.
  - epgui 6mo ago
    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.
    - joshlemer 6mo ago
      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 6mo ago
        Remembering macros is much more like remembering functions than syntax.
    - jz391 6mo ago
      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 6mo ago
        But S-Plus/R is not homoiconic in any way.
    - tancop 6mo ago
      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.
- ux266478 6mo ago
  > 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.
regularfry 6mo ago
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.

gorjusborg 6mo ago

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.

thunky 6mo ago
> 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/datahike/db/transaction.cljc 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.
- midnight_eclair 6mo ago
  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 6mo ago
    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 6mo ago
    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.
- epgui 6mo ago
  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.
  - joshlemer 6mo ago
    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 6mo ago
      Remembering macros is much more like remembering functions than syntax.
  - jz391 6mo ago
    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 6mo ago
      But S-Plus/R is not homoiconic in any way.
  - tancop 6mo ago
    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.
ux266478 6mo ago
> 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.

regularfry 6mo ago

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.