Object Mentor Blog: Ending the Era of Patronizing Language Design

Ending the Era of Patronizing Language Design

Michael Feathers — Mon, 13 Jul 2009 13:44:00 -0500

Earlier this year, I was asked to speak at a Ruby Conference. I was happy to go, but I also felt a bit out of place. I haven’t done much Ruby, but I’ve admired the language from afar. I have a number of friends who’ve left C++ and Java to jump toward Ruby and Python and for the most part, they are happy. They do great work, and they enjoy it. They are living proof that the nightmare scenarios that people imagine about dynamic languages aren’t inevitable. You can program safe, secure, high quality applications in dynamically typed languages. People do it all the time, but that’s cultural knowledge. If you are in a culture, you hear about all of the things which are normal which appear odd from outside. If you aren’t, you don’t.

This is pretty much the situation I’ve been in with Ruby, up to a point. I haven’t written a large Ruby application. I’ve tinkered around with the language and written utilities but as far as total immersion goes — no, I’ve never been totally immersed in the language but that hasn’t kept me from learning noticing interesting things at the edge. One of the striking things that I’ve noticed is that the attitude of Rubyists toward their language is a bit different. They seem to have an ethic of responsibility that I don’t see in many other language cultures.

Ethic of responsibility? What do I mean by that?

I guess I can explain it this way. 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. Much of it centers around legitimate language defects. Some languages make you work hard to use them well. Other bits of advice, though, are really extensions of culture. If a language gives you mechanisms to enforce design constraints, it doesn’t feel quite right to not use them. As an example, consider sealed and final in C# and Java. Both of those constructs do pretty much the same thing and people do go out of their way to advise people on how they should be used to protect abstractions. It’s interesting, however, that languages like Ruby, Python, and Groovy don’t have anything similar, yet people do write solid code in those languages.

Let’s leave aside, for a minute, the debate over static and dynamic typing. What I think is more important is the issue of tone. 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.

I just haven’t noticed this in Ruby culture.

In Ruby, you can do nearly anything imaginable. You can change any class in the library, weave in aspect-y behavior and do absolutely insane things with meta-programming. In other words, it’s all on you. You are responsible. 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.

For years, in the software industry, we’ve made the assumption that some language features are just too powerful for the typical developer — too prone to misuse. C++ avoided reflection and Java/C# avoided multiple-inheritance. In each case, however, we’ve discovered that the workarounds that programmers apply when they legitimately need a missing feature are worse than what the omission was meant to solve. Blocks and closures are good immediate example. There are tens of thousands of applications in the world today which contain duplication that you can really only remove with the template method design pattern or by creating a tiny class which encapsulates the variation. If blocks or closures were available, programmers would be more likely to tackle the duplication and arrive at much less cluttered design.

Meta-programming features are yet another example. Business applications are rife with situations where you need to know the value, type, and name of a piece of data, yet we use languages in which these sorts of capabilities have to be hand-coded and over and over again. The fact that it took decades for the industry to arrive at something as useful as ActiveRecord in Rails is due primarily to the attitude that some language features are just too powerful for everyone to use.

