Leaky Abstractions Are Holding Us Back

Let's just get right into it, shall we?



WHAT IS AN ABSTRACTION?




Before we can talk about leaky abstractions, and why they are bad, let's define what exactly an abstraction is.



AN ABSTRACTION IS WHEN WE TAKE A COMPLICATED THING AND WE MAKE IT SIMPLER BY GENERALIZING IT BASED ON THE WAY WE ARE USING OR TALKING ABOUT THAT THING.



We do this all the time. Our brains work by creating abstractions so that we can deal with vast amounts of information.



We don't say "my Dell Inspiron 2676 with 2 GB of RAM and a 512 GB hard drive, serial number 12398ASD." Instead we say simply "my computer."



IN PROGRAMMING, ABSTRACTIONS LET US THINK AT HIGHER LEVELS. We create abstractions when we give a bunch of lines of code that get the username and password out of a textbox and log the user into our system, a name; login. And we use abstractions when we utilize APIs or write to the "file system."



Without abstractions we'd have a really hard time managing the complexity of any software system. WITHOUT ABSTRACTIONS, IT WOULD BE PRETTY DIFFICULT TO WRITE ANY KIND OF NON-TRIVIAL APPLICATION.



If you want to feel what it is like to program with fewer abstractions, try serving up a web page with assembly code. If you want to feel what it is like to program with almost no abstractions, do the same exercise, but write your code in machine code0s and 1s.



HOW DO ABSTRACTIONS "LEAK?"



Abstractions leak when you have to understand the lower level concept to use the higher level concept.



This means THE DETAILS OF THE LOWER LEVEL CONCEPT THAT ARE BEING ABSTRACTED AWAY ARE LEAKING UP THROUGH THE HIGHER LEVEL CONCEPT.



Ever get a cryptic error message when an application you are using crashes? That is a leaky abstraction.



"Memory location 00FFE133 could not be written to" is just bad news. It means that in order to understand what is going wrong with your application, you now have to understand the inner workings of the application. Your abstraction has effectively "leaked."



Abstractions leak whenever you are forced to pull back the curtains and see the gnomes running in hamster wheels spinning the cogs.



WHY "LEAKING" IS BAD



I'm often surprised when I hear someone say "I like how you didn't hide the details of what is really going on" about some code or some technology.



Not being able to hide the details of what is really going on points to an inability to create the proper abstraction, which in my opinion, should be water tight.



It is not a good thing that we can see what is really going on. No, it is actually a very bad thing, because it forces us to think at the higher level some of the time, but have to switch gears to drop down to the lower level some of the time.



LEAKY ABSTRACTIONS PREVENT US FROM BEING ABLE TO COMFORTABLY DRIVE THE KIDS TO SCHOOL; WE HAVE TO CONSTANTLY KEEP LOOKING IN OUR REAR VIEW MIRROR AND CHECKING TO SEE IF THOSE ROWDY KIDS WHO INSIST ON SITTING AT THE BACK OF THE BUS ARE CAUSING TROUBLE AGAIN.



A good abstraction hides the details so well that we don't ever have to think about them. A good abstraction is like a sturdy step on a ladder, it allows us to build another step above us and climb up it. A leaky abstraction is like a wobbly rotted wood rung; put too much weight on it and you'll fall through--it traps you at the current step--you can't go any higher.



SHOULDN'T WE UNDERSTAND HOW THINGS REALLY WORK?



No! Stop already! Enough with the guilt trips and unnecessary burdens. You are defeating the purpose of abstractions and stunting further growth.



You only "need" to know the details if you want or need to know the details.



I know that many people WANT to know how things really work, myself included for many things, but in many cases I don't need to understand how things really work.



For example, I can buy and use a watch without understanding how the watch works. It really is better that way. I don't need those details floating around in my head. I get no benefit from knowing what is going on inside my watch and frankly, I don't want to know.



Personally, I have a similar view on cars, although I know that many other people don't, so that is why I didn't use it as my first example.



When I buy a car, I just want to drive it. I don't want to remember when to rotate tires, check fluids, etc. Waste of my time. I don't want to know how the engine works or anything about it besides I have to put gas in, turn a key, and press a few pedals to make the thing go. I know I could save money servicing my own car, but you know what? I'd rather pay money than have to do it myself. And since that is the case, as long as I can find someone I trust to work on my car, I don't want that abstraction to leak.



