Softwaredesign und Programmiersprachen...
Welche Programmiersprache die "Beste" sei, führt oft zu fast religiös anmutenden Diskussionen unter Programmierern. Aber darf die Wahl der Programmiersprache das Design eines Softwaresystems entscheidend beeinflussen? Muss dieses Design anders sein, wenn in C implementiert wird, als wenn in Java implementiert wird?
Ich verwende momentan primär C, da meine aktuellen Projekte im Linux-Systemumfeld angesiedelt sind und dies dort (immer noch) die "Sprache der Wahl" ist. Allerdings meine ich, auch anderen Sprachen gegenüber recht aufgeschlossen zu sein (und diese auch immer wieder zu verwenden). So halte ich beispielsweise auch Java für eine sehr schöne Sprache, in der vieles sehr viel schneller, besser und eleganter als in C (oder auch C++) geht.
In den letzten Tagen habe ich eine für mich sehr interessante Diskussion darüber geführt, inwiefern die Programmiersprache über das Grunddesign eines IT-Systems entscheidet. Wenn ein solches System entwickelt werden soll, so muss man zunächst ein Modell des Sachverhalts entwickeln, und kann diesen dann in einem Programmsystem abbilden. Dabei geht es darum, inwiefern ein Systemdesign für objektorientierte Sprachen (prominenter Vertreter Java) und imperative, also nicht-objektorientierte, Sprachen (prominenter Vertreter C) anders ausschauen muss.
Ich möchte hier einige von mir geäußerte Gedanken vorstellen und würde mich über Feedback sehr freuen. Ich erhebe keinerlei Anspruch darauf, dass meine Gedanken wirklich korrekt sind, betrachte sie aber als das Ergebnis aus über 25 Jahren IT-Erfahrung. Insofern bin ich sicherlich ein wenig starrköpfig ;)
Der Text ist bewusst als Diskussionbeitrag geschrieben, ja einem solchen wirklich entnommen. Ich hoffe, das macht ihn lebendiger lesbar. Nun denn:
Mein Punkt ist, dass das Design einer Anwendung sich an den Realwelt-Objekten ausrichten sollte. Es gibt keinen Grund, in Assembler oder Pascal Spaghetticode zu programmieren, nur weil diese Sprachen nicht zwingend die Sichtweise nach Objekten erfordern. Wenn man z.B. in die Realisierung von Betriebssystemen schaut, dann werden natürlich Threads als Thread-Objekte (oder halt spezielle Prozesse), Prozesse als Prozess-Objekte, Platten als Speicherresource-Objekte etc. modelliert (und das auch in Betriebssystemen, die nicht in Java geschrieben sind...). Und natürlich gibt es für Treiber abstrakte Schnittstellen, die dann von konkreten Treiberklassen ausgefüllt werden müssen. Alle diese Überlegungen gibt es nämlich schon sehr lange, und die objektorientierten Sprachen sind ja nicht zuletzt entstanden, um diese Sichtweise auch vergleichsweise einfach in der Programmierung anwenden zu können und damit eine erhebliche Arbeitserleichterung (und Qualitätsverbesserung) zu erreichen.
Ich wüsste keinen Grund, warum man explizit auf eine Modellierung mittels interagierender Objekte verzichten sollte. In diesem Sinne halte ich das Systemdesign in der Tat für prinzipiell programmiersprachenneutral. In der Umsetzung des Designs stellt sich dann natürlich die Frage nach der Implementierungssprache. Natürlich kann ich ein objektorientiertes Design am
leichtesten in einer OO-Sprache umsetzen. Und natürlich haben die verschiedenen Programmiersprachen verschiedene Vor- und Nachteile. Aus meiner Sicht eignen sich daher gewisse Programmiersprachen für gewisse Problemstellung mehr oder weniger gut.
Aber ich muss doch von der Problemstellung aus schauen. Ich darf doch nicht die Problemstellung "passend machen" und in einer wie auch immer gearteten Weise ein "C-Design" machen, nur weil C das "nun einmal nicht anders kann". Oder das Problem an die Möglichkeiten von Java anpassen. Mein Ziel sollte es doch zuerst einmal sein - auf oberer Ebene - ein System zu designen, dass die zu lösenden Sachverhalte modelliert.
Eine Anpassung des Problems an die (ggf. zu geringen) Möglichkeiten der Programmiersprache wird in der Praxis zwar durchaus schon einmal vorgenommen, aber ich habe selten erlebt, das sich daraus dauerhaft erfolgreiche Lösungen ergeben.
Natürlich muss ich auf etwas tieferer Ebene auch die Eigenschaften der verfügbaren Sprachen ("Was können meine Programmierer?") und des bereits vorhanden Codes ("Was kann ich wie wiederverwenden?") mit beachten, und das wird u. U. auch Design-Entscheidungen auf höherer Ebene beeinflussen. Aber ich kann nicht sehen, warum das Grunddesign anders aussehen muss, nur weil ich eine andere Sprache verwende.
Betrachten wir die Modellierung eines Motorrades (um es etwas griffiger zu betrachten):
Ein Motorrad besteht aus Rädern, Motor, ... Damit habe ich als Klassen doch schon einmal "Motorrad", "Rad", "Motor", ... und kann dann z.B. Subklassen von "Motor" bilden: "Viertaktmotor", "Zweitaktmotor" etc. Warum muss ich diese *Sichtweise* denn auf einmal aufgeben, nur weil ich in C (oder Pascal oder ...) programmiere?
Natürlich kann man das in Java eleganter implementieren. Aber mit einem ganz kleinen bisschen Disziplin kann ich doch auch in jeder anderen Sprache Konstruktoren (und ggf. Destruktoren) definieren, die entsprechenden Methoden, und ausserdem natürlich Methoden eng auf den zugehörigen Daten arbeiten lassen (wie man das in einer objektorientierten Sprache machen muss, bzw. machen sollte...). C zwingt mich doch nicht, das alles miteinander zu vermischen. Es
unterstützt mich nur nicht in gleicher Weise, wie es Java, ... macht. Und bei Vererbungshierarchien muss ich in einer nicht-OO Sprache natürlich sehr viel größeren Aufwand treiben. Das kann, je nach sonstigen Bedingungen, natürlich dazu führen, dass ich in Java & Co implementiere. Aber es kommt eben auch auf die sonstigen Bedingungen an. Wenn ich z.B. eine neue Komponente in ein bestehendes, in Pascal geschriebenes, System einfügen möchte, dann werde ich dazu wahrscheinlich nicht Java verwenden, auch wenn die Implementierung damit deutlich schneller ginge.
All' das hat aber doch nichts damit zu tun, dass ich in jedem Fall ein "ordentliches Design" auf dem aktuellen Stand der Technik machen sollte. Und ein solches Design ist momentan ganz sicher objektorientiert. Ich würde es für sträflich halten, ein "Spaghetti-Design" zu machen, nur weil ich C, ... verwende.
In diesem Sinne sollte die Programmiersprache das Design eines Softwaresystems nicht massiv beeinflussen. Das zumindest ist mein Standpunkt. Über Diskussionen dazu würde ich mich in der Tat sehr freuen...
Das ist doch ganz klar, GW-BASIC aus dem Jahre 1983 ist die beste Programmiersprache.
Hier findet man es:
http://members.chello.at/karl.bednarik/GWBASIC.EXE
Kein Firlefanz, keine Objekte, keine Variablen definieren, einfach nur verwenden.
GW-BASIC läuft gut unter Windows XP, und dort auch mit Grafik.
Eine RS-232-Anwendung unter MSV C++, oder eine Windows-Grafik unter MSV C++ ist dagegen ein reiner Horror.
Das alles ist in GW-BASIC um den Faktor 10 oder mehr einfacher.
Falls ich notgedrungen etwas in MSV C++ schreiben muss, dann entwerfe ich alles zuerst in GW-BASIC, weil das mindestens 10 mal schneller und einfacher geht.
In Kürze werde ich ein GW-BASIC-Programm geschrieben haben, das meine GW-BASIC-Programme vollautomatisch in das unerträgliche MSV C++ übersetzen kann.
Ist das Content Management nicht sozusagen ein Werkzeug, welches verhindert das diese gegenseitige Systembeeinflussung zu stark ist?
LG
Dein zur Diskussion gestellter Eintrag hat mich angeregt, dem einige Aspekte hinzuzufügen (was ich üblicherweise nicht mache).
Zu meinem Hintergrund: ich bin selber seit etwa 30 Jahre in der IT und durch verschiedene Sprachen gegangen (imperative: Fortran, Pascal, Cobol, C, sh, Perl; OO: Java, C++, Smalltalk; KI: Prolog, LISP) und habe selber die Erfahrung der Grenzen einer Umsetzung gemacht, für dessen Design (in OO, Java und OODBS) ich selber verantwortlich war. An diesem Punkt hätte ich mir die Durchgängigkeit der Modelle gewünscht, also die Verknüpfung von imperativen, objektorientierten und regelbasierten Komponenten aus Design-Gründen (bislang kenne ich das nur aus Performance-Gründen).
1. Aspekt: Historie
Wenn ein System neu designt und entwickelt wird, gebe ich Dir vollommen Recht; da sollte das Design das Sprachparadigma (imperativ, OO oder regelbasiert) implizieren.
In den meisten Fällen werden jedoch bestehende Systeme angepasst bzw. ergänzt. Da ist es problematisch, Paradigmenwechsel einzubringen, zum einen, weil die Schnittstellen komplexer und pflegeintensiver werden als beim Verbleib bei der ursprünglich gewählten Sprache, zum anderen, weil der Kreis der Personen, die für Weiterentwicklungen in Frage kommen dadurch i.d.R. eingeschränkt wird.
Zum anderen habe ich es in der Praxis häufig erlebt, dass das Werkzeug die Machbarkeiten definiert, nach dem Motto "Wenn ich nur einen Hammer habe, sieht über kurz oder lang Alles wie ein Nagel aus".
2. Aspekt: Design als Simulation der Realität
Nach meinem Verständnis ist SW-Entwicklung deshalb komplex und immer wieder problembehaftet, weil sie als potentiellen Betrachtungsraum nichts anderes hat als die Welt um uns herum. Mit SW simulieren wir mehr oder weniger große Teilbereiche dieser Welt um uns herum. Viele Probleme, die als "falsches Design" umschrieben werden, rühren nach meinem Verständnis daher, dass SW-Systeme i.a.R. wenig fehlertolerant sind, unser Gehirn aber schon. Wenn also ein Anwender mit einem SW-System zu tun hat, wird er sich an manchen Stellen wundern, wieso dieses "so dumm" ist. Aber das SW-System blendet eben nicht die Dinge aus, die unser Gehirn unterbewußt ausblendet, weil sie nicht in sein Raster passen.
3. Aspekt: SW und Bewußtsein
In dem Buch "Entstehung des Bewußtseins" beschreibt Julian Jaynes sehr ausführlich, was Bewußtsein aus seiner Sicht ist (bzw. was es nicht ist). Nach diesem Verständnis gehören Bewußtsein und Software zur gleichen Klasse "Simulation der Welt um uns"
4. Aspekt: Information und Kommunikation
Das Design einer solchen Simulation bedingt i.a.R. die Mitarbeit verschiedener Personen, zum einen die Experten, die dem Designer die abzubildende "Realität" mitteilen, zum anderen die Entwickler, die das Design (mit) implementieren und am Ende der Kunde bzw. der Anwender, der das Endprodukt nutzen wird. Zwischen allen Beteiligten muss Information ausgetauscht werden. Hauptmittel dazu ist die Sprache. Nun ist aber die Sprache ein Mittel, um Information, die in unserem Gehirn mindesten 3-dimensional abgebildet ist, über die Sprachschnittstelle (eindimensional) in das Gehirn des Gegenübers zu übertragen. Da ist zwangsweise mit Verlusten zu rechnen.
Ich mach jetzt hier mal Schluß, weil unsere Hunde raus müssen und die Sonne scheint.
Hallo Herr Gerhards,
meines erachtens spielt die verwendete Programmiersprache keine Rolle für das Design eines Software Systems - solange es C++ ist :-)
Nein im Ernst, jede hinreichend komplexe Programmiersprache ist für die Implementation eines jeden Softwaredesigns nutzbar. Allerdings müssen Sie meiner Ansicht nach zwischen den beiden Begriffen Design(Konstruktion) und Implementierung(Erstellung) unterscheiden sowie zwischen "Objektorientierung" und "Komponentendesign".
Der einzige Punkt, wo die verwendete Programmiersprache eine wirkliche Rolle spielt, ist die Implementierung. Und selbst hier sind evtl. verfügbare Cross Compiler eine Hilfe. So kann Herr Bednarik beispielsweise fleissig in GW Basic implementieren, und anschliessend seinen Code in C++/Java oder meinetwegen auch MUMPS übersetzen lassen. Wichtig ist schließlich, was am Ende dabei rauskommt.
Es kommt beim Design vor allem auf das Verständnis von Konzepten an. Und wie in der Hirnforschung die erlernten Sprachen und die damit einhergehende Ausrucksfähigkeit auf die Intelligenz eines Menschen wirken, wirk das Können (und wirkliche Durchdringen der Konzepte) verschiedener Programmiersprachen auf die Fähigkeit, ein SOftware System zu designen. Prinzipiell muss hierzu nochnichtmal eine "wirkliche" Programmiersprache gekonnt werden - solange die zugrundeligenden Konzepte bekannt sind.
... nun habe ich doch erst wieder mit Verzögerungen reinschauen können (und vielleicht sollte ich einmal über eine Design von auch für mich funktionierenden Benachrichtigungen nachdenken...).
Scherz beiseite: gerade die letzten beiden Kommentare drücken eigentlich schön aus, worauf ich zielte. Wobei die von Hr. Jennrich getroffene explizite Unterscheidung zwischen Design/Entwurf und Implementierung sicherlich eine sehr gute ist.
Ich stimme auch zu, dass hinreichendes *Verstehen* (und eben nicht nur "kennen") von Designmöglichkeiten extrem wichtig ist. Ich tendiere weiter dazu, dass solches Verstehen auch eine gewisse Zeit der praktischen Tätigkeit bedarf. Auf diesem Sinne ist sicherlich auch die Implementierung, und mit ihr die verwendete Programmiersprache, wichtig. Das aber eben in dem in den Kommentaren genannten Sinne, das dies den Menschen prägt. Insofern kann die Designalternativen eigentlich nur überblicken, wer auch eine gewisse Implementierungserfahrung mit Sprachen unterschiedlicher Philosophie mitbringt. Man beachte: Ich verlange hier keinesfalls jahrelange Erfahrung, aber oberflächliche Kenntnis ist sicherlich nicht hilfreich. Man sollte schon wenigstens einen nicht-Trivialen Anwendungsfall implementiert haben, zumindest meine ich das. Die Grundidee dahinter ist, dass man die Konzepte wohl nur wirklich verinnerlichen kann, wenn man sie mindestens einmal ernsthaft angewendet hat.
Dann aber, und jetzt komme ich zum Ausgangspunkt zurück, ist es letztlich egal, in welcher Sprache Implementiert wird. Natürlich wird man das ohne guten Grund nicht in Assembler machen. Und natürlich haben moderne OO-Sprachen Vorteile, wenn es gilt, ein OO-Design zu implementieren (und welches Design ist mit gutem Grund *nicht* objektorientiert...?). Aber: die Implementierungssprache sollte nicht darüber entscheiden, wie das Design aufgebaut wird.