9 ms·

IMO Lisp is just overrated, it lacks visual clues, reads right to left with horrible nesting etc.. Sure it has some good concepts. But fanboys on internet make

IMO Lisp is just overrated, it lacks visual clues, reads right to left with horrible nesting etc.. Sure it has some good concepts. But fanboys on internet make it seem like some God tier thing.

coldtea 7y ago
"Some good concepts"? It was the first language to add "if/else" constructs, GC, closures, first class functions, reference semantics, and recursion. It took between 5 to 40 years before these became available in mainstream languages (conditionals like if/else were adopted early, GC not so much, closures took even more). Add to that macros and the flexibility of runtime evaluation / code creation, which most mainstream languages still lack. And of course, Lisp's rules remain (and will always be) the most succinct way to define a full blown programming language with meta-programming facilities to boot -- as opposed to a mere Turing machine like thing or assembler. >IMO Lisp is just overrated, it lacks visual clues, reads right to left with horrible nesting etc.. This doesn't make any sense... The nesting is the same as in almost any language. "reads right to left" - huh? You know that Lisp code can be indented right?
- Joker_vD 7y ago
  > It was the first language to add "if/else" constructs, GC, closures, first class functions, reference semantics, and recursion. "Lisp is still #1 for key algorithmic techniques, such as recursion and condescension."
- lkschubert8 7y ago
  I think they are referring to the nested nature of lisp function calls. (second-fn (first-fn val)) I think that is really just personal preference/what you were taught as opposed to good or bad language design. But it really doesn't matter as one of the big benefits of lisp is it's ability to be metaprogrammed. That same example could be rewritten in clojure as (-> val first-fn second-fn) thanks to macros and doesn't suffer from the right->left reading.
  - coldtea 7y ago
    > I think they are referring to the nested nature of lisp function calls. (second-fn (first-fn val)) How's this different than: secondFn(firstFn(val)) other than the placement of parenthesis, the two cases read exactly the same, left to right.
    - lkschubert8 7y ago
      I've seen a lot of breaking that out into the following in imperative languages. var intermediaryVal = firstFn(val); var result = secondFn(intermediaryVal);
      - slifin 7y ago
        (let [intermediary-val (first-fn val) result (second-fn intermediary-val)]) Or as one of the parents said (-> val first-fn second-fn)
    - phyrex 7y ago
      I'm on the side of lisp here, but in OOP you'd usually write something like val.firstFn().secondFn()
