3 ms·

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, OO

by 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.

by edu 19y ago

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.