5 ms·

Lisp code is written to be easily parsed and manipulated by software. Python is written to be easily parsed and manipulated by humans. When I first came to Pyt

Lisp code is written to be easily parsed and manipulated by software. Python is written to be easily parsed and manipulated by humans. When I first came to Python I didn't need to become an expert Python programmer to understand Python source code without much effort. But I still haven't gotten to the point of looking at a piece of Lisp code and right away having an idea of what it does. Eventually your brain recognizes the patterns (but heck if you write assembly long enough you start to see the patters of common C control structures). But I think it all depends on the problem at hand. Certain things I can write faster in Java than Python (occasionally static typing and interfaces can make large programs easier to keep in one's head and work with). Most things I can write easier in Python. And a few things I can write easier in Lisp (primarily writing programs that manipulate trees and essentially create mini-languages).

curi 19y ago
in lisp you write trees. in other languages, you write weird things that get turned into trees, seemingly by magic. other languages seem easier to understand, to most people. this is because they have a lot of experience with all that magic -- it has become a tradition. if you're better at normal languages, go ahead and use them. i don't care. but they are not objectively easier to read, they are much harder and more complicated.
- greendestiny 19y ago
  Yeah I know the lisp trees thing is something that gets said a lot, but I really don't see how inexplicable the transformation of other languages into trees is. Ultimately in lisp you have the most flexibility in manipulating the tree, but a little study in compilers and formal languages and its obvious that all languages are describing trees. Objectively easier to read? Thats a strange road to go down. Theres no reason that languages with grammars that generate strange and wacky trees might not suit a human's ability to describe formal solutions better. I think the reason people find languages like C easier to understand is all in the state handling anyway.
  - curi 19y ago
    the reason people put so much state and local variables in their program is that non-lisp languages get hard to read if you nest a lot, so they have to. and that is basically what i mean about lisp being objectively easier to read: the notation actually works better. so you can nest a lot and it doesn't get horrible. but also, you don't have to, and then it's about the same.
    - curi 19y ago
      BTW, tell me which of these makes more sense: (+ 3 4 (- 1 (/ 3 4)) (* (- 9 2) 8 3)) +(3 4 -(1 /(3 4)) *(-(9 2) 8 3)) why oh why would you want a function to be in the same grouping (set of paren) with arguments to another function, instead of grouped with its own arguments? the less you nest, the less it matters. but it is not a matter of taste which way makes more sense and scales better.
      - greendestiny 19y ago
        Most people find infix easier to read. I really think the idea that lisp's advantage comes from having operators in the same group as parameters is ridiculous. To me lisp's power is in the orthogonality of statements, functions (and anonymous functions), data and lists. You could make a language that had very lisp like syntax but didn't support things like lists and lamda functions and it would equally clearly define a tree. That language would be just about completely useless.
        curi 19y ago
        infix and whether to call functions like foo(x y) or (foo x y) are separate issues. if infix is C's advantage, that is pretty silly. because first of all there is only a limited number of infix operators, and when you make your own constructs they are prefix, but different from s-expressions in the kinda silly way i illustrated. anyway, you can put infix into a lisp. people don't usually want to because it kinda sucks. unless you're working in certain domains. infix means: - memorizing order of operations and remembering it whenever reading code (does == or && have higher precedence? they didn't drill that one into us in middle school, so it doesn't feel quite so obvious as arithmetic order of operations) - losing characters for use in identifiers - commas in argument lists - paren for changing order of operations - functions that take a predefined number of arguments that has to be 1 or 2 - infix only works with a limited number of built in things, it doesn't scale nicely. i suppose you could change this, e.g. make # a special character, and then you can define infix foo then write arg1#foo#arg2. but like, that's ridiculous. no one wants to do that with functions in general. they only want to do it with math because they hate math and don't want to have to understand anything about it, they just want to use it mechanically like they memorized in school. - infix is an approach with less generality
- mark-t 19y ago
  You haven't taken this thought process far enough. In assembly, according to you, you don't write trees. I guess this means you write sequences of commands (procedures), and you store data in a state system. Well, in that case, Lisp gets turned into procedures and a state system, seemingly by magic. Maybe people have an easier time understanding other languages because they work in the same way the computer does.
  - curi 19y ago
    you're saying lisp is harder to understand b/c it's higher level and has more abstraction away from the way computers really work and away from assembly language (which are easy to understand, or something)? you don't need to know what your lisp gets turned into. you do need to know something about what tree your lisp, or infix math, or chained C functions, get turned into. you have to actually know which tokens go into which branches. you have to know what functions are being called on what tokens, in what order.
    - mark-t 19y ago
      Nah, I really wasn't making any claims. I just didn't buy the argument. Personally, I find Lisp easier to write but much harder to read. The syntax certainly plays some role in that, but I don't think it's the key. The problem, I think, is that it's just too dense. When you use a lot of intermediate variables, you get to name them something relevant. But Lisp code (or at least my Lisp code) usually doesn't have all of this context floating around, so it's harder to figure out what's going on.
      - curi 19y ago
        I agree throwing in a lot of variables with names can make code easier to read. You can also achieve the same effect by making one-line functions that just call a few other functions. It's quite possible that the prevalent style of writing Lisp code is in some ways worse than the dominant style for C/java/etc. But that is a different issue than the language itself, which can, for example, create a bunch of name intermediate variables, if you want them.
- projectileboy 19y ago
  I very, very strongly agree with you. A couple years ago I went through the exercises in SICP, and I remember being shocked at how hard it was for me to look at and understand Scheme code after 10 years of looking at C, C++, Java and C#. It felt really weird, because I remember being an undergrad and thinking that Fortran and Pascal and C looked really hard, but that the Scheme code in SICP felt very intuitive.
  - Hexstream 19y ago
    "Anyone can learn Lisp in a day, but if he'd previously been exposed to C, it'd take 3 days..."
asdflkj 19y ago
Where is the evidence that "Python is written to be easily parsed and manipulated by humans", as opposed to a subset of humans with certain (changeable) habits of mind? It seems silly to demand science in a discussion of programming languages, but you're making some big assumptions about how human mind works. Considering how recent the discipline of programming is, and how fast it's evolving, what makes you think the designers of Python have discovered some immutable laws of the mind--ones that go against common sense, no less? (Common sense being that fewer tokens is better.)
- imsteve 19y ago
  Because it's pseudocode that runs. Look at how many times non-python programmers have written code examples and someone says to them that "that's almost identical to python." This is a very easily testable theory.
  - brlewis 19y ago
    Yes, it's easily testable. Just write a pseudocode switch statement. That's almost identical to python, but how do you make it exactly identical? Nobody knows. http://www.python.org/dev/peps/pep-3103/ http://www.python.org/dev/peps/pep-3103/ Tested. Found false. Now how about Scheme? I recently tested that myself by using a case expression, a syntax I rarely use. I didn't have to look in R5RS. I just put the parens where they would naturally go for the most obvious syntax tree, and it worked. For someone steeped in Algol-like languages, Python will be easy to get started with. Scheme/Lisp takes longer to get started, but once you get it, you don't have to keep going back to the documentation. It just makes sense.
    - imsteve 19y ago
      Beyond idiotic. Clearly I'm not drunk enough for that inanity.
      - brlewis 19y ago
        case beercount 0 1 "inanity" 2 3 4 "good sense" else "genius" Drink all you want. The pseudocode above still translates into Scheme in a straightforward way. The Python community still can't agree how to translate it.
pg 19y ago
Python is written to be easily parsed and manipulated by humans ... used to C You sound like an English speaker claiming that English is easier for people to understand than other languages. There's nothing intrinsically human about infix syntax. It's just a question of what you're used to. I honestly find prefix syntax (or lack thereof) much easier to read, because that's what I'm used to.
- cstejerean 19y ago
  it's not just prefix vs infix. a.b().c().d().e() is easier to read to me than (e (d (c (b a)))) I also prefer object.method() instead of (method object). Now granted the OO model used in Lisp allows for some really powerful things (like methods that specialize on more than one object and adding before, after and around methods to modify code).
  - JFT 19y ago
    To each is own :) After almost 15 years of OO in C++ I jumped in the functional bandwagon (Haskell, Common Lisp etc) I sure find (e (d (c (b a)))) easier to read. Here's why: In your first exemple "a.b().c().d().e()" you have to read up to the end to know what you are "really" doing, i.e. calling e() whereas in "(e (...))" up front I know the most important part: I'm calling function "e" on something. The funniest part is even if you consider it from object perspective the message is more important at least to my view, even OO father Alan Kay thinks that too (see Computer Revolution has not happend). As someone said before what we know condition us to what will be easier to read, to that I'd like to add that it is also "how we undestand thing". Sure I know C++/Java syntax better but the way I conceptualize OO is more through message than object... Think about it this way do you like when you speak to someone and they start by a very lengthy introduction which you have no idea where it is leading to realise at the end that they were trying to sell you something? Or do you prefer to know up front and then listen for as much detail as you need before determining if you are interested or not?
