Betrachtet man die IT Umgebungen bei grossen Unternehmen, findet man primär drei Programmier Sprachen.
Sicher gibt es noch einige weitere Programmiersprachen im Portofolio, weil entsprechende Anwendungen existieren und auch weiterentwickelt werden, bei Neuentwicklungen werden aber in der Regel COBOL, Java (oder in reinen Microsoft Umgebungen c#) und C (also c++ oder manchmal auch Objective-C) gewählt.
Die Sprachen unterscheiden sich in vielerlei Hinsicht.
COBOL wurde Anfang der 1960er Jahre, also zu Zeiten der Lochkarten, entwickelt. Die Anwendungsentwickler, die es vorher wohl noch nicht gab, sollte ein Werkzeug an die Hand gegeben werden um den Bruch zwischen der Person, die die Fachlichkeit versteht und der Person, die den Computer versteht, zu vermeiden.
C wurde Anfang der 1970er Jahre für die Implementation eines Betriebssystems (Unix) entwickelt.
Java sollte die aufkommende Beherrschung von Microsoft im Bereich der Anwendungsentwicklung verhindern und wurde von Herstellern von Unix Rechnern (SUN) entwickelt und von Herstellern von Mainframes (IBM) stark unterstützt.
c# war, nachdem Microsoft die Java Welt nicht spalten konnte, der Gegenentwurf zu Java.
Bei der Speicherverwaltung gibt es grosse Unterschiede.
Der Speicher für die zur Laufzeit benötigten Variablen wird bei COBOL durch den Compiler, also schon sehr früh, festgelegt.
Dieses Vorgehen hat den Vorteil, dass eigentlich keine Speicherverwaltung benötigt wird, hier also nichts schiefgehen kann, es gibt also keine Speicher-Lecks, die ein System, das 24×7 laufen muss, zum Absturz bringen wird.
Und dieses ist auch der grosse Nachteil. Schon beim Programmieren muss festgelegt werden, welche Anzahl an Variablen (speziell in einem Array) benötigt wird, und die Erfahrung zeigt, dass irgendwann die Anzahl der benötigten Array-Elemente die Anzahl der definierten Array-Elemente übersteigt (ausser der Entwickler hat beim Design die notwendigen Vorkehrungen getroffen).
Bei Java gibt es eine automatische Speicherverwaltung. Wird zu Laufzeit ein Array-Element (in einer ArrayList oder einem Vector) zusätzlich benötigt, stellt Java den Speicherplatz zur Verfügung. Und wird der Speicherplatz nicht mehr benötigt, räumt Java den Speicher wieder auf. Diese Automatik funktioniert sehr gut, kostet aber Ressourcen, insbesondere Laufzeit, was bei grossen Servern zum Problem werden kann. Da das Aufräumen in einem eigenen Thread („Faden“ der Programmausführung) läuft, der nur Rechenzeit erhält, wenn der Computer meint, die notwendige Zeit zu haben, kann sich bei einem stark ausgelasteten Server ein grosser „Haufen“ an nicht aufgeräumten Speicher ansammeln, was auch zu Problemen führen kann.
In C, c++, Objective-C verwaltet der Programmierer den Speicher selbst. Er kann bei Bedarf Speicher anfordern und muss ihn, wenn der Speicher nicht mehr benötigt wird, freigeben. Wird der Speicher nicht freigegeben, entsteht ein Speicher-Leck. Nun sind Programm meist nicht so trivial „Speicher anfordern, etwas tun, Speicher freigeben“, so dass hier ein besonderes Augenmerk notwendig ist. Bei eher technischen Programmen, Betriebssystemen, einer Textverarbeitung ist dieses möglich und die notwendigen Test sind planbar. Was ist aber in einem ERP System bei der Erweiterung der Stücklisten-Verwaltung (welche Teile werden benötigt, um einen PKW zu bauen? Motor, … Welche Teile werden benötigt um einen Motor zu bauen? …)? Hier kann eine kleine Erweiterung (5 Zeilen), für die eine Stunde Arbeitszeit eingeplant ist, durch ein Speicher-Leck in einer aufgerufenen Funktion das gesamte ERP System zum Absturz bringen.
Was für den Speicher gilt, gilt entsprechend auch für andere Ressourcen, die von Programmen benötigt werden.
Da C für die Entwicklung von Betriebssystemen geschaffen wurde, gibt es dem Programmierer Möglichkeiten an die Hand, die der erfahrene Entwickler bewusst und mit der notwendigen Umsicht nutzt. Der unerfahrene Entwickler, oder auch der Entwickler unter Zeitdruck, können diese Möglichkeiten nutzen mit dem Ergebnis „es läuft ja“. Die Probleme treten dann später zu Tage.
C sollte also in der Anwendungsentwicklung nur in besonderen Fällen genutzt werden, oder um bestimmte Funktionen für andere Programmiersprachen zur Verfügung zu stellen.
Bleiben also Java und COBOL. Bei „Time-to-Market“ ist Java deutlich besser, sonders bei der Entwicklung von Benutzer-Oberflächen. Komplexe fachliche Zusammenhänge lassen sich in Java deutlich besser beschreiben. Es gibt also keinen Grund auf COBOL zu setzen?
Geht es um einen 24×7 Betrieb (der ja meist einen ausfallsicheren Computer, also eine Mainframe erfordert) und um einen hohen Durchsatz, rechnet sich der Einsatz von COBOL.
Es können auch beide Methoden kombiniert werden, zum Beispiel das GUI und der Work-Flow in Java, aber die Speicherung der Daten inklusive der Valdierung vor dem Speichern in COBOL. Aber dieses erfordert an der Schnittstelle einen Entwickler, der in beiden Welten zu hause ist.
Weiter oben schrieb ich von den unterschiedlichen Design zwischen einer Java und einer COBOL Anwendung. Die Phase der Analyse kann (und sollte) in OOA geschehen. Beim Design (OOD) muss dann abgebogen werden.
Als Beispiel soll in Vorbereitung auf ein Kundengespräch die Kontaktdaten mit der Telefonnummer, unter der der Kunden zu dem gewünschten Zeitpunkt erreichbar ist, ausgedruckt werden. OOA sagt, man braucht die Daten des Kunden, diese sind aufbereitet zu drucken.
OOD für Java bedeutet „Kunde = x.getKundenDaten(KundenNummer)“ und „Kunde.printKundenNameMitTelefon( Datum, Uhrzeit)“.
Für COBOL bräuchten wir die Information, wieviele Telefonnummern kann ein Kunde haben, um ein passendes Array zu definieren. Die Erfahrung zeigt, dass es immer einen Kunden geben wird, der eine Telefonnummer mehr hat, oder wir definieren, ein Kunden kann 1000 Telefonnummern haben, was auch nicht sinnvoll ist. Also nutzt uns das Objekt „Kunde“ mit einer unbekannten Anzahl an Telefonnummern nichts. Deshalb wenden wir das EVA-Prinzip (Eingabe, Verarbeiten, Ausgabe) an, lesen also nicht alles ein und verarbeiten das komplette Objekt, sondern lesen einzelne Datensätze, verarbeiten diese und geben sie aus. „holenKundenName(KundenNummer)“, „holenTelefonnummer(KundenNummer, Datum, Uhrzeit)“ und „druckeDaten()“.