One of the more interesting aspects of Ruby is that it imposes very few restrictions on the developer: A Ruby programmer can do almost anything, including changing classes at runtime, redefining methods, and so on. Indeed, many Ruby libraries cleverly take advantage of that freedom to create a pleasant developer experience. While Ruby imposes very few restrictions on the programmer, other languages are more concerned in their designs with preventing programming errors, writes Michael Feathers in a recent blog post, Ending the Era of Patronizing Language Design:
In many language communities, people are very concerned with the “right way” to do things. They learn all of the warts and edges of the language and they anticipate the ways that features could be misused. Then, they starting writing advice and style guides — all the literature which tells you how to avoid problems in that language. The advice goes on and on... If a language gives you mechanisms to enforce design constraints, it doesn’t feel quite right to not use them...
In some languages you get the sense that the language designer is telling you that some things are very dangerous, so dangerous that we should prohibit them and have tools available to prohibit misuse of those features. As a result, the entire community spends a lot of time on prescriptive advice and workarounds. And, if the language doesn’t provide all of the features needed to lock things down in the way people are accustomed to, they become irate...
If something goes wrong you have only yourself to blame. You can’t blame the language designer for not adding a feature because you can do it yourself, and you can’t blame him for getting in your way because he didn’t... So, why aren’t more people crashing and burning? I think there is a very good reason. When you can do anything, you have to become more responsible. You own your fate. And, that, I think, is a situation which promotes responsibility...
It is possible to create a mess in every language. Language designers can’t prevent it. All they can do is determine which types of messes are possible and how hard they will be to create. But, at the moment that they make those decisions, they are far removed from the specifics of an application. Programmers aren’t. They can be responsible. Ultimately, no one else can.
What do you think of Michael Feathers' comments on "patronizing" language design?