Programming languages – What you need in your toolbox.

"Languages are tools that are particularly good or bad for different applications. There will never be one language that simply replaces them all."

Welcome to "Querverlinkt – Technik über dem Tellerrand"! After our last podcast, we actually wanted to present you with IT trends of the next few years in today's episode. There's been a slight change of plans, but of course with a no less exciting topic. Today, however, we want to take you into the world of software development. Even if you don't see it immediately, software surrounds us every day and it is created with the help of programming languages. But what is a programming language anyway? How many languages are there? And how do they differ? That's what we're going to explain to you today and try to give you a brief overview of this complex topic. Programming languages – What you need in your toolbox.

 Happy listening!

Transcription

Thomas Sinnwell: Welcome to our new podcast. Today we are talking about programming languages. Why are we talking about programming languages? Simply because software surrounds us. You often don't think of it that way, but today most technical systems are controlled by software. To produce it, I need programming languages. Those of us who took a programming course at school or had contact with programming languages during their studies actually have a pretty good idea of what a programming language is. But even for them, we will discuss a few interesting aspects. And the rest of humanity may not know too much about it. We want to enlighten. I have invited reinforcements. Today's guest is Dr. Patrick Michel. Many students have been taught programming languages by Patrick. Patrick, please be so kind and introduce yourself.

Dr. Patrick Michel: Hello, I have been fascinated by programming since I was a child and I took this as an opportunity to study the subject after school. I then did my doctorate in Kaiserslautern and was involved in teaching. I introduced programming to the first-year students in introductory courses as well. For the last eight years I have been working as a senior software developer in the professional field. So for me, the topic is one that I've been taking with me for the last 30 years and always like to talk about and use in everyday life.

Thomas Sinnwell: Thank you very much! We can jump right in and perhaps clarify the central question: What is a programming language?

Dr. Patrick Michel: Ultimately, a programming language is about teaching a computer in an understandable way what it should do, what it should calculate, what contribution it should make to a software system as a whole. And such a programming language must be formal enough that a computer can understand it. There are no liberties allowed in programming language like for example in colloquial language.

Thomas Sinnwell: You just mentioned grammar. That is one part, the other is syntax, which shapes a programming language. Then of course, I have semantics.

Dr. Patrick Michel: That’s about what the programm actually does, when you execute it, it depends on what execution semantics the programme has. The syntax says what I am allowed to write down, what is permitted. And the semantics say, what it does when I execute it.

Thomas Sinnwell: Before we go and try to bring some order into these many programming languages, we can perhaps briefly discuss what all programming languages have in common. These are things like input and output, variables, functions, methods, objects. We will say a bit more about that later. Commands, operators, things like plus and minus, and control flow elements.

Dr. Patrick Michel: If you group the whole thing into the two biggest areas of programming, it's the definition of data structures and how do I represent data in the programme. Then the algorithms, where I do something with this data. That is actually the core of the whole thing in all programming languages. And depending on the paradigm, one or the other is a bit more pronounced.

Thomas Sinnwell: Nice keyword, paradigm. That brings us seamlessly to the topic of classifying programming languages. You can use very different criteria. You can distinguish them according to application areas. Is this a scientific topic? Is it perhaps about AI? It's about history as well: how did they come about? There are real branches of development in the programming languages. Then there is the point about programming language generations. And there is the point of programming paradigms. For me personally, these are the two things we should talk about a bit more intensively. But of course you can also look at the aspects of how difficult it is to learn a language. But let's just start with the aspect of generations of programming languages. And the programming languages of the first generation are machine languages. These are the languages that are executed as native binary code on processors. The scope and syntax of these machine instructions are ultimately defined by the instruction set of the processor. And that is very processor-specific, what they can do and what an instruction set looks like. And the code that is ultimately available is binary code, which is ultimately a sequence of zeros and ones, and that is extremely difficult to read at first. And that was my personal introduction to programming. I studied electrical engineering, not computer science. And in microprocessor technology, you deal with processor architectures and their instruction sets for a relatively long time, and then comes programming via assembler programming. Then we'd already be at the second-generation programming language, but I didn't get beyond that. Assembler languages are programming languages that are aligned to an instruction set of a certain processor architecture. That is of course very exciting and then we come to what I consider the actual programming languages when we look at the third, fourth and fifth generation. However, I would like to leave that to the professionals.

