Ending the Era of Patronizing Language Design

The truth, from the language designer and compiler author's perspective: programmers should be protected from their own worst instincts, and programming languages that do this well are of a higher quality than languages which don't. Patronizing, to a point, is good. The flip side is that features whose use should be encouraged should be included in the box, turned on by default, made easy to use, etc.

Ruby is patronizing because it's memory safe. C and C++ programmers don't like this kind of patronization. Ruby, and Python, are unlike C and C++ in this way: they are rigid and uncompromising in their type safety, disallowing unsafe casts and operations.

Michael makes some category errors in his rant. For example, he says:

"[...] we’ve made the assumption that some language features are just too powerful for the typical developer -- too prone to misuse. C++ avoided reflection"

The problem with this abutment is that C++ avoided reflection in its quest for power (or what C++ users thought was power), rather than its avoidance of power: C++ users wanted to hew to a philosophy of pay only for what you need. The problem with that philosophy is that if you make certain features optional, or pay as you go, then the community in general cannot assume that everyone is using available features. Instead, third-party library authors must assume that only the lowest common denominator set of features is available if they want to maximize usage.

Java and C# have avoided multiple inheritance for good reason; and Michael's rant is not a good reason for them to reintroduce that feature, because it remains problematic.

"The newer breed of languages puts responsibility back on the developer"

This is simply untrue, and bizarrely myopic, in my view. The developer always has responsibility, but the responsibility has shifted to different places, as the emphasis on abstraction level in programming languages has shifted. To take Michael's thesis at face value, you would need to believe that C mollycoddled the user and didn't bite their fingers off when they didn't take care of their pointers, or carefully handle their strings, or foolishly used fixed-size buffers for dynamic input.

Of course C put responsibility in the hands of the developer for these things. But guess what? Ruby, Python, C#, Java etc. all take away responsibility from the developer for these things! Michael says that dynamic languages like Ruby hand over the power of monkey-patching etc. to the developer, and that this is a new development; but to get equivalent power of dynamic behaviour overriding in a C application, you'd be using very abstract structures, likely looking like a Ruby or Python interpreter behind the scenes, where you would have a similar degree of responsibility. But not only that; you'd also be responsible for the dynamic runtime, as well as the memory management and all the other unsafe stuff that comes with C.

I would much rather do something the wrong way and be burned by it (and probably learn a lot in the process), than be prohibited outright from using certain techniques.

C++ coddles programmers and Ruby doesn't. Really? That sounds like a sensible thing to say?

C++ avoided reflection because it would be misused by programmers? Only a profound misunderstanding of the design goals of C++, or having never actually used it, could inspire such a claim.

ActiveRecord is a Rails innovation that took decades to realize? What? Why would you think this?