We’ve paid a price for that attitude. Fortunately, I think we are getting past it. The newer breed of languages puts responsibility back on the developer. But, language designers do persist in this sort of reasoning — this notion that some things should not be permitted. If you want to see an example of this style of reasoning see the metaprogramming section in this blog of Bruce Eckel’s ( http://www.artima.com/weblogs/viewpost.jsp?thread=260578 ). I respect Bruce, and I realize he isn’t speaking as a language designer, but I offer that as a example of that type of reasoning — reasoning about what should be permitted in a language rather than what puts a bit more control and responsibility in the hands of programmers. Maybe decorators work in 95% of the cases where you would want to do metaprogramming in an application, but there is a price to that choice, and it isn’t just the workarounds in 5% of the cases. The additional price is a decreased sense of responsibility and ownership. I think that those human dimensions have far more impact on software than many people suspect.

The fact of the matter is this: 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.

"Ending the Era of Patronizing Language Design" by ljubavni stihovi

Sat, 04 Feb 2012 09:51:57 -0600

I don’t know what to say except that I have enjoyed reading. Nice blog, I will keep visiting this blog very often.

"Ending the Era of Patronizing Language Design" by reclaim care home fees

Tue, 10 Jan 2012 21:11:48 -0600

In common, the usefulness and significance is overwhelming. Very substantially thanks as soon as once more and very good luck and maintain up the fantastic work!

"Ending the Era of Patronizing Language Design" by Backup iphone sms

Sat, 07 Jan 2012 06:05:54 -0600

We can do anything to keep the data safe.

"Ending the Era of Patronizing Language Design" by schwinn recumbent exercise bike

Fri, 06 Jan 2012 06:30:07 -0600

What a fabulous post this has been. I am grateful to you and expect more number of posts like these. Thank you very much.

"Ending the Era of Patronizing Language Design" by SEO Colorado Springs

Wed, 04 Jan 2012 11:14:34 -0600

Thanks a lot one more time for the useful information. Thanks for publishing these articles here and your blog.

SEO Colorado Springs Colorado Springs Search Engine Optimization

"Ending the Era of Patronizing Language Design" by Commercial Glass Tinting

Wed, 04 Jan 2012 10:54:26 -0600

Ethic of responsibility.. I like the way how you make an example of this, ethics deals with values of a human with respect to good and bad of the motives toward his/her actions. We are all responsible of our actions so make it good as possible always.

"Ending the Era of Patronizing Language Design" by http://www.china-phosphate.com/Products/Disodium-Phosphate-DSP.htm

Wed, 04 Jan 2012 01:22:27 -0600

disodium phosphate|sodium phosphate dibasic

"Ending the Era of Patronizing Language Design" by http://www.china-phosphate.com/Products/Disodium-Phosphate-DSP.htm

Wed, 04 Jan 2012 01:22:02 -0600

disodium phosphate|sodium phosphate dibasic

"Ending the Era of Patronizing Language Design" by http://www.china-phosphate.com/Products/Disodium-Phosphate-DSP.htm

Wed, 04 Jan 2012 01:21:37 -0600

disodium phosphate|sodium phosphate dibasic

"Ending the Era of Patronizing Language Design" by http://www.china-phosphate.com/Products/Monosodium-Phosphate-MSP.htm

Wed, 04 Jan 2012 01:19:36 -0600

monosodium phosphate suppliers!

"Ending the Era of Patronizing Language Design" by http://www.china-phosphate.com/Products/Disodium-Phosphate-DSP.htm

Wed, 04 Jan 2012 01:17:27 -0600

disodium phosphate|sodium phosphate dibasic

"Ending the Era of Patronizing Language Design" by Seattle Electrician

Mon, 02 Jan 2012 14:25:16 -0600

Article helps more people looking for comprehensive solutions.

Seattle Electrician Service, Inc. 1500 W Bertona, Seattle, WA 98119. (206) 227-3237 Seattle Electrician

"Ending the Era of Patronizing Language Design" by Dentist Carrollton

Mon, 02 Jan 2012 13:34:36 -0600

Many lessons available in this article.

Dentist Carrollton 1735 Keller Springs Rd # 204, Carrollton, TX 75006-3005

"Ending the Era of Patronizing Language Design" by Up Light

Mon, 02 Jan 2012 04:17:45 -0600

5. Having more power at your fingertips means either you will crash and burn or learn to use it!” - i agree with it.

Light Up at Onlycubes LLC is a company dedicated to serving our customers to provide with the best pricing, quick delivery, and unparalleled customer services.

"Ending the Era of Patronizing Language Design" by Womens Moncler Jackets

Mon, 02 Jan 2012 03:24:56 -0600

Everyone should have a Mens Moncler Jackets as it is the best outwear against the cold season and is also comfortable and light to wear.

"Ending the Era of Patronizing Language Design" by http://www.doorswest.net

Mon, 02 Jan 2012 02:47:25 -0600

Nice and informative post.

Doors West 1402 20th Street NW, Suite 4, Auburn 98001 (206) 772-5241 Seattle Garage Doors

"Ending the Era of Patronizing Language Design" by vacuum sealer reviews

Tue, 27 Dec 2011 16:26:53 -0600

The difference between the right word and the almost right word is really a large matter — it’s the difference between a lightning bug and the lightning. vacuum sealer reviews

"Ending the Era of Patronizing Language Design" by Securities Law

Mon, 26 Dec 2011 06:47:27 -0600

People do it all the time, but that’s cultural knowledge. If you are in a culture, you hear about all of the things which are normal which appear odd from outside. If you aren’t, you don’t.Securities Law

"Ending the Era of Patronizing Language Design" by Rug Cleaning Melbourne

Fri, 23 Dec 2011 05:01:08 -0600

You are right and I agree with you, but i believe the point of the blog post was about the language designer saying you cannot do this because it is too dangerous.

"Ending the Era of Patronizing Language Design" by Polo Outlet Online

Fri, 23 Dec 2011 01:56:00 -0600

Very honoured to see your blog, I benefited a lot from it, and it brings me a great deal of enjoyment.

"Ending the Era of Patronizing Language Design" by Bankruptcy Seattle

Wed, 07 Dec 2011 00:24:22 -0600

Many language designers make the assumption that people need to be “controlled”. Language is one of the important code in a designing

"Ending the Era of Patronizing Language Design" by Online Business Directory

Thu, 24 Nov 2011 08:08:55 -0600

Barrier broken, but at a high cost with high complexity. I much rather trust responsibility, good habits and safety nets I set up anyway to protect myself from logical mistakes. Online Business Directory

"Ending the Era of Patronizing Language Design" by optimizacija

Tue, 22 Nov 2011 07:17:02 -0600

The Contents of this site are really very good. I hope We will get this type of contents and information from this blog in future days too. Best regards. honeymoon packages

sport tours international

"Ending the Era of Patronizing Language Design" by sa

Tue, 15 Nov 2011 21:18:32 -0600

I never actually knew it was a real problem… The only difference I’ve ever had is when the server took less then I actually wrote down which I thought was weird. I would like to think I tip pretty good so this wouldn’t happen but I do check my receipts religiously just in case

"Ending the Era of Patronizing Language Design" by sa

Tue, 15 Nov 2011 21:06:22 -0600

It’s really a nice and helpful piece of information.Long time no see so excellent article