Teach Yourself Programming in Ten Years (1998)

I mostly agree, but I think 2–3 is too few. I think I'm pretty good at C, bash, Python, make, and JS, and also (if we're counting languages that aren't programming languages) SQL and HTML. I used to be pretty good at Perl, but the language has moved on since then. I think I have more than "passing familiarity" with i386 assembly, PostScript, OCaml, Java, C++, BASIC, Bicicleta, Scheme, Lua, and Brainfuck; that is, I can figure out how to write things in them without constantly looking stuff up, and I'd be comfortable writing hundreds of KLOC in them, but what I write is surely not fully idiomatic. And there are another 32-64 languages I have passing familarity with, meaning that I've written useful complete programs in them, including Golang, Rust, Excel, Smalltalk, PV-WAVE IDL, Prolog, Common Lisp, Scala, Octave, Elisp, Ruby, Pascal, Clojure, Forth, R, and Tcl, but I can't think of most of them right now.

I guess in the context of your comment this sounds like bragging, but that's not my intent; I'm trying to rebut your comment, using myself as an example, because I think this level of polyglot programming is pretty close to normal, at least after you've been at this stuff for a few decades. Maybe if you're getting into a rut of only knowing 2–3 languages well, you'd benefit from putting more effort into exploration. Unless you're about to stop programming, in which case you won't have time to take advantage of your newfound powers.

I don't think percentages are a good way to think about language fit. I think it's more like an effort multiplier. In theory I can solve any programming problem in C, but when the problem isn't huge and performance isn't much of a challenge, I can usually solve it about with about a tenth of the effort in Python. There are problems where solving them in SQL is about three times easier than in Python, and problems which can barely be solved in SQL, so solving them in Python is about a hundred times easier.

As an example, in my experience it's pretty common for Python to be about half as much effort as Scheme, but there are much better Scheme implementations out there, so when performance is a challenge, solving them in Scheme can be a hundred times easier than solving them in Python. But if you know Scheme and not Python, you can often get twice as much done by learning Python, even for problems where you might say Scheme is a pretty good fit. But it's true that at the beginning, when you have barely any experience in Python, you won't be faster; you'll be slower. And you won't know if that will ever change.

Most commonly, though, people use the language that is best integrated with their chosen platform, because that saves them the effort of writing a bunch of integration code in addition to the actual application code. If you're writing DHTML, for example, use JS, not C. If you need to invoke JVM libraries, reasonable options include Python, JS, Kotlin, Clojure, and Java, but not Perl, C, or C#. If you're writing a Minetest mod, do it in Lua.

So, if you only have more than passing familiarity with 2–3 languages, I think you're going to frequently run into cases where that ignorance costs you a factor of 2 or 3 in effort.

I certainly agree, though, that choosing the right language won't solve all your problems, and it's easy to have exaggerated hopes for it.

The thing, in my opinion, is to avoid spreading yourself too thin.

I started using C/C++ more than 20 years ago and even if I feel really comfortable with the language (except the latest revisions) I am still learning and improving.

I don't think I could achieve the same level of mastery on half a dozen languages.

I hate to do this, but:

Stop equating programming and bus drivers or waiters. They aren't equal. Programming is difficult in its depth and breadth in a way that waiting tables is not.

Stop treating all programming tasks as equal. They are not. Most of the easy ones are only easy because they run on top of all the difficult programs. That is the goal of the difficult programs, to make it possible for laymen to do work that would require an expert for certain repetitive tasks if the underlying program did not exist.

Most people would not be capable of getting Hello World to run without the OS and high-level abstractions that take expertise to develop. And making that possible requires many many experts in many different kinds of programming.

Stepping off of the single thread and single machine model into concurrent and distributed computing to enable even more laymen to make stuff takes even more experts.

There is a meme in the industry that people shouldn't strive for expertise. We still need more experts, and you become an expert through practice while still a layman. Nothing would be worse off if we had more experts capable of deciding when to use something extensible off of the shelf to enable laymen to do simple tasks, and when to build a platform to eventually enable that task to be done by a layman.

A lot of things would be worse off if we encouraged all people to stop at the layman level. We should encourage everyone to at least become a layman for their own enrichment. But we should also encourage laymen to strive for expertise to lower the barriers to entry to produce more laymen capable of doing simple tasks.

For example, without something like Node, you cannot even open a file. I consider this a very basic requirement for being "general purpose".

Ten years later I still struggle to get involved language standardization effort.