3 ms·

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 t

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.

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
- 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.
mcv 8y ago
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.
rossdavidh 8y ago
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.
- harperlee 8y ago
  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.

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

mcv 8y ago

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.

rossdavidh 8y ago

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.

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