I hate cars and the lawmakers who govern their use. Speed limits hinder my progress; if I think it’s safe to do 100mph along some road, I should be allowed to. Seat belts, urgh! Don’t get me started on how uncomfortable and restrictive they are. I think it’s patronizing for car makers to fit new cars with airbags. What kind of moron is going to drive into something that will necessitate an air bag? Like the rest of the population, I consider myself an above average driver. So I can get out of difficult situations without crashing, I can make fast progress safely and avoid all the obstacles. Also, the car manufactures restrict the type of fuel I can put in the car. Obviously, they don’t realise that sometimes one kind of fuel is cheaper than the other. Who are they to dictate to me what kind of fuel I should use?
Except that..
…I can’t avoid all crashes. Sure, more times than not, I’m a perfectly safe driver, regardless of what speed I’m doing or the road conditions or other situations. But there are two very good reasons why I need all those safety features.
- Sometimes, I’m an idiot
- Everyone else is also sometimes an idiot
This little rant is in response to a couple of articles that have been bugging me recently. Namely; Patronizing Language Design and Steve Yegge’s Java/Wikileaks article.
Now, I don’t know either of those other authors. The only thing I know about them is that they are both probably way more clever than me. They’ve probably forgotten more great stuff than I’ll ever know. Steve Yegge’s article in particular seems like it’s written as a comedy piece, but like all good comedy there’s a degree of truth hidden inside it. I’ve not had a sense of humor amputation, I laughed and smiled about it as much as the next programmer. However I do take issue the two premises that appear in these articles.
- Programming languages should allow any programmer to do whatever they want, and it’s the programmers responsibility to be safe
- Object Orientated design, particularly in Java, forces developers to only use certain software components in known ways and that’s a restrictive and bad thing
Patronizing Programming Languages
Preventing programmers from doing ‘more complicated’ things is just a kind of seat belt. Or maybe a better analogy is that of a speed-limiter as fitted to most trucks and vans these days. (At least, in the UK.) Think back to all the programmers you’ve ever worked with, all the WTF articles you’ve read. Aren’t you kind of glad that some of those developers weren’t driving a lot faster when they crashed? Particularly if it was you they crashed into!
The first article claims that even with more difficult language features available, an increase in program crashes has not been seen. I don’t have access to his data so I can’t verify that claim. My gut tells me though that this just can’t be the case. If you took all the programs written in so-called ‘safe’ languages and rewrote them in ‘un-safe’ ones, I’m convinced that you’d see an increase in the number of nasty crashes.
I’d be interested to visit an alternative reality and see what some of the enormous Java software projects that l’ve worked on look like when written in some less ‘patronizing’ language.
The phrase “enough rope to hang yourself with” comes to mind. Sure, you can hang yourself in ‘safe’ languages such as Java, C# etc. But that’s about it. Introduce language features that give you even more rope and you could probably tie up and hang the entire town. Neither outlook is pretty, but the differences in scale can’t be ignored. Obviously, I’m not saying that this always going to happen, but I would argue that the occurrences of it happening would be greater – and messier.
Doing Whatever You Want To Do
I think that’s it’s fair to say that most of us write programs that are difficult or impossible (at least, according to our individual skill sets) to formally reason about. This means that testing the behaviour of our software is limited to testing it in way we think that it’s going to be used – with some additional edge/exception cases thrown in for good measure.
In my opinion, the gripe about Java programs hiding implementation with final and non-public modifiers is more a gripe about Object Orientated design than about Java specifically. (And goodness knows, I’ve moaned about Java enough!) I just can’t get away from the fact that it is appropriate for some software components to be hidden away; other people may well want to use them in ways that they were not intended.
Ideally, any given class can be extended and have it’s non-private members overridden with predictable results. Hopefully, such things are tested or at least well enough documented to allow other developers to not break anything else. Opening up everything inside every class places an enormous burden of testing on the original developer; how can they possibly verify that if any of the internal code changes (because it has been overwritten) that the rest of the code will behave in the same expected manor.
You just have to ready any “How/Why Do I Do OO?” book or article to see why we encapsulate and hide data/functionality. If you really really need some functionality which is private or final then the correct solution is to petition the vendor and ask for an API change. (Good luck with that!) To me, the Java/Wikileaks article should be more targeted at bad API design and less about abolishing final/private in any particular language.
Programming is not just about design-test-code, whatever language or silver bullet you’re using right now. It’s also about support. Making every possibly software component open to use (and abuse) is just asking for a support nightmare. I would hazard a guess that the response to most support tickets would be closed with phrases like “Your computer caught fire because you overrode this method and you didn’t do something which the original method did” or “You lost £1,000,000 in business because you used that method which is not designed to be used in such a way”.
My car manufacturer says I should only put diesel in my particular car. They’ve left the choice on whether or not I keep that restriction up to me, although it has to be said that they have not documented the repercussions of disobeying them very well in the car handbook. I’m also not holding my breathe for any free support or fix if I do disregard their rules. Now obviously, as a sensible person, I wouldn’t put unleaded, water, Lucozade or anything else in my fuel tank, but there is nothing physically stopping me. But what happens one day when I’m day-dreaming whilst filling up and accidentally pick up the wrong pump? After I’ve paid the expensive bill to get my car fixed, I bet that I wished that there was some physical restriction stopping me from doing the wrong thing. Even though I’d never made that kind of mistake before!
Remind me again why physical restrictions against accidental (or idiotic) mistakes are a bad thing. Remind me again why an API designer hiding certain things from my code is a bad idea.
Summary
You might currently work only with brilliant people, but remember that not everyone does. Every few months (or weeks) a new article is released about how education and training in this country or that is going down the tubes. The bar to entry of the Programming Profession is already pretty low and seems to be getting lower. Keeping ‘difficult’ things away from the majority of those programmers, to me, seems like a good idea.1 I don’t let my kids play with sharp knives, but as they grow and move onto different meals (i.e. programming projects) different sets of cutlery (i.e. tools, languages, language features) will be introduced and they’ll be taught to use them. But only if I consider their aptitude sufficient enough to wield them safely. Even though some companies have very stringent hiring and interview practices, bad programmers still get jobs!
Programmers should lock their APIs down to a handful of known places which makes sense. Then they can predicate what their users are going to do and help them do that. Some programmers are going to complain that because of those restrictions they can’t do this or that with your API. That complaining is okay. Making everything open is just asking from trouble. Not from you, the reader, obviously. You’re an above-average programmer who doesn’t make mistakes. But restrictive APIs are designed to protect software against programmers like me; you know, the human ones who do make mistakes.
1 Either that, or raise the bar to entry a bit more!
