Language "efficiency"

Doghouse – Languages

Article from Issue 265/2022
Author(s):

The efficiency alone of a programming language doesn't show the full picture.

Last month I discussed the importance of portability across cloud architectures, which allows you to move your application and data if the costs of a particular vendor become too high or that cloud vendor goes bankrupt.

This month's article was inspired by a conversation on LinkedIn about a whitepaper that was published comparing the efficiency of various languages, with the claim (by the paper) that Python was very inefficient in execution as opposed to languages like C and C++. Various people made comments ranging from "Python programmers are killing the planet" to "What is a language like Python good for?"

First of all, to point to a language and say offhand that it is "inefficient" is not really useful. A language is made up of syntax and semantics to convert what humans code into the binary ones and zeros (called machine code) that the computer can follow, usually by a program known either as a compiler or interpreter.

Compilers and interpreters will use up CPU cycles in that conversion process. Compilers tend to do this conversion ahead of runtime, so the running of the machine code generated is all that uses the computer's resources – making the object code "more efficient." That efficiency sometimes comes at the cost of not having a lot of additional information that was "thrown away" by the compiler. Interpreters, which will often have that information still available at runtime, can use that information to help with debugging. As an example, if some problem occurs during the execution of the program, an interpreter may be able to point back to the actual source code statement where the issue occurred. With a compiler, that source code information may be long gone.

Secondly, even between compilers for the same language, you may get different levels of efficiency. In the C language, there are many, many implementations of C compilers, created by different teams of programmers in different companies, and often to meet different needs, with different levels of optimizations.

Some C compilers, tuned for embedded systems, may generate code optimized for size. Others, having access to more memory, may optimize for runtime speed. Same language, different optimizations. In fact, if you look at the GCC compiler, you can see many different optimizations in the option line, all of which will affect the "efficiency" of the code in one way or another.

Often programmers will write the code and get it to work without any optimization, making it faster to do the actual programming, but then turn on the optimizations for the final compilation.

This would be great except that sometimes optimization can inject errors, and often those errors are hard to find.

Many people reading the whitepaper argued that "interpreters and scripting languages are always less efficient."

I often heard about how shell scripting was inefficient. However, Unix and Linux shell commands have been rewritten over the years to be really efficient, so depending on the application, a well-written shell script might be as efficient as a poorly written C program.

Interpreters often pre-compile to get down to "atoms" (or what Java called "beans") that are then consumed by a very efficient runtime engine.

There is also the concept of a "threaded interpretive language," where a "thread" is generated that simply calls module after module very quickly.

From my viewpoint, C is a minimal syntax that is very clean, but which forces the programmer to either code their own routines or use libraries that come from the various operating systems. The use of "pointers" in C is very powerful if used well, but often this leads to mistakes in coding if the programmer is not careful.

Other languages build in many functions (or sub-functions, such as garbage collection) that not only save the programmer from writing more code, but the language works well with these functions. On the other hand, some languages have so much syntax that it makes it very hard for mortal programmers to learn the entire language. Ada comes to mind.

People ask me how they can get started with programming. I point to shell scripting as a "first language." In the Unix and Linux space, shell is always there, and the utility programs used as filters work well and are powerful.

Then I recommend Python as a "first programming language." Python is relatively simple to learn, and there are many tutorials on how to use it.

After that, I recommend a machine/assembly language, almost any of them, just so the programmer learns how a computer really works.

After that, I suggest C or C++, or (these days) Rust.

In the end, a good programmer will learn even more languages that are special purpose, or simply needed for some job or to repair some code left from another programmer.

The trade-off will be ease of programming against efficiency of the algorithms, with very little depending on the syntax of the language itself.

The Author

Jon "maddog" Hall is an author, educator, computer scientist, and free software pioneer who has been a passionate advocate for Linux since 1994 when he first met Linus Torvalds and facilitated the port of Linux to a 64-bit system. He serves as president of Linux International®.

Buy this article as PDF

Express-Checkout as PDF
Price $2.95
(incl. VAT)

Buy Linux Magazine

SINGLE ISSUES
 
SUBSCRIPTIONS
 
TABLET & SMARTPHONE APPS
Get it on Google Play

US / Canada

Get it on Google Play

UK / Australia

Related content

comments powered by Disqus
Subscribe to our Linux Newsletters
Find Linux and Open Source Jobs
Subscribe to our ADMIN Newsletters

Support Our Work

Linux Magazine content is made possible with support from readers like you. Please consider contributing when you’ve found an article to be beneficial.

Learn More

News