Kommentar zu "Eine IDE, sie zu knechten" (Heise c't 10/2018)

Kommentar zu "Eine IDE, sie zu knechten" (Heise c't 10/2018)

Meine Gedanken, als ich diesen Artikel gelesen habe

Als ich am Freitag die neuste c't in den Händen hielt und den Artikel über Crossplattform- Entwicklungssysteme gelesen habe, war ich überrascht. Ich werde jetzt keine allgemeine Kritik an Zeitschriften folgen lassen. Aber wenn man bedenkt, dass die c't auch von Entscheidungsträgern gelesen wird, denen es leider oft an technologischen Spezialwissen fehlt, die unterschwellige Werbung oder auch das Bashing zu erkennen, ist das schon bedenklich. Und gerade Artikel der c't haben in der Vergangenheit schon als Basis gedient, einen Wechsel von C und C++ hin zu Java oder anderen Sprachen zu untermauern. So kann ich mir auch dieses Mal vorstellen, dass einige Nutzer des C++Builders und von Delphi Probleme bekommen und sich in ihrem Unternehmen rechtfertigen müssen. Denn schließlich steht es ja schwarz auf weiss in der Zeitung, und irgendwie glauben wir immer noch, dass es wahr ist, wenn es gedruckt ist. Und gerade die Mischung von sinnvollen Fakten mit kleinen Seitenhieben erscheint hier immer wieder erfolgreich. So möchte ich auch nur auf einige Punkte eingehen.


So beginnt es auch gleich mit einem deutlichen Seitenhieb gegen Keringhan und Ritchie, die die Programmiersprache C entwickelt und gemeinsam das erste Standardwerk zu der Sprache geschrieben haben. Diese Programmiersprache ist immerhin das Fundament aller unser heutigen IT Systeme, die meisten anderen Sprachen haben ihren Ursprung hier, und ist damit eine der wichtigsten Entwicklungen des letzten Jahrhunderts. Nun scheinen diese beiden Namen nur im C und C++ Umfeld eine Rolle zu spielen, aber man sollte wenigsten in einem solchen Artikel damit beginnen, die Namen richtig zu schreiben. Dennis Ritchie hat neben C auch maßgeblich an den ersten Unix Versionen, und damit der Basis von MacOS und iOS, mitarbeitet. Dafür erhielt er auch den Turing Award. Und auch Android, welches auf Linux basiert, ist letztlich auch auf Unix zurückzuführen. Dennis Ritchie ist eine Woche vor Steve Jobs verstorben, und obwohl seine Erfindungen die Welt wirklich veränderten, erinnert sich heute kaum jemand an ihn. 

Aber zurück zum Artikel. Keringhan und Ritchie hätten in ihrem Standardwerk zu C postuliert, dass ein "sauber" aufgebautes C- Programm auf verschiedenen Plattformen ohne große Modifikationen übersetzbar ist. Weiter schreibt der Autor, dass schnell klar würde, dass ein Framework nötig ist. Dieses wäre eine Abstraktionsschicht zum Kapseln der Eigenheiten der Betriebssysteme. Nun ist schon das Wort postulieren ein erster Fehlgriff, bedeutet er doch im deutschen, etwas unbewiesen als gegeben anzunehmen. Nun nutzen viele Programme gar keine GUI und die Sprache C ist ausreichend für sehr konkrete Aufgaben. So beweisen unzählige in C und C++ geschriebene Systeme, dass sie plattformübergreifend erstellbar waren, und auch heute noch im Einsatz sind. Und als die beiden ihr Buch geschrieben haben, gab es noch keine grafischen Oberflächen wie Windows, es gab noch keine Maus und an Touch oder Sprachsteuerungen war gar nicht zu denken. Und niemand wäre auf die Idee gekommen, sein Telefon zu programmieren. Aber gerade aktuelles C++ erweitert mit den Threads und Prozessen, sowie dem FileSystem die Möglichkeit auf Ressourcen des Betriebssystems mit Standardbefehlen zuzugreifen.

C++ als Sprache ist universell und bietet neben der strengen Typisierung und Performance eine Standardbibliothek mit vielen Abstraktionsmöglichkeiten. Außerdem kann direkt auf das System, das meistens selber in C oder C++ geschrieben ist, zugegriffen werden. Compiler stehen für nahezu alle Zielsysteme zur Verfügung. Dabei werden die Programme in hochoptimierten Maschinencode übersetzt, der dann direkt auf dem jeweiligen Zielsystem ausgeführt werden. Übrigens im Gegensatz zu Java, hier werden alle Programme immer nur gegen ein einziges System entwickelt, die virtuelle Maschine (JVM). Diese, zu einem Bytecode umgewandelten Programme werde dann mit Hilfe dieser JVM in das konkrete System interpretiert. Die JVM ist meistens selber in C oder C++ geschrieben. Und selbst das klappt oft nicht, so finden sich auf dem Rechner oft mehrere von diesen virtuelle Maschinen, da die Programme eine bestimmte Version voraussetzen. Und auch hier finden sich diverse GUI Frameworks, ich nenne hier nur Swing, SWT, AWT, JGoodies und JavaFX. Und ich kann mich an manches Projekt erinnern, in denen neue Java Programmierer die Nutzung eines anderen Framework "postulierten", weil es besser als die anderen sei. Und schauen wir uns diesen Artikel an. Hier finden sich gleich einige diverse Frameworks, die JavaScript benutzen.

Natürlich verlangt die Nutzung einer GUI oder sehr spezieller betriebssystemspezifischer Dienste in C++ einer Abstraktionsschicht, wenn man das Programm plattformübergreifend umsetzen möchte, und hier können herstellerabhängige oder freie Frameworks helfen. Und jeder, der mir in den letzten Jahren  zugehört hat, erinnert sich bestimmt an die nachdrücklichen Warnungen, sich nicht abhängig zu machen. Das gilt aber auch für freie Bibliotheken wie Qt. Sicher für uns ist der C++ Standard und alles was wir selber geschrieben haben oder kontrollieren. Aber jeder Programmierer oder besser Architekt sollte sein Handwerk auch verstehen, und etwas über die Hardware und Dienste wissen, die im Hintergrund benutzt werden. Unterschwellig steht dieses ja auch im Artikel, wo von einem Teammitglied geschrieben wird, dass etwas vom Zielsystem verstehen Das ist ja nun eine Binsenweisheit. Leider stecken viele C/C++- Entwickler gedanklich noch in den 90iger Jahren, und die Ausbildung der neuen Entwickler war in den letzten Jahre mehr schmalspurig und fokussiert, meistens auf Java oder C#. So erinnere ich mich an Gespräch mit einem Informatikprofessor, der mir erzählte, dass ein Student entsetzt war, als er an einer C- Vorlesung teilnehmen sollte. "Wie, wir lernen hier programmieren?"

Ich werde diesen Blog nutzen, um in den nächsten Tagen und Wochen Stück für Stück ein kleines "Framework" zu entwickeln, dass die beiden GUI Frameworks von Embarvadero in einem Programm vereinigt, neue Programmiertechniken zeigt, und auch auf andere GUI- Frameworks und Betriebssysteme anwendbar sein sollte. Dabei liegt es mir fern, ein neues Framework zu entwickeln, denn dieses braucht die Welt nicht mehr. Vielmehr werde ich versuchen, die Möglichkeiten der gegebenen Frameworks jeweils optimal zu nutzen und zu integrieren.

Interpretation zur Laufzeit

So beginnt ein Bereich des Artikels. So steht hier, dass klassische Programmiersprachen kompiliert werden und dann in Form von Maschinensprache vorliegen. Nun hoffe ich mal, dass nicht die Sprachen kompiliert werden, sondern die in dieser Sprache geschrieben Programme, und dass sie dann in einen binären und für die jeweilige Plattform optimierten direkt ausführbaren Machinencode übersetzt werden. Aber was sind klassische Sprachen? Wenn ich dieses zu deuten versuche, komme ich auf herkömmlich oder altmodisch. Bringen wir es mal auf den Punkt, der Artikel meint hier native Programmiersprachen, diese bilden das Rückrat unser Informationssysteme, und punkten in Leistung, Performance und Ressourcensparsamkeit. Und alle großen Firmen setzen letztlich auf diese. So sagt Herb Sutter auf einer Keynode der Micrsoft Build- Messe in Seattle vor einigen Jahren, dass Microsoft die Sprache C# und .net liebt, genauso wie HTML und JavaScript auch, aber letztlich auf C++ gebaut ist. Er ergänzt diese Aussage um die Feststellung, dass die ganze IT- Branche auf C/C++ aufgebaut ist.

So könnte man auch die Fortsetzung im Artikel lesen, der Autor schreibt, dass native Programme die Ressourcen der Zielplattform maximal nutzen. Nur, was steht da? Es ist schlichtweg wieder einmal verkehrt, den native Programme sind darauf optimiert, mit den Ressourcen des Zielsystems möglichst sparsam umzugehen. Das ist aber das Gegenteil von der Aussage im Artikel. Sicher meint der Autor, dass native Sprachen dem Programmierer die direkte Nutzung aller Kapazitäten ermöglichen, er alle Ressourcen uneingeschränkt nutzen kann. Nur sollte das auch so klar geschrieben werden. Native Programme nutzen die Ressourcen eines Zielsystems optimal, und dabei sind sie meistens auch performanter. Gerade in der Zeit der Serverfarmen auf der einen Seite, und der mobilen Systeme mit Akkus auf der anderen Seite, eine sehr wesentliche Eigenschaft.

Im folgenden geht es dann um die Bereitstellungsprobleme mit nativen Programmen, die für jedes gewünschte Zielsystem separat übersetzt und bereitgestellt werden müssen. Hier werden dann die interpretierten Sprachen als Weg zur Entschärfung genannt. Dabei zeigt sich, dass der Artikel dem alten Mythos folgt, dass die Bequemlichkeit des Entwicklers im Vordergrund steht. Ein Programm wird aber, nachdem es übersetzt und bereitgestellt wird, millionenfach gestartet und ausgeführt. Sollte da nicht der Ressourcenbedarf und Energieverbrauch im Vordergrund stehen? Reicht es nicht, dass wir mehr als 10% unseres in Deutschland erzeugten Stroms in Servern verbrauchen? Mit vielen Programmen, die sich nicht um den Ressourcenbedarf kümmern, von Programmieren entwickeln, die es möglichst bequem haben wollten? Warum diskutieren wir dann über 3 Liter Autos und Dieselfahrverbote, wenn uns die Umwelt so wenig bedeutet?

Der Artikel nennt hier den Klassiker Basic als Sprache. Aber letztlich sind alle Skriptsprachen in dieser Kategorie, und damit auch JavaScript und php. Damit fehlt aber gerade der Compiler, der ein Programm nicht nur direkt in Machinencode übersetzt, sondern auch diverse Optimierungen durchführen kann. Und während bei der Nutzung einer nativen Sprache das Programm einmal übersetzt hat, wird es beim Interpreter immer und immer wieder übersetzt.

Eine weitere Lösung scheinen die coffee- based Sprachen zu sein. Neben Java gehört auch C# dazu. Hier wird das Programm in einen Bytecode transformiert, der dann zur Laufzeit gegen die konkrete Zielplattform interpretiert wird. Das nennt man heute JIT- Compiler (Just In Time), da Teile bedarfsgerecht in Maschinencode übersetzt werden, nicht mehr Zeile für Zeile interpretiert wird. Abgesehen, dass es dieses früher schon gab. Da nannte man es P-Code Compiler. Dabei stand das "P" für "portable", und wurde Mitte der 60iger Jahre in BCPL erstmals umgesetzt. BCPL wird übrigens häufig als "before C programming language" übersetzt, um mal das Wort "klassisch" wieder ins Spiel zu bringen. Auch Nikolaus Wirth nutzte dieses ursprünglich, als er Ende der 60iger Jahre Pascal entwickelte. Diese Compiler waren meistens auf eine schnelle Übersetzung optimiert. Die Sprache Delphi ist ein Pascal Derivat. Da es aber ein Verdienst der folgenden Jahre war, die P-Code Compiler in echte native Compiler zu übertragen, die performanteren Code erstellten, konnte man dieses für Java schlecht proklamieren. So entstand der neue Begriff "Bytecode", Marketing war schon immer gut alten Wein in neue Schläuche zu füllen.

Wieder ist es Herb Sutter, den ich erwähnen möchte. Immerhin ein führender Software- Architekt bei Microsoft. In seinem Vortrag "Not Your Father’s C++" auf der Lang NEXT 2012 spricht er über die Entwicklung der Programmierung seit 1950 und die Zukunft. Und er vergleicht natives C++ mit managed Java und C#. Also letztlich auch dem Produkt aus dem eigenen Haus. Dieser Vortrag zeigt also nicht nur die Veränderung der Sprache C++, sondern auch, wie wichtig es ist, Ressourcen zu schonen, anstatt sie maximal auszunutzen, und gegebenenfalls zu verschwenden. Die Kosten für einen Entwickler, der es möglichst bequem haben möchte, sind im Gegensatz zu den Laufzeitkosten verschwindend gering. So benötigen nur die Rechenzentren in Deutschland den Strom von 4 mittelgroßen Kohlekraftwerken (Quelle: www.swr.de). Weltweit werden mindestens 25 Atomkraftwerke benötigt, um den Strom zu erzeugen, den das Internet benötigt. Und, die Tendenz ist steigend. Wir sollten also unseren Blick auf die Laufzeitkosten und die Verschwendung von Ressourcen wenden, anstatt weiter über die Bequemlichkeit beim Programmieren nachzudenken. Oder eben diesen Programmieren die Wahl der Sprache überlassen.

Mit Dampf

Im Artikel findet sich später ein Absatz "Mit Dampf". Hier geht es um eine Lösung der Nachteile von JavaScript Lösungen (und sicher allen anderen nicht nativen Programmiersprachen). Immerhin, es scheint ja einer Lösung zu bedürfen. Hier werden die von einigen Frameworks genutzten eigenen Runtimes genannt, die auf Basis von Googles V8-JavaScript Engine entstanden sind, und die nun mehr als genug Performance bieten würden. Wieder ein Punkt, wo ich nicht weiß, was ich denken soll. Was ist den "mehr als genug", und wer entscheidet das? Jede noch so kleine Verschwendung von Performance und damit letztlich Verschwendung von Ressourcen ist bei der millionenfachen Nutzung der Programme nicht mehr hinnehmbar. Firmen benötigen zusätzliche Server, weil sie Programme auf Java oder JavaScript umgestellt haben, aber keiner hinterfragt das. Und die dafür "Verantwortlichen" werden nicht zur Rechenschaft gezogen. Immerhin bietet auch dieser Artikel diesen "Verantwortlichen" wieder eine Rechtfertigung. Wir müssen endlich aufwachen. Und dann kann die Antwort nur "Going Native" heißen, und Qualifikation der Mitarbeiter, damit sie die komplexeren nativen Sprachen nutzen können, um kompakten, wartbaren Code zu erstellen, der ressourcenschonend und performant ist. Und der Artikel stellt ja dann auch fest, dass alle die script based oder coffee based Frameworks nicht ausreichen, um performant genug für Spiele zu sein. Da aber die Entwicklung einer eigenen Spiele- Engine ohnehin für normale Unternehmen wirtschaftlich nicht in Frage kommt, ist das nicht so schlimm. Das bedeutet doch aber, dass sie in jedem anderen Einsatzfall weiteren zusätzlichen Strom verbrauchen können? Das ist dann, im Gegensatz zur Entwicklung einer eigenen Spiele- Engine wirtschaftlich tragbar? Meine Antwort ist, NEIN!

So setzt der Autor später sogar noch nach. In Zeiten von Achtkern-Prozessoren spielt die Performance selbst auf den Telefonen keine Rolle mehr. Solche Denkweisen sind in der heutigen Zeit unverantwortlich!

Der Niedergang von  Embarcadero

In einem separaten Kasten beschäftigt sich der Autor mit Embarcadero. Ich fasse mal zusammen, was da steht. Er beginnt mit dem Niedergang des einst marktführenden Unternehmens Borland. Dieses wäre immerhin noch lebendig und würde heute unter dem Namen Embarcadero das RAD Studio anbieten. Dabei ist die IDE extrem eigenwillig und bringt zwei "GUI Stacks" mit, die sich völlig unterschiedlich verhalten würden. Und es ist schwierig Delphi- Entwickler zu finden, und der verwendete C++- Dialekt wäre ebenfalls ungewöhnlich. Hinzu kommt die Gefahr, dass die Nutzung des proprietären Ansatzes bei einem Untergang von Embarcadero, der hier ja unterschwellig angedeutet wird, zu einem Totalverlust an geistigen Eigentum führt. Warum also sollte man danach eine Entscheidung für das RAD Studio treffen. Und wie dumm sind dann die, die das in der Vergangenheit getan haben?

Nun wurde der Niedergang von Borland und später Embarcadero schon oft vorhergesagt. Die Firma war auch schon tot, wenn man einigen Beiträgen glauben geschenkt hätte. Borland war führend für die Entwicklung von C und C++. Turbo C von Bob Jarvis war eine der ersten integrierten Entwicklungsumgebungen, es wurde bereits im ersten Monat zum Verkaufsschlager. Der Turbo C++ Compiler von Peter Kukol war einer der ersten, der ohne Hilfe eines C- Compilers im Background auskam, der spätere Borland Turbo C++3.1 Compiler war der erste, mit dem man 16 und 32 bit Programme gemeinsam erstellen konnte, und mit einem zweiten "GUI Stack" parallel noch DOS Programme. Die OWL des Borland C++ 5.1 (Object Windows Library) war Mitte der 90iger Jahre nicht nur für Windows und OS2 verfügbar, sondern auch für diverse Unix Derivate portiert, war also eine der ersten kommerziellen plattformübergreifende Frameworks. Der C++Builder X der 2003 unter Leitung von J.P. LeBlanc in Zusammenarbeit mit Nokia entwickelt wurde, lief unter Windows, konnte Programme für Windows, Linux und Solaris erzeugen, außerdem Programme für die damals führenden mobilen Betriebssysteme Symbian und Palm OS. Wahrscheinlich diente er auch als Inspiration für andere folgenden Projekte, da hier mit unabhängiger Parser- and Writer- Schicht gearbeitet wurde. Dabei wurde diverse Serverdienste integriert, letztlich auch das hauseigene Produkt together. Die Plattform- Unabhängigkeit wurde durch die Nutzung von wxWidget erreicht, hier sendet man auch Mitarbeiter zur Unterstützung. Die Java- IDE "JBuilder" definierte jahrelang den Java IDE Standard und war letztlich auch die Vorlage für die von IBM finanzierte Entwicklung von Eclipse. Und damit die Vorlage der meisten heutigen IDEs.

Dann wurde es etwas ruhiger, aber als 2007 Alisdair Meredith zu Embarcadero kam und die Verantwortung für den C++Builder übernahm, begann ein neuer Sprung vorwärts. So wurden sehr früh Eigenschaften von C++11 unterstützt, die Dinkumware Library als Standardbobliothek hinzugenommen, Microsoft Build ersetzte das bisherige eigene Make. Und man versuchte auch das in die Jahre gekommene Compiler- Backend  auszutauschen. Die Arbeit wurde später von John Ray Thomas fortgesetzt, der mit seinen Erfahrungen bei embedded Systemen und reichhaltigen C++ Erfahrungen weitreichende Impulse setze. Unter seiner Führung wurden wesentliche Teile mit Hilfe von CLang umgesetzt, und neben Windows können auch Programme für Mac OS, Android und iOS erstellt werden. Das neue Framework "Firemonkey" (FMX) unterstützt die plattformübergreifende Entwicklung, während das bisherige Framework "Virtual Component Library" (VCL) optimal für Microsoft Windows optimiert ist. Das erklärt die beiden, im Artikel erwähnten und unterschiedlichen "GUI Stacks". Dieses ist also durchaus vernünftig, da auf der einen Seite ein nahezu direkter Zugriff auf Windows möglich ist (VCL), auf der anderen Seite aber auch plattformunabhängige Programme erstellt werden können (FMX).

Der C++ Dialekt ist auch nicht so gewöhnungsbedürftig. Es ist in den meisten Fällen ein CLang- Compiler, dieser wurde um einige Schlüsselwörter ergänzt. Diese kann man nahezu an einer Hand abzählen, und sie sind zur Integration und Kompatibilität mit Delphi notwendig. Und sie sind oft nicht einmal sichtbar. Der "gewöhnungsbedürftige" Dialekt ist also C++ Standard! Natürlich gibt es hier gegenwärtig ein Problem, durch die Fokussierung auf eine Linux Tool- Chain und die Reorganisation der Entwicklungsstrategie nach der Übernahme von Embarcadero durch IDERA, sicher auch durch den Wechsel von John Ray Thomas zu Oracle, ist es zu einigen Verzögerungen gekommen. So unterstützt der aktuelle C++Builder 10.2.3 leider nach wie vor nur den Standard C++11 mit Teilen von C++14 und basiert auf dem in die Jahre gekommenen CLang 3.3. Dieses ist für die meisten Entwickler allerdings nur theoretisch, weil sie ihrem Wissensstand folgend noch in den 90iger Jahren verweilen, und die Firmen Kosten für die notwendige Weiterbildung gespart haben. Aber, wir schauen alle in den Herbst, hoffen auf eine neue Version, und erwarten von Embarcadero, das sie den überfälligen C++17- Compiler in der neuen Version abliefern werden.

Fazit

In einem späteren Fazit schreibt der Autor, dass man oft den Teufel mit dem Beelzebub austreibt. Wieder folgt ein Seitenhieb gegen Embardacero. Anstatt vom Hersteller des Betriebssystems wäre man jetzt abhängig von Embarcadero, und die Entwickler würden dümmlich schauen, wenn hier die vom Ex- Vorstand begonnene Zerstörung fortgesetzt, und Embarcadero in den Boden gestampft würde. Mit dieser Aussage im Rücken wäre es schon unverantwortlich, weiterhin Entwicklungen mit dem C++Builder zu finanzieren, oder gar neue zu beginnen. Aber das ist dumm, leider glauben viele das. Mit dem C++Builder können weite Teile plattformunabhängig entwickelt, und die Abhängigkeit reduziert werden. Und unabhängig von Embarcadero, es ist fahrlässig durch die direkte Nutzung von fremden Frameworks eine Abhängigkeit zu erzeugen. Das ist ja gerade die Idee von C++. Egal ob der Hersteller Embarcadero, Google, IBM, Oracle, .... oder ein Open- Source Team ist, sicher ist aus unser Sicht nur der C++ Standard und der eigene Code.

Und auch, wenn der Autor es anders gemeint hat, der ganze Artikel zeigt, wie wahr das ist. Denn anstatt in Qualifikation der Entwickler zu investieren und native Sprachen zu verwenden, versucht man mit JIT, Googles V8-JavaScript Engine und anderen Ideen die teilweise gravierenden Nachteile von script based and coffee based Sprachen auszugleichen. Das nenne ich wirklich den Teufel mit dem Beelzebub austreiben. Flankiert wird das mit Artikeln in der Computerpresse, die unterschwellig gegen native Systeme bashen, sei es vor einigen Jahren in einem c't- Artikel, der ernsthaft behauptete, JAVA ist leistungsfähiger und performanter als C++, als jetzt auch diesem Artikel. Ich bin mir sicher, dass viele Firmen dümmlich reinschauen werden, wenn sie nach der Umstellung eine breitere Internetleitung und neue Server benötigen würden, und die Akkus der Achtkern- Prozessor Telefone und Tablets der Außendienstmitarbeiter noch vor dem Feierabend leer sind. Aber ich bin mir sicher, der Programmierer sitzt in einem bequemen Stuhl, und erfreut sich an der Bequemlichkeit seiner Programmierumgebung.