I think patio's targeting the HN crowd, and not the mediocre-programmer-with-30-resume-padding-languages crowd. Most very smart programmers know enough about software engineering to do it in any language, and good engineering is far more important than mastering language idioms.

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.

Most uses of a language don't require mastery. Especially if the rest of the team knows better than to write unnecessarily clever code when boring code would do just fine.

I don't think it has to do much with clever vs. boring code, but it's more about knowing your idioms and avoiding pitfalls. When it comes to mastery I think most recruiters prefer the master over the novice.

I think it takes at least a year to learn OO design enough that you can write code worth (re)using. The Java ecosystem is also so big that it takes years of experience to really get your head around it. And don't get me started about C++.

Sure, a decent coder can learn to write "hello world" in any of those languages, but if you need to pick up a legacy system and understand what's wrong with it (I think this is 80% of the jobs) it takes depth. If you've got enough depth in how systems work you can get sort-of up to speed in various languages quickly, but there's no substitute for taking the time to know the details of what you're doing.

As for LOB work I can say that LOB systems can be a lot of fun to develop. Your average e-commerce or social media site is basically an LOB system. Developing a system of practices that lets you deliver LOB systems on time and under budget is a challenge, but in the right environment it can be done and there is something very satisfying about delivering something that makes people's work easier.

The trouble with LOB work is that it's usually not greenfield work when it comes to you. They had some junior guy who never heard of primary key integrity build an app in an access database and a year later the database is full of junk and the app doesn't really work.

The process of rebuilding the schema is tortuous and then you need to update every single screen and script to work with the new schema and then there's the long and involved process of reconstructing what the database contents should have been with minimum data loss.

Although maintenance programming can really widen your skills and ability to deal with "it" there's also something destructive about spending all day deeply understanding the logic of terribly flawed code.

Wow. You're fortunate. I've never met a recruiter who would recognize a master if they were assaulted by one.

Managers would prefer a master, not recruiters. Recruiting requires throwing everything at the wall that remotely looks like a fit (I know .NET, am not a master, but it's on my LinkedIn - every freaking unsolicited recruiter contact I get is for .NET) Also, if they can get a novice in there, there's a chance they can pay less yet bill the client the same (talking on w2 contracting here)

I thought it was amusing that he went on to say "Much of Fog Creek uses the Microsoft Stack. I can’t even spell ASP.NET and they’d still hire me." - Joel Spolsky wrote a great article on the value of knowing a language in depth: http://www.joelonsoftware.com/articles/LordPalmerston.html

That said, his point is still largely true - you don't need your entire team to be specialists. But don't underestimate the value of knowing <some significant technology> inside out, backwards, and upside down.

If you read some of his other stuff you'll see that they did hire him and paid him somewhere in the region of 5 figures per week. :-)

You respond to something that's not in the quoted text.

Picking up a new language to the point where 6 to 12 months later "nobody will notice" on average means pretty much that you know general principles of computer science so you can stay afloat by figuring out how to translate that into your new language by hitting Google 50 times a day.

It does certainly not require you to be fluent or master the language fully.