Many people who start studying Computer Science (CS) often complain, “There is way too much to memorize.” However, in my view, a vast majority of CS concepts actually derive from a few core meta-concepts.
It might be difficult to grasp or fully appreciate what I mean right away, but keeping these meta-concepts in mind will serve as a powerful compass throughout your CS journey.
1. Abstraction
Many concepts and software systems in Computer Science can be viewed as a massive stack of abstractions layered on top of one another. Therefore, having a clear understanding of what abstraction means will be beneficial.
If I were to sum up abstraction in a single sentence, it would be: The process (or result) of stripping away unnecessary details and leaving only the essential core. Depending on your perspective, you might focus on “removing the useless stuff” or “extracting what is important.” Either way, the essence remains the same: retaining only what matters.
So, what determines what is “essential”? I use a simple criterion: “Is this strictly required to solve the problem at hand?”
Let’s say a retail store needs to solve the problem of ‘calculating total daily sales’. To solve this, you absolutely need data that allows you to calculate daily revenue. If the total sales amount is already pre-calculated by date, you simply print that out, and you are done. If not, you will need data like daily sales volume per product, unit prices, and discount rates at the time of sale. Conversely, if all you care about is total daily revenue, the specific product names, shapes, or colors are completely irrelevant.
Therefore, the input data for this problem only includes parameters necessary to compute the sales amount—such as unit price, quantity sold, and discount rate. The process of taking a complex real-world entity—the “store’s merchandise”—and leaving behind only the core data required to compute revenue is abstraction.
Even for the same store, if the problem becomes ‘tracking inventory status,’ the price is no longer important. Instead, the product name or Product ID (to distinguish items) and the remaining quantity in the warehouse become crucial. If a new requirement is added—“allow a human worker to cross-check physical inventory with the records”—only then do physical traits like shape, size, or color become important.
Using abstraction also makes it easier to interact with mechanical devices. When we drive a car to get to a destination, we only need to interact with a steering wheel, accelerator, brake, and gear shifter. How the pistons move inside the engine or what percentage the tire slip ratio is at any given moment is irrelevant to the driver. From the automobile manufacturer’s perspective, they only need to provide a clean interface (wheel, pedals, gear) without needing to reveal the intricate driving mechanisms underneath. This is thanks to abstracting a complex machine into a simple interface suited for the single purpose of “driving.”
Abstraction simplifies problems by hiding or eliminating details. This not only makes problems easier to solve, but it also generalizes them. In other words, one can reuse a solution developed for one problem to solve other similar problems.
The control mechanism I just mentioned—steering wheel, accelerator, brake—can be applied almost identically to motorcycles, bicycles, and even electric scooters. Aside from minor variations like twisting a handle or pushing a pedal, the fundamental essence—“change direction, speed up, stop”—remains identical.
Programming languages like Python and JavaScript are also abstractions of computer programs. To run a program, you originally had to write complex machine code and manually upload code and data into specific memory addresses. Programming languages hide all these low-level details, exposing only the essential core required for humans to instruct a machine.
When buying a computer, you carefully check CPU models, RAM capacity, cache sizes, and SSD speeds. Yet, when writing high-level code, you don’t need to worry about these specific hardware specifications every time. That is the power of abstraction.
So far, we have mainly discussed abstracting problem inputs, but abstracting outputs is equally vital. A car’s dashboard presents only essential information—such as current speed and remaining fuel level—so the driver can make immediate decisions. The dashboard provides actionable insights: whether to speed up, slow down, or pull into a gas station. The precise air-fuel ratio inside the engine cylinders is critical to the vehicle’s operation. Still, because the driver cannot directly adjust it while driving, it is omitted from the dashboard.
In summary, abstraction simplifies immediate problems to help us find solutions, while granting us the flexibility, leverage, and scalability to solve broader classes of problems.
2. Implementation
The direct antonym of abstraction would be concretization. However, in the software world, where we instruct computers to solve problems, we more commonly use the word implementation.
Implementation is the process (or the result) of making an abstracted problem solvable by a computer, or making an abstracted system behave as intended.
While the abstraction phase removes details to define WHAT needs to be done, the implementation phase must focus on HOW the computer should execute it. Naturally, implementation demands attention to detail. During this process, you often go through a stage of concretization, deciding on the details that were ignored or removed during abstraction.
Let’s revisit the daily sales revenue problem. For currencies that do not use fractional units, using a sufficiently large integer type seems sufficient. However, for currencies like the US Dollar where fractional values are frequent, using integer types alone won’t work.
Thus, the problem “calculate daily sales revenue” is concretized during implementation into “calculate daily sales revenue for integer-only currencies” or “calculate daily sales revenue in USD.”
Because physical computers are finite machines, an abstraction that assumes infinity or unconstrained real-world conditions may lack a direct implementation. In such cases, it is wise to refine the abstraction to make it realistically implementable.
To make thinking easier, developers sometimes leave the abstraction untouched while accepting the limitations of the implementation. In this scenario, however, the user of the abstraction must be aware of the implementation details—or at least its limitations. This phenomenon is known as a Leaky Abstraction.
In the daily sales problem, if you decide to handle USD using standard double-precision floating-point types (so-called double types) instead of integers, you will encounter bizarre bugs. In floating-point arithmetic, 0.1 + 0.2 does not equal 0.3. double format uses binary fractions for speed and range; however, numbers like 0.1 and 0.2 in decimal become infinite repeating fractions in binary, introducing rounding errors that accumulate during operations.
Therefore, instead of checking equality with a == b, you must use logic that checks if the difference stays within an acceptable margin of error, such as abs(a - b) < epsilon. For USD, you must also format the output to two decimal places so that tables don’t break visually. If you prefer exact arithmetic similar to integer logic, you must use a dedicated Decimal type or find another method.
This issue is a classic leaky abstraction, caused by abstracting USD as an infinite real number while implementing it with finite binary floating-point numbers. Furthermore, because computers are finite, they cannot store or handle arbitrarily large numbers. Thus, the maximum allowable sales volume will vary depending on how you implement the daily sales calculator.
While you could leave sales volume abstracted simply as a “number,” it is far better to refine the abstraction (e.g., “a number up to 1 trillion”) to eliminate leaky abstractions as much as possible. This benefits the user of the abstraction, as they don’t need to worry about extra implementation details, and it keeps abstraction and implementation decoupled, making it easy to swap in a different implementation later.
Implementations are written as programs to run on computers, but in most cases, they are built by utilizing lower-level abstractions. Computer programs are rarely written in raw machine code loaded directly into bare memory; they are written in high-level languages and executed as processes abstracted by an operating system.
Double-precision floating-point format itself can be viewed as an abstraction. At a primitive level, a digital computer is merely a machine that processes 0s and 1s; building a floating-point type is simply creating an abstraction by grouping those bits together.
For an abstraction to function, it requires an implementation, which in turn relies on lower-level abstractions. Consequently, software architecture takes the form of multiple layers of abstractions stacked on top of one another. For example, Python forms a layered structure of abstraction and implementation like this:
The Python language itself can be viewed as an abstraction. The program that executes Python code isn’t limited to CPython (distributed by python.org); there is also PyPy, a well-known implementation written in Python. In other words, Python has more than one implementation.
Whether it is CPython or PyPy, the executable file is built on the assumption that it runs on an operating system like Windows, Linux, or macOS. That is, the Python compiler/interpreter is implemented using system calls and standard libraries provided by the given OS.
Windows is built assuming it runs on hardware conforming to the Standard PC Platform (an evolution of the IBM PC AT spec). macOS is designed to run exclusively on Macintosh. Linux is implemented to run across a vast array of computer architectures—not only PCs and Macs, but also single-board computers (SBCs) like the Raspberry Pi. Since the lower layer of Android OS is SE Linux, it also runs smoothly on Android-compatible devices. Each OS implements its system calls under the assumption that it operates on an abstracted computer defined by specific hardware specs.
The Standard PC platform initially used only x86 CPUs, but was later expanded to support ARM CPUs. Android devices primarily use ARM CPUs, though some use x86. Macintosh computers have historically transitioned across MC68000, PowerPC, and x86 CPUs, and recently shifted to Apple Silicon (ARM) exclusively. Linux has implementations running on a diverse range of CPUs, including x86 and ARM.
When multiple abstraction layers exist, lower-level details are usually hidden from upper layers, but not always. While OS abstractions hide I/O devices and storage hardware from executable binaries, they cannot entirely hide the CPU architecture because executables consist of machine code. Therefore, to install a Python interpreter, you need to know not only the target OS, but also the underlying CPU architecture.
3. Indirection
When a single abstraction can have two or more implementations, placing an intermediate connection point, rather than hardcoding a specific implementation to the abstraction, allows you to switch implementations as needed.
For instance, if both CPython and PyPy are installed on your system, the python command file doesn’t need to be a standalone executable binary. Instead, it can be a symbolic link pointing to either the CPython or PyPy executable. This makes it effortless to switch between running CPython or PyPy when invoking the python command.
This approach—referencing a value or resource through a mediator (such as a name, pointer, link, or container) rather than mentioning it directly—is called Indirection.
Indirection allows you to swap out or upgrade implementations without modifying the code that uses the abstraction, making systems much easier to change and improve. However, there are several caveats to keep in mind when using indirection:
- Prevent Infinite Loops: You must ensure that chained indirections do not form an infinite loop. Passing responsibility through indirection often means offloading details outside the scope of the abstraction. If everyone keeps offloading unwanted details, you end up with a scenario where no one actually handles the work. To prevent this, define a strict direction for abstractions and indirections—for example, enforcing that indirection only points downward to lower layers—so loops cannot form.
- Align Lifetimes: You must align the lifespans of the indirecting party and the target being referenced. If the target disappears first, following the indirection leads to nothing—resulting in a dangling reference. Conversely, if the indirecting party vanishes while the target remains in memory doing nothing, it wastes system resources as garbage.
4. Effective Decomposition
So far, we have discussed abstraction, implementation, and indirection as meta-concepts in CS. What they all have in common is that they relate to dividing and breaking down a given problem. They are methods for separating the important from the unimportant, tackling core issues while leaving details out, and placing a comfortable distance between a problem and its solution to make it easier to manage.
An important perspective we haven’t considered yet is: How, in what direction, and how granularly should we break down a problem to be effective? This is what we call Effective Decomposition.
Simply breaking a problem into tiny pieces does not automatically make it easier to solve. Decomposition is only effective if the complexity of the smaller sub-problems is significantly reduced. If the cost of solving a problem as a single monolith is lower than the cost of breaking it down and solving the pieces, there is no reason to decompose it. Furthermore, you must be able to combine the sub-answers into a solution for the original problem without incurring excessive overhead. Therefore, how, in which direction, and how much you decompose a problem is crucial.
In an Algorithms course, the section on Divide-and-Conquer teaches you how to calculate overall computational costs based on the expense of dividing and combining problems. In Software Engineering, metrics like Coupling and Cohesion are used to measure how well modules are separated and arranged. Ideally, separated components should have zero correlation; thus, various mathematical tools, including linear algebra, are employed to decouple systems into independent or orthogonal elements. In database design, data is separated through a process called Normalization.
Conclusion & Motivation
We have taken a broad look at the meta-concepts of Computer Science. These concepts are not isolated pieces of knowledge confined to a single course or programming language. They are meta-concepts for managing complexity, developed by generations of computer scientists striving to solve complex real-world problems using finite machines called computers.
Whenever you encounter a new subject, concept, framework, or programming language in the future, asking yourself the following questions may prove helpful:
- What is this abstracting? What details does it hide, and what does it consider essential?
- How is this abstract model implemented in reality? Are there real-world constraints that break the assumptions of the abstraction?
- What indirection was introduced to achieve flexibility? Could this indirection ever become a point of failure?
- How was the problem decomposed? Could it have been split in a different direction or along a different boundary?
In fact, these meta-concepts are not directly taught in the computer science curriculum. Instead, they have been taught by guiding students to recognize them on their own through repeated exposure to similar concepts across various subjects. I believe these concepts are difficult to explain because they are hard to convey in natural language and have a considerably wide range of applications. Therefore, they have been taught by inducing implicit learning through examples and analogies rather than through explicit explanations.
In an article titled “Is abstraction the key to computing?“ published in the April 2007 issue of CACM, Professor Jeff Kramer argued that what separates better students who are clearly able to handle complexity and to produce elegant models and designs from average ones is “the ability to perform abstract thinking and to exhibit abstraction skills.” In short, he emphasized that abstraction is the foundational concept in CS education. He also noted that “mathematics is an excellent vehicle for teaching abstract thinking.” In my opinion, other engineering disciplines also tend to teach abstract thinking and decomposition using mathematics.
However, recently, there are people who, far from being ashamed of their inability to perform even basic arithmetic properly, actually consider it a matter of course. Some give up trying to understand just by looking at mathematical symbols, and there are even cases where they reject mathematics itself.
Furthermore, with the development of video lectures, it seems that the number of students requiring explanations that feel as if they are being spoon-fed has increased.
That is why I wrote this article: to try explaining these meta-concepts directly in plain language even if I couldn’t quite bring myself to spoon-feed every detail. Ironically, quite a few people seem to view Computer Science as a major suitable for those who aren’t good at math, science, or engineering—even though Computer Science literally has “compute” in its name and is a science of computation, deeply rooted in mathematics.
Since many people tend to underestimate CS, I thought that explaining these meta-concepts through the familiar lens of computers and software engineering might help readers accept them easily and without prejudice.
It may feel vague or ambiguous at first glance. However, looking at detailed technical topics through this broader structural lens will make your studies far more engaging and rewarding.
Key Takeaways
- Abstraction: The process (or result) of stripping away unnecessary details to leave only the core elements required to solve a problem.
- Implementation: The process of concretizing an abstracted problem so a finite real-world computer can execute it. During this stage, details inevitably leak out, causing a Leaky Abstraction.
- Indirection: Referencing values or targets through an intermediate layer rather than directly. It gives the overall system structure flexibility and adaptability.
- Effective Decomposition: Breaking down a problem strategically so that the sub-problems have lower complexity and the cost of combining their solutions remains minimal.