[TheRealPomax]

That has never been a problem in a large part of the programming job market. If your skill set fills the job opening a big coorporation or institution has, and that job sets you up for life (instead of the frantic contract based work for startups or small companies) then exploration is a luxury, but in no way a necessity.

Note that logic applies here: I'm questioning the "you should know" claim, not claiming "you should not know" because that would be ridiculous. Learn all you like if you feel that gives you a leg up, or an enriched quality of professional life, but it is absolutely not a requirement in a well-paying part of the real world's programming landscape, so claiming "one should" is a little rich.

[wangchow]

Well, this is true if all one is interested in is getting a job today.

However, the best developers aren't primarily concerned about getting a job or not, they are genuinely interested in programming as both an art and a science. Money and jobs is secondary (and readily available because such individuals are more skilled than those that limit their pursuits).

[sbov]

Anyone who stereotypes the practices of the best developers is kidding themselves. Some of the best developers I know only know C.

In reality there are roughly two types of tech: staples and new ones. Staples are around for a long time, but HN tends to focus on new ones. The thing is, even our modern staples came from a much larger set of new pieces of tech.

What this means is, that if you're using a piece of tech that has been popular for at least 20 years, you're probably good for at least the next 20. If you keep switching to the new hotness, you will have to keep doing that because you are most likely learning stuff that won't stay around.

[wangchow]

Not stereotyping the best developers but saying that one who keeps an open mind to new ideas will be a better at what they do. Now, obviously there are limits to what people can do but more exposure is generally better.

C is all well and good (anything can be implemented in C) but one must recognize that higher level languages serve one purpose: to help express certain ideas in a more concise and easier-to-understand way than a lower-level language. It can be very helpful to look at why a particular functional language (just for example) achieves a result, and then implement the same concept in C or even assembly if necessary. But by abstracting the problem into a more simpler one, more complex ideas can be express.

Just look at integrals and derivatives in Math. One could compute derivatives using the difference-quotient but that would make more complex ideas almost impossible to understand. We create rules to help us derive common patterns, then use those to build more powerful ideas in a simpler way.

[ArkyBeagle]

You don't (usually) solve a problem directly in 'C' - you build furniture in 'C' that you arrange to then solve the problem.

Using a "higher level" toolset just means (possibly) buying rather than building. Which is "better" is an economic decision, until people's self-identity starts to get in the way.

I just remember a J2EE class, where every day we'd spend thirty minutes updating all the bizarre tools, which would frequently break things. I'm insufficiently venal to put up with that.