"I am much more impressed by the genius of the finished product rather than the expressive beauty of its implementation. "<p>Sridhar's whole argument hinges on this dichotomy between choosing great tools and having a great finished product.<p>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.<p>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 <i>also</i> 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 <i>if</i> you have a choice of tools??<p>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.<p>From Sridhar's post<p><i>"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."</i><p>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.<p>From Pg's essay<p><i>"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]<p>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.<p>Programs should be written for people to read, and only incidentally for machines to execute.<p>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."</i><p>Software should make sense to both users <i>and</i> other programmers? Oh horror, PG does seem to be focusing on the end result after all.<p>Now PG <i>also</i> seems to imply that <i>in some contexts</i> (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.<p>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.<p>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.<p>That doesn't say much about which language is intrinsically better for a given purpose in a given context.<p>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.<p><i>"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. "</i><p>But <i>no one</i> (least of all PG) ever claimed it was the <i>most</i> important issue, taking precedence <i>over</i> domain. But it is <i>an</i> important issue.<p>A programmer who didn't care <i>at all</i> 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.<p>A web word processor can be written with Clojure or Python (say) and JavaScript or with (say) PHP and JavaScript.[1]<p>Given that choice, I'd expect good developers to <i>tend</i> to one choice over the other <i>if</i> 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).<p>My nutshell reaction: Bleh what a terrible post. It hardly holds together in any logical fashion or says anything insightful.<p>[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 <i>and</i> some PHP, or none of these etc, but then how would we argue about irrelevancies? ;-)) .