Dr Patrick Michel: With the third generation, we are talking about the so-called high-level languages. Especially in contrast, assembler or machine language are very, very architecture- and CPU-specific. With high-level languages, you move away from the concrete technology, a bit more into the domain of the developer, adding means of abstraction. You get the possibility to define more complex data structures, building on the primitive data you have. You also suddenly have the possibility to abstract the algorithms. You can define subroutines that you can reuse. So you really take a big step away from the concrete machine into the world of actual programming, which you can also express better as a programmer. That is the third generation. You can subdivide it even further, but I think that ...

Thomas Sinnwell: We can come back to that later. We should definitely talk about standardising.

Dr. Patrick Michel: Standardising is something that was virtually non-existent in the first two generations. You have to imagine that computers are all just zeros and ones and that both the hardware and the operating system do not impose any restrictions on what you can represent with them, whether it is numbers, character strings or image data. Completely free, which is also a nice advantage. But that also means that as a programmer I have to be careful that data that I store as a number is also interpreted as a number when I read it. If I don't do that, if I interpret it as a string, for example, then I make a so-called type error. And usually this is unintentional and has devastating effects. And if I use standardising accordingly, it can get a grip on that.

Thomas Sinnwell: So it describes the type of data?

Dr. Patrick Michel: Exactly! That means, primitively, you usually start with whole numbers, floating point numbers, letters and strings. These are primitive standards I can store in memory. From these I then construct more complex data, at least in the high-level languages, with structures or later classes and objects.

Thomas Sinnwell: We definitely have to talk about that. What is the situation now with the fourth and fifth generation?

Dr Patrick Michel: With the fourth generation, these are the so-called domain-specific languages, which have a very focused application purpose. For example, to talk to a database or in the operating system environment for shell scripts. These are completely focused languages that have a focused application purpose and as a contrast to the general programming languages, which don't have a particular focus to begin with. And finally, the fifth generation would be the logic languages, where you move away from telling the machine exactly what it should do, but only describe what the result should be. You leave it completely open how the programme comes to that conclusion. That sounds a bit magical at first. In logic programming, you simply describe the world with invariants that are supposed to fulfil the world and you describe the result with formulas. Then the programme itself can try to find a way. In terms of runtime, this is not particularly fast, but it is of course a very elegant way to describe and solve a problem. A common application domain is AIs, or artificial intelligence, where I don't want to say how the AI comes to a decision. After all, that's exactly what I want the AI to do for me. That means I don't describe the path, only the result.

Thomas Sinnwell: Good! Let's then move on to classification and look at programming paradigms. Heavy word. First of all, the imperative aspect. Patrick, can you say a little bit about that?

Dr. Patrick Michel: This is still very close to what was done in assembler, i.e. one step after the other. You tell the programme exactly what it should do, one after the other, which instructions to use, which calculation rules to follow. What has been added to assembler are the abstraction possibilities, where you can combine whole blocks of programmes into a procedure and call them up again. It is still very close to the process architecture. And from that point of view, it is naturally the first step of high-level languages.

Thomas Sinnwell: Then the next class, object-oriented.

Dr Patrick Michel: Two things come together here. One is that object orientation has been introduced as a concept. You look at programmes as interacting objects that stand for themselves and they send messages to each other. That is a programming paradigm. At the same time, new concepts were introduced in further development of the language to support this. For example, data structures and algorithms on data structures are defined together in classes. This structures the code. It's a nice way to modularise, to encapsulate things. But from my point of view, those are two different things. That was one thing that wasn't very clear to me in my studies. In lectures you hear that they are two different things. And Java, for example, as an object-oriented language, has introduced many of these programming concepts, but has not yet taken the last step as far as the pure idea of object orientation is concerned. That is where languages like Scala come into play, or frameworks like Acer and Actors. Every actor is basically what an object should be in object orientation. It stands for itself, encapsulates its state. Actors exchange messages with each other asynchronously, which is the basic idea of object orientation.

