In the previous installment, we saw a list of types of tool used in a development environment, a bit about the purpose of the Text Editor, and a list of existing gratis text editors for several platforms.
After you have the source code, (i.e. text files describing what your software is supposed to do in a particular language), you still can’t execute it. One of the tools that help you make your code executable is the interpreter.
The interpreter is a tool which understands a particular programming language and can execute the instructions. So, if your source code states that a picture should be shown on-screen, the interpreter shows the picture.
Basically, it’s a program which you ask to run through your file and do what your file states should be done. Many programming languages have interpreters, and sometimes a single programming language can have many interpreters. Some languages can only be worked on with interpreters; those are called, rather unsurprisingly, interpreted languages.
An interpreter usually contains either a lot of functionality, the capacity to use external libraries to provide a lot of functionality, or both.
A short list of gratis interpreters follows:
- python; As well as being the name of the programming language (Python), the interpreter is called python. This naming is typically used for the old version, i.e. Python 2.x
- python3.5; that’s the name of the latest (as of today) stable Python interpreter for the 3.x version of the language.
- IronPython; an interpreter for the python 2.x language which uses the .Net CLR
- perl; it’s an interpreter for the perl programming language
- racket; an interpreter for the racket progamming language
- lispy; an interpreter for a LISP written in python
As you can see, it’s common to have the interpreter executable and the programming language share a name, and there can be several interpreters for the same programming language. This is because the interpreter provides the facilities for the code to run; different interpreters can provide different facilities for the same code to perform the same function across diverse conditions, like different installed Operating Systems.
Unlike with the text editor, each tool of this step is built to work with a particular programming language. It is so because the tool needs to know about the language to be able to understand the source code, but the text editor needs only to understand text input and how to store plain text files.
Usually, the interpreter has no output. There are two notable situations in which you have output:
- Generating output is the interpreted program’s intent, which means it’s the program’s output even if it’s generated through the facilities provided by the interpreter
- Things go wrong; in which case you get error messages
Things can go wrong in many ways, but chiefly:
- a mistake was made when writing the program’s text, such as a typo
- a rule of the programming language was broken
- the nature of the program being run makes it not work properly (for example, having a loop that never ends and never does something productive), in which case it’s not a problem directly related to the interpreter but to the written program
This track of the toolkit (editor -> interpreter) doesn’t have any more dependencies to produce running software. Just the text editor and the interpreter. If an interpreter can run in several platforms (as is often the case), it’s very likely that the same code can run in those same platforms. Other tools can be used on the code and running program, like the debugger or the static code analyzer. Those tools will be covered in a few days.
Tomorrow, we will cover the compiler.