It's not about idioms themselves. It's about the thought processes behind those idioms. The difference between learning language idioms and learning the thought processes behind them is like the difference between learning how to solve math problems that appear frequently in exams and learning math.

I'm not arguing that you can't be a decent programmer without "mastering language idioms", but there are good reasons why different languages exist. If you just pick up a language without understanding the problem it solves, you're just adding a tool to your toolbox without knowing how to use it effectively, when to reach for it and how to accomplish what it does when you don't have it.

This is true for what pg calls Blub programmers who get stuck in idiomatic ruts, but there's so much idea-sharing among the current popular high level languages that I think once you master a certain number you can pick up new ones fairly easily. The current ecosystem is one in which the really important idioms--fundamentals of good software--translate well from language to language.

Exceptions might exist for things like APL, and to a lesser extent "extremist" languages like Haskell, Lisp, Forth, which require paradigm shifts to think about effectively.

Almost everyone starts as a Blub programmer -- "Blub" was BASIC when I was a kid and that's what I learned first -- but that's beside the point.

You're right in that the more languages you learn, the easier it gets to pick up new ones, but that only happens if you make an effort to master them, so you can learn the thought processes behind them.

Of course, after a while you'll hit the point of diminishing returns, where most new languages you learn won't have a boatload of new, eye-opening, paradigm-shifting concepts for you to discover and learn. However, there are two things to keep in mind:

1) You never know when a new language will teach you something important unless you try your best to learn it properly.

2) If you think you're going to spend a lot of time working with the language X or if you're going to dive into a huge codebase written in that language, then by all means try to master it. The better you are in that language, the less code you'll write in it and the less code there is to maintain, the better.

Good engineers care about being consistent with language idioms. The only practical consequence is that they are a little bit slower than they will be after a couple of years; but they are still faster than nearly everyone else anyway.

>I think patio's targeting the HN crowd, and not the mediocre-programmer-with-30-resume-padding-languages crowd

I'm curious as to why you think there is so little overlap in those two categories. There seems to be an awfully big PHP defence force here for example.

So you're stating that most PHP programmers are mediocre programmers?

This is a very off generalization, the language you use doesn't effect your ability as a programmer, what does is the way you use it.

Anything you can build in Ruby or Python, you could also build in PHP, it may take longer, or less time, but consider this thought as a rebuttal to your elitism for just one moment:

If PHP is such a bad language, then to create equally good programs in PHP instead of Ruby would generally mean that the average PHP programmer is better than the average Ruby programmer.

That's an off generalization too, but since we are both throwing around random, baseless comments, there's another.

>So you're stating that most PHP programmers are mediocre programmers?

So, you are responding to a strawman because you just like to argue? Try reading my post again, I didn't say anything about PHP programmers.