5 ms·

I like Lisp a lot, and from my own experience I think that the main reasons why people dislike Lisp are prefix notation and parentheses. Sure, my experience is

by edu 19y ago

I like Lisp a lot, and from my own experience I think that the main reasons why people dislike Lisp are prefix notation and parentheses. Sure, my experience is only anecdotal and not at all large. But always I've tried to introduce someone to Lisp (I'm talking of about 5 people, none of them have converted...) they seem incapable to see further than the parenthesis and the prefix notation, but specially the parentheses. I tried to explain them the benefits of being such a regular language, how the source code is a list which makes it really easy to do meta-programming, the power of macros, the fact that using a good text editor (Emacs + SLIME) with an excellent indentation you really don't have to care about parentheses: you follow the indentation not count parentheses!. Not to speak about the prefix notation, which they seem allergic to. But all have been in vain. Lisp is so esthetically different from the other Algol-derived languages that it, simply, does not fit their brains, which I think is really a pity. Four of them are Perl programmers, being Perl their blub. They belive and act like there is no language better than Perl, they can do everything with perl. Whey I explain macros and metaprogramming they reply that Perl can do that with eval and strings. I've tried that and is, at least, sadomasochistic! So, after this rant (sorry), I've to restate: the main problem people have with Lisp are parenthesis and prefix notation. PS: Some of them also worship Microsoft and argue that Windows XP is the best operating system out there far better than Mac OS X (which none of them have tried for more than 5 minutes in a row), and that Linux is only good for severs. Some times I think that they suffer from severe brain damage, but apart from that they're pretty clever. So... it's an enigma.

edu 19y ago
Whoever had downmoded my comment: please, can you explain me the rationale for such action? So I never again piss you off with, what seems to me, an in-topic comment. Thank you very much.
- m0nty 19y ago
  You probably stepped on the toes of someone who likes Perl and Windows. Particularly, you mentioned Mac OS which some people have an inexplicable antithesis towards. You're playing with fire, my friend ;) Downmods are the least of your worries now.
  - Hexstream 19y ago
    I can explain the antithesis: 1. They fear the unknown; 2. They fear fanatics. Mac OS is The Unknown to them + Mac users tend to be pretty rabid fanatics = Let's bash them!
    - m0nty 19y ago
      I think I know what you mean, being a Perl programmer and Mac user myself :)
