Lisp is Poetry and Most Programmers Want Prose (2006)(blogs.adventnet.com)
blogs.adventnet.com
Lisp is Poetry and Most Programmers Want Prose (2006)
http://blogs.adventnet.com/svembu/2006/01/19/lisp-is-poetry-and-most-programmers-want-prose/
6 comments
The diversity of languages is not a diversity of signs and sounds but a diversity of views of the world.
WOW! I haven't heard that quote before. It quite aptly sums up the situation.
WOW! I haven't heard that quote before. It quite aptly sums up the situation.
Most of the devs I encounter recently are at least curious about different families of language
- 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
- 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
> smalltalk, factor, Ioke, forth,
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?
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?
Not to mention how close are Smalltalk and Ruby.
I think OP's point is that enjoying the simple prose of programming, reveling in what you can accomplish with simple tools and techniques, is another equally valid route to enjoyment.
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.
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 think OP's point is that enjoying the simple prose of programming, reveling in what you can accomplish with simple tools and techniques, is another equally valid route to enjoyment.
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".
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".
> The benefit of a highly expressive language is that you can make your code more obvious.
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 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 am not discounting the application of "poetic" solutions, certainly there are cases where this is a justified approach. E.g. I think this is particularly relevent in regards to parallelization.
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.
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 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.
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.
http://sam.bluwiki.com/blog/2007/04/y-combinators-portfolio....
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.
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.
In the interest of being sporting amidst all the downvotes - happy to make this wager up to $1k to anyone who P.M.'s me - we can draw up reasonable terms.
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.
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.
"LISP is worth learning for a different reason — the profound enlightenment experience you will have when you finally get it. That experience will make you a better programmer for the rest of your days, even if you never actually use LISP itself a lot." -- Eric Raymond (How to become a Hacker).
I wonder what percentage of people who "get Lisp" manage to stay happy working in other languages.
I wonder what percentage of people who "get Lisp" manage to stay happy working in other languages.
It may sound trite, but it's true: it all depends on how you define "happy". I'm happy coding in Java, C#, C++, Python and ActionScript 3, to name a few. I was happy to code in Lisp and plain old vanilla C, too. My happiness with programming doesn't depend entirely on the language. I can honestly say that going back to more "mainstream" languages after coding in Lisp has made me even happier, because I had new ways of doing stuff that wouldn't have occurred to me before.
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.
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.
"Old LISPer that I am, I also looked at various current dialects of Lisp and Scheme—but, as is historically usual for Lisp, lots of clever design was rendered almost useless by scanty or nonexistent documentation, incomplete access to POSIX/UNIX facilities, and a small but nevertheless deeply fragmented user community. Perl's popularity is not an accident; most of its competitors are either worse than Perl for large projects or somehow nowhere near as useful as their theoretically superior designs ought to make them."
-- Eric Raymond (Why Python? - http://www.linuxjournal.com/article/3882)
Raymond himself is very happily not using Lisp.
-- Eric Raymond (Why Python? - http://www.linuxjournal.com/article/3882)
Raymond himself is very happily not using Lisp.
That's an article from May 01, 2000. That's 10 years ago.
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.
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.
[deleted]
Well a lot i would say.
Peter norvig for starters ? I would say me if i mattered ;)
Peter norvig for starters ? I would say me if i mattered ;)
I'll accept your own experience, and am happy for you. As for how Mr. Norvig's coping -- let's wait for him to post his own.
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.
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.
I think it depends on your trajectory. I did BASIC then 6502 assembly language then C. Then a few other languages before spending considerable time in Lisp/Scheme, and then Haskell.
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.
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.
Agreed with your last point. I have read about people who loved Lisp so much, that they wrote Lisp to write programs in other languages for them. Two cases:
* http://www.merl.com/papers/TR93-17/ (Lisp to Pascal)
* Erik Naggum told of his dissatisfaction with C++, and wrote Lisp to do his job for him.
Well, the first is more of a demo, actually.
Well, the first is more of a demo, actually.
[deleted]
Here's one anecdote of my own experience. Learning LISP (and Haskell, and Smalltalk) has given me even more appreciation for computer science, for the theory and universe of knowledge that lies underneath the surface of programming.
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.
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.
In my own experience im really happy with clojure and common lisp, and im also happy with python, until one of its quirks that i have to remember comes after me and bites my ass, anything else seems either tolerable or unbearable. But thats just me, both common lisp and clojure have the capacity to drive me nuts, but it seems to happen a lot less often.
What a case of assuming your conclusion. If Lisp is poetry, and poetry is beautiful-but-archaic-language-completely-divorced-from-ordinary-human-communication, well then obviously Lisp is for a tiny minority who like to speak Elizabethan; meanwhile the much larger population of practical people will simply prefer to get things done in vernacular.
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.
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.
Say what you will about pg's writing. But he's been involved in the funding of plenty of startups that didn't write Lisp code. I think you should pay attention to where his money is going before you read too much into his essays.
"I am much more impressed by the genius of the finished product rather than the expressive beauty of its implementation. "
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? ;-)) .
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? ;-)) .
It is a false dichotomy.
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.
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.
[deleted]
> 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
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.
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.
This is getting stupid. People program real, working things in Lisp. People program real, working things in languages that aren't Lisp.
Grow up.
Grow up.
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.