4 ms·

Readability

dsrguru 14y ago
Do you mean because the syntax isn't sugary or because Lisp lends itself to a DSL-driven style of development where user-defined constructs are used more extensively than in any other language family? If the former, I'd argue that's just because you're not used to looking at Lisp code. If anything, its extreme concision should make visually parsing code faster than parsing equivalent code in other languages. If the latter, pg makes a good argument in section 4.8 of On Lisp: "So yes, reading a bottom-up program requires one to understand all the new operators defined by the author. But this will nearly always be less work than having to understand all the code that would have been required without them. If people complain that using utilities makes your code hard to read, they probably don’t realize what the code would look like if you hadn’t used them. Bottom-up programming makes what would otherwise be a large program look like a small, simple one. This can give the impression that the program doesn't do much, and should therefore be easy to read. When inexperienced readers look closer and find that this isn’t so, they react with dismay."
- voyou 14y ago
  "Its extreme concision should make visually parsing code faster than parsing equivalent code in other languages." You know, I don't think this is true at all. Concision can make things harder to read, because you have to understand everything you read from scratch. A language where some common patterns come with a bit of boilerplate allow you to orient yourself via that boilerplate. The visual representation of a common pattern provided by the sugary syntax of some languages is, in one sense a waste of space and typing, but it can make code easier to read than a more concise language would be.
  - wonderzombie 14y ago
    I'm not quite sure I understand your point, but you're disagreeing with the above quote whereas I agree wholeheartedly with the quote. Compare a language which forces you to write this ll = [] for x in xx: if bar(x): ll.append(x) This is Python, but imagine you're doing this in Java or C++ instead. Every time you read a for loop, you have to re-derive what the author intended. Are they just iterating? Are they composing a new list? Remember, these loops are often more than just two lines and they are common. Contrast the above with ll = [x for x in xx if bar(x)] Or even (in Haskell) filter bar xx When your language gives you primitives to talk at a higher level, you can write more crisply and concisely. The simple, trivial code you've written 1e9 times is replaced by a very clear, simple definition of what you're doing. The important code, the interesting code may now speak for itself.
    - drmrkela 14y ago
      To be honest that Python list comprehension is really hard for me to internalize. I find Ruby way much more natural. xx.select { |x| bar(x) } Even Clojure is better (filter (fn[x](bar x)) xx) or (filter #(bar %) xx)
      - osener 14y ago
        You don't need that anonymous function in Clojure, (filter bar xx) is enough just like Haskell.
        deleted 14y ago
        [deleted]
        drmrkela 14y ago
        You are right. Thanks.
      - wonderzombie 14y ago
        Sure, I do, too. Ruby is one of the languages that made me experience how expressive the higher-order function pattern really is. That said, in Python, you have to take what you can get, though. And generally I expect more people are familiar with Python than Haskell. Probably I should've used Ruby. Oh well.
      - wonderzombie 14y ago
        BTW, friendly tip: if you want code formatting, try using four spaces of indent. You might only need two, actually. Let's see. Two spaces: filter foo xx Four spaces: filter foo xx
- Kilimanjaro 14y ago
  http://news.ycombinator.com/item?id=1803815 http://news.ycombinator.com/item?id=1803815 Pseudocode is better expressed in Python than Lisp, therefore much better in the academic world. My point stands: READABILITY.

Readability

Do you mean because the syntax isn't sugary or because Lisp lends itself to a DSL-driven style of development where user-defined constructs are used more extensively than in any other language family? If the former, I'd argue that's just because you're not used to looking at Lisp code. If anything, its extreme concision should make visually parsing code faster than parsing equivalent code in other languages. If the latter, pg makes a good argument in section 4.8 of On Lisp: "So yes, reading a bottom-up program requires one to understand all the new operators defined by the author. But this will nearly always be less work than having to understand all the code that would have been required without them. If people complain that using utilities makes your code hard to read, they probably don’t realize what the code would look like if you hadn’t used them. Bottom-up programming makes what would otherwise be a large program look like a small, simple one. This can give the impression that the program doesn't do much, and should therefore be easy to read. When inexperienced readers look closer and find that this isn’t so, they react with dismay."

voyou 14y ago
"Its extreme concision should make visually parsing code faster than parsing equivalent code in other languages." You know, I don't think this is true at all. Concision can make things harder to read, because you have to understand everything you read from scratch. A language where some common patterns come with a bit of boilerplate allow you to orient yourself via that boilerplate. The visual representation of a common pattern provided by the sugary syntax of some languages is, in one sense a waste of space and typing, but it can make code easier to read than a more concise language would be.
- wonderzombie 14y ago
  I'm not quite sure I understand your point, but you're disagreeing with the above quote whereas I agree wholeheartedly with the quote. Compare a language which forces you to write this ll = [] for x in xx: if bar(x): ll.append(x) This is Python, but imagine you're doing this in Java or C++ instead. Every time you read a for loop, you have to re-derive what the author intended. Are they just iterating? Are they composing a new list? Remember, these loops are often more than just two lines and they are common. Contrast the above with ll = [x for x in xx if bar(x)] Or even (in Haskell) filter bar xx When your language gives you primitives to talk at a higher level, you can write more crisply and concisely. The simple, trivial code you've written 1e9 times is replaced by a very clear, simple definition of what you're doing. The important code, the interesting code may now speak for itself.
  - drmrkela 14y ago
    To be honest that Python list comprehension is really hard for me to internalize. I find Ruby way much more natural. xx.select { |x| bar(x) } Even Clojure is better (filter (fn[x](bar x)) xx) or (filter #(bar %) xx)
    - osener 14y ago
      You don't need that anonymous function in Clojure, (filter bar xx) is enough just like Haskell.
      - deleted 14y ago
        [deleted]
      - drmrkela 14y ago
        You are right. Thanks.
    - wonderzombie 14y ago
      Sure, I do, too. Ruby is one of the languages that made me experience how expressive the higher-order function pattern really is. That said, in Python, you have to take what you can get, though. And generally I expect more people are familiar with Python than Haskell. Probably I should've used Ruby. Oh well.
    - wonderzombie 14y ago
      BTW, friendly tip: if you want code formatting, try using four spaces of indent. You might only need two, actually. Let's see. Two spaces: filter foo xx Four spaces: filter foo xx
Kilimanjaro 14y ago
http://news.ycombinator.com/item?id=1803815 http://news.ycombinator.com/item?id=1803815 Pseudocode is better expressed in Python than Lisp, therefore much better in the academic world. My point stands: READABILITY.