Hacker News Reader

Comment by mbleigh | Hacker News Reader

Parentheses.

If this really is what turns you off to Lisps, then probably programming is only going to get harder and harder for you.

Lisp's parenthetical syntax is not, and never has been, its problem. You say "parenthesis" as a cute excuse to avoid doing any meaningful defense of your rejection of lisp.

In fact, the syntax of s-expressions is the key to Lisp's power. The form of program and data are the same, which allows the powerful macro facility and the functions read and eval.

I've wondered for years why people latch onto the parenthesis thing. When I learned lisp for a class, I never gave it a second's thought. To me it feels like people are looking for a handy reason to put Lisp down, perhaps either because they don't understand it or because they do understand it and they are jealous of some of the features of Lisp.

When people say they hate "parentheses" in Lisp, I'm pretty sure what they really mean is "I hate s-expressions." You may find them natural to work with, but it's pretty clear most programmers do not. Witness the crazy amount of work compiler writers put into writing parsers that could be trivially done away with if they just switched to using s-expressions.

Personally I prefer both Forth's RPN and C/C++ (Algol?) style notation to Lisp's s-expressions.

S-expressions are neither wonderful nor terrible. They are just A Decision. Certainly you can have bad syntaxes and good syntaxes, as well.

From my perspective, it comes from being used to parentheses in English. Specifically, you have a man thought, then you have some other modifiers that may expand on that concept which you enclose in parentheses. This fits well with C style functions, for example. But with Lisp, the main thought (the function name) is also enclosed in parentheses along with all its modifiers, which makes it a bit harder to follow the code.

However, I do like the overall elegance that this brings to the code, where code and data are the same. Which is why I also like Postscript -- it does the same thing but in an RPN style (a function is actually an executable array).

The parentheses may seem like a disaster at first, but one can quickly learn to use and abuse them.

Also, there is great support from lisp-friendly editors to handle parentheses management (e.g. paredit for emacs http://emacswiki.org/emacs/ParEdit).

I've been seriously spoiled by paredit. It is a brilliant, absolutely brilliant way to edit code. Editing code written in those so called free form readable languages is absolute pain compared to structured editing in paredit. It is a reason to program in Lisps by itself. You don't need that filter on your data? Easy, you just need one keystroke (M-r) to raise the inner expression. Everyone should experience it, it certainly makes me want to write more and more code in Clojure.

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