dpapathanasiou 19y ago
The best retort to the parenthesis complaint is: "I like to ask people who complain about parentheses in Lisp if they are bothered by all the spaces between words in a newspaper." (http://smuglispweeny.blogspot.com/2008/02/what-hell-is-fortune-cookie-file-anyway.html http://smuglispweeny.blogspot.com/2008/02/what-hell-is-fortu...)
- tfinniga 19y ago
  Well if you ignore the human visual processing system, that's a valid argument. One ascii character is just the same as the next. Unfortunately for lisp, that's not the case. Whitespace is different than lines. There's a reason most people can't look past the parens - they're hard to look past.
  - hernan7 19y ago
    I think parens would be less of a problem if the indentation conventions were easier on the eyes. Sometimes you need a ruler to figure out those 1-space indentations.
  - e40 19y ago
    I think this is a feeble excuse. That is, it's an excuse generated by a lazy mind. The first time I saw Lisp, I was not "primed" to dislike it. It was early in my programming education. I was fresh, as they say. It looked no more cluttered than Pascal, the main language being taught at the time. Can I write really ugly and hard to visually parse Lisp? Yes. Bad code can be written in any language.
  - dpapathanasiou 19y ago
    Parenthesis fade into the background with experience (especially if your code is well-formatted), in the same way you start to group things by curly braces in C or Java over time. No one looks at C code the first time and thinks it's clear to understand.
    - tfinniga 19y ago
      The point I was trying to make is that whitespace and parens are not equally good as delimiters. Specifically, reading a newspaper that has parens instead of whitespace would be harder. (Specifically,(reading(a(newspaper(that(has(parens(instead(of(whitespace (would(be(harder.))))))))))))) In terms of actually being a problem, I'd say it depends on the code, for sure. I could create that same example in C, but end it with }}}}}}}}}}}}}}. However, in my admittedly limited experience with lisp, it seems more likely to be highly nested, tempting people to put more levels on a single line. I also agree with you that C shouldn't be held up as the paragon of readability. Python is pretty darn good though.
jrockway 19y ago
I think your hatred for Perl is unfair. Yes, eval and strings is a terrible substitute for macros. Only an idiot would pretend otherwise. But 90% of the time, the other tools we do have available (first-class functions, everything internal being dynamic) lets us get by. For example, a few months ago I was working on a blog post about how nice it would be if Perl had macros. I had a perfect example picked out, but I decieded to try an implement it without macros. It ended up working perfectly. The docs explain the original problem, and my solution: http://search.cpan.org/~jrockway/Context-Preserve-0.01/lib/Context/Preserve.pm http://search.cpan.org/~jrockway/Context-Preserve-0.01/lib/C... Also, if you read your friendly local CLOS implementation, you will notice a lot of macros. Moose is a CLOS-alike for Perl, and it obviously didn't need macros. (Actually, I would like to port Moose to Lisp, 'cause it's much more sugary than CLOS, and it has traits. Mixins FTL.) Anyway, Perl is nearly as good as lisp, so be careful when choosing your examples. (Incidentally, I am currently working on a lisp variant that compiles to Perl, because I like lisp syntax better than Perl syntax, but I like Perl's CPAN and regex engine.)
- edu 19y ago
  Oh, I'm sorry. I didn't want to mean that Perl is a bad language at all. I was trying to explain my experience with my fellow coworkers, who happened to love perl. Actually, for the last 3 years I've been using it at work, including first-class functions (and Catalyst ;)), and I've it enjoyed quite a lot. I've some minor issues with it's syntax (for my taste too much sigils, but I understand why they are there). What I meant to be masochistic is trying to use eval with strings to emulate macros, and even trying to defend it. On the other side, the CPAN is amazing and I find difficult to live without it! BTW, I hope you'll publish here the Lisp to Perl compiler! Lisp + CPAN sound really awesome and productive!
  - jrockway 19y ago
    The source repository is here: http://git.jrock.us/?p=Perlisp.git;a=summary http://git.jrock.us/?p=Perlisp.git;a=summary It's pretty useless right now though :) I started rewriting the reader, but didn't like any of the parsing modules on CPAN... so it's sitting at that stage right now. When I get some tuits, I'll probably just port over SBCL's reader, or perhaps emacs'.
tfinniga 19y ago
I think lisp's problems started when it wasn't designed for actual use. It is elegant, functional, and amazingly regular. Usability wasn't a design goal. If you look at languages in wide use, they're all procedural - everything from ASM and basic to ruby and python. Similarly, all the pseudocode I've seen has been procedural. If you ask a lay person to come up with a way of making 20 pb&j sandwiches, you're going to get a list of steps for each sandwich. I'd argue that functional thinking is not natural, it's learned. Prefix notation is not as natural as infix notation. It's not just Algol, it's likely a reflection of natural language, and the forces that shaped natural language. My prediction is that lisp is going to become more popular in one of two scenarios. The first is that parallel processing becomes more necessary, and because functional programming is easier to parallelize, people will learn it. The second is that lisp is redesigned with usability in mind. The fact that it's not bad as long as you use emacs+SLIME is not a ringing endorsement. One of the advantages of, say, ruby is that you don't need an advanced editor to be productive. The design goal was to make a language that's nice to use, so it is nice to use. If lisp were redesigned with usability in mind, I could see it being more popular. However, the people who like and use lisp enough to try to redesign it likely aren't bothered too much by the syntax, so it's not something they try to fix.
- edu 19y ago
  But Lisp is not a functional language. You can do procedural programming with it, moreover I think that nowadays the usual Lisp program is either procedural, OOP or a mix. You really don't need to rely on Emacs+Slime, an editor with a good support for indentation will suffice. IIRC, pg codes in Vi (or Vim). The idea is that, like in C/C++, good indentation is enough to determine the nesting so you don't need to count parentheses or curly brackets. The last difference, infix vs prefix, I can see that we are more used to infix notation. But we can't forget that the Algol derived languages use a mix of them (operators and functions are different!) while Lisp always use prefix notation, and incidentally put the parentheses surrounding all the expression (and being the first element the function name).
  - tfinniga 19y ago
    Good points. Perhaps the problem is also how lisp is taught? When I learned lisp, the procedural aspects of lisp were shown, but with the understanding that they were bad, and not to be used. Probably because it was shown as a functional language, and was meant to be used as such. Similar to how, say, c++'s functional programming capabilities aren't really taught. If the indentation is sufficient, why not just remove the parens completely and rely on indentation? Lisp does have an advantage in being regular, which might not be worth giving up, and Algol descendants are kind of a mishmash, to be fair. To be honest, I'm not enough of a lisp user to be able to know what a good solution is for this one. Maybe changing some function names would be useful.. for example 'add' is better than '+', which I read as 'plus'. Repurposing infix symbols as prefix symbols seems problematic. If I were redesigning the language, one of the more important things I'd change is the keywords and builtins. For example, head and tail seem a lot better to me than car and cdr. A lot of lisp's keywords and functions come from math, and I'd probably change them to reflect mainstream algorithm design instead.

by edu 19y ago

edu 19y ago

Whoever had downmoded my comment: please, can you explain me the rationale for such action? So I never again piss you off with, what seems to me, an in-topic comment. Thank you very much.

m0nty 19y ago
You probably stepped on the toes of someone who likes Perl and Windows. Particularly, you mentioned Mac OS which some people have an inexplicable antithesis towards. You're playing with fire, my friend ;) Downmods are the least of your worries now.
- Hexstream 19y ago
  I can explain the antithesis: 1. They fear the unknown; 2. They fear fanatics. Mac OS is The Unknown to them + Mac users tend to be pretty rabid fanatics = Let's bash them!
  - m0nty 19y ago
    I think I know what you mean, being a Perl programmer and Mac user myself :)

