A Thought on Abstraction

Posted on May, 19 2016

What makes technology easier to deal with?

To answer this question, look no further than the most popular technology to deal with: The Web

The Web (HTML, CSS, JS) accomplishes the great feat of providing a standardized paradigm for delivering functionality to end users, i.e. web browsers. For any given platform with a web browser that implements the same standards, the page should function in a similar way to other platforms.

The good news here is that for the most part this is indeed true. The mechanism behind this great feat is accredited to abstraction. When writing software for web browsers, the particular machine that will eventually render the code written is not within the scope of concerns; due to the assumption that the web browser rendering the current page follows the standards set in place by web browsers.

Web Pages are a great example of a domain specific abstraction. In english, this means that the standards set in place by the web browser are limited to establishing a way to define a structure (HTML), style the structure (CSS), and modify the structure (JS). Beyond the specified standards for the web, and you've gone too far- you're in open waters.

When you're in open waters, the abstraction begins to fade and what you're left with is what every aspiring software developer is afraid of: What translates the abstraction to the machine itself.

Granted, at every level you are faced with abstraction. When you're writing in C, you're abstracting away machine code. When you're writing in assembly, the instruction opcodes are abstracted away. When you're manually writing instructions byte-by-byte, virtual addresses are abstracted away, etc.

Eventually you reach a point of no return, where there is no abstraction and all that is left is the atomic laws that compose themselves into what you're looking at right now to read this blog post. For each level you strip away the abstraction, the more you can engineer on a specific platform for speed, memory consumption, and the list goes on.

The issue people run into is the level of understanding on each platform that is needed to solve the same problem, or in the worst case the complete incompatibility of the abstraction in respect to the problem at hand. Utilizing abstraction to cover a large 'surface area' of platforms is a trade off between the extent you can engineer using the abstraction vs. how well the abstraction preforms vs. the amount of things you can do using the abstraction:

Q = ( Supported Platforms ) + ( Performance ) + ( Range )

where Q is an unknown universal constant

Depending on the domain of the problems you're trying to solve using the abstraction, you can get a wide range of supported platforms and performance, with the sacrifice of the complexity of the problems you can solve with the abstraction. Alternatively, you can get optimal performance and freedom, with the sacrifice of the number of supported platforms.

Abstraction is everywhere in computing. Classifying abstractions using this made-up constraint in respect to the problem you're trying to solve using the abstraction can help you give insight to what to use.