4 ms·

> 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

by 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.
- lispm 7y ago
  > Most Algol-derived languages use punctuation and symbols that seem to make them stand out better than words alone. If we read a long novel, then we read mostly words without much visual structure. The only thing that guides us are occasional marks of sentences, paragraphs and chapters. Still many can read Lord of the Rings without much problem. Lisp is slightly unusual, since the code is written as nested lists (trees). To make Lisp code readable there are a few things follow: speaking symbols, standardized code layout and familiar code structures. After a while the reader/writer of Lisp code will recognize the symbolic hints and the usual visual patterns of the layouted code. > The top COBOLer can probably out-code an average Lisper I'd bet. In terms of lines of code I would think that's true. > It should be a curiosity why after 60 years it never caught on mainstream Why should it be in the mainstream? Why should a programming language originally designed for certain types of meta-programming (remember: the symbolic computation and code as data ideas, which are central to Lisp) be especially popular among programmers and their customers? > easier-to-read Now you are shifting the goal. You originally claimed that functional code is hard to debug, because there are no variables you can inspect. But that's what we do in Lisp too: we use variables for that purpose.
  - tabtab 7y ago
    > Still many can read [novels] without much problem. Compared to what? I didn't say reading of Lisp comes to a stand-still, only that it's slower than block-type-indicator symbols. Maybe it is indeed possible to refactor written English for speed reading. I haven't surveyed the tests. Does anyone here want to claim English is optimized for quick reading? It's kind of off topic, but I can envision using various symbols and block-markers to delineate parts of English sentences such as subject, verb, object, etc.: "(subject..) $verb {object...}" I think it would quicken MY reading, but I can't vouch for other humans. Maybe I'll patent it, or did Oracle beat me to it ;-) But that's the idea: commonly occurring features are marked or surrounded with different symbols. You can't really do that in Lisp because nouns are verbs and verbs are nouns depending on the context/usage of the libraries or deeper code, while with Algol-derived languages mostly hard-wire the difference up front. You instantly know and don't have to stop and think or dig. Indirection/abstraction can and does slow reading in many cases. I'm just the messenger. If YOU can read and process textual words fast, that's great but may NOT be universal across most humans. > In terms of lines of code I would think that's true. No, I meant features-per-hour, at least for business-oriented coding [in COBOL]. > Why should it be in the mainstream? The standing implication, as I interpret it, is that functional programming is inherently superior in general, for a price of a slightly longer learning curve. > Now you are shifting the goal. You originally claimed that functional code is hard to debug, because there are no variables you can inspect. But that's what we do in Lisp too: we use variables for that purpose. I'm addressing TWO goals: easier-to-read and easier-to-debug. > But that's what we do in Lisp too: we use variables for that purpose. You add them just for debugging? Imperative style typically does that as in regular course. Thus, one doesn't have to alter the code as often just for debugging. > After a while the reader/writer of Lisp code will recognize the symbolic hints and the usual visual patterns of the layouted code. Indentation is not a difference maker in comparisons because both candidates can use it.

by lispm 7y ago

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.

lispm 7y ago
> Most Algol-derived languages use punctuation and symbols that seem to make them stand out better than words alone. If we read a long novel, then we read mostly words without much visual structure. The only thing that guides us are occasional marks of sentences, paragraphs and chapters. Still many can read Lord of the Rings without much problem. Lisp is slightly unusual, since the code is written as nested lists (trees). To make Lisp code readable there are a few things follow: speaking symbols, standardized code layout and familiar code structures. After a while the reader/writer of Lisp code will recognize the symbolic hints and the usual visual patterns of the layouted code. > The top COBOLer can probably out-code an average Lisper I'd bet. In terms of lines of code I would think that's true. > It should be a curiosity why after 60 years it never caught on mainstream Why should it be in the mainstream? Why should a programming language originally designed for certain types of meta-programming (remember: the symbolic computation and code as data ideas, which are central to Lisp) be especially popular among programmers and their customers? > easier-to-read Now you are shifting the goal. You originally claimed that functional code is hard to debug, because there are no variables you can inspect. But that's what we do in Lisp too: we use variables for that purpose.
- tabtab 7y ago
  > Still many can read [novels] without much problem. Compared to what? I didn't say reading of Lisp comes to a stand-still, only that it's slower than block-type-indicator symbols. Maybe it is indeed possible to refactor written English for speed reading. I haven't surveyed the tests. Does anyone here want to claim English is optimized for quick reading? It's kind of off topic, but I can envision using various symbols and block-markers to delineate parts of English sentences such as subject, verb, object, etc.: "(subject..) $verb {object...}" I think it would quicken MY reading, but I can't vouch for other humans. Maybe I'll patent it, or did Oracle beat me to it ;-) But that's the idea: commonly occurring features are marked or surrounded with different symbols. You can't really do that in Lisp because nouns are verbs and verbs are nouns depending on the context/usage of the libraries or deeper code, while with Algol-derived languages mostly hard-wire the difference up front. You instantly know and don't have to stop and think or dig. Indirection/abstraction can and does slow reading in many cases. I'm just the messenger. If YOU can read and process textual words fast, that's great but may NOT be universal across most humans. > In terms of lines of code I would think that's true. No, I meant features-per-hour, at least for business-oriented coding [in COBOL]. > Why should it be in the mainstream? The standing implication, as I interpret it, is that functional programming is inherently superior in general, for a price of a slightly longer learning curve. > Now you are shifting the goal. You originally claimed that functional code is hard to debug, because there are no variables you can inspect. But that's what we do in Lisp too: we use variables for that purpose. I'm addressing TWO goals: easier-to-read and easier-to-debug. > But that's what we do in Lisp too: we use variables for that purpose. You add them just for debugging? Imperative style typically does that as in regular course. Thus, one doesn't have to alter the code as often just for debugging. > After a while the reader/writer of Lisp code will recognize the symbolic hints and the usual visual patterns of the layouted code. Indentation is not a difference maker in comparisons because both candidates can use it.