Thomas Sinnwell: Let's see if we have some time later to talk about one or the other language in detail. You just mentioned Scala, and I think that is a very interesting language. We can certainly come back to one or the other topic. But let's finish the point here first. After object-oriented, the aspect of functional would be important to me. Of course, you could also turn it around and start with functional and then object-oriented.

Dr. Patrick Michel: We had just mentioned Scala. That is an example of a language that  has functional paradigms in it. In functional programming itself, the function, as it is already in the name, naturally has a high value. In particular, I can also pass functions as values, that is, I can call other routines and instead of simply passing a number or a string as a parameter, I can pass functions. This is one of the unique selling points of functional programming. But what is also clearly noticeable is the step away from architecture. There is less talk about where my memory is actually located, where it is created and when it is released. Basically, the language semantics take care of all that for me.

Thomas Sinnwell: After all, I don't have any assignment of values to variables.

Dr Patrick Michel: Exactly! They simply said that this side effect, which you have when you change existing variables, is taken out of the language. That is also one of the common classifications of paradigm, that one says a paradigm is actually a restriction of programming models. So I make it a bit more difficult for myself, I restrict what I can do, with the hoped-for effect, so I end up with better programmes, that have nice properties, they don't contain type errors, for example, that they are more elegant, more comprehensible to read. Actually, a paradigm is often a limitation because the languages are all equally powerful. So all general programming languages are so-called Turing complete. That means I can theoretically calculate everything with them. That is, there is no language that has another language tool that can do more, they are all equally powerful to begin with. Actually, it's about: How do I want to write my concrete programme? How many possibilities do I want to give myself? With assembler, I still have all the freedom in the world, with all the disadvantages that entails. With each paradigm, I add a new idea so to speak, of how I can restrict it so that my programmes are found more purposefully, are more elegant and have better properties.

Thomas Sinnwell: And what about the last paradigm? Logical?

Dr. Patrick Michel: I take another step away from the concrete execution, as I indicated earlier. I no longer say how I should calculate it at all, but only describe my result. I sketch out what it should look like, what properties it should have. I no longer influence how the programme or the computer really arrives at the result. That can mean that some questions don't have an answer and the programme runs for as long as it likes. That can be a side effect.

Thomas Sinnwell: Then I would like to talk about another point, namely compiler languages and interpreter languages. At least that's how I perceive it, there are often difficulties in understanding what exactly they are and what the advantages and disadvantages are. I think this is a very exciting point, especially in the context of Java.

Dr Patrick Michel: It started with the compiler, the compiled languages. The idea is that the moment you make the step from a machine language to a high-level language, you basically need another programme. You need a programme that you have already developed before that reads this language and translates it into machine language so that it becomes executable again. So even on the most modern computer, only the set of instructions from the computer is still executable and everything else I have to translate, compile beforehand. With the so-called script languages, which is the umbrella term for interpreted languages, you save the intermediate step of first translating it into machine language and then executing it, but you have both in one programme. The interpreter reads the programme and executes it at the same moment.

Thomas Sinnwell: That is now very much “en vogue” in the field of web development.

Dr Patrick Michel: Exactly! That means you can simply write a small programme fragment and execute it directly.

Thomas Sinnwell: And then you can immediately see what happens.

Dr. Patrick Michel: Exactly! Microsoft, for example, likes to call it macros, in Office Suite. So everything where even the end user is able to write small programmes, which are then directly executed. This is the area of script languages or interpreted languages, with the obvious advantage. Compilation has the huge advantage that the compiler can take a little time to analyse the programme and see if everything is correct and it can optimise it as well. Optimisation is, of course, a huge field in compilation. That means that you can afford to have the compiler run a little longer and when it comes up with the optimised end result, then I can run it highly efficient.

