3 ms·

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

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.
  - edu 19y ago
    Well, to some extent there exists a unparenthesized version of Lisp: Logo :) http://en.wikipedia.org/wiki/Logo_%28programming_language%29 http://en.wikipedia.org/wiki/Logo_%28programming_language%29 And for the names used for the keywords and builtins, I agree with you. About the +/add, I really don't see too much problem.
ken 19y ago
"If you look at languages in wide use, they're all procedural" SQL?

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.
- edu 19y ago
  Well, to some extent there exists a unparenthesized version of Lisp: Logo :) http://en.wikipedia.org/wiki/Logo_%28programming_language%29 http://en.wikipedia.org/wiki/Logo_%28programming_language%29 And for the names used for the keywords and builtins, I agree with you. About the +/add, I really don't see too much problem.

ken 19y ago

"If you look at languages in wide use, they're all procedural" SQL?