What programming languages are commonly used for web development?

[fog37]

TL;DR Summary

understand the difference between shell, console, terminal

dkdkd

 

[FactChecker]

A shell is a software system that allows a person to give commands to the operating system. It has a language and syntax that allows the user to give commands, one at a time on a command line or in a "script program".
A console is the hardware that commands can be entered at a keyboard and printed computer output displayed.
A terminal (see correction) is the logical device that allows a program to read/write to a console keyboard/display. A program that is writing to a "terminal" might actually have its output redirected to a file where the printed output can be looked at or processed later.
See https://www.hanselman.com/blog/whats-the-difference-between-a-console-a-terminal-and-a-shell

CORRECTION: I usually interpret "terminal" as the direct, interactive interface with the user. So warnings and error messages go to the terminal for actions during a run, among other things. I think of STDIN and STDOUT as the logical interfaces for normal input/output of text, which can be redirected from/to a file. But I do not know if this is the common interpretation.

 

[fog37]

• Is a specific shell able to establish an interactive session with different interpreters or it specific to a single interpreter? The Python interpreter can be accessed via the IDLE (a shell, code editor and also GUI) but also via the Windows command line interface shell after typing "python" at the Windows prompt. This should mean that different shells can connect with the same interpreter. Another example: the CLI and Powershell are two different Windows shells connecting to two different interpreters but both interpreter's goal is to communicate with the OS, correct?
• In computer programming, an interpreter is a specific program that translates source code into machine code. But cmd.ex and powershell.exe are also called interpreters...

 

[PeterDonis]

@fog37 you appear to be confusing yourself by getting hung up on terminology that actually isn't even relevant.

The Python interpreter is a program. Specifically, it is a program that interprets and runs Python code. The Python code can be contained in a file, or it can be typed in by the user in an interactive session.

IDLE is a program. Specifically, it is a GUI program that runs an interactive session with a Python interpreter, and adds some other bells and whistles.

What you are calling the "Windows command line interface shell" could be two things, either the "Command Prompt" program or Powershell. Those are two different programs that allow you to do a bunch of things (but a different set of things for each program) by typing commands at their prompts; a fair number of those things do involve "communicating with the OS", yes. However, both of them include, in the things they allow you to do, running programs by typing their names at the prompt (and many things that you are thinking of as "communicating with the OS" are actually just running programs by typing their names, where the programs do some kind of communication with the OS, but there is no requirement that all programs whose names you type in do things like that).

"python" is the name of a program, the Python interpreter; typing its name at the command prompt starts an interactive session with the interpreter.

 

[fog37]

@fog37 you appear to be confusing yourself by getting hung up on terminology that actually isn't even relevant.

The Python interpreter is a program. Specifically, it is a program that interprets and runs Python code. The Python code can be contained in a file, or it can be typed in by the user in an interactive session.

IDLE is a program. Specifically, it is a GUI program that runs an interactive session with a Python interpreter, and adds some other bells and whistles.

What you are calling the "Windows command line interface shell" could be two things, either the "Command Prompt" program or Powershell. Those are two different programs that allow you to do a bunch of things (but a different set of things for each program) by typing commands at their prompts; a fair number of those things do involve "communicating with the OS", yes. However, both of them include, in the things they allow you to do, running programs by typing their names at the prompt (and many things that you are thinking of as "communicating with the OS" are actually just running programs by typing their names, where the programs do some kind of communication with the OS, but there is no requirement that all programs whose names you type in do things like that).

"python" is the name of a program, the Python interpreter; typing its name at the command prompt starts an interactive session with the interpreter.

Thanks as always. Just reading about different shells for Linux and getting carried away trying to understand how the terms are used...

I guess the term "interpreter" is used for programs that sit in the middle between the user and the operating system.

In the context of computer languages: user's source code via a shell ->interpreter->OS.
In the context of shell programs like the CLI: user instructions via a shell->interpreter->OS.

 

[PeterDonis]

I guess the term "interpreter" is used for programs that sit in the middle between the user and the operating system.

Not really, no. The term "interpreter" means a program that implements a programming language, such as Python, by running statements or evaluating expressions one at a time, in open-ended fashion (i.e., the interpreter can go on interpreting code indefinitely), as opposed to programming languages, such as C, where you have to pre-package all the code you want to run in source code files, and then programs like compilers and linkers run that turn those source code files into a separate executable program.

