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.
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.
> However, I’m also with the author in that there are obvious social issues arising from the existence of many implementations.
There are issues with competing implementations, but I would say that's not totally bad(options are good) and over time, some equals become more equals than others. Python has numerous web frameworks, attributed to the fact that it's easy to define your own, but a newbie is more likely going to stick with Django.
As I said, people re-implementing things "just because" isn't unique to lisp and might not be as bad. Look at Flask - it was an April Fool's joke by Armin which is now a proper micro framework. It isn't like Django wasn't the dominant and recommended framework when Flask came into being. It's good to have options and progress depends on people fooling around.
Look at async scene. You have twisted and you have gevent and you have diesel. Templates? Jinja2, Mako, Django, Cheetah etc.
Python or Lisp, most of the people are going to make their choices and stick with it. It's not like everyone who programs lisp starts writing their own CLOS, and not everyone who programs Python tries to write his own framework regardless of how easy it is.
> For obvious reasons, that’s not the case with Lisp dialects despite their superficial similarities, but I think that catches many neophytes off guard.
I don't know. Doesn't most of the programmers program to a particular scheme or lisp implementation(sbcl, racket, clozure, gambit, clojure)?
> So even if such detrimental personality traits aren’t peculiar to Lispers, there is a strong apparent correlation because of the “fractured” community.
I think more than the "fractured" community, it depends on the out of the box experience. If I am programming Racket, I won't try to build an object system of my own - the one it provides is good. If I am programming Clojure, though it doesn't provide a conventional object system, I agree with the choices and won't try to implement my own.
> > For obvious reasons, that’s not the case with Lisp dialects despite their superficial similarities, but I think that catches many neophytes off guard.
> I don't know. Doesn't most of the programmers program to a particular scheme or lisp implementation(sbcl, racket, clozure, gambit, clojure)?
Common Lisp libraries seem to be getting much more portable across implementations, so within the CL dialect the language implementation is becoming less of an issue I think. And QuickLisp is one counter point to the OP -- it has broad community support.
With the full disclosure that I used to work for muvee Technologies (muvee.com), I'd like to point out that muvee Reveal's "styles" are authored in a scheme dialect. Yes, that's a commercial consumer level fun product featuring scheme.
Incremental exploratory development of the DSL for authoring these "editing styles" was made pretty easy using macros and if you ask me to reimagine it, it won't be easy for me to think of another easier route.
For those saying "macros aren't useful for day to day code", please consider the possibility that you wouldn't have to write much of that "day to day code" if you had macros in your toolkit.
Impromptu, (fluxus) and DrScheme itself are some cool dudes where the productivity per person on those teams appears disproportionately high compared to other projects.
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?
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
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.
> 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:
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.
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?
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.
> 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.
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.
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.
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.
I grabbed Clozure CL. Started it up, got a REPL. Wanted to know what I could do with it, so I went searching for help. The help is a silly, mostly empty window that starts with "Aren't you glad you waited so long to see this window ?" The first hyperlink in it is broken. The second (and only other) hyperlink takes me to something about OpenMCL, whose relationship to Clozure CL is a complete mystery to me.
Giving up on the help, I go back to the REPL and try some basic things. I quickly discover that this REPL window lacks essential features like pressing the up arrow to get the last thing you typed. And that was the point where I came back to my web browser and started writing this reply.
I realize these are small things to nitpick in the grand scheme of things, but it's such a horrible first impression compared to what I get from e.g. starting up Python for the first time.
This parallels my first exposure to scheme with guile, but in truth most repls suck more than they should. I can rant about pretty much all the ones I've ever used. With guile, I learned at some point that I had in fact built it with GNU readline support, and that I could activate it by putting in ~/.guile (analogous to $PYTHONSTARTUP):
Ahh, much better. Later interaction with Gambit Scheme was much nicer. Clisp was alright, more or less the same experience as Gambit. I hear DrRacket is nice but haven't tried it. Clojure uses jLine, so it's finicky. (I hate jLine.) Oh wait, I lied. You can use jLine, but it's not default:
alias clj='java -cp /home/kevin/clojure-1.3.0/jline-0.9.94.jar:/home/kevin/clojure-1.3.0/math.combinatorics.jar:/home/kevin/clojure-1.3.0/clojure.jar jline.ConsoleRunner clojure.main'
But I like that Clojure has built-in (doc) and (dir). I like Node's colors and it has decent tabcompletion. PyPy's REPL is probably the coolest out-of-the-box experience I've had--it reminded me of MySQL with how it helpfully gives you edit access to a whole chunk of code you wrote over multiple lines with one up-arrow. PyPy did it better, though. I've used emacs' Slime before, it was pretty sweet, but I'm a vim guy. (I'm aware of the various screen hacks to get a more or less the same experience.) I haven't messed with R in a while but I remember it offered to save the state for next time I launched.
I totally agree with you that first impressions matter. If command history and a sane consistent parsing of left/right/backspace/delete aren't features in your repl it's unusable, I can tolerate other deficiencies. It's especially annoying when REPLs are encouraged by the users of some language and they still stink. Python's (before I started using PyPy even!) is really the only one I've spent a lot of time in building a program, iteratively, albeit that's after disabling those annoying '>>> ' and '... ' prefixes so I can copy/paste-file/save/modify/paste-repl variations back and forth without pain. The rest of the repls I use mostly for isolated "will this work" style of questions since it's faster to check with the computer than simulate it myself in my head.
Regarding Clojure and JLine and the general niceness of REPLs, honestly I thinks it's a bit of a distraction. You don't need JLine at all, if you want to run a Clojure REPL in xterm or Terminal.app, just use rlwrap.
Most people who end up doing serious Clojure development move on to something more integrated, like SLIME for Emacs, slimv or the screen hacks you mentioned for vim, or Counterclockwise for Eclipse. I would much prefer the Clojure/core devs work on making Clojure awesome than re-inventing readline.
Anyway, once you've used the SLIME analogue for your language of choice, where you can select regions of code in your editor buffer for evaluation, copying and pasting to and from a REPL seems rather quaint.
I agree somewhat that first impressions are important, but I think that most programmers spend more time thinking than writing code, and that's especially true when you're first learning a language, and it's a big shift from that languages you know. I don't think that unfamiliarity with the tooling should be this big turn off, yet everyone makes it out to be one. When I started learning Clojure, my first impressions were based on the features of the language, and that's way more interesting than the fact that clj is a bit raw and rough around the edges.
Overall I agree with you. When I was a newbie programmer I was turned off by Python's forced indentation, and that cost my younger self about 6-8 months (when I looked at it again) of fun times that could have been had earlier. Now I'm capable of looking past the blemishes when trying something, but if it's a particularly grating blemish I'm going to spend less time looking at it by nature. (Thanks for the reminder about rlwrap, I was trying to remember what that command was called a few days ago. I hadn't considered using it instead of jLine as I've had bad experiences with it as well; a minute of playing around indicates it's at least as good. Which is sad for jLine. I wonder if `lein repl` uses jLine or rlwrap...)
I suspect I'll eventually outgrow my quaint process of copy/pasting here and there and embrace some variant of vim-slime. I agree most programmers spend more time thinking than writing code, but the two aren't so separate; what I like tremendously about repls in general is the ability to think with the aid of the computer, it speeds things along a lot. When the computer and I produce something worth keeping I save it. Of course I like my couch sessions (in lieu of a hammock) when they're needed.
It's easy to make it seem like a problem is bigger than it is. For all the ranting I can do about repls for various systems, it's not that big a deal in the grander scheme of things. (With repls specifically it's just an annoyance that readline behavior isn't default like it should be, not necessarily unfamiliarity with the ecosystem at large.) If the biggest criticism of Clojure is its crappy default repl, then one should think it must be a killer language if no other criticisms were mounted instead. (Personally I've only done a few applications with it but I'm already convinced it's fantastic even if I can think of some issues more important than the repl.)
OpenMCL was renamed to Clozure CL several years ago. It was called OpenMCL, because it originally was an open sourced version of MCL, Macintosh Common Lisp.
The Up-Arrow is for textual navigation in the Listener window. Like in a normal text editor window, which it is based on.
A typical way to use the history in Clozure CL is to move with the cursor keys to the input of interest and press RETURN to have it copied to the current prompt.
To get the last things you typed, press option-p. 'p' as in previous. As in Emacs, since Clozure CL has an Emacs-variant (derived from called Hemlock) at its core. But written in Common Lisp.
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) 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.
ASDF and Quicklisp are two different things. Quicklisp uses ASDF.
ASDF hasn't solved many problems. It was basically another system definition tool (with a different license). We had them before. What ASDF provided was that open source / free software used a common system definition.
Quicklisp OTOH provides a service. It uses ASDF. I provides library management and a collection of libraries.
The process over that to improve these libraries, make them better documented / more portable / rated / ... is something that happens over time.
Quicklisp does not solve all problems. It does not aim to. But it solves some.
I agree with you completely. QuickLisp does a damn fine job of solving some major problems. Honestly, looking through QuickLisp while writing up my post has made me consider moving from scheme back to CL for the first time in a long time.
My comment about asdf mostly comes from my experiences back in 2005 when I repeatedly heard that Common Lisp had NO problems and that asdf was so superior to CPAN or rubygems that there was no need to implement a new package system. In the same way, I often heard that we didn't have an issue with insufficient libraries, since UFFI (or was it CFFI?) has solved all of that. I wouldn't have been surprised if those same commentators would today declare that QuickLisp has solved everything.
However, those conversation that I had back in 2005 were not with you and I apologize for putting words in your mouth.
1.) You named one deficiency. You Googled it and although there were answers, you didn't like the answers that you received. Please enumerate the other deficiencies so I can laugh at how incredibly lame your perceived problems are.
2.) The docs for smtplib are longer than the code for cl-smtp. You'd get going quicker by reading the code and examples (tests) included in cl-smtp. Docs are wrong as soon as someone forgets to update them anyway.
---
We have had this discussion for much longer than four years. The problem is people whine about not having documentation, but refuse to put in the effort to go document libraries themselves. Same with serial ports.
How long does it take to write a few CFFI wrappers and put them on Github? If you want it so badly, do it yourself. Of course, you'd rather just use Python, which is fine, Python is fine... Norvig likes it too. You probably already know Python. Python is safe, Python is your friend. The reality is that you are justifying your perfectly reasonable desire to stay in your comfort zone with python by saying 'blah library doesn't exist'. Creating 'blah library' sounds like a perfectly reasonable place to start learning the language to me.
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.
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
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.
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.
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.
The standard image macro meme for newcomers to Lisp is this: 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.
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.
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.
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.
That dumping an image lets one quit the image dumped, that images are bound to certain versions of the runtime, etc. are inconvenient for users of images. It is a non-issue for creating an executable.
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.
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.
> 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.
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?
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.
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:
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.
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.
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.
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.
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.
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.
'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.
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.
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.
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.