Hallöchen,
Die Vorteile die Java hingegen gegenüber z.B. C++ bietet überwiegen so dramatisch
Die da wären ...?
* Durch den Wegfall der Pointerarithmetik und einer manuellen Speicherverwaltung fallen viele Probleme schlicht weg.
Hmm. Was für Probleme? Ich sehe darin, dass ich in C vieles "von Hand" machen muss, eher einen Vorteil.
Der Code wird zudem besser wartbar und lässt sich auch einfacher entwickeln.
Das lege ich mal in die Schublade "Gewohnheit".
* Die Plattformunabhängigkeit.
Diesen Vorteil lasse ich gelten. Er geht aber, wie du selbst einräumst, auch mit einem Performancenachteil einher, da der Code niemals so optimal auf das Zielsystem abgestimmt sein kann wie Native Code.
* Das Vorhandensein einer umfassenden und zudem kostenlosen Klassenbibliothek.
Darin sehe *ich* keinen Vorteil, wie schon dargestellt.
* Java ist leichter zu lernen.
Kann ich nicht beurteilen, ich kenne Java nur vom flüchtigen Drüberschauen. Aber ich bin der Ansicht, wenn man grundlegende Programmierkonzepte mal verstanden hat, ist auch C sehr einfach zu lernen.
* Die Performanceschwäche. Allerdings muss man sich gerade bei dem letzten Punkt fragen ob dieser wirklich kritisch ist, wenn z.B. der geschwindigkeitsbestimmende Schritt die Nutzerinteraktion an einer GUI ist, oder wir von Unterschieden im ms-Bereich sprechen.
Nun ja, ich denke beim Begriff "Performance" nicht nur an die vom Benutzer gefühlten Antwortzeiten, sondern auch an technische Aspekte wie CPU- und Speicherbedarf.
Oder wir verstehen unter "SDK" etwas verschiedenes.
Naja, die Grenze ist wie ich finde schwammig:
SDK = Software Development Kit: Kernbibliotheken, Compiler, ggf. Laufzeitumgebung, Dokumentation
Aha. Gerade den Compiler, allgemein: die Werkzeuge, habe ich bisher immer *nicht* zum SDK gezählt. Das SDK umfasst für mich wirklich nur die Dateien, die ich brauche, um mit einer gegebenen IDE oder einem gegebenen Compiler (meinetwegen auch direkt kommandozeilenbasiert) Anwendungen für ein konkretes Zielsystem entwickeln zu können. Deswegen geht mir auch deine Formulierung ...
IDE = Integrated Development Kit: Eine Software die die Funktionalität des SDK komfortabel verfügbar macht.
... irgendwie quer, denn nach meinem Verständnis hat ein SDK keine Funktionalität, sondern es ist nur die Menge aller Informationen, die Programmierer und Compiler zum Erstellen des Codes brauchen.
1.) Muss ich nicht wissen wie eine Funktion im Detail arbeitet, mich interessiert nur, was rein und raus geht, um den Rest haben sich bereits zuvor andere schlaue Menschen Gedanken gemacht.
Einverstanden, ja. Nur ist meine Erfahrung, dass die meisten großen Bibliotheken und Frameworks eben nicht so modular aufgebaut sind, wie ich es gern hätte (und zudem sind sie oft sehr schlecht dokumentiert). Ich muss z.B. bei MFC das Gesamtpaket nutzen (und verstehen) und kann mir nicht einzelne Punkte konkret herausgreifen, die ich nutzen möchte.
2.) Ist diese Arbeit, sich nämlich mit einer Klassenbibliothek auseinanderzusetzen eine Investition, die sich sehr schnell bezahlt macht.
Das sehe ich nicht so; der beste Code ist immer der, den man selbst geschrieben hat, weil:
Dann hätte er außerdem den Vorteil, dass sein Code für ihn durchschaubarer und leichter zu pflegen ist, weil er weiß, was er letzten Sommer getan hat.
Und das wird dadurch erleichtert, dass ich meinen Code durch immer wiederkehrende Komponenten unnötig und selbständig aufblähe, als auf eine Sammlung bereits fertiger und getesteter Komponenten zurückzugreifen?
Ja. Das schließt ja nicht aus, dass ich selbstgeschriebene Bausteine immer wieder verwende. Aber ich vermeide es immer, Fremdcode in meinen Projekten zu verwenden (außer es geht wirklich nicht anders), weil nach meiner Erfahrung der Einarbeitungsaufwand in keinem Verhältnis zum Nutzen steht.
Hätte ich für meine Windows-Applikationen irgendein Quasi-Standard-Framework wie z.B. MFC oder .NET benutzt, hätte ich schätzungsweise die drei- bis vierfache Zeit gebraucht,
Glaub ich nicht.
Musst du auch nicht. Die Tatsache an sich ist ein Erfahrungswert, der Faktor variiert jedoch mit der Komplexität des Projekts.
und das Endprudukt hätte ein Vielfaches an Code-Größe,
Das Gegenteil ist der Fall. Die Standardbibliotheken der Laufzeit darfst du ja nicht mitzählen, die sind ja sowieso schon vorhanden.
Natürlich muss ich die mitzählen! Okay, bei Java mit einem von der Anwendung getrennten JRE ist es IMHO statthaft, das Environment herauszurechnen, denn da ist das vom Design her so vorgesehen.
Die MFC-Bibliothek oder die VB-Runtime o.ä. kann ich aber nicht getrennt betrachten, denn sie werden beim Erstellen der Anwendung ein integraler Bestandteil davon. Auch wenn ich sie nicht statisch zum Programmcode linke, sondern dynamisch (als DLL), muss ich sie immer noch mit dem fertigen Projekt mitliefern, weil das Programm ohne nicht lauffähig ist. Und nein, ich möchte mich nicht darauf verlassen, dass der Anwender sich diese Bibliotheken selbst besorgt. Erstens finde ich das (aus Anwendersicht betrachtet) eine Frechheit, wenn das Programm nicht alles mitbringt, was für den Betrieb nötig ist, zweitens sind Versionskonflikte vorprogrammiert, wenn ich diese Aufgabe dem Anwender überlasse.
und ich wüsste zum Teil gar nicht, was meine Programme in Wirklichkeit tun.
Das was du programmiert hast, bzw. was in der Doku der von dir verwendeten Fremdbibliotheken steht.
Genau. Und was diese Fremdbibliotheken so alles tun, ist in den meisten Fällen eben *nicht* sauber dokumentiert. Und das würde mich als Programmierer beunruhigen.
Dass Microsoft hier mal wieder weit übers Ziel geschossen ist, seh ich genauso. Das JRE mit 15-23 MB je nach Zielsystem halte ich jedoch für absolut zumutbar.
Ja, zugegeben, das hält sich in vertretbaren Grenzen.
Ciao,
Martin
--
Success should be measured not so much by the position that one has reached in life,
but by the obstacles one has overcome while trying to succeed.
O'Brien
Der Martin