It is perfectly possible to use an interpreter, such as the Python interpreter, to do things other than talk to the operating system; and it is perfectly possible to write code in a language like C that gets turned into an executable program that talks to the operating system--indeed, that is exactly what standard Unix utility programs like "ls" are.

 

[anorlunda]

There are multiple meanings. For example, the Shell script in Unix interprets command lines and runs programs. Python is one of the programs that can be run. So we have interpreters on top of interpreters.

I agree with others that you should not put a lot of importance on the exact meaning of such words. The reasons why we use these words is often tradition and history, not necessarily logic.

 

[PeterDonis]

For example, the Shell script in Unix interprets command lines and runs programs.

Yes, by the definition of "interpreter" I gave, every "shell" program--bash in Unix, "Command Prompt" and Powershell in Windows--is an interpreter.

 

[pbuk]

A console is the hardware that commands can be entered at a keyboard and printed computer output displayed.

But it can also mean the same as a shell or terminal, e.g.

console.log('This is displayed in the console (if you have it open)');

A terminal (see correction) is the logical device that allows a program to read/write to a console keyboard/display.

But it can also mean the same as a shell or console, e.g.

The Linux command line is a text interface to your computer. Often referred to as the shell, terminal, console, prompt or various other names...

Want to take your skeptical back now ?

 

[FactChecker]

But it can also mean the same as a shell or terminal, e.g.

console.log('This is displayed in the console (if you have it open)');

But it can also mean the same as a shell or console, e.g.

