6 ms·

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 certai

by 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.
- lispm 7y ago
  I think that the syntax has some hurdles, but it's not the parentheses: It's to mentally understand when lists and symbols are data and when they are code. That's a problem not found in other programming languages and at the same time it is an interesting feature. Lisp is not alone to have such hurdles - another example would be Haskell which is also more difficult to learn than the average programming language (lazy evaluation, type system, monads, ...). Often Lisp had been used as a teaching language for computer science concepts (recursion, evaluation models, algorithms, etc.) and thus it was associated by students with novel concepts they struggle with and not with solving practical problems. A typical example is the SICP book. It's great, but mostly CS and mathematics oriented -> the result is that the feedback is mixed.
iLemming 7y ago
> In a debugger and/or Write statements I can readily examine intermediate values "a" and "b". Not so with functional. You clearly have no idea. Lisp has a REPL. True REPL. No, it's not a thing where you type something into it and it blurts out something in return like in most other languages. And it's better than so much praised Jupyter notebooks. Lisp REPL is connected to your editor, and from your editor or IDE you can not only examine and evaluate any expression and sub-expression, you can do it on the fly, it gives you immediate feedback. You don't even need to think about a debugger (which Lisps do have too). You can try things while writing them. Imagine a landscape artist that changes the entire landscape in real-time with every stroke of his brush. That's how it feels to be programming in a Lisp.
- tabtab 7y ago
  Usually real-world code has a lot of context and references such that stand-alone expression evaluation is often of limited value. Maybe there are tricks of the trade to solve this, but they are not obvious to newbies. It sounds like one has to throw away years of "imperative habits" and just do everything different: reading, debugging, structuring, etc. For us non-Sheldons, it's hard to overhaul our head in a month.
  - lokedhs 7y ago
    This may be a meme, but it's also very true (like all good comedy). It's truly represents how you start to look at Lisp code after a while: https://www.thejach.com/imgs/lisp_parens.png https://www.thejach.com/imgs/lisp_parens.png
  - iLemming 7y ago
    > they are not obvious to newbies Modern Lisps like Racket and Clojure are not that difficult to pick up. I think Clojure might be easier to learn than Python or Javascript. I'm serious. Look, I understand the sentiment because I was on the same side relatively not too long ago. I never had a formal introduction into a Lisp. I thought Lisp is a dying language, something like Fortran, COBOL, or Pascal. On a whim, out of the blue, I tried learning it. I don't remember exactly why. I was bored or something. I started reading a book on Clojure. Then I found a conference that supposed to happen in a week. It was the first Clojure/Remote conf. I thought: "Well, it's remote. It's cheap. Let me try it out. What do I have to lose?" That conference has changed my life. Quite literally. I was fascinated by seeing awesome things people building. After the conf, I sat in my chair, staring into the void of my blank screen for several minutes. The next day, I went to the office and told them that I'm leaving. Without writing a single program in a language I did not know, I decided to find a job with a tech stack focused on Clojure. There are lots of misconceptions circling Lisp. People look at Lisp code, and it just doesn't look "sexy" to them. And they immediately dismiss it, claiming it is hard to read. That's not true. They say - it's dynamically typed mess. Without ever knowing that Clojure has a type system called Spec, which can do things, most other type systems cannot. There's a ton of research happening around type systems in Racket. "Little Typer" book teaches dependent types using a Lisp. They say Lisp codebases don't scale - that's not true at all. The truth is - programming in Lisp makes people so productive, you don't need large teams to maintain a massive amount of work. And there are companies with large Lisp ecosystems, one example: NuBank in Brazil has over 400 engineers, and their primary language is Clojure. People say Lisp is not popular. Sure, Clojure's popularity might look dwarfed in comparison with massively popular Python, Javascript, C++, Java, etc. However, Clojure, compared to other "esoteric" languages, is quite popular - today, it has more books, podcasts, conferences, and meetups. More than languages like Haskell, OCaml, Rust, Elm, Purescript, ReasonML, F#. Learning Clojure has opened a world of possibilities for me personally. My only regret that I haven't gotten into Lisps earlier. Please, don't negatively take my advice. My intentions are sincere. I wish someone would've convinced me to try Lisp early in my career. Please, do sometimes try to get your head out of your shell and give it a try. I promise, if you give Lisp an honest and heartfelt try, you will find something unique. Even if you end up not using it, you will never regret learning it.
