Exception to the Law of Leaky Abstractions

Question

I've had an argument with a friendly coder who was mildly damaged by Joel's Law of Leaky Abstractions. It is very hard to convince him of using any new framework/toolbox at all. I'm trying to present a point where "abstractions are fine as long as they allow low-level access to abstracted level".

Examples:

• GWT - Google's superb Java-to-Javascript compiler, has JSNI - ability to write "native" Javascript if you really want to.
• Hibernate - AFAIK has SQLQuery - way to write native SQL.
• Java - JNI - if you miss C.

Is it sound? Am I missing something?

Thanks

Answer 1

JRuby ? Jython ?

Answer 2

What I took from reading the leaky abstractions article wasn't that abstractions were bad, but that you should make it a point to understand what goes on under the hood, so that you can account for "unexpected" behavior, and avoid them.

What does your friend program in? Machine language? :)

Answer 3

While I think its true that every abstraction is leaky, that is not necessarily a bad thing.

For example in traditional plain C (C#, Java, whatever) code you usually retrieve data from arrays by using loops, ifs etc. But that way you overspecify your solution to a problem.

The way SQL, Linq approach the same problem is more intelligent: You just say WHAT you want, the machine figures out how to do it. This way it is free of any specific ordering of commands from the traditional way and can split the work onto different cpus for example, or reorder stuff to make better use of caches etc.

So yes you give some control to the machine, but the machine has one big advantage over you: It is at the user/customer's place and that way can make on-demand decisions (like using multi-core, using advantage of MMX, whatever).

Answer 4

Joel's point (as I understand it) is that by abstracting complexity away you are sacrificing the finer control over that underlying complexity. For anything but trivial cases you will eventually need to access that finer granularity of control at which point the abstraction breaks down.

So all abstractions are leaky (almost) by definition :

• If there is complexity in a system, it must be there for a reason (or you should find a way to remove it) and so will occasionally be useful/vital.
• By abstracting you are limiting the control you have over the underlying complexity.
• When those 'occasionally's come along you will have to break the abstraction.

Answer 5

To some extent he has a point. Traditional c/unix development works to a platform that is simple enough to be able to understand more-or-less in its entirety. Modern platforms are orders of magnitude more complex, and understanding how all of the layers interact is much harder, often infeasible.

The law of leaky abstractions mainly applies when the framework does a bad job of managing the underlying complexity. Some of the ways in which a framework may be judged are its transparency (ease of understanding what's going on behind the scenes) and its ability to drop out to a custom workaround for limitations in its functionality.

When a framework does a lot of complex magic behind the scenes, diagnosing and troubleshooting become much harder, often requiring a disproportionately large amount of expertise in the underlying architecture of the framework. This means that productivity gains from the framework get absorbed in the extra effort of training and debugging the code. It also makes the framework difficult to learn and use with confidence, which is what your C programming friend is used to.

When a framework obstructs you from working around its limitations, then it becomes an impediment to development. When this happens often enough, the code base is either boxed in or becomes polluted with ever greater and messier hacks to work around the issues. This also leads to stability and debugging problems,

Examples of frameworks with these flaws abound. MFC was quite famous for failing to hide the underlying complexity of Win32. It also made extensive use of wizards that generated messy code that needed to be manually modified aftwrwards, defeating the purpose of having a code generator in the first place. Early Java GUI toolkits (AWT and early versions of Swing) have very little uptake in desktop applications because they obstructed developeers from implementing a native look-and-feel for the applications. SWT was built in no small part because of these limitations with Swing.

However, now Java has matured a bit, it could be argued that most of its early sins have been fixed in modern frameworks. J2EE is still a large, complex system, and developing a non-triviall user interface in a browser is also quite a substantial undertaking. Becoming proficient in this platform is quite a lot of work. However, it's not beyond the wit of man.