Hacker News Reader

Comment by jhbadger | Hacker News Reader

But that's because all the languages you know are basically dialects of each other because they all descend from ALGOL, not because they are inherently easier to understand. Similarly, someone trained in Lisp would find things like Scheme and Clojure easier to understand than something like Python because those likewise are dialects of Lisp. I'd strongly recommend studying languages different from ones you know -- they are mind expanding even if you never use them in practice. Not just Lisp, but things like Haskell, OCAML/F#, and Prolog will change the way you think.

View on HN

> not because they are inherently easier to understand

I'm honestly not sure that that's true. I would bet money that someone who primarily works in Lisp would still have an easier time sitting down and reading Python code than someone who works in Python sitting down and reading Lisp, because I think it might truly be inherently easier to understand.

There is intrinsic meaning in:

    x = 5
    let x = 5

etc., insofar as these translate character for character, word for word, into human language, whereas this simply doesn't:

    (let (x 5))

There is no such thing as "intrinsic meaning", and I think you might be confusing "human language" and "english-like". There is astonishing variation in human language.

I really like Lisp and its macros and I don't even mind the sea of parentheses. But I do think requiring everything to be done in prefix notation is a weakness. This is an argument I have seen -- it may not be the one you are trying to make, but your statement reminded me of it:

"No programming language is more or less natural than Lisp. It is merely a matter of familiarity and the way most programmers were taught."

One obvious problem is that familiarity does matter. Even ignoring all other programming languages, there is a barrier to climb for the vast numbers of beginner programmers who know English and common math notation like f(x) instead of (f x) and x < y instead of (< x y). I've also seen (- x y) be confusing as one incorrect way to read it as English in your head is "subtract x from y".

The other is that for some things, it really does seem like infix notation is inherently preferred by humans. Is there a natural language where conjunctions don't go between terms, i.e. one says "und x y z" instead of "x und y und z"?

Functions are more like verbs than conjugations. And Verb Subject Object (which is rather lisp-like) is not uncommon among natural languages. Arabic and Biblical Hebrew (Modern Hebrew not so much due to influence from Western languages) use that order a lot.

That's just fine for things that are function calls in any language. I have no preference between log(x, 10) or (log x 10).

But I do want to read some functions like conjunctions, and in Lisp, I am forced to call `and`, `or`, `<`, `/`, and pals the same way as log, print, etc. I just don't think I'll ever find:

    (and (not (is-blocked door))
         (< (height player) (height door))
         (or (is-unlocked door)
             (has-key player door)))

as readable as:

    not is_blocked(door)
    and height(player) < height(door)
    and (is_unlocked(door) or has_key(player, door))

Edit: to expand, I don't think it's a fundamental flaw of Lisp. There could easily be some syntax sugar that lets you specify precedence rules for functions and write them infix, just like Haskell lets you write either `(+) 1 2` or `1 + 2`. It would de-sugar to the same sexpr.

I know this can be done as a macro, in fact I did it for elisp several years ago ( https://github.com/rspeele/infix.el ) but it is really just a toy for personal use. If an infix operator system came out of the box and its use was encouraged for certain common operators, I think that would be a net positive, but most Lispers disagree with me there (if I had to guess).

The Lisp expression is a nice sideways tree, where we immediately see that three conditions are joined by and. When I look at it, I see this:

     and --.-- not (is-blocked door)
           :-- < (height player) (height door)
           `-- or --.---(is-unlocked door)
                     `--(has-key player door)

The other one looks like a bit of a lorem ipsum paragraph to me.

I guess it comes down to different strokes for different folks. It would be interesting if there was a website that quizzed you on randomly generated expressions like these, giving you S-expr forms sometimes and ALGOL/infix operator forms other times, and asking you whether the expression is true or false given a set of variable values.

Naively I would guess that I would do best on infix exprs and you would do best on s-exprs.

But I could imagine other results, like s-exprs giving me a speed disadvantage but an accuracy advantage (either because I had to read them more carefully or because they eliminate reliance on precedence rules). Or there may be other quirks, like maybe S-exprs read better for larger, multiline conditions while infix reads better on short one-liners with <= 3 operations.

It reeks of effort so I'm not going to make such a site, but I do wonder what the results would be.

That may be fine for ancient Jews and Arabs, but it still presents a bit of an obstacle to speakers of Germanic languages, including English. With the exception of Yoda, I suppose. I bet Lisp would be totally natural to him.

I have created non trivial projects in PHP and Ruby and have used a lot of other languages to do things before moving to Clojure... probably about 5 years programming before using my first lisp.

For me I find that s-expressions are the easiest thing to comprehend. Every other language is loaded with syntax and with lisp it's just mainly just (function args).

I wanted to test your argument and I have never looked at common lisp before, I just skimmed some source code from this project https://github.com/stumpwm/stumpwm and it's extremely easy for me to parse.

Comparing this to new variants of Javasscript that seem to come out biannually with some new syntax, I have no idea what's going on and have to look up references on syntax to begin to understand anything.

I guess at the end it's subjective, but lisps have ruined other languages for me.

> There is intrinsic meaning in:

No, there isn't. That just happens to be closer to the notation you were taught in elementary school, so you're more familiar with it. If you were taught s-expressions in elementary school (and this would actually be a really good idea) you would say the exact opposite. In fact, once you understand s-expressions, all other notations seem awkward and arbitrary. That's actually the reason that Lisp persists, because it's a kind of natural "local maximum" in notational idea space. It just happens to be one that very few people ever reach because of the damage done to them in their primary school education.

An objective test of "easy to understand" would be, how close does the code look, to how a programmer might pseudocode it on a whiteboard? I don't recall seeing much significant difference between how Java, Python, or Javascript devs pseudocode on a whiteboard, so it's something approximately close to how a human thinks about it in the absence of syntax issues.

I think Python code looks closer to this pseudocode than Lisp does. Once you become an experienced Lisp programmer, it probably takes little effort to convert that mental pseudocode into Lisp, but I believe it does take intrinsically less effort in Python.

I disagree. People pseudocode in algol style if they are used to program in e.g. python, or discussing about an imperative algorithm, or communicating to algol-style programmers. But if you pseudocode in a lisp context you write s-expressions, the same way that if you are discussing SQL you may draw an ER diagram, or if you are talking math or abstract topics you write mathy things in a declarative style (such as writing sigmas or inverted As and Es). No one writes imperative pseudocode if you are going to program in prolog.

In sum, using pseudocode is just temporarily liberating yourself from pesky syntax adherence in prder to better quickly iterate over an idea, but in that discussion you always have the target in mind from the onset.

I did Prolog back in university. That was really cool. Miranda was our introduction in functional programming there. I don't know Haskell, but I really like some aspects of Scala. But Scala is still not all that different from what I know. Lisp is way more alien than that.

Reply on news.ycombinator.com