[vessenes]

This sort of has a 'straw-man' feel to me. I've never heard the "Elite Programming Language" term before I saw it deconstructed in this essay.

Most discussion around programming languages I see these days is centered around assessment of developer skills. This is understandable -- we're going through a period of massive technical talent shortage. Almost all tips we read through places like HN, including PG's notes, revolved around shorthand ways to screen developers, not pushing a one-true-language approach (unless Yahoo Store programming skills are at stake, apparently..)

Unlike, say, the mid 1970s, when IBM could take its sweet time training you to program, startups don't have a lot of time to make something happen. Thus, they need a language (and application framework) that will work well, and they need developers that they are reasonably sure will be able to succeed. And they cannot wait six months to find out if they were correct about said developers.

One shorthand way to look for these developers is to find ones who have demonstrable skills in new-ish, hard-ish languages. These are the developers that you know for sure

1) Like new things

2) Aren't afraid to experiment

3) Enjoy a challenge

You have no idea if they're any good to work with, understand software architecture, have foul personal habits, or any number of other reasonable concerns for some other company. As a startup company, you don't care about most of that list (at first). This is why it's a smart move to look for people who have just coded up some crazy Arduino-Haskell-auto-shooting-usb-missile program. Those people will not be unduly dismayed when they need to reverse engineer a wireline protocol one day, and 'pick up couchbase' the next.

All this to say, sure, there's no such thing as an elite language. But, right now, there are a few languages that indicate strongly that you might wish to recruit a programmer for a stint at your startup. Clojure, Scala, Haskell are on my list.

[kenjackson]

I don't understand why those three things you listed would make a good developer. Who doesn't like new things? I want to find the person who sticks with the old thing, even after the shine has worn off. Everyone loves to code the prototype. And if you tell most devs they get to code the prototype and learn a new language at the same time they'd jump at it. In grad school, with every project I used a new language -- why? Because it's fun. But that doesn't make a good dev.

Again, I've never met anyone who is afraid to experiment. But I've met people who don't know when it makes sense to experiement.

And again, the problem I've had with programmers has never been because they don't enjoy a challenge. In fact, I'd say quite the opposite. I'd like to see more devs say early on that something looks difficult, and could use some mentoring or help on it.

I guess I'm just saying that this says almost nothing about the quality of the developer.

[ohyes]

Perhaps you aren't trying to find a great dev, you are trying to weed out the pigs in pokes. Anyone who isn't a total fraud of a programmer is lauded as an excellent hire.

It seems to me that just as with reading and writing, nearly anyone could be taught to program. The problem is that there are many people who are completely illiterate. Of those that have been trained, there are still many who are functionally illiterate (they can write godawful code slowly).

Anyway, I've seen plenty of bad code in Common Lisp. You'd have to assume that any language with significant market share would produce more bad code. This is because of bandwagon effect.

i.e. 'There are a lot of companies that want to work in lang_x, therefore everyone gets trained in lang_x, and if you just want a job, you learn lang_x.' All of the programmers who have been taught but never learned 'know lang_x', so you get them producing bad lang_x code.

The elite programming language fallacy solves this, by eliminating the people who only 'know lang_x'. If you had trouble learning to program lang_x, you aren't going to go out and read a book on your own time about lang_y or lang_z.

So lang_y and lang_z become 'elite' even though elite really means 'a bare minimum test if you could possibly to produce good code'.

[SoftwarePatent]

> I've never heard the "Elite Programming Language" term before I saw it deconstructed in this essay.

Google search for "elite programming language" -"elite programming language fallacy" [1] (to avoid links to this post) yields eight results. It seems the term "elite programming language" was coined by the author in order to knock it down, which is one type of a straw-man argument. [1] https://encrypted.google.com/search?q=%22elite+programming+l...

[fogus]

    It seems the term "elite programming 
    language" was coined by the author

You might have saved your time searching Google and instead read the first paragraph of the post.

[fogus]

    This sort of has a 'straw-man' feel to me. 
    I've never heard the "Elite Programming Language"
    deconstructed in this essay.

I all but admit to coining the term in the first paragraph. It's a term without baggage that is meant to encapsulate many related terms: hipster, academic, complex, obscure, !blub, etc. To say that the post is a straw-man is to deny these other terms exist and are used to mean roughly the same thing.

[barrkel]

Never heard of the concept, or never heard of that specific phrasing? Because I've heard of the concept repeatedly for years.

http://paulgraham.com/pypar.html

[nandemo]

I agree with vessenes, the article is vaguely strawman-ish.

What pg says in Python Paradox is not "all Python programmers are elite hackers" but rather that -- when he wrote the article -- the percentage of good hackers in the Pythonista population was higher than in the Java-programmer population.

Again, the point is not that learning Python automatically makes you a better programmer. It's that people who are great programmers or are interested in being better programmers are more likely to go and learn a non-mainstream language.

[gtani]

"advanced"

http://matt.might.net/articles/best-programming-languages/