- bayareaguy 19y ago
  Lisp expressions are different from what most people are taught in early math classes. As a result more people find y=m * x+b easier than (let ((y (+ (* m x) b))) y) until they get the chance to spend some quality time with a REPL.

curi 19y ago

in lisp you write trees. in other languages, you write weird things that get turned into trees, seemingly by magic. other languages seem easier to understand, to most people. this is because they have a lot of experience with all that magic -- it has become a tradition. if you're better at normal languages, go ahead and use them. i don't care. but they are not objectively easier to read, they are much harder and more complicated.

greendestiny 19y ago
Yeah I know the lisp trees thing is something that gets said a lot, but I really don't see how inexplicable the transformation of other languages into trees is. Ultimately in lisp you have the most flexibility in manipulating the tree, but a little study in compilers and formal languages and its obvious that all languages are describing trees. Objectively easier to read? Thats a strange road to go down. Theres no reason that languages with grammars that generate strange and wacky trees might not suit a human's ability to describe formal solutions better. I think the reason people find languages like C easier to understand is all in the state handling anyway.
- curi 19y ago
  the reason people put so much state and local variables in their program is that non-lisp languages get hard to read if you nest a lot, so they have to. and that is basically what i mean about lisp being objectively easier to read: the notation actually works better. so you can nest a lot and it doesn't get horrible. but also, you don't have to, and then it's about the same.
  - curi 19y ago
    BTW, tell me which of these makes more sense: (+ 3 4 (- 1 (/ 3 4)) (* (- 9 2) 8 3)) +(3 4 -(1 /(3 4)) *(-(9 2) 8 3)) why oh why would you want a function to be in the same grouping (set of paren) with arguments to another function, instead of grouped with its own arguments? the less you nest, the less it matters. but it is not a matter of taste which way makes more sense and scales better.
    - greendestiny 19y ago
      Most people find infix easier to read. I really think the idea that lisp's advantage comes from having operators in the same group as parameters is ridiculous. To me lisp's power is in the orthogonality of statements, functions (and anonymous functions), data and lists. You could make a language that had very lisp like syntax but didn't support things like lists and lamda functions and it would equally clearly define a tree. That language would be just about completely useless.
      - curi 19y ago
        infix and whether to call functions like foo(x y) or (foo x y) are separate issues. if infix is C's advantage, that is pretty silly. because first of all there is only a limited number of infix operators, and when you make your own constructs they are prefix, but different from s-expressions in the kinda silly way i illustrated. anyway, you can put infix into a lisp. people don't usually want to because it kinda sucks. unless you're working in certain domains. infix means: - memorizing order of operations and remembering it whenever reading code (does == or && have higher precedence? they didn't drill that one into us in middle school, so it doesn't feel quite so obvious as arithmetic order of operations) - losing characters for use in identifiers - commas in argument lists - paren for changing order of operations - functions that take a predefined number of arguments that has to be 1 or 2 - infix only works with a limited number of built in things, it doesn't scale nicely. i suppose you could change this, e.g. make # a special character, and then you can define infix foo then write arg1#foo#arg2. but like, that's ridiculous. no one wants to do that with functions in general. they only want to do it with math because they hate math and don't want to have to understand anything about it, they just want to use it mechanically like they memorized in school. - infix is an approach with less generality