lispm 7y ago
> 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. Though it has tried a bunch of times. > Some people have a certain kind of eye and/or brain that allows them to read Lisp quickly Could be that or that one just needs a bit of practice - as it is the case with many thing: riding a bike, driving a car, learning a foreign language, mastering a new dance, ... > 60 odd years without catching on in the mainstream is evidence of this That you observe two things does not mean that they are necessarily in a causal relation. > I also personally find them difficult to debug One just introduces variables like in your imperative example: (let* ((a (af param)) (b (bf a)) (c (cf b))) c) Now you'd see the variables and their bindings in a debugger.
- tabtab 7y ago
  Re: Though [separating in Lisp] has tried a bunch of times. I haven't seen it done well. The attempts kind of end up with the worse of both worlds. Re: Could be that or that one just needs a bit of practice But the key is how much, and how long does it vary per individual. There is no solid research that I know of, so it's just opinion and anecdotes either way. I tried to get used to it and read it fast, but it just felt progress was really slow. Most Algol-derived languages use punctuation and symbols that seem to make them stand out better than words alone. I'm not quite sure how to describe it, but standardizing the meaning of "funny symbols" help my particular eyes work faster. My head parses words too slow, and I have been reading words since kindergarten. Similar discussions: https://wiki.c2.com/?LispLacksVisualCues https://wiki.c2.com/?LispLacksVisualCues https://wiki.c2.com/?ChallengeSixLispVersionDiscussion https://wiki.c2.com/?ChallengeSixLispVersionDiscussion One can make that claim about any tool I should note, even COBOL. Some seasoned COBOLer's can crank out and read COBOL code really quick, I'd note. The top COBOLer can probably out-code an average Lisper I'd bet. Re: That you observe two things does not mean that they are necessarily in a causal relation. True, but per lack of formal studies per above, speculative observations are all any of us have. It should be a curiosity why after 60 years it never caught on mainstream. Almost nothing else in IT has had that many shots at it. Re: One just introduces variables like in your imperative example: Yes, but the Algol-derived languages (like C, Python, etc.) do that "style" in an easier-to-read and more consistent way, at least in my opinion. Side note: why am I getting a rotten score? What did I do bad? I don't want bad scores. I'm just expressing my opinion openly. I don't feel I deserve punishment.
