Kapitel 24. Software - Entwicklung

Software - Entwicklung ist ein heißes Thema, insbesondere unter Linux bzw. für Linux. Im Internet hat sich Linux mit dem Apache - Webserver und den Skript - Sprachen PHP und PERL erfolgreich durchgesetzt. Insbesondere die Mächtigkeit der Bibliotheken, allen voran PERL CPAN und PHP Homepage. Das OpenSource - Konzept, die unzähligen Beispiele, Tutorials, Support - Foren, Mailing - Listen und Howtos im Internet, sowie die kostenlos verfügbaren Datenbank-Server begründen den Erfolg. Inzwischen werden weit mehr Web - Applikationen in PHP geschrieben, als in irgendeiner anderen Programmiersprache sonst.

Anders sieht es bei Anwendungsprogrammen auf dem Desktop aus. Bisher nutzen nur wenige Entwickler die Möglichkeit, Anwendungen zu programmieren, die unter Linux, Windows und MAC OS X gleichermaßen laufen. Schließlich sind ja Netscape, Mozilla, Firefox, GIMP, OpenOffice als Anwendungen, die die grafische Benutzeroberfläche (GUI) und ihre Komponenten nutzen, auf allen Plattformen gleichermaßen verfügbar und laufen stabil, siehe auch Abschnitt 24.27. Sogar das Drucken funktioniert plattformübergreifend ohne Probleme, da Linux, Windows 2000/XP und MAC OS X über dasselbe Drucksystem verfügen, siehe Kapitel 23.

Sehr viele Entscheider haben noch garnicht wahrgenommen, daß Software, die über Microsoft Visual C++, Visual Basic, ... programmiert wurden, bereits unter Linux lauffähig ist. Auch die Softwareportierung, sofern Quellcode vorhanden nach Linux ist recht einfach möglich. Mehr hierzu siehe Abschnitt 24.2.

Programme ohne GUI sind schon lange auf vielen Plattformen lauffähig, siehe Datenbanken, Apache Webserver, u.s.w. Cross - Platform - Development beginnt gerade erst interessant zu werden, da portable C-Libraries mit den entsprechenden language bindings zur Verfügung stehen, also von verschiedenen Programmiersprachen aus, wie Python, Basic, Perl, C++, Ada, genutzt werden können.

Die Wahl der Programmiersprache erscheint vordergründig recht wichtig, weil sich größere Programmierprojekte halt nur in objektorientierten Programmiersprachen vernünftig in größeren Teams realisieren lassen, allen voran C++ und JAVA, C#. Die Mächtigkeit der Komponenten, die in der jeweiligen Programmiersprache zur Verfügung stehen, sparen meist sehr viel Entwicklungskosten. So hat z.B. Intershop seinen Web - basierten SHOP in PERL geschrieben, weil hierfür unglaublich mächtige Komponenten zur Verfügung stehen. Merkwürdigerweise jedoch hat PERL gegenüber PHP an Marktanteil stark verloren, weil Perl - Programme schlecht lesbar und teilweise recht kryptisch sind. Die Ähnlichkeit von PHP zu Visual Basic und der große Support hat viele Entwickler auf PHP umsteigen lassen, denen Basic von Microsoft Makros her vertraut ist. Leider sind PHP5 und PERL6 gerade erst in den letzten Versionen objektiorientiert geworden, sodaß sich hier, ähnlich wie in bei Visual Basic 6 zu Visual Basic .NET ein Technologiebruch ergibt. PHP5 ist PERL6 jedoch sind abwärtskompatibel zu früheren Versionen, Visual Basic .NET jedoch ist es nicht. Hier müssen Programmierer umlernen.

Nicht nur die Mächtigkeit der Komponenten in der jeweiligen Programmiersprache ist ein wichtiges Kriterium, sondern auch die Designwerkzeuge, RAD - Tools, eine komfortable IDE (Integrated Development Environment), wobei Funktionen für refactoring, class browsing, debugging, gui designer, icon editor, ... nicht fehlen dürfen.

