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 latin shoes

Tue, 22 Jun 2010 04:49:03 -0500

Thanks for sharing the information.It is definitely going to help me some time

"Ending the Era of Patronizing Language Design" by jewellery

Tue, 22 Jun 2010 04:46:02 -0500

I surfed here through Google! Great job.

"Ending the Era of Patronizing Language Design" by Sten

Sun, 13 Jun 2010 12:00:59 -0500

Yes. Yes. Yes. Thank you. I can’t stand it when people make you use “final” ... just in case somebody, somewhere, was going to abuse your non-final class down the lines. Hogwash.

"Ending the Era of Patronizing Language Design" by guy who hates blanket rules

Sat, 22 May 2010 15:06:19 -0500

Well, I’ve seen prescriptive advice in the Ruby community. And it’s about something you almost touch on, with closures: methods as a first class object.

I asked about Ruby’s “method” method, which detaches a method from its object so you can pass it around, just like a lambda. I got a swift and strong berating from the Ruby community on IRC as to “how you should use the language the way it was intended”.

So tell me, IRC smugnuts, if it’s not intended, why is it there?

In my experience, the Ruby community has the worst of the holier-than-thou attitude about the right and wrong ways to write code.

"Ending the Era of Patronizing Language Design" by magice

Fri, 21 May 2010 18:20:40 -0500

sign

Talking about shamelessness.

In this age of “library is everything,” talking about personal responsibility is no more than a joke. It’s like movies and novels depicting a guys going into a forest alone, with a big gun, a car, modern clothes, shooting down everything, and then talking shit about he (almost always he) not needing modernity and other people (yeah right, what’s on your hand?)

Let’s think about it. If you want personal responsibility, why don’t you implement your own stuffs? Manage your own memory? Why do you keep on screaming about this language (actually, this implementation of this language) lacks XML parser or some exotic shit that Ruby or Python happens to provide? I have not looked at Ruby that closely, but Python shines as a good example: people essentially don’t know what to do outside of the provided framework. There’s only one way to do it, remember? Where does responsibility come from? Heaven?

On the other hand, typing, restriction, etc. represent discipline. No, those Rubyists and Pythonians want none. Why? Because “it’s all about ME,” or, “I WANT IT THIS WAY”. Yeah right. Like how people talks shit about their “freedom” to throw insults at people. Or how teenagers want to be “unique” and “creative” and dumb as shit.

So much on responsibility.

"Ending the Era of Patronizing Language Design" by parça TL kontör

Fri, 09 Apr 2010 09:35:04 -0500

I like This site! Thank you for your information

"Ending the Era of Patronizing Language Design" by FLV extractor

Thu, 08 Apr 2010 01:34:40 -0500

???? ...........

"Ending the Era of Patronizing Language Design" by loz

Sat, 10 Oct 2009 09:32:50 -0500

?????

"Ending the Era of Patronizing Language Design" by PT

Mon, 05 Oct 2009 01:55:34 -0500

1. Yes I agree… what nonsense, nonsense I say!!!

2. The mistakes made by BRILLIANT people in designing languages such as C++ were not mistakes at the time, just reflective of a point in time

3. Shooting yourself in the foot is a good way to teach yourself not to!

4. Programs evolve, someone else’s mess is another’s masterpiece (e.g: the Linux kernel!)

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

6. Though after having said all of this, you wouldn’t rock climb on a cliff without a harness, not as a novice anyway!! first you need to understand the risks, then proceed accordingly.

To Conclude: You have a point (but there is also merit in providing safety nets, as others have also mentioned!)

"Ending the Era of Patronizing Language Design" by PFar

Tue, 15 Sep 2009 15:39:24 -0500

@Michael. Brilliant blog post by the way. Well done.

"Ending the Era of Patronizing Language Design" by PFar

Tue, 15 Sep 2009 15:38:19 -0500

@”Roxy and Elsewhere”

You stated that you don’t like the author’s statement on ActiveRecord. But you did not state * why * you don’t like his statement.

Please enlighten the rest of us on why you take exception to his characterization.

"Ending the Era of Patronizing Language Design" by Roxy and Elsewhere

Thu, 13 Aug 2009 18:37:46 -0500

“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.”

Although I could agree with some of the point if the article, in the right contexts, the statement above has so much wrong with it, I just can’t take the author seriously. Indeed, the irony that such an uninformed statement was made in an article about freedom and being wise enough to wield it is thicker than Oatmeal.

