5 Reasons Why I Love Linux Programming

Linux is a great platform to do programming. On our side, it is logical, highly efficient, and easy to work with source code.

In the year 2021 Linux looks more attractive than ever. I am going to write a paper about 21 ways to use Linux. In this article I want to talk about why so many programmers choose Linux.

When I started to use Linux I worked in the film industry. I chose Linux because it was a wonderful operating system for multimedia data. We found that the usual commercial video editing applications were not able to handle most of the footage we were pulling out of just about any camera-equipped device. What I did not know at the time was that Linux had a reputation as an operating system designed for servers and programmers. The more I did with Linux, the more I wanted to learn how to manage all of its features. In the end I discovered that a computer shows its full power only when its user can “speak” its language. A few years after switching to Linux I wrote scripts for automatic video editing, for merging audio files, for batch editing of photographs and for any task I could formulate and find a solution to. It did not take me long to understand why programmers love Linux. But it was Linux that taught me to love programming.

It turned out that Linux is a great platform for programmers, both beginners and experienced. This is not to say that Linux is essential for writing programs. Successful developers use many different platforms. But Linux has a lot to offer to developers. Some of these things I want to talk about.

The Logic of Linux

Linux is built around the idea of automation. The main Linux applications are deliberately made so that they can at least be started from a terminal by specifying additional options. Often they can even be used entirely from the terminal. This idea is sometimes wrongly thought of as a kind of primitive computing model, because there is a widespread (and mistaken) opinion that to write programs that run from the terminal is to make an absolute minimum effort to get a working application. This is the unfortunate result of not understanding how program code works, but many of us suffer from this misunderstanding from time to time. We think that more is always better, so an application with 1000 lines of code should be 100 times better than an application with 10 lines of code. Right? But the truth is, all other things being equal, it is better to choose an application which is more flexible, and it does not matter how many lines of code it consists of.

In Linux, solving a task by hand may take, for example, an hour. You can do the same thing in a minute with the right command line tools, and possibly in less time if you use GNU Parallel. In order to get used to this, you have to change your view of how computers work in a certain way, you have to learn to think differently than you did before. For example, if the task is to add covers to 30 PDF files, one might decide that an acceptable sequence of actions would look like this

• Open the PDF file in the editor.
• Open the file with the cover art.
• Attach the PDF file to the cover file.
• Save the resulting document as a new PDF file.
• Repeat these steps to process the rest of the old files (there is no need to process new files derived from the old ones).

This sequence of actions is quite consistent with common sense, and although it contains a lot of unpleasant repetitions, it achieves the goal. In Linux, however, it is possible to organize the work much more intelligently. The process of thinking about it, taking into account the possibilities of Linux, is similar to the process of thinking about the “manual” way of solving a problem. Namely, it starts by searching for the sequence of actions needed to get the result you want. After doing some research, you can learn about the pdftk-java command and then come up with a simple solution:

$ pdftk A=cover.pdf B=document_1.pdf \
cat A B \
output doc+cover_1.pdf

Once you are satisfied with the command’s ability to handle a single document, you will need to spend some time examining the utilities that handle datasets. In the process, you may find the parallel command:

$ find ~/docs/ -name “*.pdf” | \
parallel pdftk A=cover.pdf B={} \
cat A B \
output {.}.cover.pdf

This presents a slightly different approach to thinking about tasks than usual, because the “code” we write doesn’t handle data the way we’re used to. Normally we are constrained by notions of consistent manual data processing. But going beyond the boundaries of the old notions is important in order to write appropriate code later. And a side-effect of this “going out” is getting the ability to write more efficient programs than before.

Possibilities to manage code relationships

It doesn’t matter what platform you’re programming for when you enter code into the editor. It all comes down to the programmer weaving an intricate network of invisible links between many different files. In almost all cases, except for some very exotic ones, the code refers to header files and uses external libraries to become a complete program. This happens on all platforms, but Linux encourages the programmer to figure it all out for himself and not to entrust the care of it all exclusively to a developer’s tools for some platform.

It must be said that there is nothing wrong with trusting the developer’s tools to find libraries and include external files in the programs. On the contrary, it is a useful feature, the presence of which should cause the programmer only a sense of gratitude. But if the programmer understands absolutely nothing about what is going on, it will be much more difficult for him to take control of it all, if the developer’s tools simply do not know how to handle some problems.

This does not only apply to Linux, but also to other platforms. It is possible to write code in Linux that is intended to run on both Linux and other operating systems. Understanding how exactly the code is compiled helps the programmer to achieve his goals.

Admittedly, this kind of thing cannot be learned just by using Linux. One can happily write code in a good IDE and never even think about what version of some library was installed or where exactly some header files are. But Linux does not hide anything from the programmer. It is very easy to go deep into the bowels of the system, find what you need and read the corresponding code.

Making it easy to work with existing code

It is useful to know where the header files and libraries are, but being able to see their code is another example of the added benefit of programming in Linux. In Linux, you can see the code for just about anything you can think of (except for applications that run on Linux but aren’t ops). The usefulness of this feature of Linux cannot be overstated. As one gets better and better at programming in general, or deals with something new to him, he can learn a lot by reading the existing code in his Linux system. Many programmers have learned how to do their business by reading other people’s open-source code.

When working with systems whose code is closed, one can find developer-oriented documentation with code examples. That’s fine, documentation is important, but it doesn’t compare to being able to discover exactly the functionality you plan to implement and being able to find source code that demonstrates how it’s done in the application you use every day.

Direct access to peripherals

After having developed software on Linux for media companies, I sometimes take for granted the possibility to access peripherals. For example, when you connect a camcorder to a Linux computer you can load incoming data from /dev/video0 or from a similar device. Everything you need can be found in /dev, and it is always the shortest path from point A to point B.

This is not the case on other platforms. Connecting to systems outside of the OS is always a maze built from SDKs, closed source libraries, and sometimes privacy agreements. The situation, of course, is not the same everywhere, it depends on what platform the programmer writes the code for, but other systems are hard to argue with the simplicity and predictability of the Linux interface.

Well-designed abstractions

At the same time, Linux also provides a reasonable set of abstraction layers for situations where direct access to something or manually writing some code can result in more work than the programmer is willing to do. Many handy tools can be found in Qt and Java, and there are stacks of assistive technologies such as Pulse Audio, Pipewire and gstreamer. Linux wants its users to be able to do programming and does not hide it.

Bottom line

There are many more reasons why programming in Linux is fun. Some of them are large-scale concepts, some are tiny details that have saved me many hours of hard searching for solutions to certain problems. Linux is a nice place to be, no matter what platform the code you write in Linux will run on. Whether you are a person who has just started to learn how to write software or an experienced coder looking for a new digital home, there is no better place to program than Linux.