4 ms·

Well, I can understand (+ a b c d) Its the next level where it gets hard.

by ape4 6y ago

tartoran 6y ago
What is that, macros? Hygienic macros? Higher order functions? Recursion? I find that having such a simple syntax everything is grokkable much easier than in other languages. Having said that, I prefer scheme and racket which are much more simplified than common lisp and don’t contain so many warts.
- MaxBarraclough 6y ago
  To someone who isn't immersed in the Lisp world, Lisp syntax often looks ((((something (like) this) and) seems)) utterly impenetrable compared to a more 'conventional' syntax. It's the reason for the snarky backronym, Lost In a Sea of Parentheses. Forth, another language with a spartan approach to syntax, gets similar criticism.
  - betterunix2 6y ago
    Kind of like saying C often(looks{something{like->this;}});
    - MaxBarraclough 6y ago
      Overly dense C can be cryptic, sure, but Lisp relies heavily on parentheses. At least in C and C++, there are several types of brackets at work (parentheses, square brackets, braces, and in C++, angle brackets and even double square brackets [0]). This helps the eye get a grasp of things. At least, things seem that way to me, as someone who knows C and C++ reasonably well but has only dabbled in Lisp. [0] https://en.cppreference.com/w/cpp/language/attributes https://en.cppreference.com/w/cpp/language/attributes
      - betterunix2 6y ago
        Well that is kind of the point -- you know C and C++ reasonably well and are comfortable with the syntax, so of course you think it is easy to read. If you were as familiar with Lisp you would not find it hard to read either (I should know, since I am comfortable with both C++ and Common Lisp). That said, if you want a real C++ readability challenge, here you go: int add_one(int x) { return x+1; } Easy-to-miss undefined behavior is a much greater readability problem than the specific syntax of a language in my opinion.
        MaxBarraclough 6y ago
        I agree that UB is a serious issue in languages like C and C++. I thought you were going in another direction with that example, the Most Vexing Parse. https://en.wikipedia.org/wiki/Most_vexing_parse https://en.wikipedia.org/wiki/Most_vexing_parse
      - lispm 6y ago
        Lisp always uses prefix operator symbols. something like { ... } would be (progn ...) . Thus when one reads Lisp, one doesn't look that much for character syntax, but for operator names and list structure layout. Parentheses are there, because s-expression syntax is not only used for syntax for nested lists, but also for representing code as s-expressions. C / C++ does not have that feature. These s-expressions in Lisp are data. This means one can also write programs which create programs as data - not as text, but as list structures.
        MaxBarraclough 6y ago
        > when one reads Lisp, one doesn't look that much for character syntax, but for operator names and list structure layout. Right, but this boils down to just getting used to Lisp. > also for representing code as s-expressions. C / C++ does not have that feature. Sure, I know enough Lisp to understand that, but the point about syntax stands. Ultimately I think it's just a matter of acclimatisation. C++, Lisp, and Forth, are different enough that if you only know one or two of the languages, you'll likely find the third to be an unreadable mess.
  - tlavoie 6y ago
    What you're looking at though in lisp is an unambiguous syntax tree. It's what helps you find your way around in the forest, especially with editor support that can automagically apply operations to discrete chunks of your code. That can include doing things like re-defining a function or value on the fly, which is one of the lovely things you can do in many lisps.
    - MaxBarraclough 6y ago
      > What you're looking at though in lisp is an unambiguous syntax tree. ... > That can include doing things like re-defining a function or value on the fly, which is one of the lovely things you can do in many lisps. Sure, but like I said to lispm, I know enough Lisp to understand both of these points. Respectfully, neither addresses my point about syntax.

Well, I can understand (+ a b c d) Its the next level where it gets hard.

by ape4 6y ago

Well, I can understand (+ a b c d) Its the next level where it gets hard.

What is that, macros? Hygienic macros? Higher order functions? Recursion? I find that having such a simple syntax everything is grokkable much easier than in other languages. Having said that, I prefer scheme and racket which are much more simplified than common lisp and don’t contain so many warts.

MaxBarraclough 6y ago
To someone who isn't immersed in the Lisp world, Lisp syntax often looks ((((something (like) this) and) seems)) utterly impenetrable compared to a more 'conventional' syntax. It's the reason for the snarky backronym, Lost In a Sea of Parentheses. Forth, another language with a spartan approach to syntax, gets similar criticism.
- betterunix2 6y ago
  Kind of like saying C often(looks{something{like->this;}});
  - MaxBarraclough 6y ago
    Overly dense C can be cryptic, sure, but Lisp relies heavily on parentheses. At least in C and C++, there are several types of brackets at work (parentheses, square brackets, braces, and in C++, angle brackets and even double square brackets [0]). This helps the eye get a grasp of things. At least, things seem that way to me, as someone who knows C and C++ reasonably well but has only dabbled in Lisp. [0] https://en.cppreference.com/w/cpp/language/attributes https://en.cppreference.com/w/cpp/language/attributes
    - betterunix2 6y ago
      Well that is kind of the point -- you know C and C++ reasonably well and are comfortable with the syntax, so of course you think it is easy to read. If you were as familiar with Lisp you would not find it hard to read either (I should know, since I am comfortable with both C++ and Common Lisp). That said, if you want a real C++ readability challenge, here you go: int add_one(int x) { return x+1; } Easy-to-miss undefined behavior is a much greater readability problem than the specific syntax of a language in my opinion.
      - MaxBarraclough 6y ago
        I agree that UB is a serious issue in languages like C and C++. I thought you were going in another direction with that example, the Most Vexing Parse. https://en.wikipedia.org/wiki/Most_vexing_parse https://en.wikipedia.org/wiki/Most_vexing_parse
    - lispm 6y ago
      Lisp always uses prefix operator symbols. something like { ... } would be (progn ...) . Thus when one reads Lisp, one doesn't look that much for character syntax, but for operator names and list structure layout. Parentheses are there, because s-expression syntax is not only used for syntax for nested lists, but also for representing code as s-expressions. C / C++ does not have that feature. These s-expressions in Lisp are data. This means one can also write programs which create programs as data - not as text, but as list structures.
      - MaxBarraclough 6y ago
        > when one reads Lisp, one doesn't look that much for character syntax, but for operator names and list structure layout. Right, but this boils down to just getting used to Lisp. > also for representing code as s-expressions. C / C++ does not have that feature. Sure, I know enough Lisp to understand that, but the point about syntax stands. Ultimately I think it's just a matter of acclimatisation. C++, Lisp, and Forth, are different enough that if you only know one or two of the languages, you'll likely find the third to be an unreadable mess.
- tlavoie 6y ago
  What you're looking at though in lisp is an unambiguous syntax tree. It's what helps you find your way around in the forest, especially with editor support that can automagically apply operations to discrete chunks of your code. That can include doing things like re-defining a function or value on the fly, which is one of the lovely things you can do in many lisps.
  - MaxBarraclough 6y ago
    > What you're looking at though in lisp is an unambiguous syntax tree. ... > That can include doing things like re-defining a function or value on the fly, which is one of the lovely things you can do in many lisps. Sure, but like I said to lispm, I know enough Lisp to understand both of these points. Respectfully, neither addresses my point about syntax.