"Ending the Era of Patronizing Language Design" by Samuel A. Falvo II

Tue, 11 Aug 2009 23:08:27 -0500

Grubert writes, “I mean, if you’ve got your types well defined, how many hard-to-debug errors will result because someone passed in an Address parameter object rather then an Account parameter object?”

As a professional software engineer who has worked with all variety of type-safe and dynamically-typed languages, A* *LOT.

I’ve seen this happen all-too-often, and ESPECIALLY by people who, like you, feel they don’t need type-safety in their languages.

Indeed, those who prefer type safety in their languages are the LEAST likely to make such mistakes.

Grubert continues, “And how stupid would that programmer need to be to make such an error?”

Not stupid at all. Many of them have degrees one could only dream of acquiring—physics, electrical engineering, discrete or analytic maths, etc. in addition to their comp-sci or comp-eng degrees.

But, more importantly, these people often have been in the field for decades. Like me.

So don’t even go there.

"Ending the Era of Patronizing Language Design" by artsrc

Mon, 27 Jul 2009 23:04:13 -0500

I am convinced.

Who can doubt that goto use and misuse were common when Djikstra wrote, and is rare today. Culture has changed. So Djikstra can be right (then), and be wrong (now). Cost of the goto feature has declined.

For a collection of projects there is a return:

Return = Value – Effort

A goto language feature has a positive or negative effect on return for a collection of projects – programs and teams. The sign of the effect on return for a feature usually depends on the collection of projects.

One characterization of a powerful feature is one with high costs in misuse and high benefits with use.

The combination of education to effect culture, and power in features, is an approach which is recognized to have higher return now, than in the past.

"Ending the Era of Patronizing Language Design" by http://tradeskillsllc.blogspot.com

Thu, 23 Jul 2009 09:45:29 -0500

What are the critical thinking ethics learning tools to teach kids how to avoid organized crime through the course of their lives?

The wheel of Buddhist terms poster modular wall mural game. Doctoral dissertation for philosophy, title: The Interpenetration of Buddhist Practice and Classroom Teaching. Technocracy Ethics USA censorship Chinese military intelligence genius clones

"Ending the Era of Patronizing Language Design" by Grubert

Wed, 22 Jul 2009 21:10:51 -0500

Static type languages feel safer to the corporate IT managers. They imagine the type system will force the coders to cooperate, that the compiler will do the managing work for them.

But a strong type system doesn’t really prevent that many bugs, it just feels like it should. Most non-trivial bugs are algorithmic. I used to think a large-developer-count project should always use a static type language, now I’m not so sure.

I mean, if you’ve got your types well defined, how many hard-to-debug errors will result because someone passed in an Address parameter object rather then an Account parameter object? And how stupid would that programmer need to be to make such an error?

I just finished a substantial project in Python, and now I think that OOP and design patterns are not all that essential when you’ve got first class functions, closures and dynamic typing. I can spot a Java programmer doing Python a mile away, it’s all classes! :)

"Ending the Era of Patronizing Language Design" by PeterC

Fri, 17 Jul 2009 06:45:06 -0500

C is a language that assumes the programmer is responsible and will “do the right thing.” However, widespread use of C (and C++ in a C-like way) is a major source of buffer overflow vulnerabilities. The evidence is that programmers are not really all that “responsible” in the sense that oversights and errors are common.

I’ve used the dynamic languages (Python) for certain things and it is possible to rapidly build programs that work with them. However, I wonder if anyone has used a dynamic language for a really large program… such as 10 million lines of code created by 100 programmers spread of 5 different organizations. I also wonder if anyone has dared using a dynamic language in a safety critical application. Would you feel comfortable flying in a plane with Ruby code controlling the instruments?

On the other end of the spectrum is something like SPARK Ada. SPARK is a very limited subset of Ada with many constraints in what is and is not allowed. What do you get for this? You get the ability to statically prove that your code conforms to specified pre and post conditions. Note: statically prove.

"Ending the Era of Patronizing Language Design" by Steve Py

Wed, 15 Jul 2009 22:05:23 -0500

It’s human nature. If we could all just accept something as being the “best” option at a given time and focus our energy on it there would be a lot less time, money, and energy wasted in the world. One software development language, one spoken language, one standard of measurements, etc. etc. etc. (So Socialist of me, but one application development language, one web development language, one database…)

