4 ms·

> 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

by wycy 8y ago

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

kazinator 8y ago
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.
- rspeele 8y ago
  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"?
  - jhbadger 8y ago
    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.
    - rspeele 8y ago
      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.
Naomarik 8y ago
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 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.
lisper 8y ago
> 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.

by wycy 8y ago

kazinator 8y ago

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.

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

Naomarik 8y ago

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

lisper 8y ago

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