[lobster_johnson]

I think articles like these beg the question. It introduces a claim ("many/most people think some languages are too weird") and tries to refute it without first showing that the claim is true.

Sure, I see lots of evidence of junior developers living in a happy bubble where they apply language X to everything, when they could expand their horizons a bit by looking into Y and Z.

But this also ignores important factors such as:

* Convenience — if you've highly proficient in X, there's a low barrier to entry for anything you want to accomplish.

* Private ecosystem — if all your code is in X, you have potentially tons of reusable modules as part of your own stack.

* Public ecosystem — lots of libraries and community support.

* Mature documentation

* Stability

* Ease of hiring

and so on.

Also, not least: The journey of every developer is to broaden one's horizons gradually. As a junior you'll likely slog through a few fad languages until you reach a point where every technology out there, no matter how advanced, will suddenly become approachable.

The Blub idea also ignores the fact people can accomplish great things with poor tools. Choosing a minimal tool does not necessarily say anything about you as a developer. Sticking to one tool for many years probably says a lot about your ability to develop your skills, of course.

In short, I think Blub is a red herring, and I think it's a condescending one, a product of survivorship bias — you're not superior because you succeeded using a certain set of tools. You're probably successful for other reasons (which may correlate with your ability to choose the right tools, or not).

Graham's observation that "[languages] dictate the way [developers] think about programs" is the more important lesson to draw from his essay, though it's not exactly a new idea.

[pka]

I want to respond to one point specifically: `Private ecosystem — if all your code is in X, you have potentially tons of reusable modules as part of your own stack.`

Never ever in my OOP days have I been able to reuse a non-trivial function from a different codebase "just like that". This is because all my functions were impure - something encouraged by most mainstream languages. So I had to first rip out the context the function was living in and make it work again before being able to use it somewhere else. I wouldn't fix it in the original place though, so next time I'd want to reuse I'd have to repeat every step again.

Since I started using a pure language, reusing code actually became possible. I can rip out a function and place it in a new codebase without changing it a bit and it's gonna work just like that, no problem.

Getting back to the topic at hand, I would define the Blub paradox as "being unable to logically explain the benefits of something solving a problem you haven't realized is actually a problem yet". This may sound like trying to create problems out of nothing just so that they can be solved by "cool feature X", but I'd guess in most situations this isn't the case.

I truly believed that I was creating reusable OOP components until I realized that actually I wasn't. I truly believed a normal editor is more than sufficient for my needs until I learned vim. I truly believed svn was the best thing ever until I learned git. Etc...

[lobster_johnson]

I didn't mean copy-paste reusability, I meant packaging code into reusable modules (e.g., NPM packages, Ruby gems).

This has nothing to do with OO, really. But I don't disagree with your point about immutability.

[microtonal]

The Blub idea also ignores the fact people can accomplish great things with poor tools. Choosing a minimal tool does not necessarily say anything about you as a developer.

In fact, I think the original essay makes quite some unwarranted assumptions:

But if you work for a startup that doesn't have pointy-haired bosses yet, you can, like we did, turn the Blub paradox to your advantage: you can use technology that your competitors, glued immovably to the median language, will never be able to match.

The median language will probably have a very good ecosystem that allows a small team of developers to quickly leverage. (Of course, someone who is not stuck in a Blub language has the same opportunity.) I think that there are very many counter-examples to the 'blub paradox'. Facebook was written in PHP, Paypal was written in Java, Dropbox was written in Python (which was a Blub language by 2007).

Graham's observation that "[languages] dictate the way [developers] think about programs" is the more important lesson to draw from his essay, though it's not exactly a new idea.

Indeed, this is a very important lesson, but not foreign to anyone who learnt LISP in the 70ies or Prolog in the 80ies ;).

[lobster_johnson]

Absolutely.

Someone once claimed — I forget who and where — that Go was designed at Google precisely so that even average developers could contribute meaningfully and safely within Google's stack.

Of Google's top languages (as far as I know), Java and C++ are complex, and Python has its own idiosynchracies, notable the lack of static typing which leads to a class of potential errors (especially as relates to backwards compatibility between modules) that must be mitigated with super-extensive unit test coverage.

Go, on the other hand, is a very small and simple (easy to ramp up), very strict (hard to screw up) language with an extensive library (max productivity).

[pekk]

The implication that a developer is junior if they mainly use one language is completely absurd.

[lobster_johnson]

I don't see how you could interpret my comment that way.

A junior dev might use a single language because they apply what they know and don't go outside their comfort zone. A senior dev might use a single language for every other reason.

[joncampbelldev]

Everyone has a language they like best and spend a lot of time in (due to current job or side projects or whatever), but a developer who has never branched out to other languages and paradigms even to experiment for a bit (maybe bring back some knowledge to their preferred language) is someone I wouldn't want to work with.

But this is all from my perspective in a small startup where people have very broad responsibilities. I can completely understand a very senior developer working in a specific field (usually it's the low level stuff with C etc) who only works in one language because there's just no opportunity to use anything else.

Or perhaps someone who just sees their job as a 9-5 thing and looks elsewhere in their life for learning and growth.