Hacker News Reader

Comment by calibraxis | Hacker News Reader

Yes, I don't see how mainstream languages can possibly be considered aesthetically pleasant, with the possible exception of Python. I wouldn't visit a gallery that shows them off.

I find Lisp (particularly Clojure) much more aesthetically pleasant, in that it communicates better with me. With Paredit, it's even better to the touch.

(If there one day came to exist something even better on these metrics, then I'm sure I would start to prefer it aesthetically.)

View on HN

I agree I don't get the syntax argument. I am sure that as one of the other posters mentioned that one is more favored than the other, but once you know the limited syntax of a Lisp it becomes fairly readable. For me it's all about figuring out scope, once I know what denoted scope, it is fairly easy to format the code into a readable format for my mind. The thing about the Lisp dialects is the rules for syntax are so simple that once understood they become perfectly readable, at least to me they do.

> I agree I don't get the syntax argument

Doubly agreed! I learned Clojure just over a year ago and will never look back. My attitude to people complaining about parents is that that should just get over it. That one hang up is actually holding them back.

That should have been 'parens', not 'parents', of course. Although, in another context, it's completely valid!

I'll explain it to you: Where is the bug in..

(defun substitute-in-replacement ($-value replacement) (cond ((null $-value) replacement) ((null replacement) ()) ((eq (car replacement) '$) (cons $-value (cdr replacement))) (T (cons (car replacement)) (substitute-in-replacement $-value (cdr replacement)))))

From: http://www.csc.villanova.edu/~dmatusze/resources/lisp/lisp-e... with one paren moved.

I remember, when I was taking a class on AI, looking for some sort of style guideline that would help me get through the learning curve, but the FAQ (I want to say it was comp.lang.lisp) just had "coming soon." So this would be the allegro editor in 2001 or 2002. It may be obvious to an experienced hand, and perhaps if there was some sort of best practices when I was learning it I wouldn't have had the same problem, but I just remember the frustration of my mind playing tricks on me and (even with syntax highlighting) trying to match parens that I thought were there.

1 paren moved and all line breaks and indentation removed. This is intentionally obfuscated. Is there any language that is easy to read when you put five lines of code together like This?

I haven't read a lisp style guide, Emacs just takes care of indentation - it is immediately clear when a paren is wrong because the shape of the function is wrong. If you are writing lisp with an editor that doesn't do this, get a better editor, don't blame the language.

Oy. The mistake was actually in posting too late and not using the proper code tag. Don't drink and post, kids. ;) When I brought the code into vim I used the same indentation as the example, I saw that the indentation changed, but you're saying "The shape of the function is wrong."

It's quite possible my experience as a programmer today would be different than when I started -- I mean, I made it through a few chapters of SICP without such troubles, but in the back of my head was the memory of trying to figure out my logic error in a bit of code when it was really a misplaced paren.

>>Is there any language that is easy to read when you put five lines of code together like This?

Arguably Python -- but to get that, Python sacrificed the possibility of both usable anonymous functions and the possibility to cut-paste a code fragment and just ask the editor to reindent.

Hardly worth the price.

The Lisp compiler tells you:

    (defun substitute-in-replacement ($-value replacement)
      (cond ((null $-value) replacement)
            ((null replacement) ())
            ((eq (car replacement) '$)
             (cons $-value (cdr replacement)))
            (T (cons (car replacement))
               (substitute-in-replacement $-value (cdr replacement)))))

    CL-USER 5 > (compile 'substitute-in-replacement)
    ;;;*** Warning in SUBSTITUTE-IN-REPLACEMENT: CONS is called with the wrong
    ;;;     number of arguments: Got 1 wanted 2
    SUBSTITUTE-IN-REPLACEMENT

Lisp compilers able to present these error messages are in use since more than 40 years. Common Lisp has them since day one.

Took me less than a minute to find it. Just pasted the code into my Lisp editor (I use CCL), added a few line breaks in the obvious places, hit TAB a few times, and it was immediately obvious.

Actually, it's pretty obvious even without doing all that. CONS always takes two arguments.

My code doesn't look like that. For 30-50% of my code, I try to use a style more like:

  (defn thingies [id]
    (->> id
         fetch
         read-json
         :rows
         (map :thingy)))

(Of course, my code is often more complex and messier than that, even when using ->>, but some fairly significant percentage of my code does look that simple.)

I'm sure there's stuff to criticize about Clojure, but we can look at real-world code in another mainstream language (Javascript+node.js? PHP? Java?) and point out readability problems too. (Python maybe being an exception in terms of readability-in-the-small, for things that fit in the mainstream style. Though as someone pointed out, there's maybe some problems with manipulability.)

Reply on news.ycombinator.com