It is not about languages, it is about ideas. And the fact that you need years to master each of these languages because of ideas they are built upon, not because of such trivial things as syntax.

I strongly suspect that Joe would be equally comfortable with this list was C substituted with Go, Smalltalk substituted with Io or JavaScript substituted with Lua.

To paraphrase: "what is it with people liking or not liking JavaScript"? I know what is it with these people: they are noobs (sorry in advance, this is not intended as offensive). I have been programming for just twenty years now and I just recently, a few years ago, understood all this, so I'm not exactly surprised by your post, but still, I thought that email so well written as Joe's here would repel this kind of "Javascript is bad, use WhatEver(tm)" talk.

It seems I was overly optimistic with this one.

Syntax is not trivial. You stare at something 10 ours a day, you want it to be a good user interface.

That's kind of a silly question to ask.

For one, features are duplicated across masses of languages. If you ask, 'what is the one specific thing I can do in this language that I couldn't do in some other language?', the answer is almost certainly nothing. Languages only really start standing out from one another when you start talking about combinations of features. Javascript's combination of prototyping, closures, and first class functions isn't like any of the other languages on the list even before you get to html DOM manipulation or nosql.

But the more important point I'd like to make is, that if a whole bunch of smart people say they really like something, and you can't see why, that should be a sign to look harder.

Which is not to say, if a whole bunch of smart people like something you have to like it, too. But there's a reason smart people recommend it. And even if you eventually end up disagreeing with the reason, that doesn't mean it isn't there.

"Today there is an unhealthy concentration on language and efficiency and NOT on how things fit together and protocols - teach protocols and not languages."

Exactly. Forget the language. Use it if it works for what you need to do. Learn to program correctly, learn how things fit together, how you can use languages together and for the right purpose; learn the fundamentals, learn algorithms, and you'll build quality software in whatever language you choose.

What is it with shaming people for preferring a specific language where it is applicable?

For some reason I can like a brand of electric drill, and I can believe in using a nailgun, but I am not allowed to like a specific language without someone coming along to scold me.

If you don't ever develop opinions about tools and how to use them, are you really engaged or are you just floating along? Liking something is a good sign of engagement, being able to compare it to others in an informed way is even better. The problem is if you put other things down without knowing about them.

When you buy a drill, the main purpose is to make holes in things. When you buy a nailgun, the main purpose is to stick things together. One might do it better, one might do it faster, and yes, it's useful to know those things. But you're still building a house, not an opinion about a drill or a nailgun.

Ever notice how professionals treat their tools, versus amateurs? Photographers are a great example. Amateur photographers are all about cameras and lenses and tools. They buy gear like there was no tomorrow, and they do very little actual photography. Some of them make it past this phase and change their focus to what photography is really about (light, subject, timing) but most don't.

Professional photographers buy cameras for one purpose: because they get the shot. They buy lenses for one purpose: because they get the shot. And they buy everything else they need for one purpose: because it gets the shot. Their focus is the photograph and everything else follows. Of course there is some thought of what lens is right for what job, and what camera works best for what needs, and durability and portability especially; but mostly they use what works because they know it well and it gets the shot. And some pros use the most ridiculous gear that you'd never expect because it works so well for their particular goals.

There was an article a while back about a Iraq war journalist who used only Olympus 6MP zoom cameras made 5-6 years ago because they were workhorses, extremely portable, and held up to desert conditions. Non-pros probably thought he was crazy and dumb, but he got the shots. He shipped. You have seen his photos in the news, guaranteed. Talking about that gear out of context, it would make zero sense. But for the situation, it was perfect, because he focused on the task and not the gear.

I'm not scolding anyone, I'm not criticizing a choice of language; I'm saying, focus on the right part of your task. The tool is important, but the task is more important. That's exactly what the original article was saying, too, if you'll kindly go back and take note.

I suspect many things and have many theories, but I'd be happy if someone concisely summarized different possible causes of such a behaviour of amateur programmers (and/or photographers). My "they're just noobs" doesn't cut it, because it may well be a description of effect and not the cause (I suspect it is).

I think you're always striving for higher quality at the beginning. You always want to skip over the developing mastery part right into mastery, but it never works that way. So you take shortcuts, and you see that they have effects. To continue with the photography example, if you buy a more expensive lens, for a while it looks like your photographs are getting better. On the surface, they improve. They're smoother, sharper, with better color; whatever. For a while, you think that's what photography is all about, the quality of the image, the lust for higher and higher quality.

