Lisp's reputation is so bad that many people don't even take a look at Lisp(ilc2009.scheming.org)
ilc2009.scheming.org
Lisp's reputation is so bad that many people don't even take a look at Lisp
http://ilc2009.scheming.org/node/6
68 comments
"I hope the Clojure guys change things."
In many ways, Clojure seems like a deliberate response to each of the common complaints against Lisp.
In many ways, Clojure seems like a deliberate response to each of the common complaints against Lisp.
Lisp is old and moldy. It must be primitive by today's standards.
The exciting languages to learn now are Python, Ruby, Groovy, etc.
Lisp is only for artificial intelligence.
Lisp is interpreted and slow.
Lisp programs page heavily, so they're even slower.
The parentheses look weird and hard to manage.
Lisp uses prefix notation for things that every other popular language
does with infix notation, which is just very weird. (And it leads to
more parentheses.)
Lisp is too big.
Lisp is too hard to learn.
Lisp is all about lists and recursion; that's all you do with it.
I don't know which implementation to use.
It isn't "batteries included" (that is, it's not easy to get set up with all the tools and libraries you need).
I don't like Emacs, and you can't use Lisp without Emacs.
Lisp isn't useful for my career; few potential employers want it.
No offense but I don't think you get the concept of batteries included. Python has batteries included, Clojure has batteries available.
Even the clojure contrib jar is not included by default and has to be downloaded separately and then clojure needs to be launched with extra command line arguments to setup the classpath properly (or you need to fiddle with the classpath from within clojure), the same goes for any Java library that you want to use.
Even the clojure contrib jar is not included by default and has to be downloaded separately and then clojure needs to be launched with extra command line arguments to setup the classpath properly (or you need to fiddle with the classpath from within clojure), the same goes for any Java library that you want to use.
Except for the classes in the JDK. That gives you networking, file I/O, string processing, regex, Swing GUIs, JDBC, ZIP compression, some XML processing, among other things.
Even by itself, that is better than most Lisps out there, if not enough to make a Pythonista happy. The problem with this stuff is usually the painful verbosity of Java necessary to use it, but you can wrap away that pain very quickly with Clojure.
I do take the point about needing to fiddle with the classpath for any other Java code you want to use. But for me the Java classpath system holds up better than most other software deployment mechanisms. Usually, you just download a jar file, drop it on your classpath, and it just works. I think jar files are an unappreciated success story of the Java ecosystem. Clojure has functions to easily add jars to the classpath at runtime, which is even better, but I find it does not always work seamlessly for me.
Even by itself, that is better than most Lisps out there, if not enough to make a Pythonista happy. The problem with this stuff is usually the painful verbosity of Java necessary to use it, but you can wrap away that pain very quickly with Clojure.
I do take the point about needing to fiddle with the classpath for any other Java code you want to use. But for me the Java classpath system holds up better than most other software deployment mechanisms. Usually, you just download a jar file, drop it on your classpath, and it just works. I think jar files are an unappreciated success story of the Java ecosystem. Clojure has functions to easily add jars to the classpath at runtime, which is even better, but I find it does not always work seamlessly for me.
FYI, your "Lisp uses prefix notation for things that" line is causing the window to wrap verrry wide. Could you please edit it? (Thanks in advance.)
I kind of like Clojure but several things I find a bit disturbing:
1. A very subjective one - not enough parenthesis - take fo example "cond" operator - it accepts pairs condition-operation without extra parens around each pair. Well, it looks nice for small "cond"'s but for bigger ones it is both inconvenient and error prone - if off by 2 exprssion, fo some reason - yo'll get completely crewed up behavior. There several other syntactical things I find artistically impressive but technologi cally justified.
2. Another thing - I miss "setf" - in somke places mutability can be a way for smaller code especially in case
of VM without tail-recursion.
3. It is way biased towarda concurency, it was in fact engineered for concurency - well I sometimes a lot more dirtiy but fasterr solutions.
4. I think that great attractivenes of Lisp's is that you can craft your own in less then a month. No pain with lex/yacc, antlr etc. Just make a simple reader and focu on semantics.
By the way, could you describe your project, which smalltalk implementation you use, and how it simplified your work ?
"the world thinks we suck. How do we convince everyone we're vibrant and fun-loving?"
The only response that wasn't along those lines (or the old "Lisp is just too awesome for lame modern coders" shtick) was Ian Eslick's long one "A Coherent Portal into the Lisp World"; he actually seemed aware of why it was hard for new folks to get into Lisp and had suggestions about direction.
The only response that wasn't along those lines (or the old "Lisp is just too awesome for lame modern coders" shtick) was Ian Eslick's long one "A Coherent Portal into the Lisp World"; he actually seemed aware of why it was hard for new folks to get into Lisp and had suggestions about direction.
For pc: I asked the ALU webmaster about the fate of the CLRFI site. He said: "The CLRFI has been (successfully, imo) superseded by the Common Lisp Document Repository <http://cdr.eurolisp.org/>. So when we had to rebuild the server last year we decided to stop posting the bytes."
>> I ended up using Smalltalk for my startup.
I'm getting ready to start a new project with a significant GUI forms component. I wanted to go with Clojure, but it still seems a little rough around the edges. So I'm leaning towards Visualworks Smalltalk, in part because it seems like a great language to prototype in and partly because the OOP aspect fits so well with GUIs.
I'm curious: did you consider Clojure? Would you mind elaborating on why you went with Smalltalk? given the number of Lispers on this site, the answer might be of broad interest.
I'm getting ready to start a new project with a significant GUI forms component. I wanted to go with Clojure, but it still seems a little rough around the edges. So I'm leaning towards Visualworks Smalltalk, in part because it seems like a great language to prototype in and partly because the OOP aspect fits so well with GUIs.
I'm curious: did you consider Clojure? Would you mind elaborating on why you went with Smalltalk? given the number of Lispers on this site, the answer might be of broad interest.
"Visualworks Smalltalk,"
Doesn't VW have a "pay us x % of your revenue forever" license (http://www.cincomsmalltalk.com/userblogs/cincom/blogView?con...)?
I am curious as to why any startup would want to accept these terms.
Doesn't VW have a "pay us x % of your revenue forever" license (http://www.cincomsmalltalk.com/userblogs/cincom/blogView?con...)?
I am curious as to why any startup would want to accept these terms.
Well, I'm not thrilled about it. But getting something out the door is the key. Enjoying the development experience is #2. I can live with a 6% vig for the Cincom guys.
It sounds like your building a thick client, but in case your building a web app check out: http://www.seaside.st/
Thanks. I have looked at Seaside a bit and it looks impressive. I was impressed at how little code it seems to take to get something going.
My app will work best as a thick client, but I still need a website to sell it.
My app will work best as a thick client, but I still need a website to sell it.
This article links to another one which lists and describes actual issues with the core language. I don't think that it's quite as bad as you make it out to be.
I went to see if there was anything like ActiveRecord for Lisp, because, well, that's a pretty metaprogramming-heavy domain. What do I get as the first google hit? A forum post asking about that, http://coding.derkeiler.com/Archive/Lisp/comp.lang.lisp/2006... --- never a good sign. Two people answered, one with a link to his rant on comp.lang.lisp, and one talking about the virtues of CLSQL.
The code snippet from CLSQL looks horrendous:
The code snippet from CLSQL looks horrendous:
;; select the user with ID 1 and set his username column to joe
(let ((user (first (select 'user :where [= [id] 1] :flatp t :refresh t))))
(setf (username user) "joe")
(update-records-from-instance user))
User.find(1).update_attribute(:username, "joe")
(update-attribute (find *User* 1) 'username "joe")
I've been using leftparen (a framework written in PLT Scheme) for a project, this would be something like:
(rec-set-prop! userid 'username "joe")
(store-rec! userid)I found Elephant really nice to use with Lisp. It can use a SQL db as a data store, but uses it just for key/value mappings, so you can't use normal SQL commands as you might expect. I found the code to be very concise.
http://common-lisp.net/project/elephant/
http://common-lisp.net/project/elephant/
I've been programming in Common Lisp for about a year and I consider myself an intermediate beginner. Someone made a terrific comment in response to Ron Garret's post earlier: the way you get productive in today's environment is primarily through libraries.
Thus the situation is inescapable. You need tons of libraries to be productive. You need tons of programmers to write these libraries. You need an easy learning curve and appealing features to get these programmers. The bottom line is that you need the bad coders as well.
As a beginner, I can safely say that it took a while before I finally got reasonably productive in Lisp. I still consider it 'the best' programming language. But the learning curve is much steeper than Python.
Lisp will get nowhere without all the bad programmers. This may sound cynical, but the reason is that academically minded programmers won't spend time writing things like a download library for youtube videos, which many people find useful. These programmers are now all over Python.
So why is Lisp difficult to learn? The most severe in my opinion is assignment. People find it intuitive to make temporary variables and store intermediate results in these. This is done by 'let' in CL, but if the previous style of programming is assumed, 'let' is clumsy and inconvenient to use.
Another achilles heal I would like to mention is the lack of an editor with propper auto-completion. Yes, slime does this, but using emacs is too geeky for many programmers (remember you need these people) and this creates an additional stumbling block.
Yet another problem is the CL websites. Remember that many people are in a hurry. The Python website is ripe with snippets that lets you do stuff fast without understanding much. In contrst, CL gives you some of the most monotone autogenerated documentation sites I've ever seen. Again, fine for people who already know Lisp, tedious for people that want to try stuff out as beginners.
Faced with these realities I don't blame anyone who just want to get things done and run with Python. Unfortunately.
Thus the situation is inescapable. You need tons of libraries to be productive. You need tons of programmers to write these libraries. You need an easy learning curve and appealing features to get these programmers. The bottom line is that you need the bad coders as well.
As a beginner, I can safely say that it took a while before I finally got reasonably productive in Lisp. I still consider it 'the best' programming language. But the learning curve is much steeper than Python.
Lisp will get nowhere without all the bad programmers. This may sound cynical, but the reason is that academically minded programmers won't spend time writing things like a download library for youtube videos, which many people find useful. These programmers are now all over Python.
So why is Lisp difficult to learn? The most severe in my opinion is assignment. People find it intuitive to make temporary variables and store intermediate results in these. This is done by 'let' in CL, but if the previous style of programming is assumed, 'let' is clumsy and inconvenient to use.
Another achilles heal I would like to mention is the lack of an editor with propper auto-completion. Yes, slime does this, but using emacs is too geeky for many programmers (remember you need these people) and this creates an additional stumbling block.
Yet another problem is the CL websites. Remember that many people are in a hurry. The Python website is ripe with snippets that lets you do stuff fast without understanding much. In contrst, CL gives you some of the most monotone autogenerated documentation sites I've ever seen. Again, fine for people who already know Lisp, tedious for people that want to try stuff out as beginners.
Faced with these realities I don't blame anyone who just want to get things done and run with Python. Unfortunately.
"The most severe in my opinion is assignment."
Clojure solves this problem by going all the way to the opposite extreme. "No assignment for you." Clojure data structures are immutable, and if you really want to do assignment, you need to explicitly use a ref/var/atom, which means you are going to figure out a way to write your program without assignment if at all possible. Clojure, of course, is designed around functional programming that has many idioms to make assignment-less programming the natural way to do things.
I guess what this means is that Clojure can appeal to Python/Ruby/Perl hackers wanting to learn a different way to think about programming.
Clojure solves this problem by going all the way to the opposite extreme. "No assignment for you." Clojure data structures are immutable, and if you really want to do assignment, you need to explicitly use a ref/var/atom, which means you are going to figure out a way to write your program without assignment if at all possible. Clojure, of course, is designed around functional programming that has many idioms to make assignment-less programming the natural way to do things.
I guess what this means is that Clojure can appeal to Python/Ruby/Perl hackers wanting to learn a different way to think about programming.
you need the bad coders ... to write these libraries.
Great egalitarian point: it's not just karma, but that everyone has a unique point of view, with something to offer. Rejecting some segments of the population as inferior seems destined to fail, similar to (excuse my Godwin) rejecting people like Oppenheimer.
And when you "just want to get things done", aren't we all "bad coders"?
Great egalitarian point: it's not just karma, but that everyone has a unique point of view, with something to offer. Rejecting some segments of the population as inferior seems destined to fail, similar to (excuse my Godwin) rejecting people like Oppenheimer.
And when you "just want to get things done", aren't we all "bad coders"?
Someone made a terrific comment in response to Ron Garret's post earlier: the way you get productive in today's environment is primarily through libraries.
I think that was me. FWIW, I find CL's libraries to be adequate in many cases, but certainly not as good as Perl's.
(I have done a few Java projects, and I don't consider their libraries adequate at all. You are either stuck with full-stack frameworks, or a legacy API from 1995. I've also found that most Java programmers that write libraries don't know what OO is, and that makes the libraries painful to use. YMMV.
Slime is also vastly easier to use than Eclipse, even with "emacs emulation" turned on. Again, YMMV. :)
I think that was me. FWIW, I find CL's libraries to be adequate in many cases, but certainly not as good as Perl's.
(I have done a few Java projects, and I don't consider their libraries adequate at all. You are either stuck with full-stack frameworks, or a legacy API from 1995. I've also found that most Java programmers that write libraries don't know what OO is, and that makes the libraries painful to use. YMMV.
Slime is also vastly easier to use than Eclipse, even with "emacs emulation" turned on. Again, YMMV. :)
I don't know the specific Lisp or libraries involved, but reddit (YC funded) famously switched from Lisp to Python, (mainly) due to libraries.
http://blog.reddit.com/2005/12/on-lisp.html
http://blog.reddit.com/2005/12/on-lisp.html
I belong to those people who tried to get into lisp and gave up, because the confusion to navigate per potential advantage over my major language (python) was too large.
My background is a knowledge in C, Python and Java, using Python mostly.
I mostly looked into lisp, because I kept encountering something I call the syntactic barrier when I tried to remove duplication from my code, and I knew: lisp had macros. Macros could break this barrier. So looking into lisp looked promising.
I didn't care too much about the syntax, a good editor fixes this without a problem and it was a good opportunity to look into emacs a bit (usually, I use vim). Surfing through the chapters of practical common lisp when pretty well and understanding was not exactly hard.
However after that, I was faced with confusion. There is a boatload of lisp dialects, each with a boatload of implementations and each implementation as another boatload of libraries that do something looking similar to what other implementations libraries do without being the same or compatible. How am I supposed to select any of these without having a clue? After a few days of back and forth, I decided to close the book lisp for me, because I could not find a way through this wall of selections -- at least not without investing a lot of time. Too much time for too little benefit over python.
HTH, Tetha
I didn't care too much about the syntax, a good editor fixes this without a problem and it was a good opportunity to look into emacs a bit (usually, I use vim). Surfing through the chapters of practical common lisp when pretty well and understanding was not exactly hard.
However after that, I was faced with confusion. There is a boatload of lisp dialects, each with a boatload of implementations and each implementation as another boatload of libraries that do something looking similar to what other implementations libraries do without being the same or compatible. How am I supposed to select any of these without having a clue? After a few days of back and forth, I decided to close the book lisp for me, because I could not find a way through this wall of selections -- at least not without investing a lot of time. Too much time for too little benefit over python.
HTH, Tetha
Some people (like esr) say the main benefit of lisp is not to use it, but to use the insights it gives into how to think about code. It may be that you already have that.
I agree, but if a language doesn't teach you things you can use outside of it, that's a really bad sign. This is in no way unique to Lisp.
(I've been meaning to write about things I've learned from the dozen or so languages I've at least dabbled in, but haven't had the time.)
(I've been meaning to write about things I've learned from the dozen or so languages I've at least dabbled in, but haven't had the time.)
Hopefully some of the cooler Lisp dialects like Clojure & Nu will help out a bit. The "crazy parentheses" is usually the core reason people hate lisp, but until they realize its power, it's stupid stuff that prevents them from learning it.
For example, Nu is one of the coolest languages out there that allows one to do quick and dirty "scripting language" hacks in Objective-C. Due to Lisp's simple structure, Nu was able to directly map Objective-C method call signatures into something that clearly looks like basic Lisp. It allows one to code in 2 languages, but the Objective-C part of the language actually looks very similar to normal ObjC. One of the biggest benefits of Nu is that writing unit tests in ObjC is no longer painful... the whole testing structure is as simple as typical ruby unit test cases.
Clojure is another one of those wonderful libraries that is a must-have for anyone doing normal java. Even basic string manipulation is extremely verbose and annoying in Java, but is probably too heavy to load a JRuby/Jython interpreter... I think that's where clojure helps fill the gap. I recently implemented an "equivalent" of a google-analytics tracker in Clojure and the final result was only around 200 lines of code (with a little bit of java here and there). It's quite nice to use clojure as a glue-language to make all your java libraries work together with little clutter as possible.
For example, Nu is one of the coolest languages out there that allows one to do quick and dirty "scripting language" hacks in Objective-C. Due to Lisp's simple structure, Nu was able to directly map Objective-C method call signatures into something that clearly looks like basic Lisp. It allows one to code in 2 languages, but the Objective-C part of the language actually looks very similar to normal ObjC. One of the biggest benefits of Nu is that writing unit tests in ObjC is no longer painful... the whole testing structure is as simple as typical ruby unit test cases.
Clojure is another one of those wonderful libraries that is a must-have for anyone doing normal java. Even basic string manipulation is extremely verbose and annoying in Java, but is probably too heavy to load a JRuby/Jython interpreter... I think that's where clojure helps fill the gap. I recently implemented an "equivalent" of a google-analytics tracker in Clojure and the final result was only around 200 lines of code (with a little bit of java here and there). It's quite nice to use clojure as a glue-language to make all your java libraries work together with little clutter as possible.
The "crazy parentheses" is usually the core reason people hate lisp
I very strongly suspect that the "crazy parentheses" is not actually why most people who hate Lisp hate Lisp. Crazy parentheses are nowhere near the top of my list of reasons, anyway. And, blaming parentheses is the same as complaining about the sigils in Perl or the significant white space in Python; it's just not a very intelligent argument, and can probably safely be dismissed as merely uninformed. Sure, you like what you're accustomed to, but you can become accustomed to different syntax quite easily...one or two weeks is all it took for me to switch from Perl to Python, and then back again a few years later.
A syntactic difference is just a very simple concept to latch on to; both for those who hate Lisp (for whatever reason) and those who want to explain away the people who hate Lisp (without having to address the real, but complicated, problems). There are a lot of very good reasons to hate Lisp, but they take more than one or two sentences to explain, and most folks just aren't going to invest that much effort in talking about something they just don't have that much interest in.
The linked article does mention a few of the very good reasons to hate lisp, and leaves out a couple that I think are possibly even more important:
- Lisp has a community that is generally hostile to newbies and outsiders (mentioning other languages, in particular, seems to be a big source of trouble). Contrast this with just about any other modern dynamic language community. Friendliness is practically religion in the Perl, Python, and Ruby communities (though I think only Perl has a formal religious institution for the purpose at perlmonks.org ).
- A community that has a deeply ingrained culture of NIH. There are dozens of incompatible Lisps, with dozens of incompatible libraries for all sorts of tasks. I've found Lisp to be the most difficult language with which to produce useful software as a beginner of any dynamic language I've tried. Not because Lisp is inferior to Perl, Python, Ruby, etc. but because I found it impossible to find any combination of components that made it possible for me to produce useful software without running into bugs or incompatibilities that my weak knowledge couldn't overcome. Even if Lisp allows for code that's half or a quarter the size of any other dynamic language (which seems an unlikely compression), the sheer volume of excellent libraries in Perl/Python/Ruby means I can write a tenth the code, making those languages a win even if the total line count, including libraries, is higher. I've been told (grouchily, in keeping with the smug Lisp weenie tradition) that tons of great libraries exist for Lisp. Despite this assertion, I've never been able to build even a toy (but useful) project in Lisp.
I very strongly suspect that the "crazy parentheses" is not actually why most people who hate Lisp hate Lisp. Crazy parentheses are nowhere near the top of my list of reasons, anyway. And, blaming parentheses is the same as complaining about the sigils in Perl or the significant white space in Python; it's just not a very intelligent argument, and can probably safely be dismissed as merely uninformed. Sure, you like what you're accustomed to, but you can become accustomed to different syntax quite easily...one or two weeks is all it took for me to switch from Perl to Python, and then back again a few years later.
A syntactic difference is just a very simple concept to latch on to; both for those who hate Lisp (for whatever reason) and those who want to explain away the people who hate Lisp (without having to address the real, but complicated, problems). There are a lot of very good reasons to hate Lisp, but they take more than one or two sentences to explain, and most folks just aren't going to invest that much effort in talking about something they just don't have that much interest in.
The linked article does mention a few of the very good reasons to hate lisp, and leaves out a couple that I think are possibly even more important:
- Lisp has a community that is generally hostile to newbies and outsiders (mentioning other languages, in particular, seems to be a big source of trouble). Contrast this with just about any other modern dynamic language community. Friendliness is practically religion in the Perl, Python, and Ruby communities (though I think only Perl has a formal religious institution for the purpose at perlmonks.org ).
- A community that has a deeply ingrained culture of NIH. There are dozens of incompatible Lisps, with dozens of incompatible libraries for all sorts of tasks. I've found Lisp to be the most difficult language with which to produce useful software as a beginner of any dynamic language I've tried. Not because Lisp is inferior to Perl, Python, Ruby, etc. but because I found it impossible to find any combination of components that made it possible for me to produce useful software without running into bugs or incompatibilities that my weak knowledge couldn't overcome. Even if Lisp allows for code that's half or a quarter the size of any other dynamic language (which seems an unlikely compression), the sheer volume of excellent libraries in Perl/Python/Ruby means I can write a tenth the code, making those languages a win even if the total line count, including libraries, is higher. I've been told (grouchily, in keeping with the smug Lisp weenie tradition) that tons of great libraries exist for Lisp. Despite this assertion, I've never been able to build even a toy (but useful) project in Lisp.
A few additions:
* The parenthesis do require that you have at least a moderately capable editor to navigate them effectively. You can start coding things like PHP, Perl, Ruby, Python, etc... with a pretty crappy editor and do ok.
* NIH - bingo! Lisp has always struck me as being very insular, with a very strong 'turtles all the way down' mentality. "It would really be best if the OS were written in Lisp too...", whereas the "scripting" languages are very promiscuous in terms of what they will interact with and run on. This has led them to focus on doing what they are good at, and calling out to C or other languages for what they are not so good at, which is ultimately more productive than rewriting existing systems just so that they'll be 100% in your language of choice. (Yes, sure, not everyone in the Lisp world is like that, but I get that general feeling).
* The parenthesis do require that you have at least a moderately capable editor to navigate them effectively. You can start coding things like PHP, Perl, Ruby, Python, etc... with a pretty crappy editor and do ok.
* NIH - bingo! Lisp has always struck me as being very insular, with a very strong 'turtles all the way down' mentality. "It would really be best if the OS were written in Lisp too...", whereas the "scripting" languages are very promiscuous in terms of what they will interact with and run on. This has led them to focus on doing what they are good at, and calling out to C or other languages for what they are not so good at, which is ultimately more productive than rewriting existing systems just so that they'll be 100% in your language of choice. (Yes, sure, not everyone in the Lisp world is like that, but I get that general feeling).
>> The parenthesis do require that you have at least a moderately capable editor to navigate them effectively.
I disagree, with a caveat--writing code using a terrible editor requires knowledge of the indentation rules for the language, regardless of whether that language is a lisp, Perl, Ruby, etc.
However (the caveat), although the indentation rules for Perl, C, Python are relatively simple (indent after a '{' or ':', line up arguments), each function/macro in a lisp can have different indenting rules (e.g. in CL compare `let' to `multiple-value-bind' to functions, to lists, to the various `with-*' macros, etc).
Once you know the library for a specific implementation, the indentation rules become more obvious; at this point, using (e.g.) Notepad isn't particularly terrible (until that knowledge is acquired, though, yikes).
I disagree, with a caveat--writing code using a terrible editor requires knowledge of the indentation rules for the language, regardless of whether that language is a lisp, Perl, Ruby, etc.
However (the caveat), although the indentation rules for Perl, C, Python are relatively simple (indent after a '{' or ':', line up arguments), each function/macro in a lisp can have different indenting rules (e.g. in CL compare `let' to `multiple-value-bind' to functions, to lists, to the various `with-*' macros, etc).
Once you know the library for a specific implementation, the indentation rules become more obvious; at this point, using (e.g.) Notepad isn't particularly terrible (until that knowledge is acquired, though, yikes).
Notepad is exactly what I'm talking about. With Perl, C, and Ruby, at least, there really aren't any indentation rules - your program will work fine even if you don't put any in at all, or do a hacky job of it. With Lisp, especially when modifying someone else's code you're stuck counting parens.
Oh, also a weird (maybe crackpot?:-) theory of mine: parenthesis, graphically, don't form a nice, rigid vertical line, but sort of point diagonally, possibly making it just that much harder to see how they line up. In any case, 4 or 8 space indented C/Tcl/Ruby/whatever code is certainly more obvious to the eye.
Oh, also a weird (maybe crackpot?:-) theory of mine: parenthesis, graphically, don't form a nice, rigid vertical line, but sort of point diagonally, possibly making it just that much harder to see how they line up. In any case, 4 or 8 space indented C/Tcl/Ruby/whatever code is certainly more obvious to the eye.
(In the following text, replace "you" by "I")
"A community that has a deeply ingrained culture of NIH."
Lisp is a NIHer's heaven. I know something about it, I've just spent 3 years learning new stuff and reimplementing the universe with it (I'm not done yet. Give it some decades...). Learning Lisp is a friggin' Pandora box. It gives you absolute power (that corrupts you absolutely), it makes you discover crazy powerful and sometimes hard to implement paradigms (ex: Dataflow), and of course you have to try to implement them so you simply never get anything done. Sure, you do things The Right Way, but the investment in implementation and learning time is absolutely prohibitive. Gotta admit I'm not sure if Lisp made me a NIHer or I was just drawn to Lisp because I'm one but Lisp sure is an aggravating factor for that.
A few days ago I finally decided to STOP LEARNING and STOP REIMPLEMENTING THE UNIVERSE for a few months so I can finally launch my startup (some utility site for a niche MMORPG).
"A community that has a deeply ingrained culture of NIH."
Lisp is a NIHer's heaven. I know something about it, I've just spent 3 years learning new stuff and reimplementing the universe with it (I'm not done yet. Give it some decades...). Learning Lisp is a friggin' Pandora box. It gives you absolute power (that corrupts you absolutely), it makes you discover crazy powerful and sometimes hard to implement paradigms (ex: Dataflow), and of course you have to try to implement them so you simply never get anything done. Sure, you do things The Right Way, but the investment in implementation and learning time is absolutely prohibitive. Gotta admit I'm not sure if Lisp made me a NIHer or I was just drawn to Lisp because I'm one but Lisp sure is an aggravating factor for that.
A few days ago I finally decided to STOP LEARNING and STOP REIMPLEMENTING THE UNIVERSE for a few months so I can finally launch my startup (some utility site for a niche MMORPG).
Same experience with Lisp / Scheme here. There's a truly awe-inspiring amount of computer science research published about Scheme, in particular. I learned a TON, but I also learned that if I'm actually trying to get stuff done, I'm better off using something else, such as Lua or Python.
Lua, while even more Scheme-like than Python, was designed primarily for use as an embedded scripting engine in another languages (typically C or C++). Instead of putting effort into making Lua clones of typical libraries, they worked on making re-using other languages' existing libraries quite easy. It seems to stand the whole NIH thing on its head, too. (Though, languages such as Chicken Scheme that compile to C can inter-operate better than most.)
Lua, while even more Scheme-like than Python, was designed primarily for use as an embedded scripting engine in another languages (typically C or C++). Instead of putting effort into making Lua clones of typical libraries, they worked on making re-using other languages' existing libraries quite easy. It seems to stand the whole NIH thing on its head, too. (Though, languages such as Chicken Scheme that compile to C can inter-operate better than most.)
it's just not a very intelligent argument, and can probably safely be dismissed as merely uninformed.
Do you mean that people who hate lisp because of its parentheses are uninformed; or do you mean that thinking that this is the reason people hate lisp is uninformed? The first is about languages; the second is about people.
Assuming the latter, what's the evidence? Many people complain about parentheses, so it seems that it is an active reason, but without a rigorous survey ("Why do you hate lisp?"), it's hard to know.
The issue with parentheses is not about "hate" at all, but confusion. If you are 100% determined to learn something no matter what, you can probably learn it. But in reality, when you start to learn something, you are also assessing if it is worth the effort of learning.
The context of my first experience with lisp was that it was supposed to be more "mathematical" than other languages - and so I assumed the parentheses were used as they are in expressions, that is, for grouping. But they aren't used in that way in Lisp - they mean function call, like f(x), but with yet another syntax. So, my 5 minute cursory foray into Lisp ended with me concluding that Lisp was unexpectedly inconsistent. Since that's against my usability values, I didn't spend further time on it (since then, I have spent further time).
I didn't hate the parentheses; I just found their meaning elusive.
Do you mean that people who hate lisp because of its parentheses are uninformed; or do you mean that thinking that this is the reason people hate lisp is uninformed? The first is about languages; the second is about people.
Assuming the latter, what's the evidence? Many people complain about parentheses, so it seems that it is an active reason, but without a rigorous survey ("Why do you hate lisp?"), it's hard to know.
The issue with parentheses is not about "hate" at all, but confusion. If you are 100% determined to learn something no matter what, you can probably learn it. But in reality, when you start to learn something, you are also assessing if it is worth the effort of learning.
The context of my first experience with lisp was that it was supposed to be more "mathematical" than other languages - and so I assumed the parentheses were used as they are in expressions, that is, for grouping. But they aren't used in that way in Lisp - they mean function call, like f(x), but with yet another syntax. So, my 5 minute cursory foray into Lisp ended with me concluding that Lisp was unexpectedly inconsistent. Since that's against my usability values, I didn't spend further time on it (since then, I have spent further time).
I didn't hate the parentheses; I just found their meaning elusive.
Do you mean that people who hate lisp because of its parentheses are uninformed; or do you mean that thinking that this is the reason people hate lisp is uninformed?
Both, actually. But moreso the folks who complain about parentheses. I suspect that anyone who uses that as their reason for not learning or liking Lisp simply would never consider Lisp long enough to know anything more about the language. I just think it's more likely because they like "industry standard" languages, and have no obvious on-the-job use for Lisp, but they don't want to say "I am intellectually incurious about languages and different programming paradigms". I think those same people would never learn Lua or Haskell, despite a distinct lack of crazy parentheses.
Many people complain about parentheses
Many people complain about significant whitespace in Python and sigils in Perl. Either one has orders of magnitude more developers and more code being written in it on a daily basis. It is a triviality, and the kind of folks who pick out trivialities to complain about are not the kind of folks you can convert. They're not going to learn your favorite language, unless you make it look exactly like their favorite language. Since Lisp can't look like Java or C# or C or Visual Basic or PHP, without losing a lot of what makes Lisp Lisp, that's not a useful pursuit.
So, I'm simply saying that talking over parentheses over and over again is ignoring the real problems and focusing on the one that everyone knows won't change. It's a perfect flame war talking point, but it's not what's keeping people away from Lisp.
Both, actually. But moreso the folks who complain about parentheses. I suspect that anyone who uses that as their reason for not learning or liking Lisp simply would never consider Lisp long enough to know anything more about the language. I just think it's more likely because they like "industry standard" languages, and have no obvious on-the-job use for Lisp, but they don't want to say "I am intellectually incurious about languages and different programming paradigms". I think those same people would never learn Lua or Haskell, despite a distinct lack of crazy parentheses.
Many people complain about parentheses
Many people complain about significant whitespace in Python and sigils in Perl. Either one has orders of magnitude more developers and more code being written in it on a daily basis. It is a triviality, and the kind of folks who pick out trivialities to complain about are not the kind of folks you can convert. They're not going to learn your favorite language, unless you make it look exactly like their favorite language. Since Lisp can't look like Java or C# or C or Visual Basic or PHP, without losing a lot of what makes Lisp Lisp, that's not a useful pursuit.
So, I'm simply saying that talking over parentheses over and over again is ignoring the real problems and focusing on the one that everyone knows won't change. It's a perfect flame war talking point, but it's not what's keeping people away from Lisp.
Yes, I can see parentheses as a convenient catch-phrase. While it's less familiar than indentation in Python, you're right that people complain about that too, but it hasn't stopped adoption.
Unfortunately, I think the community is about as likely to change.
Unfortunately, I think the community is about as likely to change.
Unfortunately, I think the community is about as likely to change.
I agree. They've had longer than anyone to figure out the "community" thing, and they've self-selected into near obscurity.
I agree. They've had longer than anyone to figure out the "community" thing, and they've self-selected into near obscurity.
I agree that the "crazy parentheses" might not be the core reason people who hate Lisp hate Lisp, but it certainly doesn't help advocacy for management types. It's definitely knee-jerk, but lots of people make their decisions in a "blink" and it definitely helps when code looks like "User.find_or_create_by_name(john)". Usually the people who hate lisp, have never done a significant project in it, and never will simply because of the syntax. In a way, it's like trying to learn Korean as an English speaker. Korean is a very modern alphabet based language, but the random strokes in their alphabet would probably make anyone take one look and say "jeez, that looks chinese to me"
Sounds like reaction to Lisp syntax is a good heuristic for choosing managers not to work for.
A good manager will either 1) research more thoroughly and come up with a more sensible reason to not use Lisp (there are many reasons not to use Lisp for many kinds of projects) or 2) delegate technical decisions to the technical people he hired and trusts to make those decisions (with some way to hold them accountable for meeting objectives).
A good manager will either 1) research more thoroughly and come up with a more sensible reason to not use Lisp (there are many reasons not to use Lisp for many kinds of projects) or 2) delegate technical decisions to the technical people he hired and trusts to make those decisions (with some way to hold them accountable for meeting objectives).
Lisp was my favorite language when I studied (hrm, long ago).
IMHO, there is quite a lot of support for the argument that modern day scripting languages are getting closer and closer to becoming lisps, except for syntax and the macro system. (Maybe Perl 6 will have meta-language power enough to equal the macro system? I should start learning it.)
I've never really understood why there are no successful projects to transfer code between the S-EXPR parenthesis-based syntax and some Algol-like notation; if that managed to also copy comments between the formats and auto formatted well, it would be an easy introduction for new lispers.
IMHO, there is quite a lot of support for the argument that modern day scripting languages are getting closer and closer to becoming lisps, except for syntax and the macro system. (Maybe Perl 6 will have meta-language power enough to equal the macro system? I should start learning it.)
I've never really understood why there are no successful projects to transfer code between the S-EXPR parenthesis-based syntax and some Algol-like notation; if that managed to also copy comments between the formats and auto formatted well, it would be an easy introduction for new lispers.
Maybe Perl 6 will have meta-language power enough to equal the macro system?
Not only does it have full-on raging macros, you can redefine the languages own syntax inline. Check out one of Larry's recent talks about STD.pm (here's a Google Tech Talk from last year, which is nowhere near as funny as Larry usually is, but is still quite informative: http://www.youtube.com/watch?v=JzIWdJVP-wo )for a real "when you see it, you'll shit bricks" moment. Perl 6 is far more intimidating than I ever realized. They seem to have looked at everything good about Perl (and a handful of other languages) and said, "Let's do a lot more of that." It's somewhat scary how much more of "that" they've done. So, there's macros from Lisp, lazy evaluation from Haskell, redefine-able grammar and syntax from I dunno where, a new regex language, etc. It takes TMTOWTDI to obscene new heights (kinda like Lisp). If power is the sole determining factor in what language you choose, there's a strong case to be made that Perl 6 is the one you want. I don't know that I entirely buy that (if I did, I guess I'd be using Lisp), but I'm hopeful that the real result of Perl 6 will be a language as capable as Lisp with a community and library culture as strong as Perl 5.
Not only does it have full-on raging macros, you can redefine the languages own syntax inline. Check out one of Larry's recent talks about STD.pm (here's a Google Tech Talk from last year, which is nowhere near as funny as Larry usually is, but is still quite informative: http://www.youtube.com/watch?v=JzIWdJVP-wo )for a real "when you see it, you'll shit bricks" moment. Perl 6 is far more intimidating than I ever realized. They seem to have looked at everything good about Perl (and a handful of other languages) and said, "Let's do a lot more of that." It's somewhat scary how much more of "that" they've done. So, there's macros from Lisp, lazy evaluation from Haskell, redefine-able grammar and syntax from I dunno where, a new regex language, etc. It takes TMTOWTDI to obscene new heights (kinda like Lisp). If power is the sole determining factor in what language you choose, there's a strong case to be made that Perl 6 is the one you want. I don't know that I entirely buy that (if I did, I guess I'd be using Lisp), but I'm hopeful that the real result of Perl 6 will be a language as capable as Lisp with a community and library culture as strong as Perl 5.
What I meant was, will it be as easy to use as lisp macros?
To take most everything good existing and sum it, is how you make Perls. :-) I'm not arguing here, I do Perl today.
You should have put the content of the last sentence first; too few will read it.
To take most everything good existing and sum it, is how you make Perls. :-) I'm not arguing here, I do Perl today.
You should have put the content of the last sentence first; too few will read it.
You should really look into Nu, the language I mentioned in my parent post. It is a "glue" language for Objective-C and allows you to write code using typical lisp prefix-notation (+ 1 2) or infix (1 + 2). Reason being ObjC is mostly object oriented with infix & named parameters, so it fits in both worlds.
For example, if you're typically a lisp guy, you would probably write code like this: (init (alloc ApplicationDelegate))
But if you're an ObjC person, you'd do this: ((ApplicationDelegate alloc) init))
And strangely, if you replaced the parentheses with normal square brackets, you'd be looking at syntactically correct ObjC code! In Nu you can mix and match your sexprs and algol-like notations as long as you know what you're doing. The finished code would be something a lisp developer and ObjC developer could both understand without knowing too much of the underlying details.
For example, if you're typically a lisp guy, you would probably write code like this: (init (alloc ApplicationDelegate))
But if you're an ObjC person, you'd do this: ((ApplicationDelegate alloc) init))
And strangely, if you replaced the parentheses with normal square brackets, you'd be looking at syntactically correct ObjC code! In Nu you can mix and match your sexprs and algol-like notations as long as you know what you're doing. The finished code would be something a lisp developer and ObjC developer could both understand without knowing too much of the underlying details.
Nu looked cool. (I thought from browsing that it should be some Lisp-like macro lib; a guy I knew used something like that for assembler, started early 80s. PDP-10. :-) )
Interesting idea to level a scripting language on using the message passing mechanism of Obj-C -- and so integrate the resulting code with the compiled Obj-C!
Thanks for making me look!
Interesting idea to level a scripting language on using the message passing mechanism of Obj-C -- and so integrate the resulting code with the compiled Obj-C!
Thanks for making me look!
> IMHO, there is quite a lot of support for the argument that modern day scripting languages are getting closer and closer to becoming lisps...
Yes, but, I'm sorry, not every computer science advance came from Lisp. (Not singling you out in particular, berntb.) Insisting otherwise makes one sound condescending, fanatic, and/or naive. There are good ideas in Lisp, yes, but there are also good ideas in ML, Lua, Awk, SQL, Smalltalk, Prolog, Haskell, SNOBOL, etc.
Lisp is cool as a clean embodiment of the Lambda calculus and all, but if people stopped treating it like it were a divine revelation, other people would perhaps stop getting the impression that Lisp users are [insert torrent of unflattering adjectives].
(The Scheme community is generally much better about this than the Common Lisp community, but the Scheme community at large also seems to spend more time trying to actually move the language forward rather than insisting that some old standard has everything people will ever need.)
Yes, but, I'm sorry, not every computer science advance came from Lisp. (Not singling you out in particular, berntb.) Insisting otherwise makes one sound condescending, fanatic, and/or naive. There are good ideas in Lisp, yes, but there are also good ideas in ML, Lua, Awk, SQL, Smalltalk, Prolog, Haskell, SNOBOL, etc.
Lisp is cool as a clean embodiment of the Lambda calculus and all, but if people stopped treating it like it were a divine revelation, other people would perhaps stop getting the impression that Lisp users are [insert torrent of unflattering adjectives].
(The Scheme community is generally much better about this than the Common Lisp community, but the Scheme community at large also seems to spend more time trying to actually move the language forward rather than insisting that some old standard has everything people will ever need.)
Your point say something about the scars you got from your educational environment? :-)
AFAIK, not even the lisp snobs would argue that everything worthwhile happened in lisp; they argue that most of the lisp characteristics was copied by everyone. For some values of "most", it seems like a very good argument.
AFAIK, not even the lisp snobs would argue that everything worthwhile happened in lisp; they argue that most of the lisp characteristics was copied by everyone. For some values of "most", it seems like a very good argument.
Dude, I was a history student. :) (I taught myself to program with library books and a C-64, starting when I was five or so.)
Just, it boggles my mind how many ideas from barely ten years ago seem completely unfamiliar to most programmers. As Steve Yegge put it, "Oh, right, I keep forgetting: you were born in nineteen-ninety something, and you're nineteen, and I'm ninety-something."
I'm only 27, but I'm starting to feel like I'm at least one programmer-generation back (and, occasionally, the cranky old man yelling, "get off my lawn!"). I find a lot of inspiration in the 70s-80s Unix-era books, for example. While some of the surface details have changed, those guys wrote lucidly about ways to design useful systems without them growing into impossibly tangled monstrosities (even before C++...). A lot of issues programmers struggle with today have been mulled over for decades, and there's a lot of good advice if you look. The field hasn't changed that much.
I see ideas that keep getting rediscovered, and sometimes it's really sad how few stick. Lisp had a lot of great ideas in it, yes, but it's not the only old language that did, and the way it gets exalted that way touches a nerve of mine sometimes. (FWIW, the second paragraph in my response above was saved right as the edit window closed. I was still rewriting it, and it sounds harsher than I would have kept.)
Just, it boggles my mind how many ideas from barely ten years ago seem completely unfamiliar to most programmers. As Steve Yegge put it, "Oh, right, I keep forgetting: you were born in nineteen-ninety something, and you're nineteen, and I'm ninety-something."
I'm only 27, but I'm starting to feel like I'm at least one programmer-generation back (and, occasionally, the cranky old man yelling, "get off my lawn!"). I find a lot of inspiration in the 70s-80s Unix-era books, for example. While some of the surface details have changed, those guys wrote lucidly about ways to design useful systems without them growing into impossibly tangled monstrosities (even before C++...). A lot of issues programmers struggle with today have been mulled over for decades, and there's a lot of good advice if you look. The field hasn't changed that much.
I see ideas that keep getting rediscovered, and sometimes it's really sad how few stick. Lisp had a lot of great ideas in it, yes, but it's not the only old language that did, and the way it gets exalted that way touches a nerve of mine sometimes. (FWIW, the second paragraph in my response above was saved right as the edit window closed. I was still rewriting it, and it sounds harsher than I would have kept.)
Yeah, the standards seem to be lower in general. Probably because the barriers to entry are lower. (-: As an oldie, I try to be humble by remembering the Flynn effect. :-)
And then...
Be happy kid, it gets worse. :-)
Exercise, take vacations and make certain you relax enough (a meditation-course is good; there are non-religious ones). Also, be careful with your teeth; an infection I had no other effects of, made me chronically tired for a long time and really destroyed my life (I thought I had burned out).
And work with stuff you care about, otherwise you'll probably hate yourself and everyone else.
Most other stuff you seem to know.
Sorry for that, but a 20-something trying to sound world weary needs a pat on the head. :-)
And then...
Be happy kid, it gets worse. :-)
Exercise, take vacations and make certain you relax enough (a meditation-course is good; there are non-religious ones). Also, be careful with your teeth; an infection I had no other effects of, made me chronically tired for a long time and really destroyed my life (I thought I had burned out).
And work with stuff you care about, otherwise you'll probably hate yourself and everyone else.
Most other stuff you seem to know.
Sorry for that, but a 20-something trying to sound world weary needs a pat on the head. :-)
Isn't Dylan a sort of lisp-without-parens?
Except for the lisp macros, I think it lacks the eval-print-loop? (Quite logical, since it was done for Newton from the beginning and not comiled in the native environment, I think.) That loop is part of what makes scripting languages and lisp so productive.
The problem is, someone with these preconceptions often doesn't even look for our replies!
How's about conceptualizing the problem less as "People don't come to the light about how Lisp is not as problematic as they think it is" and more as "We need to explain better how people's lives are going to improve if they learn and use Lisp". (I know, I know, I may have just committed the sin of marketing. Please forgive me.)
I do not have a Lisp-sized hole in my life right now.
How's about conceptualizing the problem less as "People don't come to the light about how Lisp is not as problematic as they think it is" and more as "We need to explain better how people's lives are going to improve if they learn and use Lisp". (I know, I know, I may have just committed the sin of marketing. Please forgive me.)
I do not have a Lisp-sized hole in my life right now.
I think ensuring first that peoples' lives would be helped if they learn and use Lisp is important, too. Some people take this for granted (and can come off as incredibly condescending, PS), but I'm not so sure anymore.
I know (and really like) Scheme, but the balkanized Scheme ecosystem can be very confusing to curious onlookers, and can make finding one implementation with all the libraries relevant to a project difficult. There's the tiny core language, then there's a bunch of SRFIs that implementations choose whether to support, and implementations are all over the place as far as quality, libraries, and portability. (I eventually settled on Chicken.)
I learned some Common Lisp, but ran into so many portability and library problems, for stuff that would be trivial in Python, that I ultimately gave up on it. In retrospect, Scheme is a much better fit for my taste, anyway.
For a while, Python was my default language for real work. (Lately, I've switched to Lua. They're quite similar, though Lua has incorporated more of Scheme's good ideas, has more of its own, and has a much cleaner design, IMHO.) While neither has macros, they have a collection of libraries, an active community, an obvious standard implementation, great support for interactive development, a decent syntax, etc. Macros aren't everything, and SwellJoe's comment about NIH (http://news.ycombinator.com/item?id=550634) is absolutely correct. (Lua's design, in particular, assumes from the start that it will be embedded in something else. It's very simple to use it with other languages and their libraries.)
While I don't know Ruby (Python & Lua already fill that niche for me), I'd expect Ruby programmers find similar productivity there.
I know (and really like) Scheme, but the balkanized Scheme ecosystem can be very confusing to curious onlookers, and can make finding one implementation with all the libraries relevant to a project difficult. There's the tiny core language, then there's a bunch of SRFIs that implementations choose whether to support, and implementations are all over the place as far as quality, libraries, and portability. (I eventually settled on Chicken.)
I learned some Common Lisp, but ran into so many portability and library problems, for stuff that would be trivial in Python, that I ultimately gave up on it. In retrospect, Scheme is a much better fit for my taste, anyway.
For a while, Python was my default language for real work. (Lately, I've switched to Lua. They're quite similar, though Lua has incorporated more of Scheme's good ideas, has more of its own, and has a much cleaner design, IMHO.) While neither has macros, they have a collection of libraries, an active community, an obvious standard implementation, great support for interactive development, a decent syntax, etc. Macros aren't everything, and SwellJoe's comment about NIH (http://news.ycombinator.com/item?id=550634) is absolutely correct. (Lua's design, in particular, assumes from the start that it will be embedded in something else. It's very simple to use it with other languages and their libraries.)
While I don't know Ruby (Python & Lua already fill that niche for me), I'd expect Ruby programmers find similar productivity there.
I wonder how much this balkanization is a result of the syntactic extension capabilities of lispish languages?
The fact that you can implement changes to the language in the language makes it easier to improve it in terms of coming up with new features/patterns etc. However this can be a double edged sword when you need to then train large numbers of programmers in order to create libraries etc. for the new language. Or maybe its not that the splintering
occurs directly because of the language. Instead it might occur indirectly due to lisp programmers, having been exposed to the idea of language extension through lisp, become more prone to creating a whole new language when the one they have doesn't suit their needs precisely?
Well, first, the core Scheme spec is tiny. Tons of people have written at least half-complete Scheme interpreters (self included, in OCaml). It's a fun project, and it teaches you a lot about programming, even if you don't do the tricky parts (like full continuations). This seems to feed a strong "just fork your own" sentiment in the community, though, and that probably leads directly to a mishmash of incompatible libraries. That's Scheme, though, not Common Lisp; CL was an attempt to reign in several divergent Lisp dialects.
Also, I think people overuse macros. Certain people have put a lot of time into promoting them as the biggest asset of the language, which tends to encourage people to use them where they're not only unnecessary, but likely to make code harder to understand / maintain. (See, for instance, http://news.ycombinator.com/item?id=542746. Especially: "Q: What do you get when programmers design a language while trying to get something else done? A: PHP")
While I'm not knowledgeable enough about Ruby to say for certain, I could see making a big deal about "monkeypatching" causing similar problems there. Maybe the Ruby community encourages more restraint, though. Anybody?
Also, I think people overuse macros. Certain people have put a lot of time into promoting them as the biggest asset of the language, which tends to encourage people to use them where they're not only unnecessary, but likely to make code harder to understand / maintain. (See, for instance, http://news.ycombinator.com/item?id=542746. Especially: "Q: What do you get when programmers design a language while trying to get something else done? A: PHP")
While I'm not knowledgeable enough about Ruby to say for certain, I could see making a big deal about "monkeypatching" causing similar problems there. Maybe the Ruby community encourages more restraint, though. Anybody?
I absolutely love Common Lisp, but it has some problematic areas, which are not the classical stupid ones you sometimes still hear from clueless people (such as "lots of parentheses", "lisp is slow", "lisp is for AI only" etc.).
I won't even say that libraries are a real problem. Sure there is no CPAN, but still there are a lot of very good CL libraries around, and they are not really hard to install.
But:
1. The language is sophisticated. This is a "problem", in the sense that such a language takes time to study. It will never be popular. The Condition system and CLOS, for example, are way more complex and versatile than, say, the equivalent areas of Java. And then there are macros. Common Lisp has not been designed as a mainstream language for mainstream programmers. It is, I fear, an elite tool.
2. Certain kind of operations are inconvenient. Maybe when CL was designed, sockets, multithreading, text processing etc were not so popular. But now, it feels like CL has not really adapted well to the modern world. Having to install a compatibility library for using sockets is reminiscent of things like "trumpet winsock". Does not feel very cutting edge.
3. The literature is lacking. "Practical Common Lisp" is very good, but one book is not enough. For example, what are the best practices to organize large CL programs? No book tells it (maybe some obscure out-of-print text that I have not yet tracked?). What about programming idioms, or patterns as you prefer? Apart from an ancient presentation by peter norvig, nothing exist. And so on.
4. The ANSI standard is a big blessing and a big curse. It is a well-written and smart opus. But nowadays no one has the resources for a new standard; both in terms of money and focus. This means that ANSI CL seems an ancient pinnacle of beauty which will never be equalled and certainly can not be improved. (the perfection of ancient architecture, as seen by renaissance architects, comes to mind). This makes CL a splendid but dying civilization.
5. I have a feeling that the community is slowly dying as well. While in recent years many CL sites and blogs have appeared, comp.lang.lisp has lost many important contributors. Nor I can really blame them: while still a wonderful language, CL is nonetheless petrified, and I suppose one may became slightly bored after a decade or two of discussing the finer points of the Standard.
I won't even say that libraries are a real problem. Sure there is no CPAN, but still there are a lot of very good CL libraries around, and they are not really hard to install.
But:
1. The language is sophisticated. This is a "problem", in the sense that such a language takes time to study. It will never be popular. The Condition system and CLOS, for example, are way more complex and versatile than, say, the equivalent areas of Java. And then there are macros. Common Lisp has not been designed as a mainstream language for mainstream programmers. It is, I fear, an elite tool.
2. Certain kind of operations are inconvenient. Maybe when CL was designed, sockets, multithreading, text processing etc were not so popular. But now, it feels like CL has not really adapted well to the modern world. Having to install a compatibility library for using sockets is reminiscent of things like "trumpet winsock". Does not feel very cutting edge.
3. The literature is lacking. "Practical Common Lisp" is very good, but one book is not enough. For example, what are the best practices to organize large CL programs? No book tells it (maybe some obscure out-of-print text that I have not yet tracked?). What about programming idioms, or patterns as you prefer? Apart from an ancient presentation by peter norvig, nothing exist. And so on.
4. The ANSI standard is a big blessing and a big curse. It is a well-written and smart opus. But nowadays no one has the resources for a new standard; both in terms of money and focus. This means that ANSI CL seems an ancient pinnacle of beauty which will never be equalled and certainly can not be improved. (the perfection of ancient architecture, as seen by renaissance architects, comes to mind). This makes CL a splendid but dying civilization.
5. I have a feeling that the community is slowly dying as well. While in recent years many CL sites and blogs have appeared, comp.lang.lisp has lost many important contributors. Nor I can really blame them: while still a wonderful language, CL is nonetheless petrified, and I suppose one may became slightly bored after a decade or two of discussing the finer points of the Standard.
You're dead-on about the lack of literature. I am no lisp expert (python stole me away), but something like the PythonChallenge for lisp could go a long way towards building a working knowledge.
I really wish we could have books like Norvig's PAIP in the public domain - it is really one of the best books on lisp ever, however very expensive - more so in third world countries.
Oh and I really wish that brackets were used rather than parantheses - there is RSI you know!
It seems particularly telling to me that Norvig himself seems to have switched to Python for most work.
Christian Queinnec's _Lisp in Small Pieces_ is another absolutely brilliant book on Lisp, btw. It and PAIP are both about equally expensive, but both are well worth it IMHO. (FWIW, PAIP is probably of more interest to people with no intention of using Lisp.)
(Also: Remapping your keyboard helps, whether you do it in your editor or overall. And, I did not write the above just to say "IMHO FWIW PAIP". Honest. :) )
Christian Queinnec's _Lisp in Small Pieces_ is another absolutely brilliant book on Lisp, btw. It and PAIP are both about equally expensive, but both are well worth it IMHO. (FWIW, PAIP is probably of more interest to people with no intention of using Lisp.)
(Also: Remapping your keyboard helps, whether you do it in your editor or overall. And, I did not write the above just to say "IMHO FWIW PAIP". Honest. :) )
Before i learned scheme(I don't know CL), i didn't know how to write python. I knew how to write python syntax, but had no idea how to write code that doesn't suck. I still write bad code, but at least i know when its bad and i need to change it. Scheme thought me how to spot ugly code. I still use for and while loops(recursion is expensive in python, and you shouldn't write scheme in python) but i learned to write small and simple functions and combine them in smart ways(list comprehensions, maps, filters, decorators...). I guess i knew that from reading about the unix philosophy, but it took me to see it in code to understand it. So learning scheme might help you to be a better programmer, or it might screw you up and you end up writing stuff like this http://www.pick.ucam.org/~ptc24/yvfc.html
p.s. I've never written anything longer than a textbook exercise in scheme, so i don't know if you can actually write real stuff in this(or how hard it is) but playing with it is really fun, you should to it just for that.
p.s. I've never written anything longer than a textbook exercise in scheme, so i don't know if you can actually write real stuff in this(or how hard it is) but playing with it is really fun, you should to it just for that.
My suggestion for anyone wanting to make Lisp popular: make a Lisp analogue of Mark Pilgrim's "Dive Into Python". Or at least consider whether it is possible to write such a book for Lisp in its current state.
Isn't that Peter Seibel's "Practical Common Lisp"?
Pretty much. PCL is a great book that did much to bring the O'Reilly flavor to the community. Another good contribution is the Common Lisp Cookbook website, that contains snippets for common tasks.
Sadly, this doesn't seem to have struck the heart of the problem (although Lisp-in-a-box that came with PCL seems to have done it for some people).
Think about why Java is so widely used. I would argue that it's because of one thing: portable packages.
Sadly, this doesn't seem to have struck the heart of the problem (although Lisp-in-a-box that came with PCL seems to have done it for some people).
Think about why Java is so widely used. I would argue that it's because of one thing: portable packages.
The elisp tutorial that comes with Emacs is pretty well written - fluid style, usage of real language features.
Can someone explain the "it's only for AI" objection that people bring up? I have heard it from a few people first-hand and they couldn't say much else about it. Is it like "Macs are just good for graphics?"
Some people (apparently) assume Ruby is only for the web; they're confusing it and Rails.
Lisp was closely associated with AI a few decades ago.
Lisp was closely associated with AI a few decades ago.
I've been a Lisp hacker for years -- Symbolics Lisp Machine in my bedroom, coded in at least a half dozen different Lisp dialects -- but I ended up using Smalltalk for my startup. Treating Lisp's "rehabilitation" as a mere branding exercise shows just how screwed the Lisp community still is, and is symptomatic of the underlying issue. (By "Lisp", I mostly refer to Common Lisp.)
Lisp's problem is a meta-problem. The community is actively resistant to advancement, change, and evolution in the language. Attempts to modify (or even clarify) aspects of the Common Lisp standard are tedious exercises in futility, but the standardisation straitjacket is still seen as a good thing. A bit strangely, this resistance to change existing standards is accompanied by a slowness to standardise (even informally) anything that isn't already. The end result is that there's still no reliably portable way to write networking code in CL.
And this is why Lisp is unpopular.
The stasis is sad and ironic, given Lisp's hackerdom beginnings. Rather than wonder why, in 2009, so few are using Lisp, we should be amazed that the language is still pretty cool two decades after the innovation stopped.
I hope the Clojure guys change things. They seem to have the right approach.
Footnote: I was going to be a member of the CLRFI group (roughly equivalent to PEP or SRFI) that got some interest at ILC 2005, and which was going to try to create some sort of forward momentum in the community. It frizzled out, of course, and now http://clrfi.alu.org/ appears to redirect to the ALU homepage.