3 ms·

I'm surprised at the current number of likes/dislikes for Lisp and Scheme. Most of my work, including at home, work and in the past at school, was in C, C++, Ja

I'm surprised at the current number of likes/dislikes for Lisp and Scheme. Most of my work, including at home, work and in the past at school, was in C, C++, Java, Perl, Python, SQL and some mixes of Shell and other minor dabbling in other languages. I had some exposure to Lisp in school way back when, and had to do some work in Scheme. I hated it. Strong dislike! So what was I missing? It seems these have a strong following compared with how widespread they are.

betterunix 13y ago
"I had some exposure to Lisp in school way back when, and had to do some work in Scheme. I hated it. Strong dislike! So what was I missing? It seems these have a strong following compared with how widespread they are." I can say that Lisp made my current project possible, given the timeframe we had and the requirements. Here are a few things that make Lisp fantastic: * Flexibility/expressiveness: you can compose things as needed, without being held back by syntax rules. Here is a simple example, which is a bit silly but which illustrates the point: (if (defun foo (x) (+ x 5)) 'yes 'no) That is an "if" statement that follows the "yes" branch if the function is compiled without errors, and follows the "no" branch if there is an error. A bit pedantic, but let's put it this way: good luck doing that in C, C++, Java, or even Python. * Error handling: What happens when you are writing to a file, but you run out of disk space? In Java and Python, you are out of luck: an exception is thrown, and now you have to pick up the pieces. In C or C++, your code needs to be littered with conditional statements that check if your I/O operations are successful. In Common Lisp, however, we have the restart construct, which allows the thrower of an exception to set up recovery routines that the handler can invoke. The top-level exception handler can present the user with recovery options, so for something like running out of disk space, the user might delete some files and invoke a restart that continues the I/O -- and the programmer need not clutter his code with routines for restarting the operation. * Serialization is free. Kind of a pedantic point when you have things like Pickle, but it is even easier in Lisp -- no libraries needed. The caveat, though, is that some data cannot be serialized so easily, like objects in CLOS, but the metaobject protocol in most CL implementations solves that problem (A MOP are strangely absent from the Lisp standard, but most implementations include one anyway). * Macros. When all else fails, macros are a lifesaver. Macros in Lisp have all the power of the Lisp programming language itself, at compile time -- so everything mentioned above is equally applicable. There is a strange recursive phenomenon to this argument: when all else fails in macro writing, you can create a deeper level of macros (it's macros all the way down). Macros are the reason for Lisp's unusual syntax, by the way: Lisp programs are written in a way that makes it easy for a macro to operate on a Lisp program. Now, there are certainly things I do not like about CL, like the lack of any portable support for static typing (even an optional static type system), the poor collection of standard data structures, and the lack of support for modern things like sockets, threads, etc. Fortunately there are a lot of freely available libraries for such things, but a new standard that included them would be nice.

betterunix 13y ago

"I had some exposure to Lisp in school way back when, and had to do some work in Scheme. I hated it. Strong dislike! So what was I missing? It seems these have a strong following compared with how widespread they are." I can say that Lisp made my current project possible, given the timeframe we had and the requirements. Here are a few things that make Lisp fantastic: * Flexibility/expressiveness: you can compose things as needed, without being held back by syntax rules. Here is a simple example, which is a bit silly but which illustrates the point: (if (defun foo (x) (+ x 5)) 'yes 'no) That is an "if" statement that follows the "yes" branch if the function is compiled without errors, and follows the "no" branch if there is an error. A bit pedantic, but let's put it this way: good luck doing that in C, C++, Java, or even Python. * Error handling: What happens when you are writing to a file, but you run out of disk space? In Java and Python, you are out of luck: an exception is thrown, and now you have to pick up the pieces. In C or C++, your code needs to be littered with conditional statements that check if your I/O operations are successful. In Common Lisp, however, we have the restart construct, which allows the thrower of an exception to set up recovery routines that the handler can invoke. The top-level exception handler can present the user with recovery options, so for something like running out of disk space, the user might delete some files and invoke a restart that continues the I/O -- and the programmer need not clutter his code with routines for restarting the operation. * Serialization is free. Kind of a pedantic point when you have things like Pickle, but it is even easier in Lisp -- no libraries needed. The caveat, though, is that some data cannot be serialized so easily, like objects in CLOS, but the metaobject protocol in most CL implementations solves that problem (A MOP are strangely absent from the Lisp standard, but most implementations include one anyway). * Macros. When all else fails, macros are a lifesaver. Macros in Lisp have all the power of the Lisp programming language itself, at compile time -- so everything mentioned above is equally applicable. There is a strange recursive phenomenon to this argument: when all else fails in macro writing, you can create a deeper level of macros (it's macros all the way down). Macros are the reason for Lisp's unusual syntax, by the way: Lisp programs are written in a way that makes it easy for a macro to operate on a Lisp program. Now, there are certainly things I do not like about CL, like the lack of any portable support for static typing (even an optional static type system), the poor collection of standard data structures, and the lack of support for modern things like sockets, threads, etc. Fortunately there are a lot of freely available libraries for such things, but a new standard that included them would be nice.