8 ms·

The Lisp Curse

136 points by llambda 15y ago

ggchappell 15y ago
I find this very interesting. Really, there is a larger principle here: that in today's world, languages become popular, in part, by encouraging social connectedness, e.g., forums for solving problems, interoperability between different codebases, etc. The author's point, then, is that, perversely, one way to encourage social connectedness, is to be almost-but-not-quite powerful enough that one person can do everything alone. I find a couple of misconceptions, though. The most glaring is the lack of distinction between conceiving an idea, and implementing it. This is best exemplified by the following: > In a world where teams of talented academics were needed to write Haskell, one man, Dr. Tarver wrote Qi all by his lonesome. Teams of talented academics, building on the work of others going back decades, were required to design Haskell. Once that design was done, anyone could copy it. Sure, Tarver implemented Qi all by himself, and the fact that he could is significant. But let's not talk as if Qi is based entirely on ideas that he made up himself without considering the work of others.
- bgilroy26 15y ago
  > In a world where teams of talented academics were needed to write Haskell, one man, Dr. Tarver wrote Qi all by his lonesome. I think you're right about how the author is making an invalid comparison, but I think his point still stands. In order to make a good comparison, he would say the same things about Tarver and Qi, but he would have to say something along the lines of "Lisp has been extended in functional Haskell-y directions (Qi) and in object-y Smalltalk directions (CLOS). It would be very difficult to extend Haskell in as many dimensions as easily as it is to extend Lisp" Not that you necessarily want functional languages to have Smalltalk flavors, but I think it was wrong to compare Tarver with the academics like you say. The plus for Lisp is that it makes implementation of language features easier, you still have to come up with them just like everybody else.
praptak 15y ago
Clojure so far looks like a Lisp designed with at least some awareness of this curse. It has a strong "one obvious way to do it" flavour to me and I hope the devs will keep it this way.
- gtani 15y ago
  Every second or third serious Lisp hacker will roll his own implementation of lazy evaluation, functional purity, arrows, pattern matching, type inferencing, and the rest. Seems to describe clojure pretty well, tho I don't know about arrows, i haven't gotten that far into categ theory vs. real world implementations
  - asmala 15y ago
    I tend to disagree. Unified solutions exist on the level of the core language and libs for both lazy evaluation and (pragmatic) functional purity, and the recent discussion around logic programming and pattern dispatch implementation is a beautiful example of how some really smart people are working together towards a common solution, instead of everyone rolling their own.
