• Zak@lemmy.world
    311·
    2 个月前

    The first example actually has more bracket pairs (7) for Javascript than for Lisp (6). Rainbow bracket modes for editors can help when bracket matching is an issue.

    This example which suggests counting parens is also solved by rainbow brackets, and/or editor tooling like paredit-mode that won’t even let you type mismatched brackets:

    (f (g (h (i (j)))))

    And in most modern Lisps, one might use a thread/pipeline macro instead:

    (-> (j) i h g f)

    With mixed nesting, Lisp programmers often use newlines to improve clarity:

    (aap noot ((mies wim) zus) (jet teun vuur))

    becomes

    (aap noot
     ((mies wim) zus)
     (jet teun vuur))

    A later example in the post does that:

    (sum
  (filter
    (split (read (open "input.txt")
                 ",")
    (lambda (it) (> it 0)))

    Which makes one of the errors it contains clear: “,” should be an argument to split, but here it is an argument to read. It is aligned with the start of the first argument to read, so that’s very visible. There are also two levels of unclosed parens. Pasting it into an editor made that clear instantly.

    This version is correct:

    (sum
 (filter
  (split (read (open "input.txt"))
         ","))
  (lambda (it) (> it 0)))

    But I’d probably write this with a thread macro:

    (-> (open "input.txt")
    read
    (split ",")
    (filter (lambda (it) (> it 0))))

    It’s possible to write unreadable Lisp, but people who are good at Lisp don’t. This is true of most languages.

    • 9point6@lemmy.world
      15·
      2 个月前

      Thanks for this, I was half going to respond with a glib “skill issue” in response to the article

      I worked with Scheme on a project about a decade ago now, and the only code in the project that wasn’t particularly readable was the code written by someone who didn’t attempt to learn conventions and appropriate tooling before contributing.

      • Zak@lemmy.world
        6·
        2 个月前

        I was tempted, but nobody learns anything from that.

        I have the impression the author of the article has dabbled with Lisp but hasn’t actually set up a reasonable development environment and written something non-trivial. That’s not a great position from which to write critiques of a language.

    • whotookkarl@lemmy.dbzer0.com
      5·
      2 个月前

      Threading macros, rainbow parens, and paredit style auto closing parens make lisps syntaxes pretty easy to read and manage. I think declarative style languages like ML and Haskell took me longer to get familiar with than lisp style syntax, but that’s probably just because I learned procedural languages first. And I think lisps tend to be more syntactically dense than say Python or C or other languages most people start with.

      • mlatu@moist.catsweat.com
        31·
        2 个月前

        well, if familiarity can be ruled out, surely there is a quadruply-blind study then? how many participants were there? you need to test teaching lisp first then c and on another group the other way around. you also need to have groups of untrained people and show lisp first, then c, another group for the other way around.

  • Azzu@leminal.space
    61·
    2 个月前

    I agree very much.

    When I started developing in Clojure, I came across a lot of Clojure code that simply seems to be formatted/aligned “wrongly”, which was just my intuitive understanding of what the article names more accurately.

    It felt to me like everything was too cramped, not grouped properly.

    Luckily, it was super easy to fix for me in my code, just do some different alignment and line breaks and readability increased a lot. However, it now doesn’t look like “standard Clojure” which might be its own problem in collaboration, I don’t know.

  • notptr@lemmy.cyberia9.org
    2·
    2 个月前

    I get because I was like that when I first experienced lisp but I like lisp now.

    I found it pretty messy when I was going through the land of lisp book but lisp is pretty flexible and you can make it readable.

    When I was converting my 3d game engine to hare lang I missing the flexibility of lisp.

  • Denys Nykula@piefed.socialEnglish
    2·
    2 个月前

    JS written by different people became easier to read since Prettier appeared. When others’ code is formatted just like your code, it saves effort. Idk if Scheme or other Lisps have standard formatters now; there wasn’t one for Guile when I learned it.

  • KissYagni@programming.dev
    53·
    2 个月前

    I’m still convince that polish notation was the biggest mistakes of Lisp. At some point, the guy who create Lisp language decide to get rid of 2 centuries of mathematic convention just because of a technical limitation that last for maybe 2 decades.

    Oh, and no one to talked about (1- x) ?

  • onlinepersona@programming.devOP
    21·
    2 个月前

    I wanted to learn lisp, but the default formatting is just terrible. If it had a different formatting and supported infix notation, it would be readable to me.

    • Alavi@programming.dev
      4·
      2 个月前

      The polish notation is the simplest thing to wrap you head around. Instead of operations being special syntax exceptions, they’re just functions! Functions that take parameters.

      the only syntax of lisps are (myfun p1 p2 p3)

      Mathematical operations are no exception (unlike otger languages). To make it simpler, think of it like this: + is just an alias (macro) for a function named plus which does addition. (plus 1 2 4 5) is the same as (+ 1 2 4 5). We don’t use infix notation because then that would be a syntactic exepction (like other languages) while this is the only syntax we have in lisp, for everything it’s really simple.

      and also, how is (1 + 2 + 4 + 5) (15 chars) better than (+ 1 2 4 5) (11 chars)? It’s a conceptual shift and once you make it, it makes so much more sense.

    • Zak@lemmy.world
      41·
      2 个月前

      If it supported infix notation (outside of reader macros), it wouldn’t be Lisp.

        • Zak@lemmy.world
          5·
          2 个月前

          Yes. Well, sort of.

          The actual quality is homoiconicity, meaning that code in the language is represented in the language’s own data structures (beyond the entire source file being a string). This enables structural macros - using the language to manipulate code before execution.

          Some languages have tried to do this without the language syntax actually being data structure literals. Rust does it, but a typical Lisp macro looks like a simple template where some things are marked to happen at compile-time and others get spliced in at runtime. Rust macros don’t beyond the most trivial examples.

        • Zak@lemmy.world
          3·
          2 个月前

          To add to the point about homoiconicity, both the article and my toplevel comment mention thread macros. The article talks about them being equivalent (syntactically at least) to method chaining, which I agree with.

          The thing is, to get method chaining, the language has to have an object system, and the functionality you want to use has to be written in an object-oriented style. To get a thread macro, you need ten lines of code (aside from the docstring and metadata).

      • mlatu@moist.catsweat.com
        1·
        2 个月前

        i had to try again a couple times too before i got my brain to understand it, also maybe had to find just the right guide (practical common lisp in my case), but now that it’s in there its much easier for me to reason about code using LISP than it was ever in C/++/#, D, Java, Python…