3 ms·

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 function

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

kazinator 8y ago
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.
- rspeele 8y ago
  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.

kazinator 8y ago

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.

rspeele 8y ago
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.