5 ms·
Excellent article. My take is that what kills Lisp is a common allergy towards anything related to so-called release management. The Lisp technology helps with
by kunley 16y ago
Excellent article.
My take is that what kills Lisp is a common allergy towards anything related to so-called release management. The Lisp technology helps with it - it encourages staying within an image and putting all new stuff there. The problem is, it can and often does create an attitude "it works in my image and I don't care, you should know how to put it together by yourself or maybe you're not skilled enough". Well, it partly true. But the proponents of such elitist view tend to forget that today's software is so interdependent and relying on moving parts each of different quality, that actually we don't have the luxury of having "works for me" attitude. Even a genius can bang his head against stupid obstactes. It's not intelligent (and counter-hackish) to repeat the same mistakes again, or allow others to do that.
We as a civilisation invented cool things like semantic versioning, encapsulation, TDD & BDD. Please, Lispers, do follow this movement. Some people like creator od Quicklisp do a tremendous work in the area of release management, but are they a majority?
Sharing is part of creating. Making something shareable counts as well. Not being able to share makes people bitter, because we're social animals after all..
- raganwald 16y agoYou read that entire article and your takeaway is a theory about why Lisp isn't popular? I got something entirely, completely, and utterly unlike that. I read an article that was about the author's students, but I recognized the same thing in myself, in people who have devoted themselves to playing Bridge full time, and many other corners of society where extremely bright people hang out. The correlation between the personality and Lisp programming is very interesting, but I have to say that Lisp having a terrible "UI" for sharing--if true--doesn't strike me as being connected to the article. Maybe you could help me connect the dots between what the author is saying and what you are saying?
- shasta 16y ago"You read that entire article and your takeaway is a theory about why Lisp isn't popular?" He said 'take' (not 'takeaway'), which I would interpret to mean his viewpoint on Lisp that might be unrelated or even contrary to the article.
- raganwald 16y agoExcellent point, thank you. My misreading of that one word biased my interpretation of the comment!
- kunley 16y agoExactly. Please note I'm not speaking English natively and used phrase 'my take' according to my knowledge how to use it. My point was rather a digression comparing to the original article. In fact, I sympathize with the author and I put my 2cents what IMO causes the situation described.
- metageek 16y agoYou used it correctly.
- MaysonL 16y agoMuch of the article read like a description of my life, even though it's only in the past couple of years that I've gotten into Lisp.
- MaysonL 16y agoMuch of the article read like a description of my life, even though it's only in the past couple of years that I've gotten into Lisp.
- gruseom 16y agoThis seems really off-base to me. I don't think I've ever once heard a Lisper say "it works in my image". The consensus in a recent discussion on the pro-lisp group is that images are useful primarily for long-running servers, not for development. In any case, standard practice when putting out any CL code other than a snippet is to supply an .asd file with it. That seems to refute what you're saying. Can you supply concrete instances of this "it works in my image" attitude? It should be easy if it's as common as you say.
- EdiX 16y agoIn my experience packaging, TDD and images have nothing to do with the problems that Common Lisp had (has?). I tried to use Common Lisp for all my "home" projects between 2005 and 2006 and eventually gave up. My conclusion was that the problem of Common Lisp was a combination of: a) the standard is outdated, on one end it lacks many features that we now see as indispensable, due to not existing when the standard was ratified (unicode, networkings), not being commonly part of standard libraries at the time (modern packaging, regexps, C bindings) or simply were forgotten (parsing floating point numbers), on the other hand many features were specified in byzantine ways for compatiblity with systems that do not exist anymore (file system access, character encodings) b) there were 5 major implementations, 2 of which commercial with expensive licences. c) the community was small as much as that of any language that isn't C-like or PHP, Perl, Python or Ruby. None of this was a problem in itself but, in one sentence, the community was too small and fragmented to bridge the gap between an old standard and practicality. As a result even doing something as simple as a web scraper supposed to work on both OSX and Linux required major library juggling. This doesn't happen in other languages not because of some psychological attraction of biploar minds to lisp but because other languages often have either a single implementation or a lot of modern features in the standard library or both. Or they have enough users that something like boost eventually gains traction. I really hope quicklisp fixes this but it isn't simple.
- pnathan 16y agoI've also noticed a culture of doing the beautiful and elegant thing instead of duct taping a solution to get something working.
- zabuni 16y agoYes, but worse is better. http://www.jwz.org/doc/worse-is-better.html http://www.jwz.org/doc/worse-is-better.html The duct tape solution may only do 75% of the functionality, but it's there, and it's simplicity allows for hacks to be built on top of it.
- calibraxis 16y ago
- lispm 16y agoThis 'works for me' attitude is completely unrelated to Lisp. Ever worked in a Java team where some guy constantly checks in code which works for him? I've seen that. He still wanted to check in untested code.
- gruseom 16y agoHeh. A friend of mine contracted at a place where two programmers had a long-running feud. Each would check in code that wouldn't compile against the other's. One would comment out the other guy's incompatible code and check in his changes over top of it; then the other would simply uncomment his own code back in, comment out the first guy's stuff, and check in his latest work that way. They alternated this way for months.