We do the same thing in programming. You learn a language. It lets you do stuff. But then you learn a different language and it just seems so much better in the areas you believe are important right then. On the surface, it's easier to code in and easier to understand and it results in more polished code, or faster, or it lets you do things in a way that seems cool. You think "why would anyone ever use Old Language when they could use New Language?" You build lots of cool things and no one uses them but they're cool anyway.

In both fields, the beginner is just learning their tools. It's important to go through that phase in photography, because you learn that lenses and cameras and flashes and gear really do make the result different. The mistake is thinking they make the result better. Because better has many different meanings that are deeper than the surface level that the gear can affect. Same with programming: you make this mistake that New Language is better because it does XYZ better, without realizing that what you're actually building has a deeper meaning than just what the language does better. That it actually takes a lot of different languages, or that Old Language might actually be a better choice because you don't need XYZ, you need ABC. Or something.

It's the difference between mastery and the illusion of mastery or the desire for mastery, and it's the process of learning what tools are for and why they're important, before realizing that they're only important on the surface: as a means to an end. It's an attempt for quality before mastery, which has a limit.

Once you have mastery though, if you've got all the other parts right, then chances are you're going to choose the right language. Language isn't unimportant because it's not important (it is); it's unimportant because if you have everything else right, then the choice of language follows naturally. It's not a concern. It's an afterthought that a true master will already have the answer for.

This is why if you go up to a professional photographer and ask them what kind of camera and lens they're using, they'll just give you a quizzical look and roll their eyes. In their head, the answer is obvious. "The right one."

Will they still be attached to their gear? Of course. Will they still prefer what they're used to? Of course. But they have no illusion that it means anything more than that.

In the end, the photographer in the right place at the right time with the right light still wins, regardless of the gear—even though he still has the right gear. And in the end, the programmer with the right project and the right customers with the right need still wins, regardless of the language—even though that programmer has probably already chosen the right language.

That said, it's also good to remember that there's nothing wrong with loving your languages as long as you reasonably avoid bias and don't let it stop you from trying new languages and ideas.

Any language is Turing complete so the big deal is a matter of style and tools and libraries and ultimately it's who you are working with and what you want to do.

Python has Twisted, and it also has a radically better async ecosystem in gevent. Javascript's async story is far worse than Python's.

Yes and no. Python may have an great async core with Twisted and gevents, but it doesn't have an great async ecosystem. Most tools and libraries aren't written with async in mind and you end up having to roll your own in many places where Node either gives it to you out of the box or with well supported third-party libraries. After having written quite a bit of Twisted code I have to say I find writing async code in Node a lot quicker and easier, despite being a much more experienced python programmer.

It's less good than using a language with first-class support for continuation-style programming, but it's better than using a language that makes you be the compiler and chop up and manage the event handlers yourself.

Python old? Not to be snarky, but I've got programs for the PDP-11 that dated Python's great-grandmother. Excitement in a language doesn't cut it, I respect productivity, environment and progress. For automation, data munging and analysis, Python is my secret weapon in a shop of MS SQL Server DBA's and C# ditto heads. Would have be nice if MS would have adapted IronPython instead of creating PowerShell...

Yes, there are oodles of crappy Turning complete programming languages, but there's definative advantages to a much smaller sub-set of decent langauges and environments.

I vastly, vastly prefer Python. But we are NOT helping Python AT ALL if we bring it up to trash Javascript every time it's mentioned, without making any argument more specific than "I used a PDP-11".

I wasn't trashing Javascript, which is obvious if you trace through the message thread. I haven't delved much into modern Javascript, since most of my work involves data and cli/desktop/network applications instead of web applications and services, so I don't have a valid observation worth sharing.

A massive 3 years older Javascript.

Most people will recommend: http://shop.oreilly.com/product/9780596517748.do

> What can I do that is so beautiful or mindbending that I can't do in python?

The most (and plainly) obvious is; write programs that run on the widest deployed platform/distribution network by several orders of magnitude. That is mindbending and beautiful. Go use Javascript for several years to figure out the rest.

Maybe learning it just as a learning exercise is not so valuable, but Ruby is fantastically useful at getting shit done in the real world with a language that's pretty good. For instance, try and do this in standard Erlang:

    stdout_str, stderr_str, status = Open3.capture3(command)

I'd love to see a language take its backtracking feature.

The author was using Fortran on punch cards and considered himself lucky [Enter: three more Yorkshiremen ...]

Please correct me if I'm mistaken. This all comes from a cursory research on the subject.

  def outer ():
      counter = [0]
      def inner ():
          counter[0] += 1
          return counter[0]
      return inner

Although being able to write on the closed over variable is a neat feature to have, I would argue that feature does make a difference. Whether you call that complete or read-write or however you want to.