Comment by lkesteloot
15 years ago
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.
> A good feature that leads to a bad situation is a bad feature.
Pretty much every technological advancement ever has made it easier for people to get themselves into bad situations (and some people have indeed gotten themselves into bad situations). Cars enable you to move very fast, which enables you to crash and die, and many people have done just that. Clearly, cars have "led" to car accidents, which are surely "bad situations". But would you recommend eliminating or crippling cars for this reason? I don't think so. The solution is for the people who use these tools to become mindful of these dangers, not to get rid of the tools.
... Perhaps you could find some way to make the tools safer without crippling them, and, sure, that would be nice. But what you said was that it was a "bad feature", implying that in the absence of any creative alternative ideas (to remake the feature so that the risks are mitigated while the functionality is retained), it should be thrown out. And in that case, my rebuttal stands.
1 reply →
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
I always loved that image. It's like a visual or "pointing" proof in mathematics.