Das beste Entwicklungswerkzeug nutzt jedoch nichts, wenn das Design des Komponenten - Modells nicht stimmt, nicht ausbaufähig ist, siehe Abschnitt 24.10. Unzählige Softwarepakete der OpenSource Community, aber auch kommerzielle Anwendungen sind teilweise sogar mehrfach neu geschrieben worden, weil unstrukturierter Spaghetticode vorlag, den niemand mehr verstanden hat. Eric Raymonds legendärer Beitrag Die Kathedrale und der Basar gibt eine gute Vorstellung davon, wie Softwareentwicklung in einer OpenSource Community betrieben wird.

Die vielen mächtigen Bibliotheken unter Linux, zumeist in C geschrieben, und die darauf aufsetzenden Bibliotheken und Komponenten der verschiedenen Programmiersprachen, wie PHP, PERL, C++, JAVA ... harmonieren recht gut miteinander, jedoch gab es bisher keinen Standard bezüglich der grafischen Benutzeroberfläche. Bei fast jeder Linux - Distribution kann man zwischen den konkurrierenden Benutzeroberflächen GNOME und KDE wählen. Diese Benutzeroberflächen stellen, ähnlich der MFC unter Windows, die wichtigsten Komponenten bereit, mit denen man Anwenderprogramme entwicklen kann. GNOME und KDE setzen beide wiederum auf X-Windows auf, einem System, welches außer dem Zeichnen von verschiedenfarbigen Linien, Punkten, Kreisen, Flächen und Buchstaben keine Komponenten zur Verfügung stellt. Auf X-Windows können daher Benutzeroberflächen mit ihren Komponenten - Modellen aufsetzen, sogenannte Frameworks, die dem Programmierer z.B. Komponenten für die Programmierung eines eigenen Web-Browsers, einer Textverarbeitung, u.s.w. zur Verfügung stellen. Die Mächtigkeit des Frameworks und sein Design entscheidet ebenfalls über die Entwicklungskosten einer Applikation.

Auf diesen Frameworks wiederum setzen die Entwicklungswerkzeuge auf, mit denen man im Handumdrehen z.B. ein Formular zur Ein - und Ausgabe von Datenbankinhalten programmiert hat (Visual...). Wenn man jedoch noch für die Texte, die in SQL abgelegt werden sollten, einen kleinen Texteditor benötigt, so bieten leistungsfähige Frameworks diesen als Komponente an, der sich dann in eigene Programme integrieren läßt. Sowohl GNOME als auch KDE bieten solche Komponenten an, wie z.B. Qt oder Qtopia für KDE und GTK+/GTK--/GTKmm für GNOME. Mit diese objektorientierten Frameworks lassen sich leistungsfähige Programme zusammenbauen, ähnlich einem Modulbaukasten.

Sogenannte language bindings wurden für verschiedene Programmiersprachen geschaffen, sodaß man diese Kompontenen auch mit PHP, PERL, Python, Ruby, Basic und sogar JAVA nutzen kann.

So gibt es für GNOME2 inzwischen recht viele "language bindings". Hinter GNOME2 jedoch steckt noch viel mehr. GNOME2 Applikationen sind nicht nur Anwendungsprogramme, sondern sie sind im Grunde eine Ansammlung von Komponenten (ABIWORD, GNUMERIC, ...) unter einer Bedienungsoberfläche. Hierbei sind Benutzeroberfläche (GDK, Maus/Tastatur Event-Handler) und die eigentliche Anwendungslogik (GTK+) voneinander trennbar, können sogar auf verschiedenen Rechner im Netzwerk laufen. So startet z.B. die Benutzeroberfläche von ABIWORD auf dem lokalen Desktop - Rechner, und die eigentliche ABIWORD Textverarbeitung läuft dann auf der CPU im Netzwerk, die mehr Rechenleistung zur Verfügung stellen kann. Beide kommunizieren über CORBA bzw. über Bonobo / ORB miteinander. GNOME bzw. GTK+ besitzen viele Anbindungen an Interpreter - Sprachen, mehr hierzu siehe GNOME Developer Forum.

KDE3 Applikationen sind ähnlich aufgebaut, wie GNOME. KDE Applikationen verwenden, ...ZZZZZZZZZ Eine ungefähre Vorstellung davon, wie Programme für grafische Benutzeroberflächen für Linux, Windows, Apple MAC gleichzeitig entwickelt werden können, mit welchen Werkzeugen entwickelt wird, geben die folgenden Kapitel. Hierbei werden auch die Programmier - Frameworks und ihre Leistungsfähigkeit dargestellt.