---
description: 05/06/2021 • 20 minutes to read
---

# \[1.0] Language Processors

## Compilers

There are two main types of language processors, compilers and interpreters. The compiler's job is to take a source program written in one language -- typically referred to as the _source_ language -- and translate it into another language, typically much lower-level, such as Assembly or Common Intermediate Language - the _target_ language (see fig. 1). \
&#x20;       One of the main features of a compiler that is often overlooked is the ability to appropriately report any errors that are found during the translation process to the user.

<div align="center"><img src="https://2672771087-files.gitbook.io/~/files/v0/b/gitbook-legacy-files/o/assets%2F-MZIKsr7SRbZdC9diYtD%2F-MZzGCqjJRMs_kq7-CEv%2F-MZzGpKeXY620P6w21c5%2FExample%20One.png?alt=media&#x26;token=f7ad49f2-a19d-441a-9799-75a99d1f17f8" alt="(Figure 1)"></div>

&#x20;                                                 source code -> compiler -> binary code -> executable \
&#x20;                                                                 user-input -> executable -> output\
The example above shows the process of source code to executable using a compiler, then a user input to output. This output could be text or a whole application.&#x20;

## Interpreters

An interpreter is another type of language processor we'll talk about. However, I won't focus too heavily on interpreters, I'd just like to give you an idea of them.  Contrary to a compiler, an interpreter simply takes source code, translates it, then executes it on the spot, instead of generating or emitting an executable to disk. &#x20;

![(Figure 2)](https://2672771087-files.gitbook.io/~/files/v0/b/gitbook-legacy-files/o/assets%2F-MZIKsr7SRbZdC9diYtD%2F-MZzjnKPPgXjU7TMrmFo%2F-MZzn4qaqNVSdLtOfxwo%2FExample%20Two\(1\).png?alt=media\&token=f2890b20-135a-45b6-89b2-2677f6455a29)

You may be looking at this saying "now wait a minute, I thought there was no executable with interpreters?", and you're right for thinking that, but this isn't the type of executable you're thinking of, it's an _executor_, simply put, your translated source code still has to be output somewhere, but where? That's when the executor kicks in, the executor outputs your interpreters' results somewhere. A good example of this would be JavaScript code in the browser.&#x20;

> Note - another great example of executors is with REPLs (Read-Evaluate-Print-Loop), the executor will handle printing your output to the console.

## Hybrid Compilers

The last example we'll be looking at is slightly more complex. If you've ever used C# then you know that "dll" files are produced alongside your "exe" file, that's because .NET executables are merely a dummy file that initiates the .NET Runtime to Just-in-Time Compile (JIT) your program using a Virtual Machine. Java does the same thing with the Java Virtual Machine (JVM), compiling your source code into what's known as _bytecode_, and for C# it would be Common Intermediate Language (CIL). The process of compiling these low-level languages into machine code is much _much_ faster because it's known as an "Immediate Representation" and is very close to a one-to-one translation.&#x20;

![(Figure 3)](https://2672771087-files.gitbook.io/~/files/v0/b/gitbook-legacy-files/o/assets%2F-MZIKsr7SRbZdC9diYtD%2F-MZzjnKPPgXjU7TMrmFo%2F-MZzmuvqFCRzPar-pUBq%2FExample%20Three.png?alt=media\&token=8d1f5612-4691-4c98-982c-cf80b1cbfa8c)

If you're confused as to why these languages create yet _another_ layer of abstraction then you're not alone. The reason is cross-platform support, not all platforms/operating systems support the same instruction set, it's the job of the Just-in-Time Compiler and Runtime to handle converting the "Intermediate Representation" into machine code for the computer to execute natively. Languages such as C/C++ oftentimes need to modify their source code to compile for a different platform because not all code is cross-platform when you don't have a Virtual Machine to execute on.&#x20;
