7 ms·

> Why Lisp? Again > It is awesome. Why do people who write or talk about Lisp always have to start with something like this? To be honest I still can't see the

> Why Lisp? Again > It is awesome. Why do people who write or talk about Lisp always have to start with something like this? To be honest I still can't see the appeal of Lisp. Yes everything is a function so you can add/remove 'language features' as you want, and the syntax is really simple, and code is data (a rare need of mine anyway). But Lisp sacrifices the most important thing of all; readability. Everyone tries to read programming languages as close as possible to plain english in their head, but Lisp goes completely against this and makes you write things like (* 1 (+ 2 (/ 3 4))) where you have to glance back and forth to even understand the equation - is 1 * (2 + 3/4) not easier to read? Even in C# the phrase 'if (!(foo is bar))' annoys me because it reads 'if not foo is bar' when I'd like to say 'if foo is not bar'! So I think me and Lisp have no hope.

klibertp 11y ago
> Yes everything is a function No. Read on macros. > and code is data (a rare need of mine anyway) Rare? Read on macros, then on "Blub paradox". > But Lisp sacrifices the most important thing of all; readability. > Everyone tries to read programming languages as close as possible to plain english in their head No. That's too wrong to even seriously argue against. The best I can do is to paste this: http://blog.ppenev.com/parens.png http://blog.ppenev.com/parens.png without any comment. The rest of what you wrote is completely subjective and I don't want to comment on it. But I think you should go and take a look at Smalltalk, which is another awesome langauge with 4 decades of history, which pretty much reads like plain English.
- hacker_9 11y ago
  I have read through Paul Grahams essays a few times and do respect his opinion, but I just can't see it myself. The parenthesis are actually the least bit I have a problem with (as the indentation generally makes flow clear). But the actual function within a function with a function syntax and so on just seems to me to hinder the reading of the code and thus the understanding, maintenance and modification of it.
  - klibertp 11y ago
    > But the actual function within a function with a function syntax and so on just seems to me to hinder the reading of the code and thus the understanding, maintenance and modification of it. Why can't you believe that this is only because you're not used to reading this syntax? It's very frustrating for me. I know the basics of ~80 programming languages (see my blog for a full list) and I know for sure that "readability" is an artifact of familiarity and nothing more. I experienced the transformation of a bit of code from "unreadable mess" to "elegant and concise" more times than I care to count. Why can't you believe is true? Why don't you want to check it for yourself? Why don't you just - as I did - try using some Lisp for half a year and try to judge its readability then? And above all else, why do you insist on taking part in the discussion when you didn't invest the required time? EDIT: this comment went from 1 to -2 to 2 to -1 again during the last hour. I wonder, why the downvotes? Am I being rude? I didn't intend to, sorry if it sounds like that. I'm not sure how to change the wording to make it better (obviously I'm not a native English speaker). Could someone please help me? Or am I being wrong in my central proposition, which is that '"readability" is an artifact of familiarity and nothing more'? I admit that this "nothing more" part is an oversimplification on my part, but not by much. It's just that it's not worth discussing these relatively minor things which affect readability without first accepting that 99.9% of perceived readability comes from familiarity. Other than that, though, I'm honestly not aware of any serious papers or experiments which would claim otherwise - that some programming languages are inherently more readable than others.
    - marincounty 11y ago
      I wouldn't worry about the downvotes. Sometimes, I think people express their opinions for the sole purpose of upvotes? That said, you didn't say anything rude, and I would have had no idea that you weren't a native speaker from your post. I'm not much of a programmer, and don't usually comment on posts regarding on programming languages, but after looking at a lot of languages to learn; I am most intrigued by Lisp. I don't like wordy books. Lisp seems to be the least wordy? As yes, I know it looks complicated, but there is a simplicity about it too? And as a novice, I agree that "readability is an artifact of familiarity". Engish is easy because it's the only language I was taught. I had a hell of a time learning to write, and speak it as a kid. I look back, and I think I had a learning disability? I told a guy at work, "There's no way I could ever learn Chinese." He looked at me, and said, "I think you could learn the language. It's a lot of one syllable words. You're just used(familiarity) of English? I use JavaScript because I can ask questions on Google, and get an immediate response. I hope more people put up tutorials on Lisp. I would love to see a walk through(step, by every little step) on say the construction of let's say --Hacker News? I've always been intruded by construction of this website. I looked at the source code, but need help--on a lot of levels. I looked at lobster.io, and it's not Hacker News. (I guess it's part "familiarity"?) Actually, what should do is learn Lisp, and then put up a tutorial, but that will probally never happen because I'm just not the guy for the job on a lot of levels. A lot of people recommend learning the basics of a language before jumping into a complicated application, and that's good advice. I have found, I learn better when someone builds a program, and slowly walks me through the steps. I do take the side notes seriously. When someone recommends learning A before moving on the B; I follow that advice. As usual went off base-
