Which Programming Language?

by Peter Kelly (critter)

Most of my previous submissions to the PCLinuxOS magazine have been in the form of tutorials or how-to's. This time, however, I thought that I would share my experiences with trying out a new programming language, the difficulties that I experienced, the relative advantages and disadvantages of the different languages, and the benefits of being able to use one, or more, computer languages to achieve the results you require from today's powerful computer systems.

For the lowdown on a whole bunch of computer languages, take a look at the "Computer Languages from A to Z" series published in the PCLinuxOS Magazine from July 2008 to February 2011, written by Gary L. Ratliff, Sr.

You may not realize just how powerful your computer actually is when using pre-packaged applications supplied with your distribution. They will, usually, make tasks easier but at the expense of compromising your requirements and providing a 'close fit' result.

You can write your own routines - not full blown applications such as word processors and spreadsheets, but little applications or scripts that get you the results that want, how you want them, in the format that suits your requirements. Writing your own routines can be achieved in a variety of ways, and there are many programming and scripting languages available to enable you to write them.

Writing a utility application to achieve your end result need not be difficult but, like learning to play a musical instrument or to excel at a sport, it requires some effort. The more effort you put in, the more you get out of the endeavor.

Simple, 'that's useful' routines can require very little expertise, while the all-encompassing, mega-app will take much, much more.

Most of us will use what is available already, and supplement it with a few little scripts to help take away the drudgery of day-to-day requirements.

About programming and scripting

New computer users usually fall into one of two categories: those who see themselves as potential programming gurus, and those who would rather just not know about such evil practices. Both are usually misinformed and, whichever direction they eventually follow, disappointed with their experiences.

It is not necessary to be able to write computer code to achieve a satisfactory relationship with the capabilities (and complexities) of a computer. However, those who do learn to use some of this additional ability tend to get so much more from their computing time.

Choosing a language or script

After a while, it becomes apparent that there are some things that take a lot of effort to accomplish, more effort than they will save, and some that require a little bit of 'heavy lifting' code to accomplish.

Thankfully, some other people have realized this and produced their own versions of programming environments in order to:

'make the easy things easy, and the hard things possible'
                                (Larry Wall, inventor of the perl scripting language).

The first consideration I had was whether to use a compiled or interpreted language. There are some languages that support both interpretation and compilation, but ultimately the user usually decides on the way to go.

Compiled languages

C is a compiled language, which means that you have to write the code and then run it through a program called (unsurprisingly) a compiler. This converts your code, written in text, into the mysterious instructions understood by by the computer’s processor. If this succeeds, which it almost never does on the first few attempts, then another program called a linker is called up to join up your bits to the system’s own bits in order that the two can cooperate.

The compile-link process can be done seamlessly using an application known as an integrated development environment or IDE. (These IDE’s are available for most computer languages, not just compiled languages, and they really do help speed up the development process). Even so, you have to complete the process before you know if you have produced something usable.

Another compiled language is C++, which is a different flavour of C. C++ uses Object Oriented Programming (OOP), where C is a procedural language. See here for an explanation. Which one to use is mostly down to personal preference, as both are extremely powerful languages. So should I use a compiled language? No, not for writing quick fixes and small helper utilities. C is good. Unix was written in C, as were most of the GNU utilities, and of course, the Linux kernel. If you want to write device drivers or low-level systems utilities, use C. If you intend to start out from scratch and write '2nix' then choose C. If you want to do that and annoy the hell out of Linus Torvalds, then choose C++. For my purpose I wanted something lighter.

Interpreted languages

Interpreted languages tend to be lighter and easier for newcomers to grasp. This is why, when home computers first appeared on the scene, most came with a BASIC (Beginners All-purpose Symbolic Instruction Code) language interpreter installed. BASIC is not, however, a 'good' language, and can lead to some very poor programming habits. An interpreted language is written in text which is passed to an interpreter. This reads an instruction and executes it and then waits for the next instruction. This way you get to see the results immediately as each instruction is executed. Actually, most interpreters these days do two passes over the code. The first pass optimizes the code for interpretation, and the second pass performs the execution although this is invisible to the user.

