Skip to main content

The History of Abstraction and Unqork's Place in that Lineage

Unqork Solutions Architect Hank Olken explains how the advent of no-code has kept him connected to his first love—solving puzzles.

I first became interested in programming because I’ve always loved solving puzzles. From jigsaw puzzles to chess and Sudoku—I felt a deep satisfaction in finding the right solution after a 10-round bout with trial and error. 

My first project in my Intro to Computer Science course required me to program a solution for making perfect pancakes. The end goal was to create a program that could determine what the diameter of the pancakes should be, how long to cook them on each side, and so on. I spent hours on this exercise, and most of that time was spent sorting out syntax. As important as breakfast foods are to me, I dreamed of solving more significant puzzles with these skills one day. However, after four years of programming in languages like Java, C++, and Python, I became frustrated with the limitations of code. I was officially ready to graduate from flapjacks and for loops.

That's when I found Unqork, a self-described "no-code" platform that was promising to leave traditional programming in the dust. I was doubtful at first, but after seeing the platform myself, I applied to work there immediately. Within my first week as a Solutions Architect, I was already creating a complex, fully-regulated institutional fund transfer application for one of the largest banks in the world. No longer did I have to spend hours translating my thoughts into onerous syntax—Unqork abstracted all of that for me which allowed me to get right down to solving the puzzle at hand.  

Abstraction Explained

Let me take a step back. "Abstraction" is a term borrowed from object-oriented programming where a programmer hides all but the relevant data about an object in order to reduce complexity and increase efficiency. But in the context of technology, abstraction refers to the process of hiding any complex underlying information behind a user-friendly interface which allows the user to focus on what they’re creating instead of worrying about how it actually happens. 

For example, writing a blog post like this would be a lot more difficult without abstraction.  To write a post, a blogger presses the keyboard keys that correspond with the letters they want to display. They only care about making words appear on the screen, not necessarily how the computer renders those words. So a keyboard abstracts the complicated processes performed by the computer to render the letters that make up a blog post. And when the post is finally written, the blogger uses another abstraction, the “Publish” button, to share their thoughts. 

Every day, abstraction allows us to easily use the complicated technologies that make our lives easier and more efficient.  

A Brief History of Abstraction in Programming

The evolution of programming languages is really a story about abstraction. In the beginning, there was only the 1st generation programming language, also known as 1GL. This was the familiar binary number strings of 0s and 1s I mentioned earlier. 1GL was a big deal—these were the machine-level languages that were used to program the first computers. 1GL was ground-breaking and efficient, as there was no compiler needed to process the instructions. Instead, you entered the language directly through front panel switches on the computer system. Still, 1GL was notoriously hard to fix and difficult for a human programmer to understand, so the next languages to come along abstracted added a layer of abstraction atop the 0s and 1s.

With second-generation languages (2GLs), coding was beginning to become more user-friendly. Lines of code could be more easily read and written by programmers, as these languages relied on letters rather than 0s and 1s. This code was then converted into a machine-readable form in a process called assembly. The good news was that code now directly responded to processor commands; the bad news was that 2GL was machine-dependent. This meant that 2GLs could only think in terms of individual instructions as opposed to higher-level logic—meaning that programmers had to manage a lot of details about memory and hardware specific to the system on which they wanted to code. In search of a more flexible situation, the next generation of programming languages became even more abstracted from 0s and 1s.

This brings us to high-level languages, or 3GLs. Languages like Fortran and COBOL removed non-essential details and abstracted code to the point where computing concepts could finally be expressed in ways that are intelligible to the programmer. And unlike 2GLs, 3GLs were much more machine-independent. 3GLs eventually evolved to include many of our staple modern programming languages like C and Java.

The Abstraction of Programming Itself

Over time, computer languages have shifted from favoring the way a computer processes information to favoring the way humans think. This has made modern programming languages easier to read, write, and maintain for those who are willing to put in the time and effort to learn these languages. Unfortunately, doing so still requires extensive training. 

But what if, instead of continually abstracting these languages, we abstracted the concept of programming itself? Doing so would make it possible for everyone—not just trained developers—to harness the creative power of programming and build complex software.

To use another everyday example, let’s think about the process of making pizza. Just as languages like Python are more user-friendly than their predecessors, a toaster oven is more user-friendly than a wood-fired oven. If the first generation of pizza-making is the wood-fired oven and raw dough, the next level of abstraction is a conventional oven that the home cook can preheat to 450 degrees before cooking a pre-assembled frozen pizza.

So what’s next—how can we make the process even more user-friendly? What if we stop trying to abstract an oven and instead abstract pizza-making itself? In this example, let’s think of no-code not as a futuristic microwave, but as a pizza vending machine that eliminates friction, improves accessibility, and ultimately gives people greater control over the finished product. 

As it stands, learning how to build software is far more difficult than making a pizza, which makes it all the more worthwhile to abstract programming for the masses. The next layer of abstraction should further humanize application development, cut through the noise associated with coding, and allow people to operate more closely with their work. The answer is no-code. 

Abstraction with Unqork

This brings us back to Unqork. Building an application with Unqork doesn’t require any coding. Instead, I’m able to use pre-built components, drag them onto a canvas, customize component settings, and preview the solutions I’m building in real time. Each individual component is itself an abstraction of hundreds of lines of underlying code.  

These abstractions in the Unqork interface means that I can perform the complex calculations and validations I am accustomed to as a programmer, but in a way that is more intuitive... and frankly, more fun for a puzzle-lover like myself.

If the ultimate purpose of code is to solve big problems, we shouldn’t get distracted by anything else. No-code has allowed me to focus the entirety of my energy on solving the puzzle at hand on a scale that I could’ve only dreamed of as a developer.