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.
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.
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.
> 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.
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.
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?
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
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:
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.
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.
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.
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.
To wit: Java, Go, C++,....
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.
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.
(use-modules (ice-9 readline))
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'
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.
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.
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.)
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.
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 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.
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.
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.
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.
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.
and so on...
"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
These are the sorts of perennial problems common to image-based languages, specifically those that use "undump"-ish methods to create executables.
I don't know how correct it is about Lisp in specific, but he's definitely nailed a familiar type.
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 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?
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:
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.
This is all speculation on my part.
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.
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 ) or PTC's CREO Elements ( 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.