4 ms·

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,

by 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
        greendestiny 19y ago
        People prefer infix with arithmetic operators. Why? Probably because thats what they know. If your example used named functions it would look like this: (plus 3 4 (minus 1 (divide 3 4)) (times (minus 9 2) 8 3)) plus(3, 4, minus(1, divide(3, 4)), times(minus(9, 2), 8, 3)) Anyway none of this has anything to do with the assertion that people only use explicit state in procedural languages because the languages don't support nesting well. I prefer functional programming to procedural but that doesn't ring true for me at all. As a matter of fact I prefer functional languages that don't have lisp's bracketing syntax.
  - greendestiny 19y ago
    I think people tend to think in terms of explicit state as a default rather than being forced to by poor syntax. I've had experience teaching amateurs and this really tends to be bourne out in what I've seen. Students tend to find functional languages very easy to use until the problems start to involve things that need to change over time and then they can't get past the idea of storage.
    - curi 19y ago
      nothing about s-expressions is bad for using state and little nesting. something about C/etc is bad for nesting heavily. Edit: example. both lisp-style versions are nicer. if C has advantages, it isn't in making state work better. (def avg (numbers) (/ (sum numbers) (count numbers))) (def avg (numbers) (= total-number (sum numbers)) (= total-count (count numbers)) (= result (/ total-number total-count)) result) function avg (numbers) { /(sum(numbers) count(numbers)) } function avg(numbers) { =(total-number sum(numbers)) =(total-count count(numbers)) =(result /(total-number(total-count)) result }
      - greendestiny 19y ago
        State in procedural languages has more to do with side effects than nice syntax for it. This article has a nice description of how why explicit state is good in procedural languages sometimes: http://prog21.dadgum.com/3.html http://prog21.dadgum.com/3.html
        curi 19y ago
        lisp can do side effects. as i demonstrated. what's the problem?
        tjr 19y ago
        "... some people prefer not to commingle the functional, lambda-calculus part of a language with the parts that do side effects. It seems they believe in the separation of Church and state." --Guy Steele
- anamax 19y ago
  > but a little study in compilers and formal languages and its obvious that all languages are describing trees. That's not the issue - the issue is that lisp folk can easily write programs that manipulate their code. Other folks have to get a parser involved. In most cases, that means that people who write programs in "not lisp" rarely have automated methods for manipulating their code. They don't define dsls. They have macros weaker than regular expressions. Programs have a lot of structure that can't be exploited without being able to manipulate code.
  - greendestiny 19y ago
    I agree completely. However, the idea that only lisp describes trees, or that the describing is where lisp is powerful is wrong. All languages describe trees and the process is not that obscure. Like I said elsewhere I could write a lisp like language with no lists, no lamdas and no macros and it would very clearly describe a tree. It wouldnt be a powerful language.
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..."

by curi 19y ago

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
      - greendestiny 19y ago
        People prefer infix with arithmetic operators. Why? Probably because thats what they know. If your example used named functions it would look like this: (plus 3 4 (minus 1 (divide 3 4)) (times (minus 9 2) 8 3)) plus(3, 4, minus(1, divide(3, 4)), times(minus(9, 2), 8, 3)) Anyway none of this has anything to do with the assertion that people only use explicit state in procedural languages because the languages don't support nesting well. I prefer functional programming to procedural but that doesn't ring true for me at all. As a matter of fact I prefer functional languages that don't have lisp's bracketing syntax.
- greendestiny 19y ago
  I think people tend to think in terms of explicit state as a default rather than being forced to by poor syntax. I've had experience teaching amateurs and this really tends to be bourne out in what I've seen. Students tend to find functional languages very easy to use until the problems start to involve things that need to change over time and then they can't get past the idea of storage.
  - curi 19y ago
    nothing about s-expressions is bad for using state and little nesting. something about C/etc is bad for nesting heavily. Edit: example. both lisp-style versions are nicer. if C has advantages, it isn't in making state work better. (def avg (numbers) (/ (sum numbers) (count numbers))) (def avg (numbers) (= total-number (sum numbers)) (= total-count (count numbers)) (= result (/ total-number total-count)) result) function avg (numbers) { /(sum(numbers) count(numbers)) } function avg(numbers) { =(total-number sum(numbers)) =(total-count count(numbers)) =(result /(total-number(total-count)) result }
    - greendestiny 19y ago
      State in procedural languages has more to do with side effects than nice syntax for it. This article has a nice description of how why explicit state is good in procedural languages sometimes: http://prog21.dadgum.com/3.html http://prog21.dadgum.com/3.html
      - curi 19y ago
        lisp can do side effects. as i demonstrated. what's the problem?
        tjr 19y ago
        "... some people prefer not to commingle the functional, lambda-calculus part of a language with the parts that do side effects. It seems they believe in the separation of Church and state." --Guy Steele
anamax 19y ago
> but a little study in compilers and formal languages and its obvious that all languages are describing trees. That's not the issue - the issue is that lisp folk can easily write programs that manipulate their code. Other folks have to get a parser involved. In most cases, that means that people who write programs in "not lisp" rarely have automated methods for manipulating their code. They don't define dsls. They have macros weaker than regular expressions. Programs have a lot of structure that can't be exploited without being able to manipulate code.
- greendestiny 19y ago
  I agree completely. However, the idea that only lisp describes trees, or that the describing is where lisp is powerful is wrong. All languages describe trees and the process is not that obscure. Like I said elsewhere I could write a lisp like language with no lists, no lamdas and no macros and it would very clearly describe a tree. It wouldnt be a powerful language.

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