Pointless speed-comparison between java, C++ and Python

#include <iostream>
#include "math.h"
// g++ -O3 1.cpp 
//time ./a.out > 2.txt
int main()
{
  long count;

  for(long number=1;number<1000000;number++) 
  {
    count=0;
    for(long a=2;a<=sqrt(number);a++) {
      if(number%a==0) {
        count++;
      }
    }
    if(count==0) {
      std::cout << number << "\n";
    }
  }  
  return 0;
}


--------------------------------------------
# python 2.py
import math
for number in range(1, 1000000):
    count=0
    for a in range(2, int(math.sqrt(number))+1):
      if (number % a) == 0:
        count+=1
    if count==0: 
      print number

---------------------------------------------
// javac prim3.java
// java prim3
public class prim3
{
  public static void main (String[] args)
  {
    long count;
    for (int number = 1; number < 1000000; number++) {
      count=0;
      for (int a = 2; a <= Math.sqrt(number); a++) {
        if (number%a==0) {
          count++;
        }
      }
    if(count==0) {
      System.out.println(number);
    }

    }

  }
}


If you run this examples you will get:

c++: 6,9s

python: 59,7s

java: 5,78s

The winner in this speed race is java. Who has think so? And only on place 2 is C++. But clear favorite in how easy it is to write the code, python is the secret winner. But his performance is a nightmare. Python is 10 times slower than the other candidates. But, if you ask a programmer which language he prefer, than the answer would be „C++“. Because only with that language you have the feeling that you are on bare-metal. That you write efficient code. Even if you know that’s a lie, that Java is a little bit slower, you believe that C++ is faster. Only C++ can give you the feeling, that you’re know what you doing, that you’re master of your machine, that you are a good programmer.

„Hey, i use C++ and I use classes“. That is the answer we hear. Thats what real man are doing. What other language exists, which aren’t tested here? Fortran, Forth, Assembler, C#, perhaps Visual Basic and Lua. But the strangest method to program something is to use lisp and compile the program for running on a neurocomputer, see „A neurocomputer board based on the ANNA neural network chip“, 1991.

Why that (converting a lisp programm to a analog neural network chip) is possible? I have no idea. According my information it should not, because neural networks are not turing powerful. But it seems, that the authors of that paper doesn’t even heard about it. Also the guys, who invented „IBM Compass“ (simulator for truenorth chipset).

Advertisements

Ernüchterung in Bezug auf Scrolling-Text

Um mal etwas neues auszuprobieren habe ich auf Youtube mal keine SFML Animation hochgeladen sondern stattdessen ein wenig Text über den Bildschirm scrollen lassen. Die erste Idee war es, ein Laufband zu verwenden wie es auch TV Stationen tun. Leider ruckelte das Resultat massiv besonders in hoher Geschwindigkeit. Also war die nächste Idee den Text von unten nach oben im Starwars Mode hochlaufen zu lassen. Das funktionierte schon besser aber immernoch ist die Textmenge zu niedrig während die Qualität extrem schlecht ist. Und das obwohl ich SFML mit 250 Frames per Second habe laufen lassen. Aber irgendwie stammte etwas mit der Synchronisation nicht. Letztlich scheint es wohl so zu sein, dass Text in Youtube Videos keine gute Idee ist.

Was man jetzt noch ausprobieren könnte wäre Text aus dem Off einzusprechen: entweder mittels Natural Voice oder noch besser über Text2Speech. Dort hätte man dann eine halbwegs gute Qualität bei hoher Textmenge pro Minute. Nur, woher nimmt man einen Text2Speech Generator? espeak klingt nicht so toll, also muss man sich wohl selber einen programmieren. Wie sowas aussehen könnte ist derzeit unklar. Am liebsten würde ich einfach ein Plugin Modul für LMMS verwenden was möglichst dem Magic Voice auf dem C-64 nachempfunden ist, aber bisher habe ich sowas noch nicht finden können.

Aktuell gibt es trotzdem zwei Varianten die man nutzen könnte. Einmal die Software flite welche bei Fedora out-of-the-box funktioniert: „flite hello.txt -o hello.wav“ Leider kann flite nur englische Texte vorlesen. Auf Deutsch wäre das Online-Portal Wikipedia-pediaphon geeeignet wo man Texte über copy&paste eingeben kann und dank der vorinstallierten German-Dictionary wird das ganze schön auf Deutsch ausgegeben.

