Hacker News Reader

Comment by Kilimanjaro | Hacker News Reader

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."

"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.

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.

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)

(filter #(bar %) xx)

You don't need that anonymous function in Clojure, (filter bar xx) is enough just like Haskell.

You are right. Thanks.

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.

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

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.

Reply on news.ycombinator.com