CodyReichert 11y ago
That is completely subjective, and your example is bad. What's more readable here... > (+ 1 2 3 4 5) or > 1 + 2 + 3 + 4 + 5 In my (subjective) opinion, the first one is. The extra +'s are redundant and noisy, and sacrifice a meaningful syntax for "trying to read as plain english". The syntax of any language takes practice and lots of reading - that's not unique to Lisp.
- hacker_9 11y ago
  Many languages do follow a similar syntax though, that do relate to how plain english is written. I personally started with C#, and when I look at other languages I don't find them very hard to follow because they also follow the same basic 'read left to right' rule. Even coming across data formats such as html/xml for the first time are easy to follow because of the left to right reading. In your example, the 2nd one is actually what I'd prefer to read as I know that it will be compiled down to 5 ADD assembly instructions, whereas the first looks like it will be turned into a function call that will then initiate a loop. I'm guessing/hoping Lisp optimises the (+) function though so probably a null argument from me. See my reply to nnq for a better example.
- Retra 11y ago
  This is what I see when I look at lisp code: (doof-boof "1 3" f1 3 "f1 3" 'f "f3 " f") I love lisp, but I love commas too.
- renox 11y ago
  The first one is still flawed: +(1 2 3 4 5) or even better +[1 2 3 4 5] would be better IMHO as it visually separates the function from the arguments.
nnq 11y ago
You're probably a verbal thinker, and English-like code matters a lot to you I guess. Probably lots of programmers are. For me, a mostly visual thinker that ends up building and visualizing a code tree in his head anyhow, Lisp is very readable because I can more clearly see the tree without all the noise. And when it comes to math, staying close to standard math notation is a clear winner, and this is why all lisps have ways of writing infix for formula-heavy code, stuff like http://data-sorcery.org/2010/05/14/infix-math/ http://data-sorcery.org/2010/05/14/infix-math/ and others. But lispers don't use them that much because they simply get used to the Lisp notation more. ...oh, and Common Lisp is NOT an example of readable Lisp. It's probably the most unreadable and obsfucation-friendly of them all :) Take a look at some Clojure code for something that's just as readable as Python after you "get you eyes used to it" (jargon for learning to ignore the parentheses and learning the special meanings of the "funny symbols" like :, ~, # and a few more): https://github.com/weavejester/compojure/blob/master/src/compojure/core.clj https://github.com/weavejester/compojure/blob/master/src/com...
- hacker_9 11y ago
  I agree I am a verbal thinker, but that is only because I have to read the words off the screen to begin with - once I have the english in my head my mind switches between verbal and visual images to figure out the next part to write/how to fix the bug etc. Anyway to take an example from your github: > if (and form-method (= request-method :post)) am I right in saying this is pseudo-imperative: if (form-method && (request-method == 'post')) To me the ability to read it left to right seems like a huge win. With the lisp version I seem to be holding the program in my head until the very last (= ...) just so I can work it all out. Perhaps that is just in-experience though.
  - nnq 11y ago
    > the ability to read it left to right seems like a huge win It's only a win if your mind actually needs the "left to right representation". For me, reading that "if" is more like: 1. oh, so this condition is and-ing 2 child conditions, so they must both be true 2. now the first sub-condition... ok, so it just sees if form-method is truth-y 3. now the 2nd one... ok, so we're comparing if two things are equal... let's see what these things are 4. so request-method must be equal to post ...and the full code-to-English translation would be, for me, something like this: "if two things are truthy, the first of which being form-method, and the second being that there is equality between request-method and :post". This is how it would sound like if I translated my thoughts of this code into English :) The advantages of people who think more like you would be that: 1. you probably find it *much easier* to explain your thoughts about code to others, since translating thought to words is a piece of cake for you (I envy you verbal thinkers for this a lot! :) ) 2. you can easily map code to math formulas, and figure out differences between them (I can do this easily too, but I just need to use a more complicated algorithm in my head) The advantages of the people who think more like me would be: 1. breaking complicated stuff into smaller pieces that can be understood off-context is easier (try breaking up the sentence I just wrote above at each comas and see that they kind of make sense separately too) 2. thinking about meta-code (code that generates code like Lisp and Scala macros) is much easier: because our mind's representation is closer to the machine's AST representation, writing code that writes code that writes code etc. feel just as "natural" as everything else to us. For example, when thinking about implementing an ORM, my first thought is something like "oh god, if the language I'm working in just had *real macros*, I could write all this in a few hours and couple hundreds line of code, and not need a mind-bending hierarchy of classes to do it" :) As an example of meta-thinking in a verbal language... try reading some Kant or other such philosopher ...it's just too hard to be able to get to any result fast enough, so probably a bad idea... The whole point I'm trying to make is simply that people think very very differently! Indeed, the Lisp advocates should stop repeating the "it's awesome" mantra and understand that it's only awesome for those with the brain wired a certain way, and it's probably painful for the others. Nirvana would be to port Lisp's features to a more math-like and English-like language. But nobody has been successful at this. Both Scala macros and Template-Haskell are truly fucking hard if you try to actually use them for getting stuff done. So I count them just as failed experiments. But there's always hope :)
ruricolist 11y ago
Does anyone read actually read code left-to-right, line-by-line? I for one start with the shape of the code -- the pattern of color (from syntax highlighting) and negative space (from indentation) -- and only then focus on the different parts. And Lisp is particularly helpful this way, because instead of paragraph-like blocks of code where you have to reconstruct the state of the code in your head by mentally modeling side effects, you can see the general outlines of what's happening from the levels of indentation. I want to defend Lisp, of course, but I'm also genuinely curious about different ways people read code.
- hacker_9 11y ago
  I agree that the shape of the code is what I start with too: the syntax-highlighted keywords stick out as anchor points when scrolling, and I know from indentation where sections start and end. Example: if (...) { ... } else { ... } or loop { ... } After I home in on the words then yes I will generally read left to right, top to bottom. But another part of imperative style is code is usually split into separate paragraphs of related functionality - so I can usually jump down whole paragraphs too. The only other obvious variation I can think of is I will read bottom up when tracing the path a variable took to get to where I am currently looking.
- loqi 11y ago
  Same here. It's why I prefer to line-split conditionals in C-like languages like this: if (condition0 && condition1 && condition2) rather than the usual "trailing operator" style. You can immediately parse the left column as a sort of vertical operator that tells you how the individual conditions are being combined. But then, I also like Lisp. Prefix notation for "and" gives the same benefit directly, no tricky formatting required.
slowmovintarget 11y ago
The closer to English the code is, the less precise the syntax can be. In order to reduce the ambiguity, language designers must introduce additional rules, and additional conditions. This often includes context dependent semantics. All of these things are _complications_ not just in the syntax but in the mental model. In order to effectively manipulate the code, you must hold all of those rules in your head while writing it. In Lisp, the syntax requires the direct expression of context (parentheses). It also has dead simple semantics: do this to that. This means that Lisps are essentially optimized for authoring the code in the first place. This is what is meant when people say it is easy to reason about. Of course, this is a trade-off, but arguably one that makes a developer more productive. Yes debugging is more difficult. Yet I'd venture it is a less common activity with Lisp as wrongness in the program is often obvious to the author. But yes, not for everybody.
cicero 11y ago
> Why do people who write or talk about Lisp always have to start with something like this? Because to them it is awesome. People are different, and just because it isn't awesome to you doesn't mean it can't be for others. For me, I was impressed because Lisp overcame so many limitations I found in other languages. When it comes to readability, I think that a lot of it is what you are used to. I do not use Lisp all of the time, so when I switch back to it, some time is required for me to get back into the groove where it becomes readable, and then it's second nature. (I teach multiple computer science courses using different languages, and switching gears from class to class can be a challenge.) All of that being said, the greater use of punctuation and syntactic forms in other languages can aid in readability, but I don't think it is significant enough to completely offset the power you gain from the Lisp syntax.
agumonkey 11y ago
Lisps are very abstract[1]. They have no value if you write a tiny mathematical expression or conditional. Who ever had trouble reading these ? This is not were you suffer when you write code IMHO. When you want to compose, rewrap any kind of objects at scale, then it's brilliant. [1] I believe it's from birth, it was a thought experiment at first, IIRC it didn't even have numbers. Just symbols. It was about writing your own abstractions (see the symbolic differentiator in Lisp first paper). If you don't think about it that way then it surely will look absurdly convoluted.
sjolsen 11y ago
>Why do people who write or talk about Lisp always have to start with something like this? Well, the people who write or talk about Lisp generally probably think it's true, and it's the sort of thing that, if true, makes for a fantastic selling point. >you can add/remove 'language features' as you want, and the syntax is really simple, and code is data I think this is the meat of it: that Lisp offers an exceptionally low barrier to entry to the world of, let's say, "experimental programming." It lets you do things you would never dream of if you've only ever mucked around in something like C or Java. Whether or not those things are actually useful in and of themselves, it's fun and rewarding to experiment not just with programs, but the way you write and even think about them. Of course, there are people who will tell you that Lisp is also good for solid technical reasons, but I think this is the main appeal of Lisp to most people who describe it as "awesome." >Everyone tries to read programming languages as close as possible to plain english in their head That's simply not true. You may do this, and it's a perfectly valid approach, but not everyone thinks that way. Personally, I think of code in terms of what it "does," rather than what it "says," if that makes any sense— it's difficult to explain. As for readability, I firmly believe it ultimately comes down to familiarity. Yes, infix syntax is easier to read for a limited subset of small, operator-dense arithmetic expressions, but I find that kind of code is relatively rare. Broadly speaking, you're going to get most of your structural information about Lisp code from the indentation; the parentheses eventually fade into noise. And honestly, the same is true of just about every other programming language.
gglitch 11y ago
I can't speak for anyone else, and I'm a perpetual beginner with languages, but for me, lisp's syntax was sort of a god-send for clarity. Whitespace didn't matter. Indentation didn't matter. There were no symbols to memorize (except I guess precisely one, 'quote,' which could also be done without the symbol). Stringing code together seemed spectacularly simple: Everything's a list, the first atom is always a function unless explicitly declared otherwise with that one simple symbol, and you could always tell exactly how one function fit with the others you were looking at. I'm not a programmer, but with other languages, I feel like even with simple scripts, I'm always having to look up syntax details or pitfalls. Lisp is simple and uniform. It's good for beginners, I guess.

klibertp 11y ago

> Yes everything is a function No. Read on macros. > and code is data (a rare need of mine anyway) Rare? Read on macros, then on "Blub paradox". > But Lisp sacrifices the most important thing of all; readability. > Everyone tries to read programming languages as close as possible to plain english in their head No. That's too wrong to even seriously argue against. The best I can do is to paste this: http://blog.ppenev.com/parens.png http://blog.ppenev.com/parens.png without any comment. The rest of what you wrote is completely subjective and I don't want to comment on it. But I think you should go and take a look at Smalltalk, which is another awesome langauge with 4 decades of history, which pretty much reads like plain English.

hacker_9 11y ago
I have read through Paul Grahams essays a few times and do respect his opinion, but I just can't see it myself. The parenthesis are actually the least bit I have a problem with (as the indentation generally makes flow clear). But the actual function within a function with a function syntax and so on just seems to me to hinder the reading of the code and thus the understanding, maintenance and modification of it.
- klibertp 11y ago
  > But the actual function within a function with a function syntax and so on just seems to me to hinder the reading of the code and thus the understanding, maintenance and modification of it. Why can't you believe that this is only because you're not used to reading this syntax? It's very frustrating for me. I know the basics of ~80 programming languages (see my blog for a full list) and I know for sure that "readability" is an artifact of familiarity and nothing more. I experienced the transformation of a bit of code from "unreadable mess" to "elegant and concise" more times than I care to count. Why can't you believe is true? Why don't you want to check it for yourself? Why don't you just - as I did - try using some Lisp for half a year and try to judge its readability then? And above all else, why do you insist on taking part in the discussion when you didn't invest the required time? EDIT: this comment went from 1 to -2 to 2 to -1 again during the last hour. I wonder, why the downvotes? Am I being rude? I didn't intend to, sorry if it sounds like that. I'm not sure how to change the wording to make it better (obviously I'm not a native English speaker). Could someone please help me? Or am I being wrong in my central proposition, which is that '"readability" is an artifact of familiarity and nothing more'? I admit that this "nothing more" part is an oversimplification on my part, but not by much. It's just that it's not worth discussing these relatively minor things which affect readability without first accepting that 99.9% of perceived readability comes from familiarity. Other than that, though, I'm honestly not aware of any serious papers or experiments which would claim otherwise - that some programming languages are inherently more readable than others.
  - marincounty 11y ago
    I wouldn't worry about the downvotes. Sometimes, I think people express their opinions for the sole purpose of upvotes? That said, you didn't say anything rude, and I would have had no idea that you weren't a native speaker from your post. I'm not much of a programmer, and don't usually comment on posts regarding on programming languages, but after looking at a lot of languages to learn; I am most intrigued by Lisp. I don't like wordy books. Lisp seems to be the least wordy? As yes, I know it looks complicated, but there is a simplicity about it too? And as a novice, I agree that "readability is an artifact of familiarity". Engish is easy because it's the only language I was taught. I had a hell of a time learning to write, and speak it as a kid. I look back, and I think I had a learning disability? I told a guy at work, "There's no way I could ever learn Chinese." He looked at me, and said, "I think you could learn the language. It's a lot of one syllable words. You're just used(familiarity) of English? I use JavaScript because I can ask questions on Google, and get an immediate response. I hope more people put up tutorials on Lisp. I would love to see a walk through(step, by every little step) on say the construction of let's say --Hacker News? I've always been intruded by construction of this website. I looked at the source code, but need help--on a lot of levels. I looked at lobster.io, and it's not Hacker News. (I guess it's part "familiarity"?) Actually, what should do is learn Lisp, and then put up a tutorial, but that will probally never happen because I'm just not the guy for the job on a lot of levels. A lot of people recommend learning the basics of a language before jumping into a complicated application, and that's good advice. I have found, I learn better when someone builds a program, and slowly walks me through the steps. I do take the side notes seriously. When someone recommends learning A before moving on the B; I follow that advice. As usual went off base-