mark-t 19y ago
You haven't taken this thought process far enough. In assembly, according to you, you don't write trees. I guess this means you write sequences of commands (procedures), and you store data in a state system. Well, in that case, Lisp gets turned into procedures and a state system, seemingly by magic. Maybe people have an easier time understanding other languages because they work in the same way the computer does.
- curi 19y ago
  you're saying lisp is harder to understand b/c it's higher level and has more abstraction away from the way computers really work and away from assembly language (which are easy to understand, or something)? you don't need to know what your lisp gets turned into. you do need to know something about what tree your lisp, or infix math, or chained C functions, get turned into. you have to actually know which tokens go into which branches. you have to know what functions are being called on what tokens, in what order.
  - mark-t 19y ago
    Nah, I really wasn't making any claims. I just didn't buy the argument. Personally, I find Lisp easier to write but much harder to read. The syntax certainly plays some role in that, but I don't think it's the key. The problem, I think, is that it's just too dense. When you use a lot of intermediate variables, you get to name them something relevant. But Lisp code (or at least my Lisp code) usually doesn't have all of this context floating around, so it's harder to figure out what's going on.
    - curi 19y ago
      I agree throwing in a lot of variables with names can make code easier to read. You can also achieve the same effect by making one-line functions that just call a few other functions. It's quite possible that the prevalent style of writing Lisp code is in some ways worse than the dominant style for C/java/etc. But that is a different issue than the language itself, which can, for example, create a bunch of name intermediate variables, if you want them.
