3 ms·

I think it's more fundamental than that. Reading and writing Lisp means turning your brain into an AST analyzer. Some programmers love this. Most don't.

pjmlp 5y ago
Yeah although changing from print(x) to (print x) isn't that much of a deal. Where I saw fellow university friends having a problem was with thinking in Prolog and computational logic.
- mypalmike 5y ago
  You're right - at the single element level it's not that different. But the overall effect is very different. For instance, simple ergonomic things that help programmers read code, like the word "else" in an if statement/expression are elided because its AST is implicit in its position in Lisp. Similarly, you can't quickly scan a page of code for something like "=" to see what's getting assigned - you have to look for let pairs. And even then, making local variables seems to be considered wasteful in Lisp if there's a way to structure it so that the value can be placed somehow directly into the AST as the evaluation of an expression. The result is that most Lisp code I've seen has a rigidity to it of deep expressions within expressions. Deep expressions are certainly possible to implement in other languages, but it's rare to see it done so thoroughly as Lisp developers seem to enjoy doing. The result is "hard to read" in the sense that it's harder to scan syntactically (lisp having essentially no syntax) and harder to modify due to the carefully constructed expression nesting. These may both be seen as my own shortcomings wrt the language, but I think many others share them.
  - pjmlp 5y ago
    Hardly any different than hunting down for ?: on C derived languages, clever uses of LINQ inspired expressions, or why a bunch of ([{((}]]) distributed across function call, if, else, while expressions aren't nesting properly.
    - mypalmike 5y ago
      That's right. And style guidelines in those other languages tend to recommend against such things.
      - pjmlp 5y ago
        Yeah, and unless one is at a company that pretends to be like Google, largely ignored anyway.
- lmilcin 5y ago
  > (...) although changing from print(x) to (print x) isn't that much of a deal. Except it is. One is just syntax you write to get compiler to emit code you can more or less predict at "write time" and the other is a data structure you can operate on and get to emit any code you want. Most people I worked with on Common Lisp / Clojure projects never made the leap to treat the program as data structure. So it evidently is "a big deal". The whole point of Lisp is to have your program be a data structure and then have a core language that is very good at manipulating data structures, so if somebody doesn't get it they are not really realizing benefits of Lisp and they would be better off in a poorer but more approachable language like Java.
  - pjmlp 5y ago
    They have, they just did not realize that is what they were doing when placing those Spring annotations, or compiler plugins invoked via Maven dependencies.

pjmlp 5y ago

Yeah although changing from print(x) to (print x) isn't that much of a deal. Where I saw fellow university friends having a problem was with thinking in Prolog and computational logic.

mypalmike 5y ago
You're right - at the single element level it's not that different. But the overall effect is very different. For instance, simple ergonomic things that help programmers read code, like the word "else" in an if statement/expression are elided because its AST is implicit in its position in Lisp. Similarly, you can't quickly scan a page of code for something like "=" to see what's getting assigned - you have to look for let pairs. And even then, making local variables seems to be considered wasteful in Lisp if there's a way to structure it so that the value can be placed somehow directly into the AST as the evaluation of an expression. The result is that most Lisp code I've seen has a rigidity to it of deep expressions within expressions. Deep expressions are certainly possible to implement in other languages, but it's rare to see it done so thoroughly as Lisp developers seem to enjoy doing. The result is "hard to read" in the sense that it's harder to scan syntactically (lisp having essentially no syntax) and harder to modify due to the carefully constructed expression nesting. These may both be seen as my own shortcomings wrt the language, but I think many others share them.
- pjmlp 5y ago
  Hardly any different than hunting down for ?: on C derived languages, clever uses of LINQ inspired expressions, or why a bunch of ([{((}]]) distributed across function call, if, else, while expressions aren't nesting properly.
  - mypalmike 5y ago
    That's right. And style guidelines in those other languages tend to recommend against such things.
    - pjmlp 5y ago
      Yeah, and unless one is at a company that pretends to be like Google, largely ignored anyway.
lmilcin 5y ago
> (...) although changing from print(x) to (print x) isn't that much of a deal. Except it is. One is just syntax you write to get compiler to emit code you can more or less predict at "write time" and the other is a data structure you can operate on and get to emit any code you want. Most people I worked with on Common Lisp / Clojure projects never made the leap to treat the program as data structure. So it evidently is "a big deal". The whole point of Lisp is to have your program be a data structure and then have a core language that is very good at manipulating data structures, so if somebody doesn't get it they are not really realizing benefits of Lisp and they would be better off in a poorer but more approachable language like Java.
- pjmlp 5y ago
  They have, they just did not realize that is what they were doing when placing those Spring annotations, or compiler plugins invoked via Maven dependencies.