Sind OWL Ontologien Betrug?

Ich will das ganze mal etwas vorsichtiger angehen und habe es als Frage formuliert. Möglicherweise habe ich das Konzept einfach noch nicht richtig verstanden und in Wahrheit ist alles ganz anders. Doch schön der Reihe nach. Die aktuelle Version des Ontologie-Editors Protege für Linux habe heruntergeladen. Nach dem Start der 100 MB großen Java-Applikation habe ich das berühmte Pizza-Ontologie Beispiel aufgerufen und mich ein wenig durch die Menüs geklickt. Leider hat das nicht dabei geholfen, besser zu verstehen, was der Sinn von OWL ist. In den Menüs habe ich etwas versteckt zwei Funktionen entdeckt, einmal kann man aus der Ontologie Javacode erzeugen und einmal kann man eine HTML Dokumentation erzeugen. Die HTML Dokumentation sieht ein wenig aus wie bei Doxygen. Man hat verschiedene Klassen, die Attribute enthalten. Der Grund warum ich etwas skeptisch bin hat damit zu tun, dass unklar ist, wie daraus eine fertige Anwendung werden soll.

Zur Erinnerung: OWL ist angetreten um Domain-Knowledge machinenlesbar aufzubereiten. Mein Eindruck ist jedoch eher, dass man es am besten mit Mediawiki vergleichen kann. Es also eine Markup Sprache ist um darin Text hineinzuschreiben. Nun, Mediawiki ist irgendwie auch ein Tool zur Wissensmodellierung, aber in erster Linie ist es eine Webapplikation. Das heißt, Mediawiki selber weiß gar nichts, sondern die Leute die dort Content hochladen sind die Experten. Gut vorstellen kann ich mir, dass man Protege verwendet um darin ein Lexikon zu erstellen. Das heißt, man kann da Kategorien definieren, und diese zu einem Glossar erweitern. Aber was dann? Der Nachteil von Mediawiki ist ja, dass die Inhalte nicht machinenlesbar sind. Die chinesische Version von Wikipedia ist für deutschsprachige Leser komplett unzugänglich. Der Grund ist, dass die Wikimarkup-Sprache eben kein ausführbarer Computercode ist sondern natürlichsprachlich funktioniert.

Vom Anspruch her ist OWL und Protege angetreten ein Zwischending zwischen Domain-Knowledge auf der einen Seite und ausführbarem Computercode auf der anderen Seite zu sein. Leider wird dieses Ziel nicht erreicht. Für Programmierer ist Protege komplett nutzlos, wenn man seine Klassen dokumentieren will kann man auch einfach doxygen aufrufen und erhält ebenfalls eine schicke HTML Ausgabe, sogar in grafischer Darstellung.

Richtig ist zwar, dass OWL und Protege bei Google Scholar ein sehr breit diskutiertes Thema ist, aber irgendwie werde ich den Verdacht nicht los, dass es nur heiße Luft ist. Möglicherweise kann man das Paradox so erklären: auf der einen Seite gibt es heute sehr mächtige Programimersprachen wie C++ die nach dem imperativen Modell arbeiten. Es gibt einen klaren Bedarf nach einem Nachfolger zu C++, also eine Sprache die leichter zu programmieren ist und mit der sich besser Domain-Knowledge formalisieren lässt. OWL und Semanticweb ist aber nicht die Antwort auf das Problem. Weil man jetzt eine Domäne erst in Protege modelliert, dannnochmal in C++ und am Ende immernoch ohne ausführbaren Code dasteht. Wäre Protegie die Lösung gäbe es Beispiele wo jemand zuerst eine Ontologie erstellt, diese dann mit Rules anreichert und zu guter letzt daraus ein Computerspiel macht. Aber genau das geht nicht.

