<p>Actually you have a misconception about compilers vs interpreters in the modern age. The stages of compilation (simplified) are</p>
<blockquote>
<p>Syntax Analysis (scanners - find the words and symbols and replace with internal values)</p>
<p>Structural Analysis (parsers - build a tree equivalent)</p>
<p>Optimization (maybe several stages - tree pruning etc)</p>
<p>Code Generation (output the translated code)</p>
</blockquote>
<p>The only difference between this and an interpreter is the last step. The output of the optimization code (likely still a tree but possibly an abstract machine code) is walked at execution.</p>
<p>So, it is incorrect to say that an interpreter doesn't need 'compilation'. What it doesn't need is code generation which is normally a small part of the time involved in running a compiler. The scanner takes up most of the time unless the optimizations are very sophisticated.</p>
<p>I'll leave this here for now but a simple language can be defined with a BNF. If it is LL(1) then a recursive descent parser is pretty simple. If it has few symbols then a scanner is pretty simple. Ignore optimization (null optimization). Then you can either produce a code generator for some simple abstract machine simulator that looks like machine language (a compilation) or you can directly interpret the tree output by the parser (an interpretation).</p>
<p>But no reasonable interpreter today would work directly off of the source code during the interpretation. Scanning and parsing at least are the same as in a compiler. And scanning is the slow part since a decision needs to be made at every character of the input. Actually several decisions for many.</p>
<p>I don't have a FOSS application for you, but it isn't terribly difficult to build one for a simple input language. One of the easiest is a prefix version of arithmetic, since it is easy to parse into a tree:</p>
<blockquote>
<p><code>+ 3 4</code> should yield 7</p>
<p><code>+ 3 * 4 5</code> should yield 23.</p>
</blockquote>
<p>This is <a href="https://en.wikipedia.org/wiki/Polish_notation" rel="nofollow noreferrer">Polish Notation</a>, so named since no one wanted to remember how to spell Łukasiewicz, the name of its inventor.</p>
<p>If you stick to single digit literal values (no variables) and single character operators, it is dead simple to both scan and parse. The parser is the driver and calls the scanner for the next symbol. The parser produces a tree.</p>
<p>Whether it produces an output value (an interpreter) or an executable (a compiler is up to you. The simplicity comes from the fact that machine code is also often just polish notation. But if the architecture is a stack machine with all operations done on the stack the compiler version gets a bit more complex.</p>
<p>Then the first example translates to</p>
<blockquote>
<p>push 3</p>
<p>push 4</p>
<p>add</p>
<p>print (producing 7)</p>
</blockquote>
<p>However, the value of compilation isn't obvious from this example since the scanner and parser are so trivial (hence fast).</p>
<p>But it becomes more interesting if you make the language a bit more complicated. Suppose, for example that you permit both integer and non-integer values. Now you have to distinguish between integer and floating point operations. The beauty of pre-processing is that the disambiguation needs to be done only once, whether in a compiler or interpreter, not on every pass if the operation is in a loop, for example.</p>
<p>And if you add non-literal values, such as variables, then you also probably need a symbol table. Again, process once use many in both the interpreter and the compiler.</p>
<p>The overall lesson here is that a compiler and an interpreter differ by a lot less than most people think they do.</p>
<hr />
<p>If you understand Pascal then an absolutely elegant introduction to the structure of compilers is <a href="https://rads.stackoverflow.com/amzn/click/com/0130830984" rel="nofollow noreferrer" rel="nofollow noreferrer">On Pascal Compilers</a> by Per Brinch Hansen. There aren't many CS books that can be described as literature, but this is one. Not cheap anymore, but it will be in many libraries.</p>
<hr />
<p>I also just found the following which might be suitable for a first compiler course or as the basis of a demo: <a href="http://eli-project.sourceforge.net/pascal_html/pascal-.html" rel="nofollow noreferrer">http://eli-project.sourceforge.net/pascal_html/pascal-.html</a>. I haven't had a chance to evaluate it, though. My old compiler course used something similar.</p>

CC BY-SA 4.0
2020-04-23T11:40:43.413Z
Of course an interpreted language isn't just run as is. All the steps that a compiler does are still done, but while the program - or script - is running, every time it is running, whereas with compiled software, you'd have to do the first three steps only once. Hence using an interpreted language is only practical for rather small projects. I just want to have an illustrative example for this issue.
JC_CL
CC BY-SA 4.0
2020-04-23T11:48:30.860Z
No, not true. The first steps are done only once in any modern interpreter. Remember that Pascal was often run on a p-machine.
Buffy
CC BY-SA 4.0
2020-04-23T12:07:14.150Z
I'm not an expert on that, but I'm pretty sure that you are going to do all of those steps again on your machine if I did send you mydemo.py and asked you to run it.
JC_CL
CC BY-SA 4.0
2020-04-23T12:51:21.187Z
I am an expert, actually. But if you give me source, I need to run all the steps, of course, unless the "interpreter" will export an abstract tree that I can interpret. That is how the p-machine worked. And since it was implemented on various hardware you could create the abstract tree (first three steps) and then "run" on a different architecture.
Buffy
CC BY-SA 4.0
2020-04-23T13:13:32.863Z
Actually, Java works this way too. The "compiler" outputs JVM code, which runs on an interpreter - the Java Virtual Machine. There are tools that will take the JVM code and produce real machine code for your architecture, but they are used mostly in high performance applications.
Buffy
CC BY-SA 4.0
2020-04-24T14:47:18.933Z
Your edits are really interesting and I'll use them to brush up on my knowledge, but all those details are too involved for the point I'm trying to make.
JC_CL
CC BY-SA 4.0
2020-04-23T10:42:41.387Z
2020-04-23T15:42:32.723Z
2020-06-18T08:36:57.023Z
Buffy
<p>One crazy suggestion, <em>install Python from <a href="https://www.python.org/downloads/source/" rel="nofollow noreferrer">source</a></em>. Configure time about 42 sec. and compile time either around 3 minutes, or 48 sec with <code>make -j</code>.</p>

<p>Your class will be using Python anyway, and seeing how long it takes to build from C vs. how long it takes to run <code>Hello World</code> in Python ought to begin to give them some appreciation of the differences.</p>

<hr>

<p>Otherwise, two options that I'd considered are one with a relative fast compile and the other with a longer compile.</p>

<h2>Fast compile - C source</h2>

<p>The option for a fast, but watchable, compile is <code>curl</code>, which is probably already on the system. <code>curl</code> is written in C. It is available on <a href="https://github.com/curl/curl/releases" rel="nofollow noreferrer">GitHub</a>. <code>curl</code> is released under its own <a href="https://curl.haxx.se/docs/copyright.html" rel="nofollow noreferrer">license</a> which is similar to MIT/X, but not identical. If <code>curl</code> is on the system already you can perform the <code>configure</code> and <code>make</code> commands, and then stop. The students will be able to see what goes into the process of compiling it, and you won't have to modify your system with the actual install. The original install of <code>curl</code> can be used to show what it does. Of course, once you demonstrate the speed of the binary it's nice to have a flashy result. As <code>curl</code> does not require the returned file to be rendered in a browser, you could have a simple ASCII-art file to download. Hosted on the same computer, and using the <code>127.0.0.1</code> IP would, of course, be the fastest, and best show of the difference between compile and run times. A simple demo of what could be downloaded could be <a href="https://www.gypsyspellweaver.work/hello_class" rel="nofollow noreferrer">"HELLO CLASS"</a>. <code>curl https://www.gypsyspellweaver.work/hello_class</code> or from the <a href="https://gist.githubusercontent.com/GypsySpellweaver/76a32555ac899d9034132a164f4f1c70/raw/bece7923c2b9ff2bcd0e9f52f6f2436188294119/hello_class" rel="nofollow noreferrer">Gist</a>, </p>

<p>My expirements, using an AMD FX 8300 8-core CPU, gives configure times in the one minute range and compile times in the one minute range. In both cases there shouldn't be the need to add any switches or options, and while speaking you won't have to think about <em>what options was I supposed to use?</em> for the commands. Timing your delivery around the process should be reasonably simple, and the process is fast enough to not become boring for the students to observe.</p>

<h2>Slow compile - FORTRAN source</h2>

<p>There is a project for physics (good place to look for FORTRAN programs) called <a href="https://octopus-code.org" rel="nofollow noreferrer">Octopus</a> for doing virtual experiments. Octopus is released under the <a href="https://www.gnu.org/licenses/old-licenses/gpl-2.0.txt" rel="nofollow noreferrer">GPL ver 2</a> license, and contains external libraries licensed under a variety of other OpenSource license. The current list of licenses can be found in the <a href="https://gitlab.com/octopus-code/octopus/-/blob/develop/COPYING" rel="nofollow noreferrer">GitLab</a> repository. The program does have some dependencies, all of which were easily found in my SUSE repositories for simple installation.</p>

<p>Again, using my system, I found the <code>./configure</code> command to be quite fast, typically under 30 sec. The compile time, however, was much longer, avg. of 8 min. Use of the <code>-j</code> flag on <code>make</code> was significant in this case, avg. of 3 minutes to compile. As in the <code>curl</code> case, there's no need of switches or options (unless you want to use the <code>-j</code> swwitch on <code>make</code> for the time savings.</p>

<h3>Octopus dependencies</h3>

<p>The non-optional dependencies listed on the installation <a href="https://octopus-code.org/wiki/Manual:Installation" rel="nofollow noreferrer">page</a> are:</p>

<ul>
<li>cpp (should be there already)</li>
<li>Perl (should be there already)</li>
<li><a href="http://www.tddft.org/programs/Libxc" rel="nofollow noreferrer">Libxc</a></li>
<li><a href="http://www.fftw.org/" rel="nofollow noreferrer">FFTW</a></li>
<li><a href="http://www.netlib.org/" rel="nofollow noreferrer">LAPACK &amp; BLAS</a></li>
<li><a href="http://www.gnu.org/software/gsl/" rel="nofollow noreferrer">GSL</a></li>
</ul>

<p>Since SUSE had these in their repos, I'm guessing they're likely in the repos of other major repos. Just be sure that the development packages, <code>-devel</code> or <code>-dev</code>, are installed as those include the headers needed to build other programs, such as Octopus.</p>

<p>In the case of Octopus I have no real idea what would make a fast, and simple, output for the maiden launch of the program. Their website gives a simple run to use. It involves creating an input file, always named <code>imp</code>, in the current directory and running <code>octopus</code>. The simple input file is:</p>

<pre><code>CalculationMode = gs

%Coordinates
 'H' | 0 | 0 | 0
%
</code></pre>

<p>Using that example, the best I can create for a demo is to trap the output to a log file, then display the convergence result data. <code>octopus &gt;&amp;log; cat static/convergence</code>. Using my system as a reference, the typical run time is between 1.000s and 1.025s. Changing the command to <code>octopus &gt;&amp;log; octopus &gt;&amp;log; cat static/convergence</code> so that the command runs twice, using the results of the first run to fine-tune the results of the second run, adds approx. .650s to each run. The output of the single run is a table of 9 results and the double run produces a table of one result.</p>

<hr>

<p>As a final resource, if none of these ideas work for your situation, or instructional style, you could look through the list of programs, organized by language, on <a href="https://dmoz-odp.org/Computers/Programming/Languages/" rel="nofollow noreferrer">dmoz</a>. Surely something there will work for your presentation.</p>

CC BY-SA 4.0
2020-04-24T14:44:09.067Z
That sounds like what I'm looking for! Gotta play around with it a bit first to see if it's really the answer I was looking for.
JC_CL
CC BY-SA 4.0
2020-04-24T04:31:22.147Z
2020-04-24T04:31:22.147Z
Gypsy Spellweaver
<p>I'm looking for an application that I can compile live, in class to show the students that compilation takes time, but brings speed benefits in the end, whereas interpreted languages always take time, but need no compiling.</p>

<p>Of course I can just simply compile and run some hello world (e.g. this <a href="https://en.wikibooks.org/wiki/Fortran/Hello_world" rel="nofollow noreferrer">FORTRAN version</a>), but that would just zip through in microseconds, whereas compiling, say, Firefox would take forever, involve many confusing additional steps and be way too complicated to illustrate the point (and probably fail anyways).</p>

<p>Ideally, I'm looking for an application that takes a minute to 3 (on a tad older hardware, think 5 years old i5) to compile, and really just takes one <code>gfortran -o hello hello.f90</code> like command to get started and results in a binary that I can run in terminal that produces some simple and easily visible result (A plot? Some calculator?).</p>

<p>I'd prefer fortran or C and it all should be happening on a Linux system.</p>

<p>The point of that application would not be to show anything in fortran or C, or to detail the intricacies of compiling, it's solely to show that this can take time, but generally is fast afterwards. I intend to maybe talk 5 minutes about the whole thing, about 3 of which, it'll compile in the background. The main subject of the course is teaching python, an interpreted language.</p>

<resource-request><compiling><language-types>
(FOSS) Application to show/explain compilation?
# (FOSS) Application to show/explain compilation?

(Asked by: username_0 on 2020-04-23)

I'm looking for an application that I can compile live, in class to show the students that compilation takes time, but brings speed benefits in the end, whereas interpreted languages always take time, but need no compiling.

Of course I can just simply compile and run some hello world (e.g. this [FORTRAN version](https://en.wikibooks.org/wiki/Fortran/Hello_world)), but that would just zip through in microseconds, whereas compiling, say, Firefox would take forever, involve many confusing additional steps and be way too complicated to illustrate the point (and probably fail anyways).

Ideally, I'm looking for an application that takes a minute to 3 (on a tad older hardware, think 5 years old i5) to compile, and really just takes one `gfortran -o hello hello.f90` like command to get started and results in a binary that I can run in terminal that produces some simple and easily visible result (A plot? Some calculator?).

I'd prefer fortran or C and it all should be happening on a Linux system.

The point of that application would not be to show anything in fortran or C, or to detail the intricacies of compiling, it's solely to show that this can take time, but generally is fast afterwards. I intend to maybe talk 5 minutes about the whole thing, about 3 of which, it'll compile in the background. The main subject of the course is teaching python, an interpreted language.

**Tags:** resource-request, compiling, language-types


---

## 2 answers

### Answer by username_2 on 2020-04-24. Score: 3 | Accepted answer

One crazy suggestion, install Python from source. Configure time about 42 sec. and compile time either around 3 minutes, or 48 sec with make -j.
Your class will be using Python anyway, and seeing how long it takes to build from C vs. how long it takes to run Hello World in Python ought to begin to give them some appreciation of the differences.

Otherwise, two options that I'd considered are one with a relative fast compile and the other with a longer compile.
Fast compile - C source
The option for a fast, but watchable, compile is curl, which is probably already on the system. curl is written in C. It is available on GitHub. curl is released under its own license which is similar to MIT/X, but not identical. If curl is on the system already you can perform the configure and make commands, and then stop. The students will be able to see what goes into the process of compiling it, and you won't have to modify your system with the actual install. The original install of curl can be used to show what it does. Of course, once you demonstrate the speed of the binary it's nice to have a flashy result. As curl does not require the returned file to be rendered in a browser, you could have a simple ASCII-art file to download. Hosted on the same computer, and using the 127.0.0.1 IP would, of course, be the fastest, and best show of the difference between compile and run times. A simple demo of what could be downloaded could be "HELLO CLASS". curl https://www.gypsyspellweaver.work/hello_class or from the Gist, 
My expirements, using an AMD FX 8300 8-core CPU, gives configure times in the one minute range and compile times in the one minute range. In both cases there shouldn't be the need to add any switches or options, and while speaking you won't have to think about what options was I supposed to use? for the commands. Timing your delivery around the process should be reasonably simple, and the process is fast enough to not become boring for the students to observe.
Slow compile - FORTRAN source
There is a project for physics (good place to look for FORTRAN programs) called Octopus for doing virtual experiments. Octopus is released under the GPL ver 2 license, and contains external libraries licensed under a variety of other OpenSource license. The current list of licenses can be found in the GitLab repository. The program does have some dependencies, all of which were easily found in my SUSE repositories for simple installation.
Again, using my system, I found the ./configure command to be quite fast, typically under 30 sec. The compile time, however, was much longer, avg. of 8 min. Use of the -j flag on make was significant in this case, avg. of 3 minutes to compile. As in the curl case, there's no need of switches or options (unless you want to use the -j swwitch on make for the time savings.
Octopus dependencies
The non-optional dependencies listed on the installation page are:

cpp (should be there already)
Perl (should be there already)
Libxc
FFTW
LAPACK & BLAS
GSL

Since SUSE had these in their repos, I'm guessing they're likely in the repos of other major repos. Just be sure that the development packages, -devel or -dev, are installed as those include the headers needed to build other programs, such as Octopus.
In the case of Octopus I have no real idea what would make a fast, and simple, output for the maiden launch of the program. Their website gives a simple run to use. It involves creating an input file, always named imp, in the current directory and running octopus. The simple input file is:
CalculationMode = gs

%Coordinates
 'H' | 0 | 0 | 0
%

Using that example, the best I can create for a demo is to trap the output to a log file, then display the convergence result data. octopus >&log cat static/convergence. Using my system as a reference, the typical run time is between 1.000s and 1.025s. Changing the command to octopus >&log octopus >&log cat static/convergence so that the command runs twice, using the results of the first run to fine-tune the results of the second run, adds approx. .650s to each run. The output of the single run is a table of 9 results and the double run produces a table of one result.

As a final resource, if none of these ideas work for your situation, or instructional style, you could look through the list of programs, organized by language, on dmoz. Surely something there will work for your presentation.

> **Comments:**
> **username_0**: That sounds like what I'm looking for! Gotta play around with it a bit first to see if it's really the answer I was looking for.  

---

### Answer by username_1 on 2020-04-23. Score: 1

Actually you have a misconception about compilers vs interpreters in the modern age. The stages of compilation (simplified) are

> Syntax Analysis (scanners - find the words and symbols and replace with internal values)
>
> Structural Analysis (parsers - build a tree equivalent)
>
> Optimization (maybe several stages - tree pruning etc)
>
> Code Generation (output the translated code)

The only difference between this and an interpreter is the last step. The output of the optimization code (likely still a tree but possibly an abstract machine code) is walked at execution.

So, it is incorrect to say that an interpreter doesn't need 'compilation'. What it doesn't need is code generation which is normally a small part of the time involved in running a compiler. The scanner takes up most of the time unless the optimizations are very sophisticated.

I'll leave this here for now but a simple language can be defined with a BNF. If it is LL(1) then a recursive descent parser is pretty simple. If it has few symbols then a scanner is pretty simple. Ignore optimization (null optimization). Then you can either produce a code generator for some simple abstract machine simulator that looks like machine language (a compilation) or you can directly interpret the tree output by the parser (an interpretation).

But no reasonable interpreter today would work directly off of the source code during the interpretation. Scanning and parsing at least are the same as in a compiler. And scanning is the slow part since a decision needs to be made at every character of the input. Actually several decisions for many.

I don't have a FOSS application for you, but it isn't terribly difficult to build one for a simple input language. One of the easiest is a prefix version of arithmetic, since it is easy to parse into a tree:

> `+ 3 4` should yield 7
>
> `+ 3 * 4 5` should yield 23.

This is [Polish Notation](https://en.wikipedia.org/wiki/Polish_notation), so named since no one wanted to remember how to spell Łukasiewicz, the name of its inventor.

If you stick to single digit literal values (no variables) and single character operators, it is dead simple to both scan and parse. The parser is the driver and calls the scanner for the next symbol. The parser produces a tree.

Whether it produces an output value (an interpreter) or an executable (a compiler is up to you. The simplicity comes from the fact that machine code is also often just polish notation. But if the architecture is a stack machine with all operations done on the stack the compiler version gets a bit more complex.

Then the first example translates to

> push 3
>
> push 4
>
> add
>
> print (producing 7)

However, the value of compilation isn't obvious from this example since the scanner and parser are so trivial (hence fast).

But it becomes more interesting if you make the language a bit more complicated. Suppose, for example that you permit both integer and non-integer values. Now you have to distinguish between integer and floating point operations. The beauty of pre-processing is that the disambiguation needs to be done only once, whether in a compiler or interpreter, not on every pass if the operation is in a loop, for example.

And if you add non-literal values, such as variables, then you also probably need a symbol table. Again, process once use many in both the interpreter and the compiler.

The overall lesson here is that a compiler and an interpreter differ by a lot less than most people think they do.

---

If you understand Pascal then an absolutely elegant introduction to the structure of compilers is [On Pascal Compilers](https://rads.stackoverflow.com/amzn/click/com/0130830984) by Per Brinch Hansen. There aren't many CS books that can be described as literature, but this is one. Not cheap anymore, but it will be in many libraries.

---

I also just found the following which might be suitable for a first compiler course or as the basis of a demo: <http://eli-project.sourceforge.net/pascal_html/pascal-.html>. I haven't had a chance to evaluate it, though. My old compiler course used something similar.

> **Comments:**
> **username_0**: Of course an interpreted language isn't just run as is. All the steps that a compiler does are still done, but while the program - or script - is running, every time it is running, whereas with compiled software, you'd have to do the first three steps only once. Hence using an interpreted language is only practical for rather small projects. I just want to have an illustrative example for this issue.  
> **username_1**: No, not true. The first steps are done only once in any modern interpreter. Remember that Pascal was often run on a p-machine.  
> **username_0**: I'm not an expert on that, but I'm pretty sure that you are going to do all of those steps again on your machine if I did send you mydemo.py and asked you to run it.  
> **username_1**: I am an expert, actually. But if you give me source, I need to run all the steps, of course, unless the "interpreter" will export an abstract tree that I can interpret. That is how the p-machine worked. And since it was implemented on various hardware you could create the abstract tree (first three steps) and then "run" on a different architecture.  
> **username_1**: Actually, Java works this way too. The "compiler" outputs JVM code, which runs on an interpreter - the Java Virtual Machine. There are tools that will take the JVM code and produce real machine code for your architecture, but they are used mostly in high performance applications.  
> **username_0**: Your edits are really interesting and I'll use them to brush up on my knowledge, but all those details are too involved for the point I'm trying to make.  

---