- jecel 7y ago
  One small detail - though COND and IF/ELSE are very closely related, they aren't quite the same thing. Early Smalltalk also started out with COND (a right arrow which made code look like modern switch/case) and later evolved to #ifTrue:ifFalse: which is still postfix, so feels backwards compared to other languages. Lisp and Scheme got more conventional if/else eventually.
  - LandR 7y ago
    Something I discovered about Clojure's cond recently. It usually looks likethis: (cond (< a b) (println "a < b") (> a b) (println "a > b") :else (println "a = b")) I thought the :else had to be :else, but it only needs to be truthy, so it can be anything that isn't false or nil (which makes sense as you want it to always execute that form if no others match). So this is just the same: (cond (< a b) (println "a < b") (> a b) (println "a > b") :hotdog (println "a = b")) Probably obvious to everyone else but it was a bit of a "duh, of course!" moment for me.
    - sparkie 7y ago
      It's conventional in Scheme and Lisp to just use `#t` directly to match anything.
    - lispm 7y ago
      In Lisp usually all non-nil values mean true. CL-USER 13 > (let ((a 1) (b 2)) (cond ((> a b) 'foo) (:hello :there))) :THERE In some early Lisp dialects not all objects (other than lists and symbols) would be self-evaluating, so one would have to quote them.
    - kazinator 7y ago
      In traditional Lisp and common Lisp, and similar dialects, the symbol t is customarily used as the catch all last case. There is an interesting situation is in the case family of constructs which match an input value against keys, in Common Lisp. Inspired by cond, the t symbol also serves as the fallback in case when the key doesn't match the other cases. So that is to say: (case (expr) (a ...) (b ...) (42 ...) (t ...)) ;; <-- this isn't matching on the t symbol! Common Lisp also supports the symbol otherwise in place of t. But the programmer may also sometimes have the t symbol as a specific key value; or likewise the otherwise symbol. That requirement is handled by putting the key into a list: (case (expr) (a ...) ... ((t) ...)) ;; <- match on t
- LandR 7y ago
  Nesting can be sorted via macros, e.g. closures threading macros (defn unique [str] (->> (str/split str #"\s+") (map #(Integer/parseInt %)) (partition-by even?) (take-while #(not= (count %) 1)) (first) (count) (inc))) (unique "2 4 6 8 7 10 12") => 5
- tabtab 7y ago
  As far as "Lisp lacks visual clues", after many heated debates on this, I've concluded that the ugliness and rigidness of "production" languages enforces certain visual and syntactic standards that makes reading others' code easier. Indentation of Lisp won't "solve" this because production languages also can be indented. It's not a difference maker. Parameter lists are wrapped in parenthesis and separated with commas, while code blocks are wrapped in curly braces and separated with semi-colons. Lisp won't do this because it's then harder to blur/merge/change the distinction between code and data, which is the very power of Lisp. Building architectural eyesores is probably not a rational plan for a city, but dammit, those eyesores help you know and remember where you are. Some people have a certain kind of eye and/or brain that allows them to read Lisp quickly, but this may not be universal. Some say "with enough time you'll get used to it", but the fact Lisp has been around for 60 odd years without catching on in the mainstream is evidence of this. Somebody would be rich by now off its alleged advantages if they were real (beyond a "write-only" startup language). Functional languages are better at expressing ideas but slower at communicating them to other readers, on average. I also personally find them difficult to debug because they don't have enough "intermediate state" to x-ray for debugging purposes. Here's a conceptual illustration: // imperative: a = af(param); b = bf(a); c = cf(b); // functional c = cf(bf(af(param))); In a debugger and/or Write statements I can readily examine intermediate values "a" and "b". Not so with functional. SQL presents a similar issue. Its new WITH statements help out, but only partly. Divide-and-conquer works better if you can examine the divisions.
  - armitron 7y ago
    You know your brain adapts so you can read something easier/faster the more you are exposed to it. For me, Lisp code couldn't be easier/faster to read and comprehend. I'm convinced most of the people making jokes about parentheses or Lisp code being hard to read are superficially dismissing it without putting in even a minimal effort of working with it. Things that don't immediately click are discarded. Individual curiosity ("Really smart people say great things about this, I wonder why that is..") leading to individual effort leading to deep understanding is not the prevailing attitude. Sad state of affairs.
- deleted 7y ago
  [deleted]
iLemming 7y ago
No, Lisp does not lack visual clues. But yes, very often people complain about Lisp readability. And that stems from the lack of familiarity, most people are familiar with the infix notation, but not prefix, used in Lisp. But I have seen many times, people who pick up Lisp (Clojure, Racket, etc.) as their first programming language - they do just fine, a matter of fact - they later find code written in other languages harder to read. Unlike other languages, Lisp sometimes is difficult to read by just looking at it. Staring at Lisp code, examining its "static" properties without prior training indeed may pose a challenge. But there is a way to learn how to parse Lisp code mentally. And the best way of learning that is by editing it. First, you need to find an IDE that supports structural editing of symbolic expressions (or s-exps). Basically, it would help if you learned a few operations: slurp, barf, transpose, raise, kill s-exp, yank s-exp Depending on the IDE you use, they may be called differently, and there may be more, these are the basic ones. Once you learn those basic operations, you are now ready to untangle "unreadable" Lisp. The trick is to change the code while you read it. Similar to how Tony Stark looks at the hologram of a model and moves his hands outward, forcing the hologram to expand, then he picks one of the parts, studies it, maybe completely removes it. He then would move his hands in a closing motion, and hologram would "assemble." That's how you work with Lisp. So, for example, you read a function, if necessary, extract things, pick an expression, evaluate it, etc. Once you gain a good understanding of what the function does, you can undo all the changes, or if you think you have improved it - do save. In other languages, when the structure of the code is settled, it's more challenging to pick it apart, move things in and out. You are forced to read the code "top to bottom." But in Lisp, code is a living, breathing thing. You basically feel like performing a surgery - you can tweak things, try them, and see instantaneous feedback in the REPL. In other languages, code is "dead," until you save it, (re)compile it and execute it. And REPL in those languages is "crippled" and not a fully-fledged "true" REPL like in Lisp. Being able to pick any [sub]expression and evaluate it, without any kind of prior ceremony is truly liberating and empowering. It takes time, for some it's hours, for others - weeks, but eventually you will stop seeing parentheses, and instead, you will see structure, consistency, and meaning. And Lisp becomes more readable than any other language you've used before.
- tabtab 7y ago
  Re: It takes time, for some it's hours, for others - weeks, but eventually you will stop seeing parentheses, and instead, you will see structure, consistency, and meaning. And Lisp becomes more readable than any other language you've used before. I'd like to see a university test this theory. I suspect it's subjective and varies greatly per individual, but testing on say 100 random subjects could better resolve the Great Lisp Dispute.
iLemming 7y ago
> But fanboys on internet make it seem like some God tier thing Lisp is based on math and logic. And if there's a God, he probably speaks Math. So, maybe those fanboys onto something here. But, seriously, once you learn a bit of Lisp, you realize that Lisp has influenced every single modern programming language. Essentially, no matter what PL you are programming in - we are all programming in a Lisp. Sometimes your language of choice adheres to core principles of Lisp, sometimes that connection is loose. Nevertheless, there's plenty of Lisp in every modern programming language. So, no. Lisp is not overrated.
- tabtab 7y ago
  I personally admire Lisp conceptually. It's a work of art. It's the practical use as tool in a team environment that you cannot carefully control hiring is where I have skepticism.
  - iLemming 7y ago
    I've started using Clojure a few years ago as my primary language of choice. I switched multiple jobs since then. I never had a problem with finding one. I worked once for a big fin-tech company. We never said that knowing Clojure was a requirement, but we admitted that the preference would be given to people at least interested in Clojure. And you know what? It helped us to build an incredibly strong team. Even though not everyone used Clojure. Some teams used languages like Ruby, Go, and Javascript. If I were given a choice to either hire five Javascript/Python/Go programmers and pay them each 100K/Y or hire only three Lispers and pay them each 200K/Y, I would go for the latter. ROI, in that case, would be much, much higher. And Clojure is a very, very practical tool. Just watch Rich Hickey talks, you will see that the pragmatism of the language is paramount for everyone who uses it.
    - tabtab 7y ago
      Re: If I were given a choice to either hire five Javascript/Python/Go programmers and pay them each 100K/Y or hire only three Lispers and pay them each 200K/Y, I would go for the latter. ROI, in that case, would be much, much higher. If that were universally true, one could out-compete the entrenched software companies and be the next Bill Gates. The common "production" languages are successful I believe because they offer a semi-consistent way to doing things, and for large or fungible staff, that turns out more important than less lines-of-code or powerful abstractions. In business, communicating between humans is more important than parsimony. This is based on direct and indirect experience. My own "grand abstractions" have been rejected also at times. The "best" programmers are often those who have a decent understanding of the domain, UI design, and various "team" skills. Somebody good in all those may not necessary be the best abstractionist or parsimonist. The best programmers get B's on lots of topics rather than an A+ in just one, such as abstraction. I'm just the messenger. Scott Adams made a similar observation: https://www.forbes.com/sites/carminegallo/2013/10/23/dilbert-creator-scott-adams-reveals-the-simple-formula-that-will-double-your-odds-of-success/#16b88fe52dbc https://www.forbes.com/sites/carminegallo/2013/10/23/dilbert...

IMO Lisp is just overrated, it lacks visual clues, reads right to left with horrible nesting etc.. Sure it has some good concepts. But fanboys on internet make it seem like some God tier thing.

coldtea 7y ago

"Some good concepts"? It was the first language to add "if/else" constructs, GC, closures, first class functions, reference semantics, and recursion. It took between 5 to 40 years before these became available in mainstream languages (conditionals like if/else were adopted early, GC not so much, closures took even more). Add to that macros and the flexibility of runtime evaluation / code creation, which most mainstream languages still lack. And of course, Lisp's rules remain (and will always be) the most succinct way to define a full blown programming language with meta-programming facilities to boot -- as opposed to a mere Turing machine like thing or assembler. >IMO Lisp is just overrated, it lacks visual clues, reads right to left with horrible nesting etc.. This doesn't make any sense... The nesting is the same as in almost any language. "reads right to left" - huh? You know that Lisp code can be indented right?

Joker_vD 7y ago
> It was the first language to add "if/else" constructs, GC, closures, first class functions, reference semantics, and recursion. "Lisp is still #1 for key algorithmic techniques, such as recursion and condescension."
lkschubert8 7y ago
I think they are referring to the nested nature of lisp function calls. (second-fn (first-fn val)) I think that is really just personal preference/what you were taught as opposed to good or bad language design. But it really doesn't matter as one of the big benefits of lisp is it's ability to be metaprogrammed. That same example could be rewritten in clojure as (-> val first-fn second-fn) thanks to macros and doesn't suffer from the right->left reading.
- coldtea 7y ago
  > I think they are referring to the nested nature of lisp function calls. (second-fn (first-fn val)) How's this different than: secondFn(firstFn(val)) other than the placement of parenthesis, the two cases read exactly the same, left to right.
  - lkschubert8 7y ago
    I've seen a lot of breaking that out into the following in imperative languages. var intermediaryVal = firstFn(val); var result = secondFn(intermediaryVal);
    - slifin 7y ago
      (let [intermediary-val (first-fn val) result (second-fn intermediary-val)]) Or as one of the parents said (-> val first-fn second-fn)
  - phyrex 7y ago
    I'm on the side of lisp here, but in OOP you'd usually write something like val.firstFn().secondFn()
jecel 7y ago
One small detail - though COND and IF/ELSE are very closely related, they aren't quite the same thing. Early Smalltalk also started out with COND (a right arrow which made code look like modern switch/case) and later evolved to #ifTrue:ifFalse: which is still postfix, so feels backwards compared to other languages. Lisp and Scheme got more conventional if/else eventually.
- LandR 7y ago
  Something I discovered about Clojure's cond recently. It usually looks likethis: (cond (< a b) (println "a < b") (> a b) (println "a > b") :else (println "a = b")) I thought the :else had to be :else, but it only needs to be truthy, so it can be anything that isn't false or nil (which makes sense as you want it to always execute that form if no others match). So this is just the same: (cond (< a b) (println "a < b") (> a b) (println "a > b") :hotdog (println "a = b")) Probably obvious to everyone else but it was a bit of a "duh, of course!" moment for me.
  - sparkie 7y ago
    It's conventional in Scheme and Lisp to just use `#t` directly to match anything.
  - lispm 7y ago
    In Lisp usually all non-nil values mean true. CL-USER 13 > (let ((a 1) (b 2)) (cond ((> a b) 'foo) (:hello :there))) :THERE In some early Lisp dialects not all objects (other than lists and symbols) would be self-evaluating, so one would have to quote them.
  - kazinator 7y ago
    In traditional Lisp and common Lisp, and similar dialects, the symbol t is customarily used as the catch all last case. There is an interesting situation is in the case family of constructs which match an input value against keys, in Common Lisp. Inspired by cond, the t symbol also serves as the fallback in case when the key doesn't match the other cases. So that is to say: (case (expr) (a ...) (b ...) (42 ...) (t ...)) ;; <-- this isn't matching on the t symbol! Common Lisp also supports the symbol otherwise in place of t. But the programmer may also sometimes have the t symbol as a specific key value; or likewise the otherwise symbol. That requirement is handled by putting the key into a list: (case (expr) (a ...) ... ((t) ...)) ;; <- match on t
LandR 7y ago
Nesting can be sorted via macros, e.g. closures threading macros (defn unique [str] (->> (str/split str #"\s+") (map #(Integer/parseInt %)) (partition-by even?) (take-while #(not= (count %) 1)) (first) (count) (inc))) (unique "2 4 6 8 7 10 12") => 5
tabtab 7y ago
As far as "Lisp lacks visual clues", after many heated debates on this, I've concluded that the ugliness and rigidness of "production" languages enforces certain visual and syntactic standards that makes reading others' code easier. Indentation of Lisp won't "solve" this because production languages also can be indented. It's not a difference maker. Parameter lists are wrapped in parenthesis and separated with commas, while code blocks are wrapped in curly braces and separated with semi-colons. Lisp won't do this because it's then harder to blur/merge/change the distinction between code and data, which is the very power of Lisp. Building architectural eyesores is probably not a rational plan for a city, but dammit, those eyesores help you know and remember where you are. Some people have a certain kind of eye and/or brain that allows them to read Lisp quickly, but this may not be universal. Some say "with enough time you'll get used to it", but the fact Lisp has been around for 60 odd years without catching on in the mainstream is evidence of this. Somebody would be rich by now off its alleged advantages if they were real (beyond a "write-only" startup language). Functional languages are better at expressing ideas but slower at communicating them to other readers, on average. I also personally find them difficult to debug because they don't have enough "intermediate state" to x-ray for debugging purposes. Here's a conceptual illustration: // imperative: a = af(param); b = bf(a); c = cf(b); // functional c = cf(bf(af(param))); In a debugger and/or Write statements I can readily examine intermediate values "a" and "b". Not so with functional. SQL presents a similar issue. Its new WITH statements help out, but only partly. Divide-and-conquer works better if you can examine the divisions.
- armitron 7y ago
  You know your brain adapts so you can read something easier/faster the more you are exposed to it. For me, Lisp code couldn't be easier/faster to read and comprehend. I'm convinced most of the people making jokes about parentheses or Lisp code being hard to read are superficially dismissing it without putting in even a minimal effort of working with it. Things that don't immediately click are discarded. Individual curiosity ("Really smart people say great things about this, I wonder why that is..") leading to individual effort leading to deep understanding is not the prevailing attitude. Sad state of affairs.
deleted 7y ago
[deleted]

iLemming 7y ago

No, Lisp does not lack visual clues. But yes, very often people complain about Lisp readability. And that stems from the lack of familiarity, most people are familiar with the infix notation, but not prefix, used in Lisp. But I have seen many times, people who pick up Lisp (Clojure, Racket, etc.) as their first programming language - they do just fine, a matter of fact - they later find code written in other languages harder to read. Unlike other languages, Lisp sometimes is difficult to read by just looking at it. Staring at Lisp code, examining its "static" properties without prior training indeed may pose a challenge. But there is a way to learn how to parse Lisp code mentally. And the best way of learning that is by editing it. First, you need to find an IDE that supports structural editing of symbolic expressions (or s-exps). Basically, it would help if you learned a few operations: slurp, barf, transpose, raise, kill s-exp, yank s-exp Depending on the IDE you use, they may be called differently, and there may be more, these are the basic ones. Once you learn those basic operations, you are now ready to untangle "unreadable" Lisp. The trick is to change the code while you read it. Similar to how Tony Stark looks at the hologram of a model and moves his hands outward, forcing the hologram to expand, then he picks one of the parts, studies it, maybe completely removes it. He then would move his hands in a closing motion, and hologram would "assemble." That's how you work with Lisp. So, for example, you read a function, if necessary, extract things, pick an expression, evaluate it, etc. Once you gain a good understanding of what the function does, you can undo all the changes, or if you think you have improved it - do save. In other languages, when the structure of the code is settled, it's more challenging to pick it apart, move things in and out. You are forced to read the code "top to bottom." But in Lisp, code is a living, breathing thing. You basically feel like performing a surgery - you can tweak things, try them, and see instantaneous feedback in the REPL. In other languages, code is "dead," until you save it, (re)compile it and execute it. And REPL in those languages is "crippled" and not a fully-fledged "true" REPL like in Lisp. Being able to pick any [sub]expression and evaluate it, without any kind of prior ceremony is truly liberating and empowering. It takes time, for some it's hours, for others - weeks, but eventually you will stop seeing parentheses, and instead, you will see structure, consistency, and meaning. And Lisp becomes more readable than any other language you've used before.

tabtab 7y ago
Re: It takes time, for some it's hours, for others - weeks, but eventually you will stop seeing parentheses, and instead, you will see structure, consistency, and meaning. And Lisp becomes more readable than any other language you've used before. I'd like to see a university test this theory. I suspect it's subjective and varies greatly per individual, but testing on say 100 random subjects could better resolve the Great Lisp Dispute.

iLemming 7y ago

> But fanboys on internet make it seem like some God tier thing Lisp is based on math and logic. And if there's a God, he probably speaks Math. So, maybe those fanboys onto something here. But, seriously, once you learn a bit of Lisp, you realize that Lisp has influenced every single modern programming language. Essentially, no matter what PL you are programming in - we are all programming in a Lisp. Sometimes your language of choice adheres to core principles of Lisp, sometimes that connection is loose. Nevertheless, there's plenty of Lisp in every modern programming language. So, no. Lisp is not overrated.

tabtab 7y ago
I personally admire Lisp conceptually. It's a work of art. It's the practical use as tool in a team environment that you cannot carefully control hiring is where I have skepticism.
- iLemming 7y ago
  I've started using Clojure a few years ago as my primary language of choice. I switched multiple jobs since then. I never had a problem with finding one. I worked once for a big fin-tech company. We never said that knowing Clojure was a requirement, but we admitted that the preference would be given to people at least interested in Clojure. And you know what? It helped us to build an incredibly strong team. Even though not everyone used Clojure. Some teams used languages like Ruby, Go, and Javascript. If I were given a choice to either hire five Javascript/Python/Go programmers and pay them each 100K/Y or hire only three Lispers and pay them each 200K/Y, I would go for the latter. ROI, in that case, would be much, much higher. And Clojure is a very, very practical tool. Just watch Rich Hickey talks, you will see that the pragmatism of the language is paramount for everyone who uses it.
  - tabtab 7y ago
    Re: If I were given a choice to either hire five Javascript/Python/Go programmers and pay them each 100K/Y or hire only three Lispers and pay them each 200K/Y, I would go for the latter. ROI, in that case, would be much, much higher. If that were universally true, one could out-compete the entrenched software companies and be the next Bill Gates. The common "production" languages are successful I believe because they offer a semi-consistent way to doing things, and for large or fungible staff, that turns out more important than less lines-of-code or powerful abstractions. In business, communicating between humans is more important than parsimony. This is based on direct and indirect experience. My own "grand abstractions" have been rejected also at times. The "best" programmers are often those who have a decent understanding of the domain, UI design, and various "team" skills. Somebody good in all those may not necessary be the best abstractionist or parsimonist. The best programmers get B's on lots of topics rather than an A+ in just one, such as abstraction. I'm just the messenger. Scott Adams made a similar observation: https://www.forbes.com/sites/carminegallo/2013/10/23/dilbert-creator-scott-adams-reveals-the-simple-formula-that-will-double-your-odds-of-success/#16b88fe52dbc https://www.forbes.com/sites/carminegallo/2013/10/23/dilbert...