Was jedoch Sinn macht, in der Literatur aber sehr selten thematisiert wird (Ausnahme: https://thesai.org/Downloads/Volume2No2/Paper%2018-To%20Generate%20the%20Ontology%20from%20Java%20Source%20Code.pdf) ist der umgekehrte Weg. Wo man also Java Sourcecode in eine OWL Datei konvertiert. Genausogut könnte man aber auch Java Code in die Mediawiki-Syntax überführen und sich ähnlich wie bei Doxygen durch die Topics klicken. Nur, irgendwas verbessert sich dadurch nicht, weil man ja erstmal den Java Sourcecode haben muss. Die Tragik mit OWL ist, dass es zu stark Meta ist, also eine semantische Auszeichnungssprache für vorhandenen Content darstellt. Man kann damit natürliche Texte annotieren, man kann auch Java Code anreichern, aber beides hat nichts mit Wissensmodellierung zu tun.

Insofern ist die eingangs formulierte Frage, ob Protege möglicherweise nur Betrug ist berechtigt. Ich habe jedenfalls subjektiv das Gefühl, als ob das Semantic Web overrated und overhyped ist.

DOMAINWISSEN
Wenn Protege ungeeignet ist um Domainknowledge zu formalisieren, was ist dann die best-Practice Methode? Dazu ein Beispiel. Es geht um den Bereich Verkehrswissenschaft. Dieses Themengebiet ist für autonome Autos interessant. Bei Wikipedia hat dazu jemand schon vorgearbeteitet und eine eigene Kategorie angelegt: https://de.wikipedia.org/wiki/Kategorie:Verkehrswissenschaft Es handelt sich um eine HTML Datei die dynamisch aus einer Datenbank generiert wurde worin wiederum die Mediawiki-Markup-Language eingesetzt wird. Man kann sagen, dass diese Wikiseite die Domäne ist um die es geht. Jetzt die ketzerische Frage: was kann man hier mit OWL und Protege besser machen? Semantisch annotiert sind die Stichworte bereits, und in einem machinenlesbaren HTML Format sind sie auch schon gespeichert. Dennoch ist die Wikipedia Seite alles andere als maschinenlesbar, sondern man muss erstens Deutsch können, zweitens muss man sich durch die Stichworte klicken und drittens wird da möglicherweise noch auf weitere PDF Dokumente verwiesen. Anders gesagt, Wissen wurde zwar in der Wikipedia formalisiert, aber es ist kein ausführbarer Java Code.

Und genau an diesem Beispiel wird deutlich wo die Schwäche von Protege / OWL liegt. Setzt man es als Alternative zu Mediawiki ein, macht es keinen Sinn, weil Mediawiki ziemlich perfekt funktioniert und praxiserprobt ist. Man kann in Mediawiki ausgezeichnet Informationen zusammentragen über beliebige Fachgebiete, es ist das ideale Werkzeug zum systematischem Anlegen eines Wissensspeicher. Wenn man Protege als Hilfsmittel einsetzt um damit Java Code zu erzeugen kann man ebenfalls nur verlieren, weil das mit IDEs wie Eclipse sehr viel besser geht. Dort gibt es sogar eingebaute Syntaxprüfer und Formatierungstools um die Klammern zu setzen und man kann aus bestehenden Libraries auswählen. Wo also ist der Einsatzzweck für Protege? Mir kommt das Tool wie ein überflüssiges Rad am Wagen vor …

Das Geheimnis hinter OWL

Anfänglich betrachtet man das Semantic Web und OWL keinen Sinn. Es gibt irgendwo im Internet eine Anleitung wie man mit Protege eine Ontologie erstellt. Geradezu peinlich detailiert wird darin der Leser an die Hand genommen und soll auf bestimmte Buttons klicken um Klassen zu erzeugen. In einem vorherigen Blogpost habe ich das ganze als Betrug bezeichnet doch in Wirklichkeit steckt viel mehr dahinter. Und zwar ist das Aufblühen von Protege und der OWL-Beschreibungssprache Ausdruck von sozialen Bedürfnissen. Heutzutage sitzen die Softwarekonzerne auf sehr viel Sourcecode, der jedoch nicht unter der GPL Lizenz veröffentlicht wird sondern Firmenintern erstellt wurde und folglich auch dort bleiben soll. Und weil das den Firmen bewusst ist, haben sie einen Bedarf entwickelt nach einer Meta-Sprache um diesen Sourcecode zu katalogisieren. Nicht so, wie sich das Richard Stallmann vorgestellt hat, das man also einfach die 10 GB große Zipdatei auf github hochlädt und sie „free-to-the-people“ stellt sondern stattdessen haben die Firmen angefangen sich für OWL zu interessieren. Machen wir es etwas genauer: wenn man eine 1 MB große Java Sourcecode Datei hat, die firmenintern erstellt wurde kann man daraus automatisiert eine OWL Datei erzeugen. Diese besitzt die selben Klassen wie die Java Datei auch, enthält aber nicht den kompletten Sourcecode. Vergleichbar, wie die Kataloge die früher in den Bibliotheken verwendet wurden, wo der Titel, Autor und ein Abstract verzeichnet wurde aber nicht der eigentlche Sourcecode. Wenn eine Firma / Organisation also eine komplette Ontologie veröffentlicht heißt das nicht etwa, dass sie zuvor manuell in Protege erstellt wurde sondern es heißt, dass sie aus vorhandenem C++/Java oder C Code rückwärts generiert wurde, man aber nicht zugeben will, dass man derartgigen Code bereits geschrieben hat.

Es gibt auf Google Scholar einige Paper in denen OWL konforme Ontologie für selbstfahrende Autos vorgestellt werden. Sie sind schön als Diagramm visualisiert und man sieht wie sie in Protege angezeigt werden. Heißt das jetzt, dass BMW angefangen hat, mit Protege eine Ontologie zu erstellen? Wohl eher nicht, sondern man wird einfach den vorhandenen C++ Sourcecode genommen haben, ihn über einen C++2OWL Konverter gejagt haben und jetzt in dem Paper den Lesern zu erklären, dass man die Ontologie from scratch erstellt habe und im nächsten Schritt daraus eine komplette Applikation basteln will. Natürlich ist das eine dreiste Lüge, in Wirklichkeit ist die Software längst geschrieben nur BWM will sie nicht bei github hochladen und bevor jemand fragt warum nicht, sagt man lieber, dass man bisher nur die Ontologie hat und sonst gar nichts.

Dieses Bedürfnis vorhandenen Sourcecode in eine Ontologie zu verpacken und dann behaupten sie wäre manuell erstellt worden, haben alle großen Softwarehäuser. Überall dort wo zwar viel programmiert wird, aber man nur wenig unter der GPL Lizenz veröffentlicht steht der Konzern unter öffentlichem Druck: „ihr programmiert doch an selbstfahrenden Autos, wo ist die Software?“. „Ihr programiert doch Computerspiele, wo ist das Klassendiagram?“. Natürlich wissen die Firmen was die Öffentlichkeit gerne sehen möchte, die .cpp oder die .java Datei. Also den Sourcecode, möglichst noch den aus dem origalen git repository inkl. dem Mail-Archiv worüber die Entwickler den Erstellungsprozess koordiniert haben. Nur genau den wird die Firma nicht in 100 Jahren veröffentlichen. Stattdessen wurde Protege erfunden und seitdem lügen sich die Firmen gegenseitig die Hucke voll und überbieten sich mit Ontologien, die sich angeblich erstellt haben um eine Domäne zu modellieren. Ich habe — hüstel — ebenfalls darüber nachgedacht ob ich meinen selbstgeschriebenen C++ Code in eine OWL Ontologie verwandeln sollte um sie gegegebenfalls zu veröffentlichen. Technisch geht das ausgezeichnet. Anschließend würde ich den Leuten in einem Tutorial noch erzählen wie sie mit Protege selbst so ein Semantic Network erzeugen wohl wissend, dass es so garantiert nicht gemacht wird. Doch irgendwie fühle ich mich der OpenSource Szene stärker verbunden als dem Semantic Web und so lade ich lieber den Sourcecode bei github hoch und brauche so keinen Unsinn zu verbreiten.

In dem Paper http://people.cs.ksu.edu/~abreed/CIS890/References/ontologydrivensoftwaredevelopment.pdf wird eine Vision ausgebreitet von einer ontologie-getriebenen Softwareentwicklung. Was sich zunächst wie ein technisches Thema klingt ist bei näherer Betrachtung eine Anti-These zur OpenSource Szene. Die Zukunft stellen sich die Autoren ungefähr so vor: über REST API und Meta-Ontologien werden im Internet Dienste bereitgestellt. Wenn ein Computer diese Nutzen will kommuniziert er mit dem Server über eine API. Sourcecode gibt es in dieser Verwertungskette keinen mehr. Jedenfalls keinen öffentlich einsehbaren. Das schöne an einer REST API ist, dass man nur das Interface bereitstellt aber die Software unter der Kontrolle des Unternehmens bleibt. Das Semantic Web kann man sich vorstellen wie einen riesigen Kopierschutz. Früher wurde zumindest noch eine kompilierte Exe-Datei auf CD-ROM ausgeliefert, im Semantic Web gibt es nichtmal mehr das. Sondern es gibt nur noch allgemeine APIs, das heißt dem Anwender wird jedweder Sourcecode vorenthalten. Er bekommt weder den C++ Sourcecode, noch das kompilierte C++ Binary, sondern er bekommt nur noch Zugriff auf das API Interface, worüber er dann seine Spiele, Webseiten oder was auch immer anzeigen kann.

OWL ist keine technische Innovation, sondern es ist ein rechtliches Instrument um geistiges Eigentum zu schützen. Es ist ein hochwirksamer Kopierschutz der verhindert, dass sich Sourcecode verbreitet und man Technologie nachbauen kann.

Eine gute Vorstellung davon was das Semantic Web in WIrklichkeit ist, erhält man durch das Projekt Xanadu. Ein Vorläufer des heutigen Internets was 1960 von Ted Nelson erfunden wurde. Xanadu war sehr viel stärker in Richtung Repository und Objekte hinausgelegt und hatte eine Micropayment Funktion sowie einen Urheberrechtsschutz. Genau genommen war Xanadu weniger technisch motiviert als vielmehr dem Bedürfniss geschuldet, Informationen kontrollieren zu wollen. Und genau dasselbe wird im Semantic Web angestrebt. Das heutige freie Internet wird als zu fortschrittlich bezeichnet, github und ähnliche OpenSource Projekte werden als Sackgasse bezeichnet und stattdessen wird das künftige Semantic Web sehr viel stärker auf die Bedürfnisse des Patentrechts hin ausgerichtet.

Automatic Programming durch Semantische Analyse von Sourcecode

Anfangs erschienen mir die Ansätze des automatischen Programmierens nicht besonders funktionsfähig zu sein. Es gibt zwar Genetic Programming, Neuralnetworks, grammatical Evolution aber echte Software kann man damit nicht erzeugen. Aber womöglich gibt es doch einen Weg den Traum von Programmgeneratoren zu verwirklichen. Und zwar wenn man einen Schritt zurückgeht und nicht direkt das Erzeugen von Software in den Mittelpunkt stellt, sondern etwas bescheidener die Analyse von existierendem Sourcecode betreibt. Bei der automatischen Programmierung gibt es das grundsätzlich selbe Problem zu lösen wie bei der Robtoik auch: das Domain-Modelling. Es geht darum, ein maschinenlesbares Modell zu erzeugen was Programmieren ist und wie man es richtig angeht. Lange Zeit war unklar wie genau so ein Domain-Modell aussieht. Rein formal ist es vermutlich normaler Sourcecode in einer höheren Programmiersprache wie C++ aber wie man so ein Modell erstellt das blieb unklar. Wenn man hingegen als Ziel formuliert, zunächst einem Semantischen Parser zu schreiben kommt man der Sache schon näher. Der semantische Parser hat die Aufgabe ein bestehendes Programm zu untersuchen, also zu ermitteln wo die Klassen definiert werden, was in den Klassen drinsteckt und das ins Verhältnis zu setzen mit Dokumentation. Das interessante an dieser Aufgabe ist dass, das so ein Semantischer Parser und ein Domain-Modell ein und dasselbe sind. Um so einen Parser zu programmieren muss man das Domain-modell erstellen. Also formal beschreiben was eine Java Klasse ist und was der Unterschied ist zwischen einer while schleife und einer For-Schleife.

Und noch etwas ist interessant. So ein Sourcecodeparser ist noch kein Programmgenerator, sondern es ist nur die Vorstufe dazu. Insofern eürfte es leichter sein, ihn zu programmieren. Die Paper die Google Scholar zu der Thematik anzeigt sind schonmal solide. Die Richtung scheint die richtige sein. Einig sind sich die Autoren darin, dass der Abstract Syntax Tree den ein Standard-Compiler erzeugt nicht aussagekräftig genug ist und man den Sourcecode um Annotations erweitern müsste. Einige bevorzugen XML, andere setzen auf OWL und wieder andere stellen den Parser als solchen in den Mittelpunkt. Im Kern geht es darum, Sourcecode mittels Datamining auszuwerten und höherwertige Informationen zu extrahieren. Manchmal wird das gekoppelt mit einer Plagiatssuche oder Vorschlägen zur Fortsetzung von bereits erstelltem Code.

Auf den Punkt gebracht hat es das Paper „SE-CodeSearch: A scalable Semantic Web-based source code search infrastructure“ https://www.researchgate.net/profile/Juergen_Rilling/publication/224185107_SE-CodeSearch_A_scalable_Semantic_Web-based_source_code_search_infrastructure/links/0046352d5ad84dbc11000000.pdf worin eine Codesuchmachine vorgestellt wird, die mit semantischen Anmerkungen erweitert wurde. Die Domäne „Programmiersprache“ wurde in einer OWL Ontologie modelliert.

Machen wir zur Erläuterung ein kleines Beispiel. Eine minimal Ontology um Sourcecode zu annotorieren ist in der Lage ein Codesegment zu identifizieren und zu bestimmen welches Segment davor und danach kommt. Ferner kann der Parser erkennen ob eine loop, eine if Abfrage oder eine Zuweisung erfolgte. Diese Informationen werden in einer Datenbank zusammen mit dem Orginal Sourcecode gespeichert. Technisch ist sowas relativ leicht zu realisieren. Der Vorteil ist dramatisch. Man erhält neben dem Code noch eine topicmap, also eine Landkarte davon wie der Code aufgebaut ist. Man kann jetzt eine Anfrage stellen wie: zeigen mir alle codesegmente mit einer For-Schleife. Die Suchmaschine geht einfach durch die Annoations durch und gibt den passenden Sourcecode zurück. Was die Ontologie auch nicht kann ist es, auf Knopfdruck neuen Programmcode zu erzeugen. Dafür ist die Ontologie nicht komplex genug. Aber sie enthält zumindest eine sehr grobe Domainmodellierung. Und diese kann man erweitern. Beispielsweise wäre es technisch vorstellbar, alle Codesegmente anzuzeigen wo etwas auf die Textkonsole ausgegeben wird oder auf die GUI. Im Regelfall liegen solche Codefragmente verteilt über das Dokument und können von normalen Suchmacshinen nicht vollständig gefunden werden. Der Compiler der den Code in Maschinensprache übersetzt, weiß zwar in der Theorie dass ein printf Befehl etwas auf die Textkonsole ausgibt, aber eine dezidierte Annotation nimmt er nicht vor. Anders gesagt, obwohl ein Standard-Compiler zwar den Sourcecode vollständig parst und in Machinencode übersetzt weiß der GCC Compiler nicht, was in dem Code drinsteht. Jedenfalls nicht richtig. Um es explizit zu machen braucht man obige Ontologie.

Software-Entwicklungskosten

Seit es Linux und Opensource Software gibt wurde der frühere Diskurs über Softwarepiraterie dadurch überlagert. Anstatt sich Günter mit Freiherr von Gravenreuth und den Geschäftspraktiken von Microsoft auseinanderzusetzen hat und Richard Stallman erklärt was die GPL Lizenz ist. Leider ist dabei etwas verloren gegangen, und zwar der Blick auf die ökonomischen Kosten von Software. Im obigen Video wird nicht nur das Raubkopieren als solches thematisiert, sondern was noch viel spannender ist, warum die Kosten der Softwareentwicklung so hoch sind. Der Clip fragt etwas spöttisch warum eine simple 5 1/4 Zoll für 500 US$ verkauft wird.

Mit Linux hat sich einiges verändert, heute ist es möglich Software umsonst zu installieren. Was jedoch gleichgeblieben sind ist der hohe ökonomische Aufwand um Software zu erstellen. Bei der Programmierung des Linux Kernels fallen exakt die selben Kosten an, die auch bei propritärer Software anfallen, und die Abläufe (Arbeit im Team, Bezahlung der Angestellten) ist ebenfalls gleich. Der Diskurs rund um Software-Piraterie hatte den Vorteil, dass er eben nicht auf den Sourcecode fokussiert war, also in welcher Programmiersprache etwas programmiert wurde, und mit welchem Compiler es übersetzt wurde, sondern Softwarepiraterie stellt die sozioökonomischen Bedingungen der Softwareindustrie in das Zentrum. Der Diskurs wird geführt anhand von Software-Publishern, Patentrechten und Produktivität. Es ist also ein business-orientierter Management-Diskurs.

Warum sich Pascal nicht hat durchsetzen können

https://www.bernd-leitenberger.de/pascal-und-c.shtml Im OP wurde ein Pascal Programm mit einem C Programm gegenübergestellt. Und es ist schon paradox, dass das Pascal Programm leichter zu lesen ist, aber die Sprache C sich hat durchsetzen können. Das hat hauptsächlich etwas mit den Communities zu tun, die hinter der Sprache stehen. Pascal wurde von akademischen Professoren gepusht, sie haben damit ihre Lehrveranstaltungen bestückt und in PhD Arbeiten wurden Erweiterungen zu Pascal programmiert. Während C Bibliotheken von kommerziellen Softwarefirmen wie Microsoft und Co entwickelt wurden. Objektiv muss man sagen, dass C/C++ keine gute Sprachen sind, aber dafür sind es ausgezeichnete Communities. Die Anzahl von Microsoft Programmierer liegt oberhalb von 10k, und viele weitere Firmen programmieren Bibliotheken in diesen Sprachen. Und gegen diese Community welche mit Geld, Manpower und Erfahrung ausgestattet ist, kommt keine akademische Programmiersprache an.

Das Spiel Pascal vs. C wiederholt sich übrigens gerade mit C++ vs. alle anderen Sprachen. Es gibt viele gute Vorschläge aus den Universitäten wie man objektorientiert programmieren kann: Java und Python sind die wichtigsten. Nur das Problem ist wiederum die Community dahinter. Man möge sich bitte die Anzahl der Personen anschauen welche für Java Libraries entwickelt und das mit der Anzahl vergleichen die für C++ Librarires programmiert um den Sieger festzulegen. Genau genommen ist es fast egal, wie C++ aufgebaut ist oder was im neuen Standard C++17 enthalten ist, sondern entscheidener sind die Leute die in dieser Sprache Sourcecode schreiben.

Der Grund warum Programmiersprachenvergleiche meist anhand des Sourcecode durchgeführt werden hat damit zu tun, dass es dazu verlässliche Angaben gibt. Wie ein C Sourcecode aussieht ist bekannt, wie man mit Pascal ein Programm schreibt ebenfalls. Zu den dahinterstehenden Communities hingegen gibt es fast keinerlei Angaben. Insbesondere kommerzielle Softwareentwicklung legt großen Wert auf Anonymität, selbst eine simple Angabe welche Bibliotheken es überhaupt für C++ gibt ist nicht so einfach herauszufinden. Leider hat das zur Folge dass in den typschen Programmiersprachenvergleichen die Community nicht berücksichtigt wird. Man konzentriert sich bewusst auf die technischen Fragen, also ob es Pointer gibt, oder welche Sprache schneller kompiliert. Das sind jedoch unwichtige Detailfragen.

Warum die Industrie C und nicht Pascal einsetzt ist simpel: weil die Industrie ganz bestimmte Anforderungen hat. Üblicherweise will man Geld verdienen indem man neue Grafikhardware auf den Markt bringt oder neue Spiele programmiert. Zweitens will man Kosten minimieren indem man vorhandenen Code mehrmals verwendet und man ist stark an Software interessiert die besser ist als die der Konkurrenz, also wo das Scrolling ohne Ruckeln erfolgt, und wo der Kunde zufrieden ist. Andere Ziele wie leichte Erlernbarkeit der Sprache und klare Standards sind hingegen im industriellen Umfeld unwichtig. Die Industrie setzt mit Vorliebe unsaubere Programmiersprachen wie C und C++ ein. Damit haben sie die maximale Kontrolle über die Hardware und können ihre Agenda nach vorne bringen.