Comment by winestock
15 years ago
"I'm experiencing a fatigue from reading articles/books/posts about great powers of Lisp and why Lisp is where it is today."
So am I. I wrote the essay because this idea has been banging in my head for some time and I had to let it out. The urgency shows in places. Elsewhere in this thread, others are pointing out that I don't know that much C. Guilty.
Another commenter's suspicion about the "we lost because we're so awesome" theme also has merit. I suppose that Lisp must have some intrinsic problems, but reading about the Lisp Machine period makes the language so enchanting.
I've always suspected that Lisp is write-only. For example, it fails the squint test, which I wrote about here: http://www.teamten.com/lawrence/writings/the_language_squint...
Being write-only would explain why there are so few collaborative Lisp projects.
And I don't particularly buy the thesis of this essay that there are few collaborative Lisp projects because it's possible to do anything with a single person. You can always find sufficiently difficult problems that would require a team. Projects in Lisp should be putting projects in other languages to shame. I think there's something about Lisp that makes collaboration too difficult, and I suspect it's the expressiveness itself.
The squint test only passes for one and fails for the other because of your familiarity with the Algol-style language.
I immediately recognized a defun or defmacro in the second, and didn't know wtf was going on in the first. It is a (def-something name (arguments ) &body).
(Also, properly placing curly braces inflames my OCD. It seems like a lot of wasted white space, so I end up stacking them, and then they are impossible to match. So I unstack them, but then everything is all spread out and I don't like that at all.)
So, my point is personal preference and experience there...
Aside from that, there are idiomatic patterns for macros (i.e. let-binding-forms, with-x, def-something, etc.) that you learn and generally stick to.
Then again, I like to read, I am reasonably good at reading, and probably read faster than most.
I dunno, I don't really buy your squint test for languages. While it makes some sense for graphical user interfaces, (most) source code isn't graphical, it's textual, and you wouldn't apply the squint test to the arbitrary written word, would you? Where every page of every book looks the same...
It's true that I wouldn't apply it to prose, but that doesn't mean it's not useful for code, where you often want to look at lots of it and get a gist of what it's doing. Also I often do think of a programming language as a user interface, even if it's not actually made of buttons and icons.
I'm not claiming this is the main problem with Lisp; only that it's one of them.
Excluding books like novels which are written to be read from beginning to end, the easiest to skim-read books have chapter and section divisions, each with intro and concluding paragraphs. They have pictures, charts, and diagrams; they have margin notes summarizing each paragraph; they have color. Each paragraph has a topic sentence, either first or last. The book begins with contents on a single page, then a detailed contents. The written word's come a long way since scrolls were the writing medium.
I'd say the squint test does apply to the written word.
"I think there's something about Lisp that makes collaboration too difficult, and I suspect it's the expressiveness itself."
That goes back to the point of the essay. The expressiveness of Lisp encourages, among other things, the creation of a "little language" for each project. This makes collaboration more difficult. Ergo, it's a social issue rather than a technical issue.
Okay, I see what you mean by that now. I might still quibble that calling it a "social issue" (as opposed to technical) makes it sound like it's not Lisp's fault. A good feature that leads to a bad situation is a bad feature. I want to call out macros for what they are: a feature that contributes to Lisp not being used.
Thinking about it more, I might describe macros as "anti-social" in that they help the programmer but hurt the team. This might be what you meant.
Note that I'm not saying that the idea of macros is bad; only that Lisp's decision to make them look like function calls is bad. I once saw a macro system for Lua that made their invocation look clearly different than normal language.
2 replies →
You've got your squint test backwards. What you should do is leave the letters stand and replace all parentheses and punctuation characters by blanks. What remains is pretty much the semantics-carrying part of the code.
This is what I do when I show people Lispy (pseudo)code in presentations and it works fine. The people who like Algol-style syntax imagine the curly brackets are there and the Lispers imagine they see parentheses.
Good illustration:
http://img264.imageshack.us/img264/1397/lispnd7.png
1 reply →