What does it really mean to "install" a programming language?

2.2k views Asked by At

I would like to know what it means to "install" a programming language.

So far my search has yielded two conflicting answers:

  1. You don't install a programming language. You install a compiler/interpreter and then just feed it text files containing your source code. The language is, therefore, just a standardized syntax that you learn and that the compiler/interpreter is programmed to "understand". In other words, the "source" of the language is not in some file/program installed on your machine but, rather, its "source" is in the language specification, the text files that you write, and the ability of the compiler/interpreter to "work" with said files. (For example, to work with C++ you have to install a compiler but you don't install C++. Or do you?)

  2. However, it appears that some languages require to be installed. For instance, PHP documentation starts with a section titled "Installation and Configuration". Similarly, to install Python you have to first download it. Once you do, it shows up in your file system as an executable.

So what exactly does it mean to install a language? What does the installation contain? And why do some languages appear to require installations (PHP, Python), while others don't (C++)?

Thank you.

1

There are 1 answers

0
sanaris On

And why do some languages appear to require installations (PHP, Python), while others don't (C++)?

Strict view looks like that.

Compiler is just a sequence of binaries+src, same as any other software package. Take for example Clang or GCC or Rust. In your operating system, you download source and build it. Machine codes are generated for your particular Processing Unit architecture, be it CPU or GPU or specialized hardware.

It looks like this SRC=>BIN. Then the compiler is using itself to build its sources again.

SRC => BIN => SRC => BIN2

The question arises. If you require compiler to build itself, how do you build it in the first round? There is one neat part of the question, bootstrapping.

Another question is, how do you decide when to stop? You can build your compiler with different angles, focusing on 'size' or 'speed' or 'compilation time' or all of those.

Is the compiler worse when you simply never build it yourself? Yes, it will be worse, but in what terms? Most likely it will be bloated, i.e. have increased size and its compilation times will be bigger.

Also there is things outside of compiler. Having compiler on Linux means it will generate ELF binaries, so you need 'libelf'. And it requires you to obtain certain libraries first, namely 'libatomic', 'libgcc', 'libstdc++', 'mpfr', 'gmp', 'coreutils'. These libraries are making your 'environment' so you could possibly be able to build your next compiler iteration from previous (GCC in this case).

Some languages have compilers written in themselves, like PyPy. But initial python compiler will anyway require you to have C language to build initial version and to have environment of libraries.

Software is aging, meaning that newer versions of libraries and tools are being created, so the compilers should be rebuilt from source regularly with whole system rebuilt by those.

So strictly speaking, all languages require "installation" meaning user should build them from sources (Linux), or extract the codes required for their particular CPU from already existing binary (Microsoft). Or both, in some cases (Ubuntu and other binary-based linuxes).

Described above "source installation" may look complicated, but "binary installation" in fact is far more complicated for compilers, because you should check environment, check dependencies, check libraries, then check hardware, then extract binary parts, then recompile binary parts you cannot have the same (x86 vs x64) or simply ship numbers of different versions of same compiler for different architectures and architectural tricks like ELF/WINPE binary compatibility, 'setjmp' jumping conventions etc.

PS. Also not building your compiler from source hinders developers of hardware, like it was with x86 -> x86_64 architecture transition. Hardware developers are using their precious time not for actual improvement of raw power of your processor and new features, but for supporting old instruction sets and backward-compatibility of instruction sets, simply because software developers too slow to update their compilers. All of it creates huge 'lag' in the system of software-hardware cycle of development.