lispm 15y ago
TL,DR: repeats old misconceptions. Task: go to the Apple Macintosh App Store. Download Clozure CL. Get Quicklisp. Get libraries. Start hacking. Connect via #lisp, reddit/lisp, the CLozure CL mailing list. Put your stuff on Github, make it available via Quicklisp. http://ccl.clozure.com/ http://ccl.clozure.com/ http://www.quicklisp.org/ http://www.quicklisp.org/ Have fun.
- rprospero 15y ago
  Just took a look at QuickLisp and that's a big improvement over the last time I looked at Common Lisp. On the other hand, there's a couple of points to make. 1) While quick lisp does have an amazing array of packages, there's still some simple, yet glaring deficiencies. For instance, there's no package to talk over a serial port. If I go to Google, the top link is a stack overflow post with some code on how to do that on Windows. The next few posts links are either people being told to use the FFI or raw writing to /dev/stty with the unix command line being used to set the tty parameters. Comparatively, the first link Google returns for python is for PySerial, which will handle all the serial port settings on its own. I was originally going to use this as an example of contrasting documentation, since I assumed that both languages would at least have a serial library. 2) If I want to send an e-mail, quicklisp offers cl-smtp and smtp4cl, while python mostly just offers smtplib. On the other hand, the documentation for smtplib (http://docs.python.org/library/smtplib.html http://docs.python.org/library/smtplib.html) is readily available, while cl-smtp is limited to the (admittedly clear) README file. --- I happen to love the lisp aesthetic (though I'll admit to preferring scheme over CL). Still, the main thrust of the article is that Lisp is cursed with a disorganized array of unsupported, poorly documented, incomplete solutions. QuickLisp has only solved the disorganized part of that. If there's a bug in smtplib, I can feel pretty secure that it will get fixed. Honestly, I bet I'd have the same luck with cl-smtp, but what about smtp4cl? I don't believe that it's a curse and I do think that it can be solved. However, this is a cultural problem in the lisp community and ignoring it. To put it differently, if we'd had this discussion four years ago, someone would have brought up asdf and said that that solved all the problems. However, we now have QuickLisp because asdf wasn't solving all the problems. It's great and things are better than they were, but we're not done yet.
siavosh 15y ago
I wonder though if this is an out of date concern because the last time Lisp was popular was before the proliferation of open source and tools like github. As a newbie Clojure programmer, I feel like I've already come across some very successful open source frameworks/libs (ex. Noir, Storm). I do get concerned though how PL fads seem to move in circles, and would love to learn more why Lisp is experiencing a renaissance. What's changed?
- lispm 15y ago
  Lisp had open source before you had it. The Lisp implementations were already shared during the 60s. They travelled by tape. The github of that time was the time-sharing system, where hundreds of users shared a computer and its storage: mainframes and large minicomputers. See ITS: http://en.wikipedia.org/wiki/Incompatible_Timesharing_System http://en.wikipedia.org/wiki/Incompatible_Timesharing_System The MIT in the 70s and 80s had LANs and file servers already. The networked Lisp Machines used common repositories. There weren't passwords. Different sites shared files via tapes and via the early ARPA net. Losing this when the MIT commercialized some of the technology inspired Richard Stallman to start the free software movement. Lisp and AI users collected and shared a lot of software. See for example this repository with software from the 80s and early 90s: http://www.cs.cmu.edu/afs/cs/project/ai-repository/ai/0.html http://www.cs.cmu.edu/afs/cs/project/ai-repository/ai/0.html Sharing was done via FTP servers. When Common Lisp was initially developed from 82-84, immediately open source implementations (with different licenses) were created: CMUCL, KCL, AKCL, WCL, CLISP, ... which can be traced to today's SBCL, ECL, CCL, ABCL and others.
- spacemanaki 15y ago
  I think a big part of it is the interest in functional languages in general. There was also something of a minor Lisp renaissance around the time that Practical Common Lisp (2005) and pg's "Revenge of the Nerds" (2002) was written. Now Clojure is fueling another bump in interest, including interest in CL and Scheme, as people coming to Lisp via Clojure are discovering some of the Lisp classics: PAIP, SICP, On Lisp, Lisp in Small Pieces, etc. This is all speculation on my part.
wpietri 15y ago
The linked article "The Bipolar Lisp Programmer" is brilliant: http://www.lambdassociates.org/blog/bipolar.htm http://www.lambdassociates.org/blog/bipolar.htm I don't know how correct it is about Lisp in specific, but he's definitely nailed a familiar type.
- lispm 15y ago
  Mr. Tarver failed to see that this is not specific to Lisp.
stcredzero 15y ago
Lisp is so powerful that problems which are technical issues in other programming languages are social issues in Lisp. Here's my take on it: Social issues will swamp the technical power of any language. Corollary: Virtuous cycles in the social dimension will augment the technical power of any language by an order of magnitude. The over-arching principle: A programming language community is as much a social artifact as it is a technical one. You have to get both sides right to succeed.
- mcguire 15y ago
  "Corollary: Virtuous cycles in the social dimension will augment the technical power of any language by an order of magnitude." To wit: Java, Go, C++,....
  - bane 15y ago
    It's interesting to note that most of the Java language design was specifically targeted at the social aspect of writing software.
    - lubutu 15y ago
      But only that of certain social circles. For example, it fails miserably (imho) as a "hacker's language". I suspect the social and technical aspects of a language are inextricably linked.
Tycho 15y ago
I find Lisp a bit unsettling because when you look at the code it's like you're looking at pure abstraction... there is a lack of semantic/symbolic content to latch on to and feel 'anchored.' Gives you the feeling that if you use Lisp, you'll have to be thinking hard the whole time you're using it.
- lispm 15y ago
  There is one part of Lisp which is not transported by looking at code. Lisp makes code data and allows code to transform other code. So what you see might either be the process of some transformation or it might be transformed before it is run. What you see is not necessarily what executes. Also the interactive process during development, its tools, its working with code is not easy to understand by 'looking' at code.
- gruseom 15y ago
  I'd be careful about drawing any conclusions from a first, second, or even tenth impression. That unsettling feeling may just be unfamiliarity. What you really want is a sense of what it would be like after you've developed a feel for it - admittedly something of a chicken-and-egg problem. What used to feel like "pure abstraction" to me now feels like lightweight (if dense) code whose shape is determined by the problem rather than by arbitrary constraints and noise.
  - Jach 15y ago
    The standard image macro meme for newcomers to Lisp is this: http://img264.imageshack.us/img264/1397/lispnd7.png http://img264.imageshack.us/img264/1397/lispnd7.png But I agree there's something more as you work with the language and start mastering macros, perhaps it's similar to the Tetris Effect, and the process takes you from frightful screams to delusions of grandeur back to solid practicality and programs that solve a problem. The process may take a while.
brownbat 15y ago
I really wish people would stop citing the Paradox of Choice. The studies are not reproducible, and meta-analysis reveals extra choices have basically zero impact on consumers. We've apparently somehow learned to cope, which is probably why a chain of supermarkets specializing in choice-free shopping has yet to take off. See Scheibehenne, B., Greifeneder, R. & Todd, P. M. (2010). Can There Ever be Too Many Options? A Meta-Analytic Review of Choice Overload. Journal of Consumer Research, 37, 409-425. You can download it here: http://www.scheibehenne.de/ScheibehenneGreifenederTodd2010.pdf http://www.scheibehenne.de/ScheibehenneGreifenederTodd2010.p...
- jwhite 15y ago
  Thanks for your comment and link, I'll read it tomorrow. As to choice-free supermarkets, isn't Aldi somewhere in the ball-park of choice-free shopping?
- jeffdavis 15y ago
  > I really wish people would stop citing the Paradox of Choice. Even if it were true, it's not as though there is no choice in other language communities. What python web framework should I use? I can choose among several well-documented, supported, maintained systems; and if I need an extra library for a specialized task, there's a packaging system to install it (and it's probably well-maintained and documented, as well). The times I've looked at lisp I just don't see that at all. Look here: http://stackoverflow.com/questions/540953/best-web-framework-in-common-lisp http://stackoverflow.com/questions/540953/best-web-framework... Those frameworks are all either dead or pre-production-quality. I'd like to like lisp, but I find that I'm a software engineer before a computer scientist. Things like a good extension mechanism, good documentation, a complete standard library, and a robust community matter more to me than a powerful macro system. Clojure and racket may be exceptions. I'll probably try one of those out.
jamesaguilar 15y ago
I tried to write a Lisp application once. Couldn't figure out how to make something standalone that could be run from bash. Most of the websites and discussions I looked at around the issue suggested that one would be wrong for even wanting such a thing. Eventually did my project in python.
- lispm 15y ago
  You could have read a manual (creating standalone applications is documented for each implementation) or asked other users. SBCL: http://www.sbcl.org/manual/#Generating-Executables http://www.sbcl.org/manual/#Generating-Executables CLISP http://www.clisp.org/impnotes.html#image http://www.clisp.org/impnotes.html#image and so on...
  - jamesaguilar 15y ago
    Yes, I was able to find the SBCL one, but as I recall at the time it interacted badly with the FFI (uffi? Something like that? I don't remember the name), and it wasn't clear how to combine it with a build system like make. I'm sure it can be done, but it was inordinately difficult compared to, say, python, where creating standalone scripts is essentially the very first thing in the tutorial.
    - KC8ZKF 15y ago
      I'm confused by what you mean as "standalone." Do you mean that you created object code that allowed users without Python installed to run your script? Because if not, getting Clisp or another CL to run a script from the command line is almost as trivial as with Python.
  - mcguire 15y ago
    SBCL: "This implementation is not as polished and painless as you might like: "It corrupts the current Lisp image enough that the current process needs to be killed afterwards. This can be worked around by forking another process that saves the core. "There is absolutely no binary compatibility of core images between different runtime support programs. Even runtimes built from the same sources at different times are treated as incompatible for this purpose. "This isn't because we like it this way, but just because there don't seem to be good quick fixes for either limitation and no one has been sufficiently motivated to do lengthy fixes." CLISP: "Memory images are not portable across different platforms (in contrast with platform-independent #P".fas" files). They are not even portable across linking sets: image saved using the full linking set cannot be used with the base runtime: $ clisp -K full -x '(EXT:SAVEINITMEM)' $ clisp -K base -M lispinit.mem base/lisp.run: initialization file `lispinit.mem' was not created by this version of CLISP runtime" These are the sorts of perennial problems common to image-based languages, specifically those that use "undump"-ish methods to create executables.
stephencanon 15y ago
I have a genuine fondness for lisp, but this article lost my interest pretty quickly with the thought experiment. "Adding object orientation to C" doesn't require "the programming chops of Bjarne Stroustrup"; you can write object-oriented code in unmodified C (indeed, there are people who do exactly that). Nor is C++ the only way to extend the language to add convenience to doing so. Objective-C, for example, takes a completely different and much simpler approach. C++ doesn't even satisfy the stated requirement of "keeping them backward-compatible with the original languages, modulo some edge cases", unless "some edge cases" means "large parts of the language" (semantics of storage class specifiers and type qualifiers, what is and isn't an lvalue, rules for implicit type conversion, ...) From a certain perspective, these are silly little details, but if you don't understand the silly little details of the other languages you write about, why should I listen to what you have to say about the virtues of lisp?
- deleted 15y ago
  [deleted]
- bgilroy26 15y ago
  On he other hand, I didn't really need the C/objects piece of technical evidence to support the "Lisp makes metaprogramming trivial in ways that other languages don't" argument. That one kind of stands on it's own, so I could move on to the rest of the article. The article wasn't about Lisp as much as it was about Not Invented Here syndrome. As others have said, the social and organizational issues become the major obstacle when your working with the greybeards and technical wizards that make the actual CS + CE questions a breeze
irahul 15y ago
Will it be too much to ask that the lispers build cool shit, and then brag about how lips made it easy? That would be more pleasant compared to this chest thumping. The traits associated with lispers(lone wolves, nih syndrome, not interested in boring tasks viz. documentation) aren't unique to lipsers. Most of the good programmers, regardless of their language choice, suffer from this mentality, and a lot of good stuff comes out of it. CLOS is cool - I get it. And extending the language by parse time code transformations is cool - I get that too. But does anyone seriously think that's the only thing that makes cool shit possible? There is a lot of great stuff out there which is written in languages which don't have macros, lot of stuff which was written by lone wolves, lot of stuff which existed but was re-written just because. When someone is orgasming to perceived benefits of lisp(not all of it is real), why does he have to make it look like "look lisp is so powerful, so powerful it's harmful"? Can't you just leave it at lisp is powerful and it helped me build this thing super fast. Why is this pathetic excuse of "it's so powerful it's harmful" necessary? And before you take out your pitch forks, please, you aren't the only one who programs lisp. I like Clojure, but mostly because of its nice seq abstractions, small core, interesting concurrency primitives, jvm. Macros are very low in my list of reasons to like Clojure. I tried liking Racket, and though I still like it, I would have preferred a higher level seq abstraction. I have skimmed through "Practical Common Lisp" and I fail to see the charm - there isn't anything which can't be conveniently and concisely coded in Ruby or Python. Lisp has its benefits, but they are overblown.
- evincarofautumn 15y ago
  I’d tend to agree. The powerful metaprogramming features of Lisp are often unnecessary in day-to-day code, and definitely overhyped. It’s poor form to use a macro when something simpler will do. They’re just another tool, and when you need them it’s great to have them, but do all projects demand the most powerful language features? Hardly. However, I’m also with the author in that there are obvious social issues arising from the existence of many implementations. If I write in C (or even C++) using standard libraries, then I can be reasonably assured that my code will compile anywhere. For obvious reasons, that’s not the case with Lisp dialects despite their superficial similarities, but I think that catches many neophytes off guard. So even if such detrimental personality traits aren’t peculiar to Lispers, there is a strong apparent correlation because of the “fractured” community. Still, I think that has less to do with the power of the language and more to do with its simplicity and lack of BDFL. Anybody can make their own Lisp, their own object system, and no one will object—no pun intended.
ChristianMarks 15y ago
Managers want employees to be fungible, so they hamper their employees. That points to a severe Principal-Agent problem. Why not ban programming altogether and make them parrot the venerable ITIL corpus? The post is stunningly ignorant. Alan Kay points out that actual programming practice represents a tiny fraction of what is known. The answer isn't for managers to create Principal-Agent problems by dumbing down their employees, but hiring knowledgeable managers who recognize the abyss that separates the state-of-the art from industrial practice. Startups emerge from this gap in understanding.
whackberry 15y ago
This is bullshit. People adopt languages because interesting things are made in them. The most interest I've found in lisp has been Emacs, because it's an awesome editor. If more Emacs-level projects in lisp were out there I bet lisp would be more popular. Otherwise, this is just political bravado with no concrete aplication.
- lispm 15y ago
  'interesting' is a somewhat vague concept. You need either 'interesting for a lot of people' and/or 'easy enough for an implementor who would create such a thing'. It is also important that a programming language and its implementation is used by people who develop new stuff. Currently no large company supports Lisp for that - not Apple (they did that in the 80s), not Google, not SAP, not ... Sometimes they buy technology which has traces of Lisp. Google bought ITA software - they are a Lisp shop. Apple bought Siri, Siri had traces of Lisp in - the original research project was done at SRI, which assembled modules written in many languages - among them Lisp. But that's it. When display-oriented text editors were developed, very early Lisp programmers implemented them in Lisp and even created engines which were portable for it (the Emacs C part which implements a simple Lisp runtime). When a CAD company needed an extension language, they added a simple Lisp dialect written in C to their CAD system. Born was Autolisp for AutoCAD - used in millions of installations. Today there are enough alternative languages around which can be easily embedded - for example Lua. Common Lisp is slightly more difficult to embed. One either uses ECL (Embeddable Common Lisp) or a home-grown Common Lisp variant. Which for example Quicksilver ( http://www.broadvision.com/en/quicksilver.php http://www.broadvision.com/en/quicksilver.php ) or PTC's CREO Elements ( http://www.ptc.com/product/creo-elements-direct http://www.ptc.com/product/creo-elements-direct ) do. You might never hear of the latter two - they are interesting applications - but not used by that many people. There are interesting and unique applications written in Common Lisp - but their user domain is very specialized. In music composition you could use OpenMusic, PWGL and several others. In cognitive modelling (used for example to test user interfaces) ACT-R is used. In proving correctness of software something like ACL2 or PVS might be used. But these are certainly not the interesting applications you have in mind, even though there were probably hundreds of interesting research projects done with something like ACT-R - but it is software for a narrow user group.
akkartik 15y ago
Previous discussion from a year ago: http://news.ycombinator.com/item?id=2450973 http://news.ycombinator.com/item?id=2450973
- winestock 15y ago
  I'm surprised. I wrote this essay a year ago and it's still getting attention. I've received occasional upvotes for that post since I submitted it but I have no idea why it made it to the front page again.
leon_ 15y ago
> On the other hand, adding object orientation to C requires the programming chops of Bjarne Stroustrup. I don't know but Objective C is a pretty simple extension to C.
wedesoft 15y ago
> Lisp is so powerful that problems which are technical issues in other programming languages are social issues in Lisp. I think this is a rather stupid argument. The same way you could argue that a boat is a better means of transportation than an airplane. With the boat agreeing on a holiday destination is less of a social issue because it is limited by technical constraints anyway.
Xion 15y ago
Consider the case of Scheme, again. Since making Scheme object-oriented is so easy, many Scheme hackers have done so. More to the point, many individual Scheme hackers have done so. In the 1990s, this led to a veritable warehouse inventory list of object-oriented packages for the language. It's funny that something quite similar can be said about today's arguably most popular and ubiquitous language: JavaScript. Each of MooTools, ExtJS, Prototype etc. sport their own model of OOP, with minor or even major differences. Yet it doesn't seem to be so big of an issue that it prevents cool stuff from being done in JS. For one, I don't think many people would claim that you need some implementation of OOP (i.e. classes, inheritance 'n stuff) to effectively program in JS. The readily available mechanisms are perfectly sufficient to just start coding what you want to code and doesn't require "amending" the language first. JavaScript code generally seem to be fine with that and happily proceed to create another batch of coolstuff.js. But according to the article, Lisp hackers have totally different mindset: they first "create a language" and only then proceed to use it to actually code stuff. (There is quote about giving man a Lisp...) If that's indeed true, I don't think it's really an issue of the Lisp itself, i.e. it's all-too-great power. After all you can just proceed into writing your program rather than writing a language first - like in JS. If Lisp coders fails to do that, I would say it's a problem of Lisp coders.
gouranga 15y ago
Ok to be honest I agree, but in a different way. The curse is when you have to go back from a Lisp variant to a crappy procedural language. It just makes you cry, even if it is really more productive than Lisp.

136 points by llambda 15y ago

I find this very interesting. Really, there is a larger principle here: that in today's world, languages become popular, in part, by encouraging social connectedness, e.g., forums for solving problems, interoperability between different codebases, etc. The author's point, then, is that, perversely, one way to encourage social connectedness, is to be almost-but-not-quite powerful enough that one person can do everything alone. I find a couple of misconceptions, though. The most glaring is the lack of distinction between conceiving an idea, and implementing it. This is best exemplified by the following: > In a world where teams of talented academics were needed to write Haskell, one man, Dr. Tarver wrote Qi all by his lonesome. Teams of talented academics, building on the work of others going back decades, were required to design Haskell. Once that design was done, anyone could copy it. Sure, Tarver implemented Qi all by himself, and the fact that he could is significant. But let's not talk as if Qi is based entirely on ideas that he made up himself without considering the work of others.

bgilroy26 15y ago
> In a world where teams of talented academics were needed to write Haskell, one man, Dr. Tarver wrote Qi all by his lonesome. I think you're right about how the author is making an invalid comparison, but I think his point still stands. In order to make a good comparison, he would say the same things about Tarver and Qi, but he would have to say something along the lines of "Lisp has been extended in functional Haskell-y directions (Qi) and in object-y Smalltalk directions (CLOS). It would be very difficult to extend Haskell in as many dimensions as easily as it is to extend Lisp" Not that you necessarily want functional languages to have Smalltalk flavors, but I think it was wrong to compare Tarver with the academics like you say. The plus for Lisp is that it makes implementation of language features easier, you still have to come up with them just like everybody else.

praptak 15y ago

Clojure so far looks like a Lisp designed with at least some awareness of this curse. It has a strong "one obvious way to do it" flavour to me and I hope the devs will keep it this way.

gtani 15y ago
Every second or third serious Lisp hacker will roll his own implementation of lazy evaluation, functional purity, arrows, pattern matching, type inferencing, and the rest. Seems to describe clojure pretty well, tho I don't know about arrows, i haven't gotten that far into categ theory vs. real world implementations
- asmala 15y ago
  I tend to disagree. Unified solutions exist on the level of the core language and libs for both lazy evaluation and (pragmatic) functional purity, and the recent discussion around logic programming and pattern dispatch implementation is a beautiful example of how some really smart people are working together towards a common solution, instead of everyone rolling their own.

lispm 15y ago

TL,DR: repeats old misconceptions. Task: go to the Apple Macintosh App Store. Download Clozure CL. Get Quicklisp. Get libraries. Start hacking. Connect via #lisp, reddit/lisp, the CLozure CL mailing list. Put your stuff on Github, make it available via Quicklisp. http://ccl.clozure.com/ http://ccl.clozure.com/ http://www.quicklisp.org/ http://www.quicklisp.org/ Have fun.

rprospero 15y ago
Just took a look at QuickLisp and that's a big improvement over the last time I looked at Common Lisp. On the other hand, there's a couple of points to make. 1) While quick lisp does have an amazing array of packages, there's still some simple, yet glaring deficiencies. For instance, there's no package to talk over a serial port. If I go to Google, the top link is a stack overflow post with some code on how to do that on Windows. The next few posts links are either people being told to use the FFI or raw writing to /dev/stty with the unix command line being used to set the tty parameters. Comparatively, the first link Google returns for python is for PySerial, which will handle all the serial port settings on its own. I was originally going to use this as an example of contrasting documentation, since I assumed that both languages would at least have a serial library. 2) If I want to send an e-mail, quicklisp offers cl-smtp and smtp4cl, while python mostly just offers smtplib. On the other hand, the documentation for smtplib (http://docs.python.org/library/smtplib.html http://docs.python.org/library/smtplib.html) is readily available, while cl-smtp is limited to the (admittedly clear) README file. --- I happen to love the lisp aesthetic (though I'll admit to preferring scheme over CL). Still, the main thrust of the article is that Lisp is cursed with a disorganized array of unsupported, poorly documented, incomplete solutions. QuickLisp has only solved the disorganized part of that. If there's a bug in smtplib, I can feel pretty secure that it will get fixed. Honestly, I bet I'd have the same luck with cl-smtp, but what about smtp4cl? I don't believe that it's a curse and I do think that it can be solved. However, this is a cultural problem in the lisp community and ignoring it. To put it differently, if we'd had this discussion four years ago, someone would have brought up asdf and said that that solved all the problems. However, we now have QuickLisp because asdf wasn't solving all the problems. It's great and things are better than they were, but we're not done yet.

siavosh 15y ago

I wonder though if this is an out of date concern because the last time Lisp was popular was before the proliferation of open source and tools like github. As a newbie Clojure programmer, I feel like I've already come across some very successful open source frameworks/libs (ex. Noir, Storm). I do get concerned though how PL fads seem to move in circles, and would love to learn more why Lisp is experiencing a renaissance. What's changed?

lispm 15y ago
Lisp had open source before you had it. The Lisp implementations were already shared during the 60s. They travelled by tape. The github of that time was the time-sharing system, where hundreds of users shared a computer and its storage: mainframes and large minicomputers. See ITS: http://en.wikipedia.org/wiki/Incompatible_Timesharing_System http://en.wikipedia.org/wiki/Incompatible_Timesharing_System The MIT in the 70s and 80s had LANs and file servers already. The networked Lisp Machines used common repositories. There weren't passwords. Different sites shared files via tapes and via the early ARPA net. Losing this when the MIT commercialized some of the technology inspired Richard Stallman to start the free software movement. Lisp and AI users collected and shared a lot of software. See for example this repository with software from the 80s and early 90s: http://www.cs.cmu.edu/afs/cs/project/ai-repository/ai/0.html http://www.cs.cmu.edu/afs/cs/project/ai-repository/ai/0.html Sharing was done via FTP servers. When Common Lisp was initially developed from 82-84, immediately open source implementations (with different licenses) were created: CMUCL, KCL, AKCL, WCL, CLISP, ... which can be traced to today's SBCL, ECL, CCL, ABCL and others.
spacemanaki 15y ago
I think a big part of it is the interest in functional languages in general. There was also something of a minor Lisp renaissance around the time that Practical Common Lisp (2005) and pg's "Revenge of the Nerds" (2002) was written. Now Clojure is fueling another bump in interest, including interest in CL and Scheme, as people coming to Lisp via Clojure are discovering some of the Lisp classics: PAIP, SICP, On Lisp, Lisp in Small Pieces, etc. This is all speculation on my part.

wpietri 15y ago

The linked article "The Bipolar Lisp Programmer" is brilliant: http://www.lambdassociates.org/blog/bipolar.htm http://www.lambdassociates.org/blog/bipolar.htm I don't know how correct it is about Lisp in specific, but he's definitely nailed a familiar type.

lispm 15y ago
Mr. Tarver failed to see that this is not specific to Lisp.

stcredzero 15y ago

Lisp is so powerful that problems which are technical issues in other programming languages are social issues in Lisp. Here's my take on it: Social issues will swamp the technical power of any language. Corollary: Virtuous cycles in the social dimension will augment the technical power of any language by an order of magnitude. The over-arching principle: A programming language community is as much a social artifact as it is a technical one. You have to get both sides right to succeed.

mcguire 15y ago
"Corollary: Virtuous cycles in the social dimension will augment the technical power of any language by an order of magnitude." To wit: Java, Go, C++,....
- bane 15y ago
  It's interesting to note that most of the Java language design was specifically targeted at the social aspect of writing software.
  - lubutu 15y ago
    But only that of certain social circles. For example, it fails miserably (imho) as a "hacker's language". I suspect the social and technical aspects of a language are inextricably linked.

Tycho 15y ago

I find Lisp a bit unsettling because when you look at the code it's like you're looking at pure abstraction... there is a lack of semantic/symbolic content to latch on to and feel 'anchored.' Gives you the feeling that if you use Lisp, you'll have to be thinking hard the whole time you're using it.

lispm 15y ago
There is one part of Lisp which is not transported by looking at code. Lisp makes code data and allows code to transform other code. So what you see might either be the process of some transformation or it might be transformed before it is run. What you see is not necessarily what executes. Also the interactive process during development, its tools, its working with code is not easy to understand by 'looking' at code.
gruseom 15y ago
I'd be careful about drawing any conclusions from a first, second, or even tenth impression. That unsettling feeling may just be unfamiliarity. What you really want is a sense of what it would be like after you've developed a feel for it - admittedly something of a chicken-and-egg problem. What used to feel like "pure abstraction" to me now feels like lightweight (if dense) code whose shape is determined by the problem rather than by arbitrary constraints and noise.
- Jach 15y ago
  The standard image macro meme for newcomers to Lisp is this: http://img264.imageshack.us/img264/1397/lispnd7.png http://img264.imageshack.us/img264/1397/lispnd7.png But I agree there's something more as you work with the language and start mastering macros, perhaps it's similar to the Tetris Effect, and the process takes you from frightful screams to delusions of grandeur back to solid practicality and programs that solve a problem. The process may take a while.

brownbat 15y ago

I really wish people would stop citing the Paradox of Choice. The studies are not reproducible, and meta-analysis reveals extra choices have basically zero impact on consumers. We've apparently somehow learned to cope, which is probably why a chain of supermarkets specializing in choice-free shopping has yet to take off. See Scheibehenne, B., Greifeneder, R. & Todd, P. M. (2010). Can There Ever be Too Many Options? A Meta-Analytic Review of Choice Overload. Journal of Consumer Research, 37, 409-425. You can download it here: http://www.scheibehenne.de/ScheibehenneGreifenederTodd2010.pdf http://www.scheibehenne.de/ScheibehenneGreifenederTodd2010.p...

jwhite 15y ago
Thanks for your comment and link, I'll read it tomorrow. As to choice-free supermarkets, isn't Aldi somewhere in the ball-park of choice-free shopping?
jeffdavis 15y ago
> I really wish people would stop citing the Paradox of Choice. Even if it were true, it's not as though there is no choice in other language communities. What python web framework should I use? I can choose among several well-documented, supported, maintained systems; and if I need an extra library for a specialized task, there's a packaging system to install it (and it's probably well-maintained and documented, as well). The times I've looked at lisp I just don't see that at all. Look here: http://stackoverflow.com/questions/540953/best-web-framework-in-common-lisp http://stackoverflow.com/questions/540953/best-web-framework... Those frameworks are all either dead or pre-production-quality. I'd like to like lisp, but I find that I'm a software engineer before a computer scientist. Things like a good extension mechanism, good documentation, a complete standard library, and a robust community matter more to me than a powerful macro system. Clojure and racket may be exceptions. I'll probably try one of those out.

jamesaguilar 15y ago

I tried to write a Lisp application once. Couldn't figure out how to make something standalone that could be run from bash. Most of the websites and discussions I looked at around the issue suggested that one would be wrong for even wanting such a thing. Eventually did my project in python.

lispm 15y ago
You could have read a manual (creating standalone applications is documented for each implementation) or asked other users. SBCL: http://www.sbcl.org/manual/#Generating-Executables http://www.sbcl.org/manual/#Generating-Executables CLISP http://www.clisp.org/impnotes.html#image http://www.clisp.org/impnotes.html#image and so on...
- jamesaguilar 15y ago
  Yes, I was able to find the SBCL one, but as I recall at the time it interacted badly with the FFI (uffi? Something like that? I don't remember the name), and it wasn't clear how to combine it with a build system like make. I'm sure it can be done, but it was inordinately difficult compared to, say, python, where creating standalone scripts is essentially the very first thing in the tutorial.
  - KC8ZKF 15y ago
    I'm confused by what you mean as "standalone." Do you mean that you created object code that allowed users without Python installed to run your script? Because if not, getting Clisp or another CL to run a script from the command line is almost as trivial as with Python.
- mcguire 15y ago
  SBCL: "This implementation is not as polished and painless as you might like: "It corrupts the current Lisp image enough that the current process needs to be killed afterwards. This can be worked around by forking another process that saves the core. "There is absolutely no binary compatibility of core images between different runtime support programs. Even runtimes built from the same sources at different times are treated as incompatible for this purpose. "This isn't because we like it this way, but just because there don't seem to be good quick fixes for either limitation and no one has been sufficiently motivated to do lengthy fixes." CLISP: "Memory images are not portable across different platforms (in contrast with platform-independent #P".fas" files). They are not even portable across linking sets: image saved using the full linking set cannot be used with the base runtime: $ clisp -K full -x '(EXT:SAVEINITMEM)' $ clisp -K base -M lispinit.mem base/lisp.run: initialization file `lispinit.mem' was not created by this version of CLISP runtime" These are the sorts of perennial problems common to image-based languages, specifically those that use "undump"-ish methods to create executables.

stephencanon 15y ago

I have a genuine fondness for lisp, but this article lost my interest pretty quickly with the thought experiment. "Adding object orientation to C" doesn't require "the programming chops of Bjarne Stroustrup"; you can write object-oriented code in unmodified C (indeed, there are people who do exactly that). Nor is C++ the only way to extend the language to add convenience to doing so. Objective-C, for example, takes a completely different and much simpler approach. C++ doesn't even satisfy the stated requirement of "keeping them backward-compatible with the original languages, modulo some edge cases", unless "some edge cases" means "large parts of the language" (semantics of storage class specifiers and type qualifiers, what is and isn't an lvalue, rules for implicit type conversion, ...) From a certain perspective, these are silly little details, but if you don't understand the silly little details of the other languages you write about, why should I listen to what you have to say about the virtues of lisp?

deleted 15y ago
[deleted]
bgilroy26 15y ago
On he other hand, I didn't really need the C/objects piece of technical evidence to support the "Lisp makes metaprogramming trivial in ways that other languages don't" argument. That one kind of stands on it's own, so I could move on to the rest of the article. The article wasn't about Lisp as much as it was about Not Invented Here syndrome. As others have said, the social and organizational issues become the major obstacle when your working with the greybeards and technical wizards that make the actual CS + CE questions a breeze

irahul 15y ago

Will it be too much to ask that the lispers build cool shit, and then brag about how lips made it easy? That would be more pleasant compared to this chest thumping. The traits associated with lispers(lone wolves, nih syndrome, not interested in boring tasks viz. documentation) aren't unique to lipsers. Most of the good programmers, regardless of their language choice, suffer from this mentality, and a lot of good stuff comes out of it. CLOS is cool - I get it. And extending the language by parse time code transformations is cool - I get that too. But does anyone seriously think that's the only thing that makes cool shit possible? There is a lot of great stuff out there which is written in languages which don't have macros, lot of stuff which was written by lone wolves, lot of stuff which existed but was re-written just because. When someone is orgasming to perceived benefits of lisp(not all of it is real), why does he have to make it look like "look lisp is so powerful, so powerful it's harmful"? Can't you just leave it at lisp is powerful and it helped me build this thing super fast. Why is this pathetic excuse of "it's so powerful it's harmful" necessary? And before you take out your pitch forks, please, you aren't the only one who programs lisp. I like Clojure, but mostly because of its nice seq abstractions, small core, interesting concurrency primitives, jvm. Macros are very low in my list of reasons to like Clojure. I tried liking Racket, and though I still like it, I would have preferred a higher level seq abstraction. I have skimmed through "Practical Common Lisp" and I fail to see the charm - there isn't anything which can't be conveniently and concisely coded in Ruby or Python. Lisp has its benefits, but they are overblown.

evincarofautumn 15y ago
I’d tend to agree. The powerful metaprogramming features of Lisp are often unnecessary in day-to-day code, and definitely overhyped. It’s poor form to use a macro when something simpler will do. They’re just another tool, and when you need them it’s great to have them, but do all projects demand the most powerful language features? Hardly. However, I’m also with the author in that there are obvious social issues arising from the existence of many implementations. If I write in C (or even C++) using standard libraries, then I can be reasonably assured that my code will compile anywhere. For obvious reasons, that’s not the case with Lisp dialects despite their superficial similarities, but I think that catches many neophytes off guard. So even if such detrimental personality traits aren’t peculiar to Lispers, there is a strong apparent correlation because of the “fractured” community. Still, I think that has less to do with the power of the language and more to do with its simplicity and lack of BDFL. Anybody can make their own Lisp, their own object system, and no one will object—no pun intended.

ChristianMarks 15y ago

Managers want employees to be fungible, so they hamper their employees. That points to a severe Principal-Agent problem. Why not ban programming altogether and make them parrot the venerable ITIL corpus? The post is stunningly ignorant. Alan Kay points out that actual programming practice represents a tiny fraction of what is known. The answer isn't for managers to create Principal-Agent problems by dumbing down their employees, but hiring knowledgeable managers who recognize the abyss that separates the state-of-the art from industrial practice. Startups emerge from this gap in understanding.

whackberry 15y ago

This is bullshit. People adopt languages because interesting things are made in them. The most interest I've found in lisp has been Emacs, because it's an awesome editor. If more Emacs-level projects in lisp were out there I bet lisp would be more popular. Otherwise, this is just political bravado with no concrete aplication.

lispm 15y ago
'interesting' is a somewhat vague concept. You need either 'interesting for a lot of people' and/or 'easy enough for an implementor who would create such a thing'. It is also important that a programming language and its implementation is used by people who develop new stuff. Currently no large company supports Lisp for that - not Apple (they did that in the 80s), not Google, not SAP, not ... Sometimes they buy technology which has traces of Lisp. Google bought ITA software - they are a Lisp shop. Apple bought Siri, Siri had traces of Lisp in - the original research project was done at SRI, which assembled modules written in many languages - among them Lisp. But that's it. When display-oriented text editors were developed, very early Lisp programmers implemented them in Lisp and even created engines which were portable for it (the Emacs C part which implements a simple Lisp runtime). When a CAD company needed an extension language, they added a simple Lisp dialect written in C to their CAD system. Born was Autolisp for AutoCAD - used in millions of installations. Today there are enough alternative languages around which can be easily embedded - for example Lua. Common Lisp is slightly more difficult to embed. One either uses ECL (Embeddable Common Lisp) or a home-grown Common Lisp variant. Which for example Quicksilver ( http://www.broadvision.com/en/quicksilver.php http://www.broadvision.com/en/quicksilver.php ) or PTC's CREO Elements ( http://www.ptc.com/product/creo-elements-direct http://www.ptc.com/product/creo-elements-direct ) do. You might never hear of the latter two - they are interesting applications - but not used by that many people. There are interesting and unique applications written in Common Lisp - but their user domain is very specialized. In music composition you could use OpenMusic, PWGL and several others. In cognitive modelling (used for example to test user interfaces) ACT-R is used. In proving correctness of software something like ACL2 or PVS might be used. But these are certainly not the interesting applications you have in mind, even though there were probably hundreds of interesting research projects done with something like ACT-R - but it is software for a narrow user group.

akkartik 15y ago

Previous discussion from a year ago: http://news.ycombinator.com/item?id=2450973 http://news.ycombinator.com/item?id=2450973

winestock 15y ago
I'm surprised. I wrote this essay a year ago and it's still getting attention. I've received occasional upvotes for that post since I submitted it but I have no idea why it made it to the front page again.

leon_ 15y ago

> On the other hand, adding object orientation to C requires the programming chops of Bjarne Stroustrup. I don't know but Objective C is a pretty simple extension to C.

wedesoft 15y ago

> Lisp is so powerful that problems which are technical issues in other programming languages are social issues in Lisp. I think this is a rather stupid argument. The same way you could argue that a boat is a better means of transportation than an airplane. With the boat agreeing on a holiday destination is less of a social issue because it is limited by technical constraints anyway.

Xion 15y ago

Consider the case of Scheme, again. Since making Scheme object-oriented is so easy, many Scheme hackers have done so. More to the point, many individual Scheme hackers have done so. In the 1990s, this led to a veritable warehouse inventory list of object-oriented packages for the language. It's funny that something quite similar can be said about today's arguably most popular and ubiquitous language: JavaScript. Each of MooTools, ExtJS, Prototype etc. sport their own model of OOP, with minor or even major differences. Yet it doesn't seem to be so big of an issue that it prevents cool stuff from being done in JS. For one, I don't think many people would claim that you need some implementation of OOP (i.e. classes, inheritance 'n stuff) to effectively program in JS. The readily available mechanisms are perfectly sufficient to just start coding what you want to code and doesn't require "amending" the language first. JavaScript code generally seem to be fine with that and happily proceed to create another batch of coolstuff.js. But according to the article, Lisp hackers have totally different mindset: they first "create a language" and only then proceed to use it to actually code stuff. (There is quote about giving man a Lisp...) If that's indeed true, I don't think it's really an issue of the Lisp itself, i.e. it's all-too-great power. After all you can just proceed into writing your program rather than writing a language first - like in JS. If Lisp coders fails to do that, I would say it's a problem of Lisp coders.

gouranga 15y ago

Ok to be honest I agree, but in a different way. The curse is when you have to go back from a Lisp variant to a crappy procedural language. It just makes you cry, even if it is really more productive than Lisp.