Perl is an interpreted language, and many of the PCLinuxOS configuration utilities are written in perl. Therefore, I looked at perl. I was impressed. Perl is vast and has been around since at least 1987 (Larry won't say exactly). In that time, almost anything that can be done in perl has been done by someone, and that code is available for re-use in a central repository named CPAN - The Comprehensive Perl Archive Network. Perl is available for free on almost any platform, Linux, BSD, Windows, Mac and others. Most Linux distributions install it by default.

The documentation is as near complete as the documentation for a project of this size can be. Online tutorials are plentiful, and books on perl abound. Perl is also easy to use. Well, at least the beginnings of perl are easy, but adventurous folk can get as deeply involved as they like. One of perl’s maxims is 'there is more than one way to do it' and this is certainly true. If you have a perl problem and try to Google the answer, you are likely to get five people come up with eight different solutions, all of which work.

So, is perl the language that I should choose? No. The problem with perl is its completeness. There is just so much of it and so many ways to do things that I felt lost, I was drowning in a sea of possibilities. For some this is a plus, but I felt overwhelmed so I could not concentrate on the problem at hand. I agree with Forrest Gump -- 'Simple is as simple does.'

A friend suggested I try Java. I did. Again no. Why not? I didn't like it, simple as that. It may be the perfect solution for some folks, but not for me.

Next up came Python, a language that has been around as long as perl (1987) but has in recent years become the darling of coders in the open source world. A wonder language -- I wonder...

There are currently two versions of Python, similar but incompatible with each other: Python 2 and Python 3, with current releases at 2.7.10 and 3.5.0 respectively. Python 3 is stable but still in development, while Python 2 is also stable but unlikely to receive new features. Python 2 is not going to disappear any time soon, as there is too much existing code dependent upon it, but Python 3 is the way forward. I decided to try Python 3.

Python is an interpreted, object-oriented language that can also be used as a procedural language. Object-oriented because everything in Python is an object, but if you don't like that way of working, don't want to have to use classes and methods, use functions. Python will take care of the details, but then you will miss out on some of the power of Python.

OOP is not difficult, but it is different if you are used to the traditional way of coding. Python allows you to transition at your own pace. Once you begin to grasp the concepts of OOP, you can appreciate the simplicity and power available. Like perl, Python has a wealth of ready written code available in the form of importable modules, has excellent documentation, is free to use, is available on most platforms, and is installed by default in most Linux distributions.

So, once again, should I choose Python as my development platform? Yes, because unlike perl, I didn't get that feeling of being overwhelmed. Like perl, there is more than one way to do it, but unlike perl there is only one correct way to do it and the structure of Python tends to lead you towards that level of correctness. However, Python is tolerant if you do wander from the straight and narrow.

Often, compiled programs are used in speed critical situations. An interpreted language may call a compiled module to optimize the execution, as interpreted languages tend to run more slowly. Python has some useful features that help to speed things up. Here's an example:

One way of benchmarking programs is to perform many iterations of a repetitive task and to record the time taken. A Fibonacci sequence is a series of numbers such that the next number in the series is the sum of the previous two numbers -- 0, 1, 1, 2, 3, 5, 8, 13...

To find the largest Fibonacci number in the range 0 to n in python

To time the run of this routine this is called with:

time fibo_test.py n

Where n is the number to stop at.

I did this for two maximums, 1e3 which is 1000 and 1e308 which is 1 followed by 308 zeros, a ridiculously large number that should seriously test the routine. The screenshot shows the results.

Quick enough for me.

So, Python it is then. I've only been using it for a couple of weeks, but I like it. From the few examples that I've tried, OOP seems to make integrating GUI components much easier, so I think I'll stick with it a while.

I know that Linus thinks that C++ and OOP are an abomination, but then he's biased. He's a genius. For me, all things are difficult, and hard things are very difficult. But perhaps, with python, they are all achievable.