CodyReichert 11y ago

That is completely subjective, and your example is bad. What's more readable here... > (+ 1 2 3 4 5) or > 1 + 2 + 3 + 4 + 5 In my (subjective) opinion, the first one is. The extra +'s are redundant and noisy, and sacrifice a meaningful syntax for "trying to read as plain english". The syntax of any language takes practice and lots of reading - that's not unique to Lisp.

hacker_9 11y ago
Many languages do follow a similar syntax though, that do relate to how plain english is written. I personally started with C#, and when I look at other languages I don't find them very hard to follow because they also follow the same basic 'read left to right' rule. Even coming across data formats such as html/xml for the first time are easy to follow because of the left to right reading. In your example, the 2nd one is actually what I'd prefer to read as I know that it will be compiled down to 5 ADD assembly instructions, whereas the first looks like it will be turned into a function call that will then initiate a loop. I'm guessing/hoping Lisp optimises the (+) function though so probably a null argument from me. See my reply to nnq for a better example.
Retra 11y ago
This is what I see when I look at lisp code: (doof-boof "1 3" f1 3 "f1 3" 'f "f3 " f") I love lisp, but I love commas too.
renox 11y ago
The first one is still flawed: +(1 2 3 4 5) or even better +[1 2 3 4 5] would be better IMHO as it visually separates the function from the arguments.

nnq 11y ago

You're probably a verbal thinker, and English-like code matters a lot to you I guess. Probably lots of programmers are. For me, a mostly visual thinker that ends up building and visualizing a code tree in his head anyhow, Lisp is very readable because I can more clearly see the tree without all the noise. And when it comes to math, staying close to standard math notation is a clear winner, and this is why all lisps have ways of writing infix for formula-heavy code, stuff like http://data-sorcery.org/2010/05/14/infix-math/ http://data-sorcery.org/2010/05/14/infix-math/ and others. But lispers don't use them that much because they simply get used to the Lisp notation more. ...oh, and Common Lisp is NOT an example of readable Lisp. It's probably the most unreadable and obsfucation-friendly of them all :) Take a look at some Clojure code for something that's just as readable as Python after you "get you eyes used to it" (jargon for learning to ignore the parentheses and learning the special meanings of the "funny symbols" like :, ~, # and a few more): https://github.com/weavejester/compojure/blob/master/src/compojure/core.clj https://github.com/weavejester/compojure/blob/master/src/com...

hacker_9 11y ago
I agree I am a verbal thinker, but that is only because I have to read the words off the screen to begin with - once I have the english in my head my mind switches between verbal and visual images to figure out the next part to write/how to fix the bug etc. Anyway to take an example from your github: > if (and form-method (= request-method :post)) am I right in saying this is pseudo-imperative: if (form-method && (request-method == 'post')) To me the ability to read it left to right seems like a huge win. With the lisp version I seem to be holding the program in my head until the very last (= ...) just so I can work it all out. Perhaps that is just in-experience though.
- nnq 11y ago
  > the ability to read it left to right seems like a huge win It's only a win if your mind actually needs the "left to right representation". For me, reading that "if" is more like: 1. oh, so this condition is and-ing 2 child conditions, so they must both be true 2. now the first sub-condition... ok, so it just sees if form-method is truth-y 3. now the 2nd one... ok, so we're comparing if two things are equal... let's see what these things are 4. so request-method must be equal to post ...and the full code-to-English translation would be, for me, something like this: "if two things are truthy, the first of which being form-method, and the second being that there is equality between request-method and :post". This is how it would sound like if I translated my thoughts of this code into English :) The advantages of people who think more like you would be that: 1. you probably find it *much easier* to explain your thoughts about code to others, since translating thought to words is a piece of cake for you (I envy you verbal thinkers for this a lot! :) ) 2. you can easily map code to math formulas, and figure out differences between them (I can do this easily too, but I just need to use a more complicated algorithm in my head) The advantages of the people who think more like me would be: 1. breaking complicated stuff into smaller pieces that can be understood off-context is easier (try breaking up the sentence I just wrote above at each comas and see that they kind of make sense separately too) 2. thinking about meta-code (code that generates code like Lisp and Scala macros) is much easier: because our mind's representation is closer to the machine's AST representation, writing code that writes code that writes code etc. feel just as "natural" as everything else to us. For example, when thinking about implementing an ORM, my first thought is something like "oh god, if the language I'm working in just had *real macros*, I could write all this in a few hours and couple hundreds line of code, and not need a mind-bending hierarchy of classes to do it" :) As an example of meta-thinking in a verbal language... try reading some Kant or other such philosopher ...it's just too hard to be able to get to any result fast enough, so probably a bad idea... The whole point I'm trying to make is simply that people think very very differently! Indeed, the Lisp advocates should stop repeating the "it's awesome" mantra and understand that it's only awesome for those with the brain wired a certain way, and it's probably painful for the others. Nirvana would be to port Lisp's features to a more math-like and English-like language. But nobody has been successful at this. Both Scala macros and Template-Haskell are truly fucking hard if you try to actually use them for getting stuff done. So I count them just as failed experiments. But there's always hope :)

ruricolist 11y ago

Does anyone read actually read code left-to-right, line-by-line? I for one start with the shape of the code -- the pattern of color (from syntax highlighting) and negative space (from indentation) -- and only then focus on the different parts. And Lisp is particularly helpful this way, because instead of paragraph-like blocks of code where you have to reconstruct the state of the code in your head by mentally modeling side effects, you can see the general outlines of what's happening from the levels of indentation. I want to defend Lisp, of course, but I'm also genuinely curious about different ways people read code.

hacker_9 11y ago
I agree that the shape of the code is what I start with too: the syntax-highlighted keywords stick out as anchor points when scrolling, and I know from indentation where sections start and end. Example: if (...) { ... } else { ... } or loop { ... } After I home in on the words then yes I will generally read left to right, top to bottom. But another part of imperative style is code is usually split into separate paragraphs of related functionality - so I can usually jump down whole paragraphs too. The only other obvious variation I can think of is I will read bottom up when tracing the path a variable took to get to where I am currently looking.
loqi 11y ago
Same here. It's why I prefer to line-split conditionals in C-like languages like this: if (condition0 && condition1 && condition2) rather than the usual "trailing operator" style. You can immediately parse the left column as a sort of vertical operator that tells you how the individual conditions are being combined. But then, I also like Lisp. Prefix notation for "and" gives the same benefit directly, no tricky formatting required.

slowmovintarget 11y ago

The closer to English the code is, the less precise the syntax can be. In order to reduce the ambiguity, language designers must introduce additional rules, and additional conditions. This often includes context dependent semantics. All of these things are _complications_ not just in the syntax but in the mental model. In order to effectively manipulate the code, you must hold all of those rules in your head while writing it. In Lisp, the syntax requires the direct expression of context (parentheses). It also has dead simple semantics: do this to that. This means that Lisps are essentially optimized for authoring the code in the first place. This is what is meant when people say it is easy to reason about. Of course, this is a trade-off, but arguably one that makes a developer more productive. Yes debugging is more difficult. Yet I'd venture it is a less common activity with Lisp as wrongness in the program is often obvious to the author. But yes, not for everybody.

cicero 11y ago

> Why do people who write or talk about Lisp always have to start with something like this? Because to them it is awesome. People are different, and just because it isn't awesome to you doesn't mean it can't be for others. For me, I was impressed because Lisp overcame so many limitations I found in other languages. When it comes to readability, I think that a lot of it is what you are used to. I do not use Lisp all of the time, so when I switch back to it, some time is required for me to get back into the groove where it becomes readable, and then it's second nature. (I teach multiple computer science courses using different languages, and switching gears from class to class can be a challenge.) All of that being said, the greater use of punctuation and syntactic forms in other languages can aid in readability, but I don't think it is significant enough to completely offset the power you gain from the Lisp syntax.

agumonkey 11y ago

Lisps are very abstract[1]. They have no value if you write a tiny mathematical expression or conditional. Who ever had trouble reading these ? This is not were you suffer when you write code IMHO. When you want to compose, rewrap any kind of objects at scale, then it's brilliant. [1] I believe it's from birth, it was a thought experiment at first, IIRC it didn't even have numbers. Just symbols. It was about writing your own abstractions (see the symbolic differentiator in Lisp first paper). If you don't think about it that way then it surely will look absurdly convoluted.

sjolsen 11y ago

>Why do people who write or talk about Lisp always have to start with something like this? Well, the people who write or talk about Lisp generally probably think it's true, and it's the sort of thing that, if true, makes for a fantastic selling point. >you can add/remove 'language features' as you want, and the syntax is really simple, and code is data I think this is the meat of it: that Lisp offers an exceptionally low barrier to entry to the world of, let's say, "experimental programming." It lets you do things you would never dream of if you've only ever mucked around in something like C or Java. Whether or not those things are actually useful in and of themselves, it's fun and rewarding to experiment not just with programs, but the way you write and even think about them. Of course, there are people who will tell you that Lisp is also good for solid technical reasons, but I think this is the main appeal of Lisp to most people who describe it as "awesome." >Everyone tries to read programming languages as close as possible to plain english in their head That's simply not true. You may do this, and it's a perfectly valid approach, but not everyone thinks that way. Personally, I think of code in terms of what it "does," rather than what it "says," if that makes any sense— it's difficult to explain. As for readability, I firmly believe it ultimately comes down to familiarity. Yes, infix syntax is easier to read for a limited subset of small, operator-dense arithmetic expressions, but I find that kind of code is relatively rare. Broadly speaking, you're going to get most of your structural information about Lisp code from the indentation; the parentheses eventually fade into noise. And honestly, the same is true of just about every other programming language.

gglitch 11y ago

I can't speak for anyone else, and I'm a perpetual beginner with languages, but for me, lisp's syntax was sort of a god-send for clarity. Whitespace didn't matter. Indentation didn't matter. There were no symbols to memorize (except I guess precisely one, 'quote,' which could also be done without the symbol). Stringing code together seemed spectacularly simple: Everything's a list, the first atom is always a function unless explicitly declared otherwise with that one simple symbol, and you could always tell exactly how one function fit with the others you were looking at. I'm not a programmer, but with other languages, I feel like even with simple scripts, I'm always having to look up syntax details or pitfalls. Lisp is simple and uniform. It's good for beginners, I guess.