Beginner-friendly History: From low-level to high-level languages

Yuzhou Guo
4 min readJan 24, 2021

A brief introduction to how machine manipulates data: From a series of zeros and ones to the rules and conventions we follow nowadays, there must be history and science behind.

If you are curious about how we get this far in the computer language field, we gotta dive into history a bit 😎

Over fifty years ago…

When computer science and engineering don’t have this many terminologies, conventions and jargon, programmers talk to the hardware directly. Meaning they wrote something called machine language that machines can understand, which is not much different from waterfalls of binary strings: lines of zeros and ones.

People tried their best to invent some simple rules so that this particular language can be understood by the human side as well. Now a group of professions know how to talk with machines in a much more efficient way. This language is called assembly language which is still been widely using in today’s world.

These two languages are called low-level languages. They are hardware-specific meaning the code running on this machine can’t guarantee to be successful on another machine…

As the informatics industry grew larger and the programmable fields expanded at an exponential rate, high-level languages finally ascended on the history stage.

comparison between low and high

High-level Languages

These languages are much much closer to human language (a.k.a English) which boosts the communication between programmers as well as the abstractive software design ideas.

One of the big reasons that high-level languages are revolutionary is that, from this point on, the art of programming now has its own field called computer science or software engineering depends on where you are. Files written in high-level languages are portable, meaning they can run on any machine in the world with a helper on the side.

If you wanna know even more about the helper categories, the helpers can be roughly divided into two categories: compiler and interpreter.

There are three steps for a file to be run on a machine:

  1. Its error must be checked if any
  2. It must be translated to machine code
  3. The machine code must be executed

For a compiler, it checks the entire file. If there’s no error, the entire file will be translated to machine code. As a product, the compiler will produce an executable file so that whoever needs to run this file can run it. The compiler doesn’t touch the execution part.

Compiler:

Source code — — — — — → .exe file — — — (somebody else) — — → execution

For an interpreter, it checks the entire file line by line following these three steps:

  • Line one — No error here, translate to machine code, then immediately execute
  • Line two — No error here, translate to machine code, then immediately execute
  • ……

No extra files get produced.

Interpreter:

Source code — — — — — — — — — — — — — — — — — — — — — → execution

How they work exactly?!

As an intuitive example, a compiler is like a translation machine: once it gets the translation job done. You don’t need the compiler to be on the side anymore unless you make some modification on the source code and now retranslation is needed.

An interpreter is more like a human translator: translate the language line by line until everything is finished. No matter how many times you repeat the same interpretation, you always need the translator to be there.

Compiler vs. Interpreter

One extra perspective we can compare is that when there does exist an error in such a file, for example, in line number 10.

As soon as a compiler finds the error, it simply stops at the error checking stage and asks the programmer to double-check his/her code. Nothing will be translated and nothing will be executed.

However, since the interpreter does all three stages altogether line by line, by the time it fins the error on line ten, everything until line nine has already been executed.

Speed-wise In general, even though it takes some time for a compiler to translate from source code to executable files, it’s very fast to run the .exe on any machine. Interpreted languages are much slower from source code all the way to be executed.

There are also some languages trying to take advantage of both compiler and interpreter and ended up using a mixture of them, but that’s another topic.

Hello! My name is Yuzhou and I’m a student now studying computer science at Montreal. If you like this article and have an interest get in touch with me, please feel free to find me on my Linkedin and talk to me there :))

--

--

Yuzhou Guo

Hello there! I’m Yuzhou from Shanghai and now studying computer science at Montreal. I monthly write new articles about software development and algorithms.