An age old dilemma is whether you should learn the higher level abstraction first, or whether you should learn the foundation first and only move onto the abstraction over the foundation afterwards.
Joel Spolsky’s classic blog post from 2002 tells us:
“All non-trivial abstractions, to some degree, are leaky.” – Spolsky
So there is always a benefit to learning the lower level foundation first. But this can be time consuming, and perhaps it is holding back the progress we have made over the years. Is it a throwback to the past?
This is a topic that has been argued over pretty much ever since. In 2006, Ryan Bemrose argued that an 80/20 rule applies:
“Abstractions are still very useful. They make things easier for the 80% case and improve efficiency. But when designing your abstraction, be careful that you don’t also disable the 20% case in the process.” – Bemrose
Jeff Atwood covered the topic with a LINQ to SQL focused blog post in 2009.
Jon Sonmez followed up with Leaky Abstractions are holding us back in 2013.
So when should we learn the abstraction first and when should we learn the foundation first?
Universities are particularly good at teaching the fundamentals. In my first year of university I learned functional programming using SML, and low level programming using MIPS assembly in my first semester. At the time I didn’t enjoy it very much, I just wanted to learn C and Java, which I had to wait for. It’s only after working professionally for a number of years that I’ve come to appreciate the importance of learning those fundamentals.
But I have said before and will again that you don’t necessarily need to have studied Computer Science academically to be a good software engineer. I know plenty of developers who are self taught and talented and super productive without any study of C++ or Assembly. But doesn’t this contradict the law? How can this be?
“The LAW of leaky abstractions. Any time somebody couches an observation about software development as a LAW, you know something fishy is going on.” – Katz, RailsConf 2014
The leakiness of different abstractions vary enormously. With .NET, how often do you need to go down to understanding the IL code? In most industries, very rarely. I would say that the core .NET Framework makes things easier a lot more than 80% of the time. Probably more than 99%. But having an understanding of the basic mechanics of a PC, the stack, the heap, address spaces, virtual memory etc. those things are still pretty important and will remain so for a long time.
And then there are many higher level APIs that are built on top of the .NET Framework. For example ASP.NET Webforms is great to start off with, allowing you to mostly drag and drop your way to building a simple application in hours or even minutes. But once you need to build a large and complex enterprise application, the leaks can be expensive and painful.
The “painful” example linked above is an actual memory leak. The law of leaky abstractions applies much more generally than that, but it is still a valid scenario. You could say that we have a leak caused by a leak! Note that the problem here exists at the Framework level, so knowing C/C++ or Assembler won’t help, rather it was an understanding of the fundamentals of memory allocations, along with knowledge of the abstraction that diagnosed the problem.
With jQuery, there will be times when it leaks. This doesn’t mean that it isn’t a good piece of software. It’s a great piece of software. Most of the problems are due to the numerous browser incompatibilities which jQuery generally does a good job of abstracting over. There are also problems with poor performance due to naive use due to beginner programmers not understanding the fundamentals.
Recently there have been an increasing number of blog posts warning of similar pitfalls with Angular JS.
“Too many frameworks fall into an all-too-common trap: they make it easy to get started quickly, which is great, and then make it very hard to maintain and extend your code over time. That part’s not so great.” – James Shore
So, my advice is learn both. Learn the basics of the abstraction and the basics of the foundation, then move on to learning intermediate level knowledge of the abstraction while also gradually learning the foundation better. That way, if you find a leak, you won’t be far away from the plumbing knowledge you need to fix your problem.
Living with leaks
xkcd: fields arranged by purity (abstractions considered unpure)
One thought on “Chicken or Egg? Foundation or Abstraction?”
Pingback: Why Do We Need Software Craftmanship? | Zombie Code Kill