dpapathanasiou 19y ago

The best retort to the parenthesis complaint is: "I like to ask people who complain about parentheses in Lisp if they are bothered by all the spaces between words in a newspaper." (http://smuglispweeny.blogspot.com/2008/02/what-hell-is-fortune-cookie-file-anyway.html http://smuglispweeny.blogspot.com/2008/02/what-hell-is-fortu...)

tfinniga 19y ago
Well if you ignore the human visual processing system, that's a valid argument. One ascii character is just the same as the next. Unfortunately for lisp, that's not the case. Whitespace is different than lines. There's a reason most people can't look past the parens - they're hard to look past.
- hernan7 19y ago
  I think parens would be less of a problem if the indentation conventions were easier on the eyes. Sometimes you need a ruler to figure out those 1-space indentations.
- e40 19y ago
  I think this is a feeble excuse. That is, it's an excuse generated by a lazy mind. The first time I saw Lisp, I was not "primed" to dislike it. It was early in my programming education. I was fresh, as they say. It looked no more cluttered than Pascal, the main language being taught at the time. Can I write really ugly and hard to visually parse Lisp? Yes. Bad code can be written in any language.
- dpapathanasiou 19y ago
  Parenthesis fade into the background with experience (especially if your code is well-formatted), in the same way you start to group things by curly braces in C or Java over time. No one looks at C code the first time and thinks it's clear to understand.
  - tfinniga 19y ago
    The point I was trying to make is that whitespace and parens are not equally good as delimiters. Specifically, reading a newspaper that has parens instead of whitespace would be harder. (Specifically,(reading(a(newspaper(that(has(parens(instead(of(whitespace (would(be(harder.))))))))))))) In terms of actually being a problem, I'd say it depends on the code, for sure. I could create that same example in C, but end it with }}}}}}}}}}}}}}. However, in my admittedly limited experience with lisp, it seems more likely to be highly nested, tempting people to put more levels on a single line. I also agree with you that C shouldn't be held up as the paragon of readability. Python is pretty darn good though.

jrockway 19y ago

I think your hatred for Perl is unfair. Yes, eval and strings is a terrible substitute for macros. Only an idiot would pretend otherwise. But 90% of the time, the other tools we do have available (first-class functions, everything internal being dynamic) lets us get by. For example, a few months ago I was working on a blog post about how nice it would be if Perl had macros. I had a perfect example picked out, but I decieded to try an implement it without macros. It ended up working perfectly. The docs explain the original problem, and my solution: http://search.cpan.org/~jrockway/Context-Preserve-0.01/lib/Context/Preserve.pm http://search.cpan.org/~jrockway/Context-Preserve-0.01/lib/C... Also, if you read your friendly local CLOS implementation, you will notice a lot of macros. Moose is a CLOS-alike for Perl, and it obviously didn't need macros. (Actually, I would like to port Moose to Lisp, 'cause it's much more sugary than CLOS, and it has traits. Mixins FTL.) Anyway, Perl is nearly as good as lisp, so be careful when choosing your examples. (Incidentally, I am currently working on a lisp variant that compiles to Perl, because I like lisp syntax better than Perl syntax, but I like Perl's CPAN and regex engine.)

edu 19y ago
Oh, I'm sorry. I didn't want to mean that Perl is a bad language at all. I was trying to explain my experience with my fellow coworkers, who happened to love perl. Actually, for the last 3 years I've been using it at work, including first-class functions (and Catalyst ;)), and I've it enjoyed quite a lot. I've some minor issues with it's syntax (for my taste too much sigils, but I understand why they are there). What I meant to be masochistic is trying to use eval with strings to emulate macros, and even trying to defend it. On the other side, the CPAN is amazing and I find difficult to live without it! BTW, I hope you'll publish here the Lisp to Perl compiler! Lisp + CPAN sound really awesome and productive!
- jrockway 19y ago
  The source repository is here: http://git.jrock.us/?p=Perlisp.git;a=summary http://git.jrock.us/?p=Perlisp.git;a=summary It's pretty useless right now though :) I started rewriting the reader, but didn't like any of the parsing modules on CPAN... so it's sitting at that stage right now. When I get some tuits, I'll probably just port over SBCL's reader, or perhaps emacs'.

tfinniga 19y ago

I think lisp's problems started when it wasn't designed for actual use. It is elegant, functional, and amazingly regular. Usability wasn't a design goal. If you look at languages in wide use, they're all procedural - everything from ASM and basic to ruby and python. Similarly, all the pseudocode I've seen has been procedural. If you ask a lay person to come up with a way of making 20 pb&j sandwiches, you're going to get a list of steps for each sandwich. I'd argue that functional thinking is not natural, it's learned. Prefix notation is not as natural as infix notation. It's not just Algol, it's likely a reflection of natural language, and the forces that shaped natural language. My prediction is that lisp is going to become more popular in one of two scenarios. The first is that parallel processing becomes more necessary, and because functional programming is easier to parallelize, people will learn it. The second is that lisp is redesigned with usability in mind. The fact that it's not bad as long as you use emacs+SLIME is not a ringing endorsement. One of the advantages of, say, ruby is that you don't need an advanced editor to be productive. The design goal was to make a language that's nice to use, so it is nice to use. If lisp were redesigned with usability in mind, I could see it being more popular. However, the people who like and use lisp enough to try to redesign it likely aren't bothered too much by the syntax, so it's not something they try to fix.

edu 19y ago
But Lisp is not a functional language. You can do procedural programming with it, moreover I think that nowadays the usual Lisp program is either procedural, OOP or a mix. You really don't need to rely on Emacs+Slime, an editor with a good support for indentation will suffice. IIRC, pg codes in Vi (or Vim). The idea is that, like in C/C++, good indentation is enough to determine the nesting so you don't need to count parentheses or curly brackets. The last difference, infix vs prefix, I can see that we are more used to infix notation. But we can't forget that the Algol derived languages use a mix of them (operators and functions are different!) while Lisp always use prefix notation, and incidentally put the parentheses surrounding all the expression (and being the first element the function name).
- tfinniga 19y ago
  Good points. Perhaps the problem is also how lisp is taught? When I learned lisp, the procedural aspects of lisp were shown, but with the understanding that they were bad, and not to be used. Probably because it was shown as a functional language, and was meant to be used as such. Similar to how, say, c++'s functional programming capabilities aren't really taught. If the indentation is sufficient, why not just remove the parens completely and rely on indentation? Lisp does have an advantage in being regular, which might not be worth giving up, and Algol descendants are kind of a mishmash, to be fair. To be honest, I'm not enough of a lisp user to be able to know what a good solution is for this one. Maybe changing some function names would be useful.. for example 'add' is better than '+', which I read as 'plus'. Repurposing infix symbols as prefix symbols seems problematic. If I were redesigning the language, one of the more important things I'd change is the keywords and builtins. For example, head and tail seem a lot better to me than car and cdr. A lot of lisp's keywords and functions come from math, and I'd probably change them to reflect mainstream algorithm design instead.