projectileboy 19y ago
I very, very strongly agree with you. A couple years ago I went through the exercises in SICP, and I remember being shocked at how hard it was for me to look at and understand Scheme code after 10 years of looking at C, C++, Java and C#. It felt really weird, because I remember being an undergrad and thinking that Fortran and Pascal and C looked really hard, but that the Scheme code in SICP felt very intuitive.
- Hexstream 19y ago
  "Anyone can learn Lisp in a day, but if he'd previously been exposed to C, it'd take 3 days..."

asdflkj 19y ago

Where is the evidence that "Python is written to be easily parsed and manipulated by humans", as opposed to a subset of humans with certain (changeable) habits of mind? It seems silly to demand science in a discussion of programming languages, but you're making some big assumptions about how human mind works. Considering how recent the discipline of programming is, and how fast it's evolving, what makes you think the designers of Python have discovered some immutable laws of the mind--ones that go against common sense, no less? (Common sense being that fewer tokens is better.)

imsteve 19y ago
Because it's pseudocode that runs. Look at how many times non-python programmers have written code examples and someone says to them that "that's almost identical to python." This is a very easily testable theory.
- brlewis 19y ago
  Yes, it's easily testable. Just write a pseudocode switch statement. That's almost identical to python, but how do you make it exactly identical? Nobody knows. http://www.python.org/dev/peps/pep-3103/ http://www.python.org/dev/peps/pep-3103/ Tested. Found false. Now how about Scheme? I recently tested that myself by using a case expression, a syntax I rarely use. I didn't have to look in R5RS. I just put the parens where they would naturally go for the most obvious syntax tree, and it worked. For someone steeped in Algol-like languages, Python will be easy to get started with. Scheme/Lisp takes longer to get started, but once you get it, you don't have to keep going back to the documentation. It just makes sense.
  - imsteve 19y ago
    Beyond idiotic. Clearly I'm not drunk enough for that inanity.
    - brlewis 19y ago
      case beercount 0 1 "inanity" 2 3 4 "good sense" else "genius" Drink all you want. The pseudocode above still translates into Scheme in a straightforward way. The Python community still can't agree how to translate it.

pg 19y ago

Python is written to be easily parsed and manipulated by humans ... used to C You sound like an English speaker claiming that English is easier for people to understand than other languages. There's nothing intrinsically human about infix syntax. It's just a question of what you're used to. I honestly find prefix syntax (or lack thereof) much easier to read, because that's what I'm used to.

cstejerean 19y ago
it's not just prefix vs infix. a.b().c().d().e() is easier to read to me than (e (d (c (b a)))) I also prefer object.method() instead of (method object). Now granted the OO model used in Lisp allows for some really powerful things (like methods that specialize on more than one object and adding before, after and around methods to modify code).
- JFT 19y ago
  To each is own :) After almost 15 years of OO in C++ I jumped in the functional bandwagon (Haskell, Common Lisp etc) I sure find (e (d (c (b a)))) easier to read. Here's why: In your first exemple "a.b().c().d().e()" you have to read up to the end to know what you are "really" doing, i.e. calling e() whereas in "(e (...))" up front I know the most important part: I'm calling function "e" on something. The funniest part is even if you consider it from object perspective the message is more important at least to my view, even OO father Alan Kay thinks that too (see Computer Revolution has not happend). As someone said before what we know condition us to what will be easier to read, to that I'd like to add that it is also "how we undestand thing". Sure I know C++/Java syntax better but the way I conceptualize OO is more through message than object... Think about it this way do you like when you speak to someone and they start by a very lengthy introduction which you have no idea where it is leading to realise at the end that they were trying to sell you something? Or do you prefer to know up front and then listen for as much detail as you need before determining if you are interested or not?
bayareaguy 19y ago
Lisp expressions are different from what most people are taught in early math classes. As a result more people find y=m * x+b easier than (let ((y (+ (* m x) b))) y) until they get the chance to spend some quality time with a REPL.