Language "efficiency"
Doghouse – Languages
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.
Buy this article as PDF
(incl. VAT)
Buy Linux Magazine
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.
News
-
Gnome 48 Debuts New Audio Player
To date, the audio player found within the Gnome desktop has been meh at best, but with the upcoming release that all changes.
-
Plasma 6.3 Ready for Public Beta Testing
Plasma 6.3 will ship with KDE Gear 24.12.1 and KDE Frameworks 6.10, along with some new and exciting features.
-
Budgie 10.10 Scheduled for Q1 2025 with a Surprising Desktop Update
If Budgie is your desktop environment of choice, 2025 is going to be a great year for you.
-
Firefox 134 Offers Improvements for Linux Version
Fans of Linux and Firefox rejoice, as there's a new version available that includes some handy updates.
-
Serpent OS Arrives with a New Alpha Release
After months of silence, Ikey Doherty has released a new alpha for his Serpent OS.
-
HashiCorp Cofounder Unveils Ghostty, a Linux Terminal App
Ghostty is a new Linux terminal app that's fast, feature-rich, and offers a platform-native GUI while remaining cross-platform.
-
Fedora Asahi Remix 41 Available for Apple Silicon
If you have an Apple Silicon Mac and you're hoping to install Fedora, you're in luck because the latest release supports the M1 and M2 chips.
-
Systemd Fixes Bug While Facing New Challenger in GNU Shepherd
The systemd developers have fixed a really nasty bug amid the release of the new GNU Shepherd init system.
-
AlmaLinux 10.0 Beta Released
The AlmaLinux OS Foundation has announced the availability of AlmaLinux 10.0 Beta ("Purple Lion") for all supported devices with significant changes.
-
Gnome 47.2 Now Available
Gnome 47.2 is now available for general use but don't expect much in the way of newness, as this is all about improvements and bug fixes.