[mikeash]

I realize this is probably unpopular, but I personally think we shouldn't aim for beginner-friendliness in our production languages. If we can do it then fine, but it shouldn't come at the cost of anything else.

People are only beginners for a (hopefully) short time, then they're not. Making things better for them in the post-beginner period is far more advantageous, since that's when the vast majority of productive work occurs.

There is certainly a place for beginner-friendly languages. People need to learn to program at some point, and something which is aimed at helping them do that is really useful. But there's no reason that it should be the same language used by professionals to do real work.

Imagine changing the design of a 747 to make it easier to fly for new pilots. We wouldn't dream of doing such a thing. The cockpit of a 747 is for experienced professionals. If you're learning to fly then you belong in the cockpit of something like a Cessna 152.

Note that I'm not advocating for difficulty just for the sake of difficulty, and I don't want to keep people out. And if a language can accommodate beginners without making things worse for professionals then let's go for it. But it shouldn't be a major goal of most languages.

[ScottBurson]

It's a quandary. Beginner-friendliness does make a language somewhat easier to learn -- someone just trying to wrap their heads around the very idea of a program as a sequence of operations isn't going to appreciate being told that an integer is fundamentally different from a numeric string for reasons they don't yet understand (just to take one example).

Yet once someone has learned a language, they tend to keep using it. Their very inexperience prevents them from understanding that they should switch to something more industrial-strength once they start to write something larger and more complex. Plus, they don't even know when they start to write a program how big it is likely to get.

I don't know what to do about this except to continue to bang on the point you're making.

[LeoNatan25]

The cynic in me sees these approaches as a corporate-friendly way to be able to hire more "juniors" to save money. Entire frameworks and languages seemingly exist to enable low barrier entry to junior developers without any effort of the corporate to invest in these junior developers. There needs to be a balance between the need for junior developers to be productive and restricting technology just so as many as possible junior developers can be productive at low cost for the corporate. With stuff like React Native and Electron, I feel the former takes the lead at the expense of technology.

Agree that simplistic languages could work well in academia, as the first language that students see. I studied C as my first language, and I am not sure that is optimal. Nor do I think Java is that language, as many study that first, these days.

[kornish]

Agreed. Go works for Google's use case (hiring thousands of fresh grads with low average tenure - need to minimize ramp-up time) but most companies should hire to the language, not bring the language to the hires.

[LeoNatan25]

A good hire is a good hire in any language. Just focus on good hires.