Put the energy into improving the tool, not reinventing the wheel every time the trend points out that there may just be a “better way”.

Heck, let’s just start small and agree on one, or at most two screw heads! Phillips vs. Slot vs. Robertson vs. Hex vs. Torque vs…. ENOUGH! At least get rid of Slot. Just re-brand the damned things as paint can openers and be done with it.

"Ending the Era of Patronizing Language Design" by Michael Feathers

Wed, 15 Jul 2009 17:19:32 -0500

Offh: I wasn’t saying that I don’t see the need for pointers, but rather that they can be constrained in managed memory environments. I spend a lot of time in C and I know that you do have to touch the metal at times. The trick is separating out those cases where you need to to that from the cases where you don’t.

"Ending the Era of Patronizing Language Design" by 0ffh

Tue, 14 Jul 2009 20:10:32 -0500

Michael: Just so! If you do systems programming, for example (as I do for part of my living): There you often need some way to directly access specific memory locations – and pointers are the fastest and most convenient way to do this. When I code other stuff, I try to avoid them (unless they’re just too convenient to resist, hehe).

"Ending the Era of Patronizing Language Design" by 0ffh

Tue, 14 Jul 2009 20:02:09 -0500

yup: the programmer can fix the language, but the language cannot fix the programmer =)

"Ending the Era of Patronizing Language Design" by Michael Feathers

Tue, 14 Jul 2009 15:26:29 -0500

Laurent: I knew someone would bring up that point. Although, I thought their example would be pointers rather than goto. Frankly, I think goto is okay to have in a language for the odd cases when you feel you have to use it. Raw pointers in a managed memory language, on the other hand, are a harder issue. The question is really whether you can do anything useful with them.

"Ending the Era of Patronizing Language Design" by Wedge

Tue, 14 Jul 2009 15:14:56 -0500

Excellent!

I think it does come back to different cultures and different priorities and different ideas about responsibility. Some folks are very concerned with childproofing languages. But at best this helps only the lowest tier of developers, almost always at the cost of hamstringing the language for more advanced users, if for no other reason than that the language developers are wasting a lot of time on this rather than other features. Java is very much a blub language through and through, and it shows in the concentration on childproofing over capability or elegance. C# is somewhere in between but leaning heavily away from childproofness and more and more toward elegance, power, conciseness, etc.

Java is the Xanax of languages, it’s got some nifty features that remove a lot of pain from, say, C++ development, but it’s so hemmed in with childproofing that trying to do anything of value in the language becomes frustrating and cumbersome very quickly.

Languages should very much be designed to guide programmers into a “pit of success”, but attempting to design a language such that it’s impossible to write bad code is itself an impossible task. No matter how safe, how clear, how well-designed a language is there will always be a way to misuse it horribly. You can’t baby programmers as if they were children, and you can’t make the world a 100% safe place. The world is messy, complicated, and dangerous. And it takes serious tools wielded by experienced, responsible craftspeople in order to build anything of value in such a world.

Look at any construction site, there are nail guns, hammers, saws, concrete, generators, compressed flammable gas, high ledges, etc. Imagine if all the tools of a construction worker were childproofed to such a degree that they could not injure themselves or others no matter how hard they tried. Such tools would be useless. Instead, the tools have reasonable safety measures put in place that are just enough so that responsible operators don’t have to fear for their safety yet not too much so that the tools are completely useless.

"Ending the Era of Patronizing Language Design" by Laurent

Tue, 14 Jul 2009 14:39:22 -0500

Michael,

Reading this, I immediately though of Dijkstra’s “Go To Statement Considered Harmful”.

Are you saying that you disagree with that?

"Ending the Era of Patronizing Language Design" by Hans

Tue, 14 Jul 2009 13:26:37 -0500

Magice: “In my opinion, Python out-javas Java in the department of restricting the programmers.”

How, exactly? Python is more restrictive than Lisp, and the community can be pedantic sometimes, but I fail to see how Python-the-language restricts the programmer more than Java.

The only thing I can think of is the significant whitespace issue. Other than that, Python doesn’t have all of the balls-and-chains that Java does. It doesn’t require the public/private/protected/static/final/etc hodgepodge, there’s no silly one-class-per-file rule, it has actual introspection, you can add/delete an object’s attributes at runtime, no checked exceptions, etc. Not to mention that it doesn’t have the static typing straightjacket. ... So what exactly does Python have that supposedly makes it restrictive, compared to Java?