Lisp is Poetry and Most Programmers Want Prose (2006)
blogs.adventnet.com
blogs.adventnet.com
Don't get me wrong, you can get to be a damn good Blub programmer. You can also work at an international company, headquartered in US, without being skilled enough at English to appreciate Shakespeare's work; or, for that matter, loathe it, since you need the same level of proficiency.
I do believe that you'll never get to enjoy English to the fullest, if you don't explore its poetic reaches. In words of Wilhelm von Humboldt:
The diversity of languages is not a diversity of signs and sounds but a diversity of views of the world.
I believe that the same applies to programming languages. Yes, you can be really good with just Java. But just by learning C# on the side, you can gain valuable insights without stepping too far from your comfort zone. Learning Lisp, Self, Python and Factor, to name a few, will give you whole new worldviews, make you think differently. You don't really need that stuff to make software (or money). But it can make you a hell of a lot better at it and, more importantly, it can make you enjoy it more.
- ruby or python (GTD lang's)
- java, C and derivatives
- concurrent/FP: ocaml, clojure, scala, haskell, clean, erlang, F#
- lisp/scheme, dylan
- smalltalk, factor, Ioke, forth,
Fortunately, you can spend all weekend reading about languages:
- hacker news; reddit; infoq.com; artima.com; theServerside.com and .net; Lambda the Ultimate
This is an unexpected grouping; the design philosophies of Factor and Forth seem quite different from those of Smalltalk, which in turn I think is only one of the points of inspiration for Ioke. Is there some deeper similarity that you're pointing out here?
WOW! I haven't heard that quote before. It quite aptly sums up the situation.
It's hard for me to disentangle pg's "blub" epithet from the fact that he's an investor who benefits from having a technical audience overly concerned with artistic merit and underly concerned with economic benefit.
If that was true, the OP would have shown better understanding of the difference between "poetry" and "prose". Plinkplonk posted a pretty good analysis of false dichotomies and misinterpretations present in the OP's essay, so I won't repeat all that.
There is one point, however, that I would especially highlight here. The OP first claimed that when he has to look at the code, "the more obvious the code the better". Yet he claims further down that "the vast majority of the world’s programmers, want an 'easy' language, not a highly expressive, poetic language". That's where the OP's lack of understanding of what he calls "poetic languages" is made evident. The benefit of a highly expressive language is that you can make your code more obvious.
As it is, the essay basically reads as "Yes, we Blub programmers like Blub precisely because it's in our comfort zone and that's good enough and we don't care for the rest."
It's hard for me to disentangle pg's "blub" epithet from the fact that he's an investor who benefits from having a technical audience overly concerned with artistic merit and underly concerned with economic benefit.
I confess that I don't understand your logic. How does Paul Graham "benefit" from "having a technical audience overly concerned with artistic merit and underly concerned with economic benefit"? I would expect the opposite, that an investor would benefit from having an audience that always keeps both its eyes on the economic bottom line. I would give your statement a benefit of a doubt if he was a CEO of a company that markets some fancy, new Lisp platform as "The Next Big Thing".
There's a time for poetry and a time for prose: I'm merely saying that neither side should be throwing epithets.
pg extracts shareholder value by managing the artistic/economic gap. I am not being critical: this is a perfectly valid thing to do with one's time, I'd take his job in a heartbeat =o)
However, I'd wager that if you added up salaries forgone by ycombinator participants and compared them against aggregate payout it would paint a fairly bleak economic picture.
I'd take that wager at a 100:1 payout in a heartbeat!
My guess is that it takes 5-7 years for payouts to start happening from startups, so allowing for that much time, I have no doubt that the total payout will be much greater than would be from regular salaries. All you need are a few to hit it out of the park, and you've covered everyone.
Of course, we're talking about aggregates here; I could certainly imagine that for some fraction of the participants, it might be a net lose monetarily.
Their most successful sale is still Reddit, yes? Assuming moderate dilution, I imagine payout per founder in the $1mm-$2mm range. Assuming the average ycombinator is capable of securing a 6-figure job, their greatest success only accounts for 2 years living wages of 10 failures.
Forget the multi-million dollar company valuations: almost everyone on this board would have a multi-million dollar valuation if they were willing (or legally able) to sell ownership over all their future cash flows.
Please note I have the greatest respect for entrepreneurs and what they do, I'm just making the point that what they do is not economically motivated in general. I'm also not making a comment on whether ycombinator itself does well - their investments are much smaller than forgone wages.
I completely agree with your point about the expressiveness of poetry. Yes, there is some high initial investment in understanding poetry (in spoken language or programming language). And in return, you get a higher level of expressiveness. People look at the high level of investment, and say that the poetry isn't worth it, because they mistakenly think that it will require that level of investment every time. But like any language construct, once you really learn it, it becomes natural to you and doesn't require that high investment each time.
I wrote a Turing machine generator in arc once. To me, that was the prime example of the power and pitfalls of poetic language. At the time, I was practicing lisp like languages a lot, so it just flowed out off me. It was short and very powerful, and I could read through the dozen or so lines and see the equivalent logic expanding in my head. It would've taken many more lines of C++ or Python to get that logic working. Now that I'm out of practice, going back and reading it makes the whole thing seem completely inscrutable. That doesn't mean the language is any less easy or less expressive, it means I'm less good at seeing it.
I wonder what percentage of people who "get Lisp" manage to stay happy working in other languages.
Peter norvig for starters ? I would say me if i mattered ;)
I could see a language designer (say someone like Guy Steele) who has made major contributions in Lisp happily moving on to his or her next research interest, pursuing a completely new design. Those of us stuck in the "real world" of trying to make a living with our software skills are a different matter.
In my experience, once having worked with Lisp I found it extremely difficult to switch to programming in Java. I spent a lot of time trying to make Java look like Lisp, which in my opinion made my code more readable, but to other programmers I worked with - not so much. My point is, Lisp can be a mind altering experience, much like LSD (I suppose). Some have the ability to compartmentalize the experience and move on with other pursuits and some are forever hooked on the "forbitten" fruit.
Much like the author of the posting, I find some elegance in Lisp, but I've never been comfortable with it. While I can code anything I've ever felt the need to do with it, it would rarely be my first choice language. And especially with respect to performance -- I find myself having to spend a lot more time at the whiteboard ensuring that what I'm doing isn't too computationally expensive with Lisp. I just don't have nearly the same sense of cost with it.
Well, the first is more of a demo, actually.
I often run into stuff I can't do in one language that I could do in another. The challenge this poses can be (and often is) frustrating, but it can also be fun: how can I do XYZ as expressively and elegantly as possible in language ABC?
It's the kind of work I do that makes me happy or unhappy, and the freedom I have in it.
-- Eric Raymond (Why Python? - http://www.linuxjournal.com/article/3882)
Raymond himself is very happily not using Lisp.
The situation of Lisp in that timeframe has improved by leaps and bounds. Much better documentation, many more libraries, less community fragmentation (SBCL has become the clearly-best-supported implementation), better OS integration, new exciting stuff like Clojure, etc.
And as for my day job in C++? Well, I prototype in Python for a couple hours, then spend a week translating it to C++. My boss doesn't understand the whole languages thing, but he's happy when I get a 2 wk job done in one.
As for my feelings? Well, I keep reminding myself that I get to move from project to project faster. And that's fun.
It's nonsense, of course. If Lisp weren't good for getting things done, I for one wouldn't bother with it. But having assumed his conclusion in the first three words of the second paragraph, the author need offer no argument, and doesn't. In fact he doesn't even mention Lisp after that.
Sridhar's whole argument hinges on this dichotomy between choosing great tools and having a great finished product.
It is a false dichotomy - In some situations you don't have to choose one to the exclusion of the other. You can have both, especially in startups (PG specifically mentions startups in his essay, as a context to where powerful languages would be effective). Use AND instead of XOR and this post falls apart.
If you start with the intention of building a finished product with "genius", it might help to look for the best tools to build that genius product with, which would also give you expressive beauty (and effectiveness). Again AND, not XOR. Sure you could end up with a beautiful creation using crude tools, but why would you want to if you have a choice of tools??
Extremist positions about a largely artificial choice between great tools and great end-product aren't very convincing. I don't buy this argument anymore than I buy the "I am cooler than you because I write in lisp and you write in C" argument.
From Sridhar's post
"I bet that the vast majority of the world’s programmers, want an “easy” language, not a highly expressive, poetic language Contrast this view with Paul Graham’s Hackers & Painters."
Interesting rhetorical device(again) but there isn't as much of a conflict between their views. There isn't a conflict between "easy" and "poetic". The same language can be used to produce works which are either, neither or both, with all sorts of intermediate positions and shading.
From Pg's essay
"Part of what software has to do is explain itself. So to write good software you have to understand how little users understand. They're going to walk up to the software with no preparation, and it had better do what they guess it will, because they're not going to read the manual. The best system I've ever seen in this respect was the original Macintosh, in 1985. It did what software almost never does: it just worked. [6]
Source code, too, should explain itself. If I could get people to remember just one quote about programming, it would be the one at the beginning of Structure and Interpretation of Computer Programs.
Programs should be written for people to read, and only incidentally for machines to execute.
You need to have empathy not just for your users, but for your readers. It's in your interest, because you'll be one of them. Many a hacker has written a program only to find on returning to it six months later that he has no idea how it works. I know several people who've sworn off Perl after such experiences."
Software should make sense to both users and other programmers? Oh horror, PG does seem to be focusing on the end result after all.
Now PG also seems to imply that in some contexts (startups with a few skilled hackers competing with larger companies with not so killed hackers, say) choosing powerful languages (or generally "running upstairs") would get you to the desired endpoint faster/with less resources etc. Debating that point is fine. Mischaracterizing it isn't.
The problem again seems to be the artificial divide between "simple and easy" vs "poetic "(and by implication NOT simple and easy). The only real argument offered for this dichotomy seems to be based on his personal experience in learning two languages. One learning experience seems to have focused on learning with simple sentences and the the other on learning via/with classical poetry.
If the two languages (and teaching styles) were interchanged, so if you learn English by/with analysing Tudor poetry and Tamil by learning conversational and practically useful sentences, I suspect you would find the latter easier.
That doesn't say much about which language is intrinsically better for a given purpose in a given context.
English can be taught simply or in a complicated manner. So can Tamil. You can read/write complex, layered poetry in both, which are nearly untranslatable into the other. You can write simple , clear prose in both.
"After all, if you are doing wireless communications systems simulation [as I was] or writing a web word processor [as we are], what matters is the particular domain, and the language in which it is developed is not the most important issue. "
But no one (least of all PG) ever claimed it was the most important issue, taking precedence over domain. But it is an important issue.
A programmer who didn't care at all about his tools and didn't have clear preferences, not only about programming languages, but also about other tools like Editors, Version Control Systems etc is hardly a professional. A preference need not be absolute and fanatic. Use AND when you can and XOR only when you have to.
A web word processor can be written with Clojure or Python (say) and JavaScript or with (say) PHP and JavaScript.[1]
Given that choice, I'd expect good developers to tend to one choice over the other if they had the choice (Once you have a large enough base of legacy code/a large enough company, often you don't have that choice).
My nutshell reaction: Bleh what a terrible post. It hardly holds together in any logical fashion or says anything insightful.
[1](Here I am using the same rhetorical device of setting up two arbitrary extremes and forcing a choice - Domain XOR Powerful languages, Clojure XOR PHP. In the real world you could used Clojure, JavaScript and some PHP, or none of these etc, but then how would we argue about irrelevancies? ;-)) .
And yet this is what happens when speaking about LISP developers ... they are usually those very smart kinds that learn things as they go along, so they never have to work through high-school / college.
The most productive communities (i.e. number of useful applications / number of lines of code / number of people actively involved) have always been those that favor handicapped languages like Basic, PHP, Java and C++.
That doesn't mean one shouldn't use LISP to get shit done (correlation is not causation), just don't get trapped in a never ending cycle of yak-shaving ... also keep in mind that personal preferences usually define who you are ... personally I don't want to be the brilliant kid that never finishes anything.
Perhaps, but in practice communities centered around more esoteric languages seem to spend more time working on elegant hacks and self-referential tools than on producing working, useful products. I met a lot of very smart hackers when I was still seriously doing Common Lisp coding but none of them could show me anything actually useful they'd done with it, although they had a lot of very clever tricks up their sleeves.
For example, package management in Common Lisp was a mess. There were three or four completely incompatible systems in use and none of them were really polished enough to depend on. I was astonished at how quickly the Ruby community implemented and rallied around a single, simple, usable package manager, because I'd previously just assumed it was a hard problem to solve.
Grow up.