Thomas Sinnwell: So now, if you go back to the programming language, C++ would be a very prominent example of a compiler language.

Dr. Patrick Michel: Exactly! C, C++, these are the hardware-oriented, highly optimised languages, where I want to generate machine code directly. With the disadvantage that I need a different compiler for each architecture, which can then generate the output accordingly.

Thomas Sinnwell: And that would be the seamless transition to the Java world.

Dr Patrick Michel: With Java, you have a so-called virtual machine for which you compile. This means that the Java programmes are translated into byte code that is not directly executable for any specific architecture. You combine the whole thing with a programme, which has to be developed in an architecture-specific way, for the Java Virtual Machine, which can execute this byte code again. From this point of view, you have the best of both worlds: you can write the compiler hardware-independently and compile it, you can optimise it, you can take the step to the entire end platforms separately and you can execute the programme for every platform that has a JVM, i.e. a Java Virtual Machine. In particular on mobile devices, in a browser, Java was used directly everywhere. Sometimes one takes a step backwards. Java, for example, has actually been removed from the browser in the meantime. JavaScript has now completely taken over. Java is a powerful language and we had to struggle with security more and more, which wasn’t worth it in the end. You can see that they tried to exploit this approach at the beginning.

Thomas Sinnwell: Good! I think we have now managed to group, structure and classify programming languages a bit. I would now like to talk about one aspect: old programming languages. There are an incredible number of them. One could get the idea: Oh, such old languages, you don't need to bother with them anymore. I find COBOL quite exciting. It was developed in the 60ties and is still very much used in banks and in administration. I assume you can tell me why that is.

Dr Patrick Michel: Some of the first high-level languages already did many things very well for the domain for which they were intended. At that time, a lot of code was successfully developed. Today's topicality is due to two major reasons. One is that there is simply a huge code base, well-functioning code, which you can't just replace. On the other hand, the languages have special support, for example in COBOL, for business programmes with precise support for calculating with currencies, where you calculate to two decimal places. You can't make any mistakes there. In addition, the languages can do that very precisely and that's why it's still used. Of course, they try to limit new developments a bit, because it's getting more and more difficult to find people who can use that language. As they say in the industry, if you want to earn a lot of money, you learn the old languages, not the current ones, because that's where people are wanted.

Thomas Sinnwell: In our company we came into contact with another somewhat older language, Fortran. That was Fortran 77, by the way, the first high-level language I was allowed to learn at university, when I was a student in the last century. You still find Fortran 4 and Fortran 77 in the industrial sector. There are many porting projects where it's a question of understanding this old code again. It helps if you know the language and then port the whole thing into a more up-to-date language, for which you can find even more people. I found that very remarkable, because Fortran was developed in 1957, I think, and is still around.

Dr. Patrick Michel: Of course, some languages are much older than others. Java is certainly more modern than C or C++, for example. Languages like C and C++ have been continuously developed and there are modern standards for them. Because they differ so much in their paradigm and their application, there are still enough applications for these languages, useful applications, they have their reason to exist. I would say that they are actually on an equal footing, they are tools that are used at the right time.

Thomas Sinnwell: What is the best way to learn a programming language?

Dr. Patrick Michel: As with most things, as long as you are interested in it and just learn by doing, just try it out. That is actually the best approach. Nowadays you can find lots of introductions, tutorials and websites, especially on the internet, that make it interactive. It has never been so easy to get good learning material. But in the end, just try it out, just do it.

Thomas Sinnwell: Does it matter which language one chooses to learn first?

Dr Patrick Michel: No I don’t think so, but it depends a bit on your own preferences. Some people like it when something happens graphically. Some people want to see something when they do something, they want to see the effect directly in front of their eyes. Then, of course, there are languages that can do to that.

Thomas Sinnwell: There are some programming languages, that have a very distinct ecosystem. What does that mean?

Dr Patrick Michel: That means that the language has execution semantics, paradigms, everything we have discussed so far, but that is one side of the coin. The other side is how many libraries exist for this language? What can I draw from? Because not everyone who develops software can start from scratch. You have to buy such things or simply take them from the open source sector.

