Comment on "An IDE to enslave them" (Heise c't 10/2018)

My thoughts as I read this article

When I held the latest c't in my hands on Friday and read the article about crossplatform development systems, I was surprised. I will not follow up with a general criticism of magazines now. But if you consider that the c't is also read by decision makers who unfortunately often lack the technological expertise to recognize subliminal advertising or even bashing, this is already alarming. And especially articles of the c't have already served in the past as a basis to support a change from C and C++ to Java or other languages. So I can also imagine that some users of C++Builder and Delphi will have problems this time and will have to justify themselves in their company. After all, it's in black and white in the newspaper, and somehow we still believe it's true when it's printed. And it's precisely the mixture of meaningful facts with little side blows that always seems to be successful here. So I would just like to touch on a few points.

For example, it starts right away with a clear side blow against Keringhan and Ritchie, who developed the programming language C and together wrote the first standard work The C Programming Language on the language. After all, this programming language is the foundation of all our IT systems today, most other languages have their origin here, and is therefore one of the most important developments of the last century. Now these two names only seem to play a role in the C and C++ environment, but you should at least start to spell the names correctly in such an article. Besides C, Dennis Ritchie also played a major role in the first Unix versions, and thus the basis of MacOS and iOS. For this he also received the Turing Award. And Android, which is based on Linux, is ultimately also based on Unix. Dennis Ritchie passed away a week before Steve Jobs, and although his inventions really changed the world, hardly anyone remembers him today.

But back to the article. Keringhan and Ritchie postulated in their standard work The C Programming Language that a "clean" C program can be compiled on different platforms without major modifications. The author also writes that it quickly became clear that a framework was needed. This would be an abstraction layer to encapsulate the characteristics of the operating systems. Now the word postulate is already a first mistake, because in German it means to assume something unproven as given. Now many programs do not use a GUI at all and the language C is sufficient for very concrete tasks. Countless systems written in C and C++ prove that they could be created cross-platform and are still in use today. And when they wrote their book, there were no graphical user interfaces like Windows, there was no mouse and touch or voice controls were not even an option. And nobody would have thought of programming their phone. But just current C++ extends with the threads, processes and the FileSystem the possibility to access resources of the operating system with standard commands.

C++ as a language is universal and offers a standard library with many abstraction possibilities in addition to strict typing and performance. In addition, the system, which is usually written in C or C++ itself, can be accessed directly. Compilers are available for almost all target systems. They translate the programs into highly optimized machine code, which is then executed directly on the respective target system. By the way, in contrast to Java, here all programs are always developed against only one system, the virtual machine (JVM). These programs, converted to bytecode, are then interpreted into the concrete system with the help of this JVM. The JVM itself is usually written in C or C++. And even that often does not work, so there are often several of these virtual machines on the computer, because the programs require a certain version. And also here you can find several GUI frameworks, I only mention Swing, SWT, AWT, JGoodies and JavaFX. And I can remember some projects where new Java programmers "postulated" the use of another framework because it was better than the others. And let's take a look at this article. Here are some different frameworks that use JavaScript.

Of course, the use of a GUI or very special operating system specific services in C++ requires an abstraction layer if you want to implement the program cross-platform, and here vendor dependent or free frameworks can help. And everyone who has listened to me in the last few years will certainly remember the strong warnings not to become dependent. But that also applies to free libraries like Qt. Save for us is the C++ standard and everything we have written or control ourselves. But every programmer or better architect should also know his craft, and know something about the hardware and services used in the background. This is also mentioned in the article, where a team member writes that he or she understands something about the target system. Unfortunately, many C/C++ developers are still in the 90s, and the training of new developers has been more narrow and focused in recent years, mostly on Java or C#. So I remember a conversation with a computer science professor who told me that a student was horrified when he was asked to attend a C-lecture. "What, we're learning programming here?"

I will use this blog to develop over the next days and weeks, piece by piece, a small "framework" that combines the two Embarcadero GUI frameworks in one program, shows new programming techniques, and should be applicable to other GUI frameworks and operating systems. It is far from my mind to develop a new framework, because the world doesn't need it anymore. Rather I will try to use and integrate the possibilities of the given frameworks in each case optimally.

Interpretation at runtime

This is how a section of the article begins. It says here that classical programming languages are compiled and then exist in the form of machine language. Now I hope that not the languages are compiled, but the programs written in this language, and that they are then translated into a binary and directly executable machine code optimized for the respective platform. But what are classical languages? When I try to interpret this, I come across conventional or old-fashioned. Let's get to the point, the article is about native programming languages, which are the backbone of our information systems, and score points in power, performance and resource efficiency. And all big companies ultimately rely on them. For example, Herb Sutter says at a keynote at the Micrsoft Build show in Seattle a few years ago that Microsoft loves the language C# and .net, just like HTML and JavaScript, but is ultimately built on C++. He supplements this statement with the statement that the whole IT industry is built on C/C++.

So one could also read the continuation in the article, the author writes that native programs make maximum use of the resources of the target platform. Only, what does it say? It's simply wrong once again, native programs are optimized to use the resources of the target system as economically as possible. But this is the opposite of the statement in the article. Certainly the author means that native languages allow the programmer to use all capacities directly, he can use all resources without restrictions. But this should be written so clearly. Native programs make optimal use of the resources of a target system, and in most cases they are also more performant. Especially in the time of server farms on the one hand, and mobile systems with batteries on the other hand, a very important characteristic.

The following section deals with the deployment problems with native programs, which must be translated and deployed separately for each target system. Here, the interpreted languages are then mentioned as a way to mitigate them. It turns out that the article follows the old myth that the convenience of the developer is the main concern. However, once a program has been translated and made available, it is started and executed millions of times. Shouldn't the resource requirements and energy consumption be the main focus here? Isn't it enough that we consume more than 10% of our electricity generated in Germany in servers? With many programs that don't care about the resource requirements, develop by programmers who wanted to have it as comfortable as possible? Then why are we discussing 3 litre cars and diesel driving bans if the environment means so little to us?

The article refers here to the classic Basic as a language. But in the end, all scripting languages are in this category, and so are JavaScript and php. But this means that the compiler is missing, which not only translates a program directly into machine code, but can also perform various optimizations. And while when using a native language, the program has translated once, the interpreter translates it over and over again.

Another solution seems to be the coffee-based languages. Besides Java, C# is also part of it. Here, the program is transformed into bytecode, which is then interpreted against the concrete target platform at runtime. Today this is called JIT compiler (Just In Time), because parts are translated into machine code as needed, no longer interpreted line by line. Apart from the fact that this already existed in the past. It was called the P-Code Compiler. The "P" stood for "portable", and was first implemented in the mid-60s in BCPL. By the way, BCPL is often translated as "before C programming language", to bring the word "classic" back into play (BCPL stand for "Basic Combined Programming Language"). Even Niklaus Wirth originally used it when he developed Pascal in the late 60s. These compilers were mostly optimized for fast translation. The language Delphi is a Pascal derivative. But since it was a merit of the following years to transfer the P-Code compilers into real native compilers, which created more performant code, it was difficult to proclaim this for Java. So the new term "bytecode" was born, marketing has always been good old wine to pour into new tubes.

Again, it's Herb Sutter I want to mention. After all, a leading software architect at Microsoft. In his lecture "Not Your Father's C++" at Lang NEXT 2012 he will talk about the development of programming since 1950 and the future. And he compares native C++ with managed Java and C#. So ultimately also the product from his own company. So this talk does not only show the change of the C++ language, but also how important it is to save resources instead of using them to the maximum and wasting them if necessary. The costs for a developer who wants to have it as convenient as possible are negligible in contrast to the runtime costs. For example, only the data centers in Germany require the electricity of 4 medium-sized coal-fired power plants (source: www.swr.de). Worldwide, at least 25 nuclear power plants are needed to generate the electricity that the Internet needs. And, the trend is rising. So we should turn our attention to run-time costs and the waste of resources instead of thinking further about the convenience of programming. Or leave the choice of language to these same programmers.

With steam

The article later contains a paragraph "With steam". This is about solving the disadvantages of JavaScript solutions (and certainly all other non-native programming languages). After all, it seems to need a solution. Here we mention the own runtimes used by some frameworks, which are based on Google's V8 JavaScript Engine, and which would now offer more than enough performance. Again a point where I don't know what to think. What is the "more than enough" and who decides that? Any waste of performance, no matter how small, and thus ultimately waste of resources is no longer acceptable given the millions of times the programs are used. Companies need additional servers because they have switched programs to Java or JavaScript, but nobody questions that. And those "responsible" for this are not called to account. After all, this article again offers these "responsible persons" a justification. We must finally wake up. And then the answer can only be "Going Native", and qualification of the employees so that they can use the more complex native languages to create compact, maintainable code that is resource-saving and high-performance. And the article also states that all the script based or coffee based frameworks are not enough to be performant enough for games. But since the development of an own game engine is not economically viable for normal companies anyway, this is not that bad. But doesn't this mean that they can use additional power in any other case? This is then, in contrast to the development of an own game engine, economically viable? My answer is, NO!

So the author will even pursue this later. In times of eight-core processors the performance even on the phones does not matter anymore. Such ways of thinking are irresponsible nowadays!

The downfall of Embarcadero

In a separate box the author deals with Embarcadero. Let me summarize what it says. It begins with the demise of Borland, once the market leader. This company would still be alive today and would offer the RAD Studio under the name Embarcadero. But the IDE is extremely idiosyncratic and comes with two "GUI Stacks" that would behave completely different. And it is difficult to find Delphi developers, and the C++ dialect used would also be unusual. In addition, there is the danger that using the proprietary approach would lead to a total loss of intellectual property if Embarcadero were to go under, which is implied here. So why then make a decision for the RAD Studio. And then how stupid are those who have done so in the past?

Now the decline of Borland and later Embarcadero has been predicted many times. The company was already dead, too, if some contributions were to be believed. Borland was a leader in the development of C and C++. Turbo C by Bob Jarvis was one of the first integrated development environments, it became a bestseller in its first month. The Turbo C++ compiler by Peter Kukol was one of the first to work without the help of a C compiler in the background, the later Borland Turbo C++3.1 compiler was the first to allow you to create 16 and 32 bit programs together, and with a second "GUI stack" you could create DOS programs in parallel. The OWL of Borland C++ 5.1 (Object Windows Library) was not only available for Windows and OS2 in the mid 90s, but also ported to various Unix derivatives, so it was one of the first commercial cross-platform frameworks. C++Builder X, which was developed in 2003 under the direction of J.P. LeBlanc in cooperation with Nokia, ran on Windows, could create programs for Windows, Linux and Solaris, as well as programs for the leading mobile operating systems at that time, Symbian and Palm OS. Probably it also served as inspiration for other following projects, since it worked with an independent parser and writer layer. Various server services were integrated, finally also the in-house product together. The platform independence was achieved by using wxWidget, where they also send employees for support. The Java IDE "JBuilder" defined the Java IDE standard for many years and was ultimately also the template for the development of Eclipse, which was financed by IBM. And thus the template for most of today's IDEs.

Then things calmed down a bit, but when Alisdair Meredith joined Embarcadero in 2007 and took over responsibility for C++Builder, a new step forward began. Very early on, C++11 features were supported, the Dinkumware library was added as the default library, and Microsoft Build replaced the previous custom make. And they also tried to replace the aging compiler backend. The work was later continued by John Ray Thomas, who provided far-reaching impulses with his experience in embedded systems and extensive C++ experience. Under his leadership, essential parts were implemented with the help of CLang, and besides Windows, programs for Mac OS, Android and iOS can also be created. The new framework "Firemonkey" (FMX) supports cross-platform development, while the previous framework "Virtual Component Library" (VCL) is optimally optimized for Microsoft Windows. This explains the two different "GUI Stacks" mentioned in the article. So this is quite reasonable, because on the one hand an almost direct access to Windows is possible (VCL), but on the other hand platform independent programs can be created (FMX).

The C++ dialect is also not so habituation needy. It is in most cases a CLang compiler, this has been extended by some keywords. You can count them almost on one hand, and they are necessary for integration and compatibility with Delphi. And they are often not even visible. So the "getting used to" dialect is C++ standard! Of course there is a problem here at the moment, due to the focus on a Linux tool chain and the reorganization of the development strategy after the takeover of Embarcadero by IDERA, certainly also due to the change from John Ray Thomas to Oracle, there have been some delays. Unfortunately, the current C++Builder 10.2.3 still only supports the C++11 standard with parts of C++14 and is based on the outdated CLang 3.3, but this is only theoretical for most developers, because they are still in the 90s and companies have saved costs for the necessary training. But, we all look forward to the fall, hope for a new version, and expect Embarcadero to deliver the overdue C++17 compiler in the new version.

Conclusion

In a later conclusion the author writes that one often casts out the devil with the Beelzebub. Again a side blow against Embardacero follows. Instead of the operating system manufacturer, they would now be dependent on Embarcadero, and the developers would look stupid if the destruction begun by the ex-executive board were to continue and Embarcadero were to be stamped into the ground. With this statement in mind, it would be irresponsible to continue funding development with C++Builder, or even to start new development. But that's stupid, unfortunately many believe that. With C++Builder, you can develop large parts platform-independent, and reduce dependency. And regardless of Embarcadero, it is negligent to create dependency by directly using foreign frameworks. This is the very idea of C++. No matter if the manufacturer is Embarcadero, Google, IBM, Oracle, ... or an Open- Source team, from our point of view only the C++ standard and our own code is safe.

And even if the author meant it differently, the whole article shows how true this is. Because instead of investing in qualification of the developers and using native languages, we try to compensate the sometimes serious disadvantages of script based and coffee based languages with JIT, Google's V8 JavaScript Engine and other ideas. That's what I really call casting out the devil with Beelzebub. This is flanked by articles in the computer press that are subliminally based on native systems, be it a few years ago in a c't article that seriously claimed that JAVA is more powerful and performant than C++, than this article is now. I'm sure that many companies will look in stupidly if they need a wider Internet connection and new servers after the changeover, and the batteries of the eight-core processor phones and tablets of the field staff are empty before the end of the day. But I'm sure the programmer is sitting in a comfortable chair, enjoying the convenience of his programming environment.