Wrong. A shell is not a console or terminal. There is the Bourne shell, the Korn shell, the C shell, the Bash shell, and others (see e.g. https://en.wikipedia.org/wiki/Bourne_shell )

Want to take your skeptical back now ?

No.

 

[pbuk]

There is the Bourne shell, the Korn shell, the C shell, the Bash shell, and others (see e.g. https://en.wikipedia.org/wiki/Bourne_shell )
No.

Yes, these are all examples of the use of the word 'shell' - there is also the PS4 console, the Nintendo console, an electrical terminal, a ferry terminal, GNOME terminal, KDE Konsole, Windows Powershell etc. but I don't think this is relevant here.

My point is that shell, terminal, console, prompt, command line, cli etc. can all be used to refer to the same thing.

 

[FactChecker]

Yes, these are all examples of the use of the word 'shell' - there is also the PS4 console, the Nintendo console, an electrical terminal, a ferry terminal, GNOME terminal, KDE Konsole, Windows Powershell etc. but I don't think this is relevant here.

My point is that shell, terminal, console, prompt, command line, cli etc. can all be used to refer to the same thing.

They are all the type of thing that is referred to by the term"shell" in the world of computer programming. I have never seen "shell" used to refer to a terminal or a type of terminal and I would consider it an incorrect use of the word.

 

[PeterDonis]

@FactChecker, since you've already admitted this...

I do not know if this is the common interpretation.

...you should not be making dogmatic claims like this...

Wrong.

All of the terms being thrown around in this thread have multiple usages.

 

[PeterDonis]

I would consider the use of "shell" to refer to a terminal as incorrect. Do you think that use is common?

No, but the use of "terminal" to refer to the shell program that is running instead of to the hardware keyboard + monitor is not uncommon. ("Terminal" is also used in Unix to refer to the tty driver that the shell gets its standard input and output from, which might not even correspond to a physical keyboard + monitor.) And that usage is what @pbuk was referring to in the quote you called "wrong".

 

[PeterDonis]

Moderator's note: Some off topic posts have been deleted.

 

[FactChecker]

No, but the use of "terminal" to refer to the shell program that is running instead of to the hardware keyboard + monitor is not uncommon. ("Terminal" is also used in Unix to refer to the tty driver that the shell gets its standard input and output from, which might not even correspond to a physical keyboard + monitor.) And that usage is what @pbuk was referring to in the quote you called "wrong".

Good point. Just to be clear, the console is the hardware with the keyboard and display. The term "terminal" might refer to the console or to the tty driver software that receives the typed input. A person might say input at the console or terminal without distinguishing between the two. On the other hand, a "shell" provides a command user interface to the operating system. It is software. It is not a specific application like a text editor or a spreadsheet. If a person says "Type xxx to the shell", he is implying that an 'xxx' typed at the console keyboard is going directly to the shell software, rather than to an application like a word processor.

 

[PeterDonis]

the console is the hardware with the keyboard and display

Even that is not always the case; @pbuk in post #9 gave an example where it's a text screen that outputs messages (the browser's debug console). I believe there are other programming languages as well where "console" means something like "shell".

a "shell" provides a command user interface to the operating system

That's one of the things a shell can do, but by no means the only one.

It is software. It is not a specific application like a text editor or a spreadsheet.

Sorry, but I disagree. A shell is an application like a text editor or a spreadsheet. It's just an application with different functions than a text editor or a spreadsheet.

If a person says "Type xxx to the shell", he is implying that an 'xxx' typed at the console keyboard is going directly to the shell software, rather than to an application like a word processor.

Here you are simply wrong. As above, a shell is an application. There is no difference, as far as the operating system is concerned, between your keystrokes going to the shell and them going to a word processor or a spreadsheet. To the OS they are both applications. When a person says "type xxx to the shell", he simply means "open the shell application and type xxx". In Windows, the shell application is Command Prompt or Powershell; in Unix it might be bash or ksh or zsh or any of a number of other applications.

Don't be confused by the fact that it is possible to boot your computer in "text mode", where you end up at the prompt of a shell program. (Actually, I haven't done this with any Windows version since Windows 95, so I don't know how straightforward it is in current Windows versions. In Linux you can usually do it by booting into "advanced" mode or whatever your particular distro calls it, or by reconfiguring your computer to boot in text mode instead of GUI mode.) The shell program is still an application even in this mode.

 

[FactChecker]

A shell is an application like a text editor or a spreadsheet.

When a person says "Type 'xxx' to the shell", he means it is going to the shell. When he says "Type 'xxx' to the text editor", he means it is going to the text editor. When he types "Type 'xxx' at the terminal." it is context-dependent on where it is going. It could be going to the shell, a text editor, or to many other software applications. A terminal is not a shell, or a text editor.
Regarding the term "application", typically the term "application programmer" does not include programmers who are developing the shells.

 

[PeterDonis]

When a person says "Type 'xxx' to the shell", he means it is going to the shell. When he says "Type 'xxx' to the text editor", he means it is going to the text editor.

Yes, but both of these, the shell and the text editor, are applications. There is no such thing as typing text and not having it go to some application.

When he types "Type 'xxx' at the terminal." it is context-dependent on where it is going.

If by "terminal" you mean "keyboard", yes, the text being typed will go to whichever application currently has the foreground.

A terminal is not a shell, or a text editor. Period.

Again, you should not be dogmatic about this since the term "terminal" can be used to refer to the shell, i.e., to a particular type of application, as has already been pointed out in post #14. It would be nice if everyone always used particular terms with a single, precise meaning, but that's just not what actually happens. The distinction between the physical keyboard, the software driver that processes input from the keyboard, and the application program that receives the keystrokes, is certainly important (as is the analogous distinction between the physical monitor that displays output, the software driver that tells the monitor what to output based on commands from applications, and the applications themselves, which "draw" to an abstract representation of a screen), but the unfortunate fact is that there is not a single agreed term that always gets used for any of these things.

 

[PeterDonis]

the term "terminal" can be used to refer to the shell, i.e., to a particular type of application, as has already been pointed out in post #14

Btw, for those of us old enough to remember dialup connections, "terminal" was also used back then to refer to the application that you used to manage dialup connections. Early versions of Windows even called that application "Terminal".

 

[Filip Larsen]

The different names obviously have different origins going back to 1980 and before, and thus somewhat different meanings that perhaps today has been "watered out" a bit by the normal language weathering process and the changes computers and their input/output devices has been through.

For instance, I would say "shell" has origin as meaning a prompting and scripting engine under Unix (i.e. Unix shell with shell scripts) while the terminal or console originally was a physical device for human input/output.

And in my young days around 1980, "terminal" was used as a general term while system console (for a multi-user computer at least) was a terminal (e.g. a TTY) with special functions or privileges. For me, even today, "terminal" indicate input/output capability, while "console" indicate special function/privileges.

 

[pbuk]

At the risk of adding yet more confusion to the multiple technical meaning of these words, it is perhaps worth noting that when you open a Command Prompt or Powershell window in Windows you open an application which provides a character-based interface to the operating system.

When you open what is usually called a terminal window in most Linux GUI desktop environments you open two applications:

1. a shell application which reads and writes to streams of character data and interacts with the operating system
2. a terminal application which reads and writes to the shell's streams and interacts with the keyboard and display

The end result is the same: a window where you can type commands at the keyboard to interact with the operating system and to run character-based applications. As far as the end user is concerned this similarity is what is important rather than any technical, historical or etymological differences.

 

[Rive]

I've also seen many different usage for these terms. As I use them is like this:

- shell is the program itself which allows the interaction with the OS: interprets the (text based) commands and executes them: lays between the text and the OS
- console is the actual interface between the user and the shell, producing text data for the shell from user input
- terminal is a special, remote console running on a different system than the shell it is connected to and the focus is kind of the communication towards the remote shell, like through network, some kind of serial line or so

 

[anorlunda]

@Filip Larsen reminded me. The authoritative source for all such questions is The Hacker's Dictionary. Almost all the definitions originated in the MIT Multics project from the 60s.

Curiously, the dictionary has no definition for terminal but it does have this.

The Original Hacker's Dictionary also has no entry for terminal, but it has many for different kinds of terminals.

As you can see, a long list (truncated here) of acronyms still used today originate from use of terminals.

I am a great admirer of Multics. Every time I look into it, I am astounded at how many software issues, and software culture were strongly influenced by Multics. Ken Thompson and Dennis Richie were both Multics alumni when they created Unix.

 

[fog37]

Thanks everyone. Just to summarize, broadly speaking, there are two types of software:

1. system software (operating system (same as the kernel), device drivers, utility software)
2. application software (Python, Word, Photoshop, etc.)

• Shells are interactive programs that make interacting with the kernel (i.e.OS) easier and provide a environment and interface for programs to use. For example, the same shell can be used to run Python or another interpreter.
• In general, is it correct to say that shells run interpreters? Is an interpreter any program converting user commands into instructions for the OS? Does every application program have to have an interpreter running under the hood every time the application is running? For example, when using a word processor, we don't need to run a shell. But is there an interpreter running somewhere?
• Which application programs are designed to always need a shell to run? Programs like Photoshop, etc. are executable files that we can launch by either clicking on an icon or by typing a command inside a shell.

In sequence:
user uses the shell -> the application program is run and interacts with the shell -> shell interacts with the OS/kernel (via the interpreter?)

Terminal vs Shell: the Terminal in Macs is an application that users use as the command line. The Terminal app is just a window and a shell runs inside of it automatically. The shell is a command-line program accepting inputs and displaying outputs. Terminal is not a shell but it allow us to interact with a shell. In Mac computer there are many shells to choose from (bash, csh, etc.). In Windows, the two most common ones are cmd and powershell...

Thanks!

 

[FactChecker]

The OP should have been a little more specific. To me, a terminal and a console are hardware. A terminal window and a shell are software. It is hard to say that any hardware is the same as software. If the words are used as adjectives, it depends on what the entire phrase is. If "terminal" is being used as an abbreviation for "terminal window", that may explain to me why I have been talking at cross purposes to others in this thread.

 

[fog37]

The OP should have been a little more specific. To me, a terminal and a console are hardware. A terminal window and a shell are software. It is hard to say that any hardware is the same as software. If the words are used as adjectives, it depends on what the entire phrase is. If "terminal" is being used as an abbreviation for "terminal window", that may explain to me why I have been talking at cross purposes to others in this thread.

Thanks FactChecker. I think there is no confusion anymore on my end on the fact that a physical terminal is a machine with no resources or computational power which just serves as an interface to connect to a computer to use its computational resources.

Yes, I am focused on software definitions. Sorry I wasn't clear enough.

 

[FactChecker]

Yes, I am focused on software definitions. Sorry I wasn't clear enough.

Sorry. Maybe that should have been obvious to me, but it never occurred to me at all. Old age, I guess. :-)

 

[pbuk]

Thanks everyone. Just to summarize...

Oh dear, I think that things have become rather confused. Above all, I think you need to stop trying to fit these things into rigid boxes, they won't fit and this will just lead to frustration and confusion. To pick up on some of the confusion:

Thanks everyone. Just to summarize, broadly speaking, there are two types of software:

No, there are many types of software.

1. system software (operating system (same as the kernel), device drivers, utility software)

The term 'operating system' normally includes more than just the kernel.

1. application software (Python, Word, Photoshop, etc.)

Python is not an application in the same sense as Word and Photoshop. And where do things like databases, and web servers fit in this categorisation?

Software is often depicted in multiple layers, but the number and nature of the layers depends on the context, trying to nail a fixed definition to the wall is pointless.

• Shells are interactive programs that make interacting with the kernel (i.e.OS) easier and provide a environment and interface for programs to use. For example, the same shell can be used to run Python or another interpreter.

No, applications don't generally use a shell, they interact directly with the OS (but not with the kernel, the OS will generally have one or more layers between its API and the kernel (API = Application Program Interface, the layer which applications communicate with - note that this term has different meanings in different contexts as well).

In general, is it correct to say that shells run interpreters?

No. You can use a shell to start an interpreter application, but there are other ways of starting applications, and other applications that can be started from a shell.

Is an interpreter any program converting user commands into instructions for the OS?

No.

Does every application program have to have an interpreter running under the hood every time the application is running?

No.

For example, when using a word processor, we don't need to run a shell. But is there an interpreter running somewhere?

Not for any word processor you are likely to come across in 2021 (I seem to remember something that ran on BBC Basic back in the 80s or am I imagining that?)

Which application programs are designed to always need a shell to run?

None that I know of.

Programs like Photoshop, etc. are executable files that we can launch by either clicking on an icon or by typing a command inside a shell.

In sequence:
user uses the shell -> the application program is run and interacts with the shell -> shell interacts with the OS/kernel (via the interpreter?)

No, see above.

Terminal vs Shell: the Terminal in Macs is an application that users use as the command line. The Terminal app is just a window and a shell runs inside of it automatically.

No, on a Mac (and most other *nix-like OSs with a GUI), the terminal app is a GUI application that accepts keyboard input and directs it to an OS stream and receives data from an OS stream which it displays as text characters within a GUI window. In most cases, the terminal app will connect its stream to the default shell and so to the user there the fact that the terminal process is distinct from the shell process is not significant.

The shell is a command-line program accepting inputs and displaying outputs.

'Command line program' doesn't mean anything here, and as above the shell (in a Mac) doesn't actually display anything, it just writes to a stream; the terminal program reads from the stream and displays it.

Terminal is not a shell but it allow us to interact with a shell. In Mac computer there are many shells to choose from (bash, csh, etc.).

This is true in a Mac or Linux context but not in many other contexts, particularly Windows.

In Windows, the two most common ones are cmd and powershell...

As stated somewhere above in both cmd and powershell there is only one application that is both 'shell' and 'terminal'.

 

[pbuk]

In summary, we have come full circle to the point I was trying to make in my first two posts in this thread (which have now been deleted).

Summary:: understand the difference between shell, console, terminal

These words can be used to describe completely different things, and they can also be used to describe exactly the same thing so there is no meaningful general answer to this question.

Edit: if you are still confused, I will repeat these words from the official Ubuntu tutorial:

The Linux command line is a text interface to your computer. Often referred to as the shell, terminal, console, prompt or various other names, it can give the appearance of being complex and confusing to use.

 

[jbriggs444]

Btw, for those of us old enough to remember dialup connections, "terminal" was also used back then to refer to the application that you used to manage dialup connections. Early versions of Windows even called that application "Terminal".

Some of us old dudes would use "terminal" to refer to the physical keyboard/display unit that sits at the end of a terminal connection. The connection traditionally being RS-232c or 50 ma current loop. [Or 110 baud acoustic coupler when I was first learning]. The terminal being something like a VT52, VT100, ASR33 or LA120.

The "console" is then the specific terminal that is plugged into the console port which is where the computer displays critical error messages, accepts boot time commands and, perhaps, run time interrupts. For instance, halting the computer for everyone by hitting control-P on the console terminal.

 

[FactChecker]

• In general, is it correct to say that shells run interpreters? Is an interpreter any program converting user commands into instructions for the OS? Does every application program have to have an interpreter running under the hood every time the application is running? For example, when using a word processor, we don't need to run a shell. But is there an interpreter running somewhere?

Just to clarify the interpreter. An interpreter can work on each command as it is typed in by the user. That allows great flexibility for the user, who can see the results of one command before he decides what to do next. But the process of interpreting slows things down, and the user can make errors. If a programmer already knows what he wants a program to do from beginning to end, he can compile and link the program into an executable program. That allows the executable to run much faster every time without interpreting the original program each time, and often without needing constant interaction with the user. It might also reduce user errors in a repetitive process that might be tricky to get right every time. So there is a trade-off between the interpreter's step-by-step flexibility and the executable's speed and repeatability. Each has its place.

 

[fog37]

Just to clarify the interpreter. An interpreter can work on each command as it is typed in by the user. That allows great flexibility for the user, who can see the results of one command before he decides what to do next. But the process of interpreting slows things down, and the user can make errors. If a programmer already knows what he wants a program to do from beginning to end, he can compile and link the program into an executable program. That allows the executable to run much faster every time without interpreting the original program each time, and often without needing constant interaction with the user. It might also reduce user errors in a repetitive process that might be tricky to get right every time. So there is a trade-off between the interpreter's step-by-step flexibility and the executable's speed and repeatability. Each has its place.

thanks FactChecker. So what kind of software programs generally need the assistance of an interpreter? Those programs that are run through a shell?

As mentioned, a word processor is a different type of software than Python whose purpose is to run Python code...

 

[jbriggs444]

thanks FactChecker. So what kind of software programs generally need the assistance of an interpreter? Those programs that are run through a shell?

As mentioned, a word processor is a different type of software than Python whose purpose is to run Python code...

Essentially no software programs require the assistance of an interpreter. Word processors, spreadsheets, email programs, complex numerical applications, video games, flight control programs, etc. They can all run standalone. They will typically use operating system API's directly.

The exception to this rule are things like shell scripts. Roughly speaking, these are sequences of commands that a shell can execute.

e.g.

$ cat zonedump.sh
#!/bin/bash
/opt/nwreg2/local/usrbin/nrcmd <<EOD > zonelist.tmp
zone listnames
EOD
egrep "\.$" zonelist.tmp | awk '{print "./dumpzone.sh ", $1}' > zonelist.sh
. zonelist.sh

$ cat dumpzone.sh
$!/bin/bash
dig @127.0.0.1 $1 axfr | grep $1 | grep -v ";;" | sort -u > zones/${1}dump

One could argue that things like Basic programs, Perl scripts, Python scripts, Java applets, etc need a Basic interpreter, a Perl interpreter or a Python interpreter or a Java run time environment, etc in order to be executed.

In the Unix environment, such programs are identified by a stylized first line that identifies the program that needs to be used to run them. In the above example, those two scripts need to use the bash shell which lives in /bin/bash.

For a Perl script, one might have...

$ head /usr/local/scripts/imac-add.pl
#!/usr/bin/perl
#
# imac-add.pl -- process an IMAC add or rediscover
#
# Usage: imac-add.pl hostname ip > cnrcommands.txt
[...]

In other environments, different approaches are taken to activating the needed support environment. For instance, in Windows, the Registry records what application is to be used then "opening" a file with a particular extension. So Perl might be automatically activated when invoking a program with a .pl extension.

 

[FactChecker]

thanks FactChecker. So what kind of software programs generally need the assistance of an interpreter? Those programs that are run through a shell?

As mentioned, a word processor is a different type of software than Python whose purpose is to run Python code...

There are trade-offs and a large gray area in between. In general, I prefer interpreted languages when I am developing a process/algorithm and want to see the results of intermediate steps. That allows me to correct mistakes and decide what to do next. This is especially true if I do not think that I will need to repeat that exact process often enough to make an executable program.
Suppose I have a process that will be repeated and the steps are tricky. Once I think that I have the correct sequence of commands, I would usually put them into a script in that same language and run the script through the interpreter for future runs.
Now suppose the process is one where the interpreted language is too slow. A compiled executable has a distinct advantage there. It does not need to reinterpret the code every time. It can also do a lot more optimization of the process because it knows the entire sequence of steps from beginning to end and can do a lot of smart things to speed up the process. If that is true, it would be worthwhile to convert the program to a compilable language.
The decision of which language to use can get blurred. There has been a lot of work to improve the speed of interpreted languages and to allow them to make compiled versions or partially compiled p-code. But I am not aware of any interpreted language that can achieve the speed of optimized executables from C, C++, Fortran, etc. unless they are also compiled and optimized.