Thomas Sinnwell: You mentioned libraries. What do you mean by that?

Dr. Patrick Michel: It starts with simple data structures. There are some classic data structures in computer science that one likes to use for development. I don't want to develop them from scratch every time; I want to use a library. It's about being practical as well, if I want to read an image in a specific format, then I can either deal with the format specification or I take a library that can simply load it, that has already implemented that. Then I can save myself the trouble.

Thomas Sinnwell: Or, if I want to perform statistical operations, if I want to display graphs.

Dr. Patrick Michel: Exactly!

Thomas Sinnwell: For all these tasks there is, let's say, ready-made code and that is in a library.

Dr. Patrick Michel: Yes, so there are domains where this is really very widespread. For example, in the field of artificial intelligence, Python is relatively far ahead as a language with a lot of libraries that are simply already there. That makes Python the first choice if you want to develop something in this area.

Thomas Sinnwell: But some people will naturally ask themselves the question: What should I learn? What is en vogue at the moment? And of course you can find many top ten lists. These differ according to the criterion used to determine the top ten order. If you compare different lists, three languages jump out at you. Now on RedMonk, it's JavaScript. You find Java in first place or Python. These correspond quite well with our perception. I would say that C++ is not too far behind, regardless of which of the individual lists you look at.

Dr. Patrick Michel: You notice that there is a good coverage of different paradigms in the most common languages. We have Python as a dynamically typed language and Java as a statically typed language. JavaScript is of course very much on the rise in today's environment, in the web environment and is used in every browser. That means, of course, that it is now one of the most widespread languages. We still use a lot of C++, for example, simply for hardware-related, very efficient programming. With Scala, we have another dedicated language for functional programming. It has to be said that functional programming constructs are increasingly finding their way into other languages. Java, for example, has had higher-order functions since version 8, which would normally have been part of functional programming.

Thomas Sinnwell: Then you can summarise at this point that programming languages also have different strengths or main areas of application for which it makes sense to use them. There is not THE programming language that is above all others.

Dr. Patrick Michel: Exactly! In fact, when a new language comes onto the market that does something particularly well, it is usually due to a new paradigm with a new restriction that makes it particularly good for an application purpose and as soon as the language becomes established, the call becomes louder: Why can I not do everything else with it? If the language is so beautiful, then maybe if I add one or two features, I can do everything with it. That is the wrong approach, because languages are tools that are particularly good or particularly bad for different applications. There will never be a language, which simply replaces all others. It goes exactly against the principle.

Thomas Sinnwell: That ultimately also picks up on the title of the podcast episode, "What do I need in my toolbox? There are different tools used for different types of problems. There will never be one universal tool that can fix everything from a bike to a car or broken sink. Finally, I would like to ask you a personal question: What is your favourite programming language and why?

Dr. Patrick Michel: I have a particular soft spot for Haskell. Haskell is a functional programming language that implements some programming paradigms very rigorously. It is a lot of fun to programme with it. However, it is, let's say, unfortunately not yet as widely used in practice as one would like due to their ecosystem. Especially because of Scala, which is a great alternative.

Thomas Sinnwell: Scala has a good ecosystem.

Dr. Patrick Michel: Exactly!

Thomas Sinnwell: Thank you very much for your statement, for your answer. I hope we have succeeded in giving you a small overview of the topic of programming languages. You can find more information in the show notes. You are welcome to apply and send us your CV. See you next time! Bye!

Dr. Patrick Michel: Bye!

That's it from us again. We hope we were able to bring you a little closer to the world of software development and perhaps make you curious for more. Because there will be a continuation on this topic in our next podcast. Then we will talk about design concepts in software development. One of these concepts is Domain Driven Development. And if you want to know what that is, just tune in. As always, we have further links to the current episode for you in the show notes, and if you want to hear more, we would of course be happy if you subscribed to us. The next episode will be released on 1 July, as always on the first Thursday of the month. We look forward to you!