Comment by TY
15 years ago
Most of the essay can summarized by this quote from it:
Lisp is so powerful that problems which are
technical issues in other programming languages
are social issues in Lisp.
While this is not a bad essay I'm experiencing a fatigue from reading articles/books/posts about great powers of Lisp and why Lisp is where it is today.
Instead, I'd love to see that mental energy spent on advocacy/defence/adulation/hatred of various Lisp dialects on actually writing great software.
Let's stop looking at Lisp as a religion and instead use it as a great tool to create beautiful things.
Disclaimer: I've used CL, Scheme and Clojure on my various (mostly personal) projects. For the current one, I use Python as it fits better for what I'm doing today. My next project will use whatever it needs to work.
"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...
2 replies →
"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.
3 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.
2 replies →
There's also the tendency among lispers to shoot for the right solution, instead of the working one. I've encountered that a few times in #lisp.
When I write Lisp, I am trying to Get Stuff Done. The Right Way matters, but not until it matters (Everything is fast when n < 10).
So I'd rather advocate by - in due time - rolling out working projects for people to use, pointing, and saying, "Look, this is useful software in Lisp".
c.f., Worse is Better, Worse is Worse, and Worse is Still Better, by rpg.
...so long as we balance the long term cost in future maintenance/extension work against the short term gain.
> so long as we balance the long term cost in future maintenance/extension work against the short term gain.
There is no "long term" unless the short term system survives.
Anything that ships is better than the best thing that didn't ship.
1 reply →