Turing_Machine 7y ago
> Not so with functional. Sure you can, if you have an editor and REPL worth their salt. Select af(param)and evaluate it. There's what you're calling "a". Select bf(af(param) and evaluate it. There's what you're calling "b". How one carries out "select and evaluate" varies depending on the language, REPL, and editor in use, but there's almost always (always, in my experience) an easy way to do it. Bonus: if it's a pure functional language (no side-effects) you can do it as many times as you like without messing anything up, and you didn't have to invent any otherwise-useless variables.

by tabtab 7y ago

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.

lispm 7y ago
I think that the syntax has some hurdles, but it's not the parentheses: It's to mentally understand when lists and symbols are data and when they are code. That's a problem not found in other programming languages and at the same time it is an interesting feature. Lisp is not alone to have such hurdles - another example would be Haskell which is also more difficult to learn than the average programming language (lazy evaluation, type system, monads, ...). Often Lisp had been used as a teaching language for computer science concepts (recursion, evaluation models, algorithms, etc.) and thus it was associated by students with novel concepts they struggle with and not with solving practical problems. A typical example is the SICP book. It's great, but mostly CS and mathematics oriented -> the result is that the feedback is mixed.

iLemming 7y ago

> In a debugger and/or Write statements I can readily examine intermediate values "a" and "b". Not so with functional. You clearly have no idea. Lisp has a REPL. True REPL. No, it's not a thing where you type something into it and it blurts out something in return like in most other languages. And it's better than so much praised Jupyter notebooks. Lisp REPL is connected to your editor, and from your editor or IDE you can not only examine and evaluate any expression and sub-expression, you can do it on the fly, it gives you immediate feedback. You don't even need to think about a debugger (which Lisps do have too). You can try things while writing them. Imagine a landscape artist that changes the entire landscape in real-time with every stroke of his brush. That's how it feels to be programming in a Lisp.

tabtab 7y ago
Usually real-world code has a lot of context and references such that stand-alone expression evaluation is often of limited value. Maybe there are tricks of the trade to solve this, but they are not obvious to newbies. It sounds like one has to throw away years of "imperative habits" and just do everything different: reading, debugging, structuring, etc. For us non-Sheldons, it's hard to overhaul our head in a month.
- lokedhs 7y ago
  This may be a meme, but it's also very true (like all good comedy). It's truly represents how you start to look at Lisp code after a while: https://www.thejach.com/imgs/lisp_parens.png https://www.thejach.com/imgs/lisp_parens.png
- iLemming 7y ago
  > they are not obvious to newbies Modern Lisps like Racket and Clojure are not that difficult to pick up. I think Clojure might be easier to learn than Python or Javascript. I'm serious. Look, I understand the sentiment because I was on the same side relatively not too long ago. I never had a formal introduction into a Lisp. I thought Lisp is a dying language, something like Fortran, COBOL, or Pascal. On a whim, out of the blue, I tried learning it. I don't remember exactly why. I was bored or something. I started reading a book on Clojure. Then I found a conference that supposed to happen in a week. It was the first Clojure/Remote conf. I thought: "Well, it's remote. It's cheap. Let me try it out. What do I have to lose?" That conference has changed my life. Quite literally. I was fascinated by seeing awesome things people building. After the conf, I sat in my chair, staring into the void of my blank screen for several minutes. The next day, I went to the office and told them that I'm leaving. Without writing a single program in a language I did not know, I decided to find a job with a tech stack focused on Clojure. There are lots of misconceptions circling Lisp. People look at Lisp code, and it just doesn't look "sexy" to them. And they immediately dismiss it, claiming it is hard to read. That's not true. They say - it's dynamically typed mess. Without ever knowing that Clojure has a type system called Spec, which can do things, most other type systems cannot. There's a ton of research happening around type systems in Racket. "Little Typer" book teaches dependent types using a Lisp. They say Lisp codebases don't scale - that's not true at all. The truth is - programming in Lisp makes people so productive, you don't need large teams to maintain a massive amount of work. And there are companies with large Lisp ecosystems, one example: NuBank in Brazil has over 400 engineers, and their primary language is Clojure. People say Lisp is not popular. Sure, Clojure's popularity might look dwarfed in comparison with massively popular Python, Javascript, C++, Java, etc. However, Clojure, compared to other "esoteric" languages, is quite popular - today, it has more books, podcasts, conferences, and meetups. More than languages like Haskell, OCaml, Rust, Elm, Purescript, ReasonML, F#. Learning Clojure has opened a world of possibilities for me personally. My only regret that I haven't gotten into Lisps earlier. Please, don't negatively take my advice. My intentions are sincere. I wish someone would've convinced me to try Lisp early in my career. Please, do sometimes try to get your head out of your shell and give it a try. I promise, if you give Lisp an honest and heartfelt try, you will find something unique. Even if you end up not using it, you will never regret learning it.

lispm 7y ago

> 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. Though it has tried a bunch of times. > Some people have a certain kind of eye and/or brain that allows them to read Lisp quickly Could be that or that one just needs a bit of practice - as it is the case with many thing: riding a bike, driving a car, learning a foreign language, mastering a new dance, ... > 60 odd years without catching on in the mainstream is evidence of this That you observe two things does not mean that they are necessarily in a causal relation. > I also personally find them difficult to debug One just introduces variables like in your imperative example: (let* ((a (af param)) (b (bf a)) (c (cf b))) c) Now you'd see the variables and their bindings in a debugger.

tabtab 7y ago
Re: Though [separating in Lisp] has tried a bunch of times. I haven't seen it done well. The attempts kind of end up with the worse of both worlds. Re: Could be that or that one just needs a bit of practice But the key is how much, and how long does it vary per individual. There is no solid research that I know of, so it's just opinion and anecdotes either way. I tried to get used to it and read it fast, but it just felt progress was really slow. Most Algol-derived languages use punctuation and symbols that seem to make them stand out better than words alone. I'm not quite sure how to describe it, but standardizing the meaning of "funny symbols" help my particular eyes work faster. My head parses words too slow, and I have been reading words since kindergarten. Similar discussions: https://wiki.c2.com/?LispLacksVisualCues https://wiki.c2.com/?LispLacksVisualCues https://wiki.c2.com/?ChallengeSixLispVersionDiscussion https://wiki.c2.com/?ChallengeSixLispVersionDiscussion One can make that claim about any tool I should note, even COBOL. Some seasoned COBOLer's can crank out and read COBOL code really quick, I'd note. The top COBOLer can probably out-code an average Lisper I'd bet. Re: That you observe two things does not mean that they are necessarily in a causal relation. True, but per lack of formal studies per above, speculative observations are all any of us have. It should be a curiosity why after 60 years it never caught on mainstream. Almost nothing else in IT has had that many shots at it. Re: One just introduces variables like in your imperative example: Yes, but the Algol-derived languages (like C, Python, etc.) do that "style" in an easier-to-read and more consistent way, at least in my opinion. Side note: why am I getting a rotten score? What did I do bad? I don't want bad scores. I'm just expressing my opinion openly. I don't feel I deserve punishment.

Turing_Machine 7y ago

> Not so with functional. Sure you can, if you have an editor and REPL worth their salt. Select af(param)and evaluate it. There's what you're calling "a". Select bf(af(param) and evaluate it. There's what you're calling "b". How one carries out "select and evaluate" varies depending on the language, REPL, and editor in use, but there's almost always (always, in my experience) an easy way to do it. Bonus: if it's a pure functional language (no side-effects) you can do it as many times as you like without messing anything up, and you didn't have to invent any otherwise-useless variables.