The same with machine code and compilers. YES, IT IS INTERESTING TO UNDERSTAND HOW MEMORY MAPPING AND CPUS AND LOGIC GATES WORK AND HOW MY C# CODE GETS COMPILED INTO MSIL WHICH IS INTERPRETED BY THE CLR AND SO FORTH AND SO ON, UNTIL IT ENDS UP AS ELECTRONS OPERATING ON REGISTERS IN MY CPU. AND I LEARNED ABOUT HOW MUCH OF THAT WORKS, BECAUSE I WAS INTERESTED, BUT LET'S BE COMPLETELY HONEST HERE. THAT ABSTRACTION IS REALLY GOOD. IT IS SO GOOD AND SO AIR-TIGHT, THAT I DON'T NEED TO KNOW ALL OF THAT CRAP IN ORDER TO WRITE A WEB APP. If I did, I'd probably find another profession, because my brain would explode every time I tried to write the simplest piece of code.



By the way, if you do want to understand what is happening behind many of those abstractions, I highly recommend Charles Petzold's book: (This is the kind of book you read for "fun," not because you need to know this information.)



LEAKING ABSTRACTIONS IN TECHNOLOGY



Too many technologies and frameworks today are leaky, and this is bad- really bad.



Want an example? Whatever happened to ORM (Object Relational Mapping?)



Nothing. Nothing happened. It was invented, oh, like thousands of years ago and while lots of other technologies and frameworks grew up and got jobs and left the nest, ORM is still a fat unemployed balding 30 year old man playing WOW all day in his mum and dad's basement.



Don't get me wrong. I use ORMS; I sometimes like to think I like ORMS. But, I CAN'T USE THEM WELL BECAUSE I HAVE TO UNDERSTAND SQL AND WHAT IS GOING ON IN MY RELATIONAL DATABASES ANYWAY. WHAT GOOD IS THAT?!



Seriously. This is a completely failed abstraction. The leakiness of it makes it actually more work to learn an ORM framework, because in learning one you must also learn hairy details of SQL and understand what N+1 means and so on. You can't just fire up your ORM and put in the Konami code, you have to blow the cartridge out and fiddle with the reset button half a dozen times. Useless.



The other major example that is holding us back today is MV* in JavaScript. Look, . I'm actually starting to like JavaScript, but it is total bullcrap that in order to write a single page web application today, you have to understand 500 other different technologies and how JavaScript is working under the covers. If we are going to do MV* in JavaScript- and I am actually starting to become a believer in this truth--then we gotta seal up the abstraction and put what we need into the language or the DOM or the technology stack itself. BOLTING THINGS ON TO CREATE ABSTRACTIONS THAT ARE ULTIMATELY LEAKY WORKS FOR NOW, BUT IT IS LIKE THAT ROTTEN CREAKY STEP IN THE LADDER, EVENTUALLY WE ARE GOING TO FALL THROUGH IT AND WE AREN'T GOING TO BE ABLE TO CLIMB ANY HIGHER UNTIL WE REPLACE THAT STEP.



I used to be convinced replacing that step meant getting rid of JavaScript and using something else superior that does what we want, but maybe it just means making JavaScript and browser APIs themselves evolve. I don't care how we do it, but we aren't going to advance until we do.



I could go on and on with examples of leaky abstractions in technology and how they are holding us back, but I think you get the point by now.



Leaky abstractions are bad. They don't do anything good for us besides require us to know more and add more points where things can go wrong. We've got to seal up these abstractions, if we want to be able to keep climbing the software development ladder. You can't keep building a tower if you have to worry about every single block beneath you. You eventually get to a point where you can't keep it all straight and your tower comes crashing to the floor.



LEAKY ABSTRACTIONS AND YOU



So, what can you do about it?



Not much as far as ORMs and JavaScript. But, next time you write some code, seriously think about whether or not you are creating a leaky abstraction.



YOU REALLY HAVE TO MAKE A CHOICE. AM I GOING TO HIDE THE DETAILS SO THAT NO ONE NEEDS TO KNOW ABOUT THEM, OR AM I GOING TO EXPOSE THE WHOLE THING? Either make a really good abstraction that doesn't require someone using your code to understand what is going on underneath that abstraction or don't attempt to make an abstraction at all.



It takes more effort to create good abstractions. Sometimes the effort required is orders of magnitude greater. But, if other people are going to use your abstraction, to save the mental burden of understanding what is happening beneath it is going to go a long way in making up for your extra effort.



10 STEPS TO LEARN ANYTHING QUICKLY COURSE



By the way, I just released by 100% .If you want free access to it, just .It is a totally free video course and optional workbook that reveals the process I use to quickly learn technologies.



The post appeared first on .
Full Post