Python is to 2020 what interpreting Basic was to 1985

This article is bound to upset some Python fans and those that trust external sources.

Both Python and Basic shares some similarities, some good and some bad. A lot of this also applies to other interpreting languages.

On the good side it's easy to code in and easy to learn. The bad side is that it's very easy to create bad code.

As someone that has been coding Basic and also have had to maintain Basic programs I see that the history repeats itself with Python. It's not the same bugs, but the reasons for the bugs are similar and in many cases beginners mistakes, but also inherent problems with the language itself.

To look back into history Basic was never one single language, it was several dialects that evolved over time and got new features depending on manufacturer. This did mean that code written for one computer could to 90% work on another but you had to figure out how to get around the 10% that differed.

The similar thing is with Python – with new generations of the language you can get some new features and old might no longer be working. So upgrading the interpreter might cause your application to break. Dependency on external libraries are also adding to this, especially if they are dynamically loaded from an external source that you don't have control over. This of course applies to many other languages, but interpreting languages are usually more sensitive to this since the external libraries are loaded during runtime and not at compile time.

However problems with upgrading the interpreter is often a minor problem compared to the problem with maintaining the code. Since it’s an interpreting language you will often not find a problem until you start to execute that part of the code. On a compiling language like Java, C# or C++ (to name the more common) you will discover basic mistakes during the compilation or linking phase where the classes and method signatures of the calls are matched to the implementations. C is a bit less stringent and some code problems may fall through.

The result is that if you can’t discover the issues at compilation time then you will have to discover the issues at runtime. And at runtime you will then have to execute the program in a way that ensures 100% coverage. For some languages like Python there are some code quality tools that you can run as a developer, but you aren’t forced to use them except if you have a build system that prevents you from delivering without having a successful execution of the check. Other script languages may lack this kind of check completely.

As an example take the following Python code.

When executing f1.py you will then discover that the program sometimes crashes and sometimes works as expected. This is because the function print_life() doesn’t exist in f2.py. This is an inherent problem of an interpreting language – you will see the problem first when the execution reaches that point.

So imagine that the function is such as it’s called once per month from one point in the code and once per year from somewhere else. If the function is updated and the per month call is updated but not the per year call then someone will have a bad New Year’s Eve. Or even worse it’s not discovered until months later that the yearly execution failed. This is included in what often is called “Software Rot” and “Dependency Hell” (look them up on Wikipedia).

You might argue that it should be discovered during testing, but in reality testing is often cut short. And a test process for a large system has to cover a huge amount of permutations to ensure 100% test coverage to catch things like this.

So the conclusion I have to make here is that writing in Python may speed up the development of a system but can make maintenance of the system a lot more expensive in the long run. The scope of the solution is one important factor here. If you need to develop something small and simple with limited performance that is not expected to live for long then you can use Python or another script language. But if you are going to develop something that shall have a long life and be maintained over many years a script language can be very tricky. And stay away from dynamically loaded external libraries.