Aversion gegen Java
-
Ich finde, die IDE-Unterstützung bei Java bis dato am Besten.
Wenn ich bei einer Java-IDE "Find Usage (of method/class)", dann bekomme ich wirklich genaue Ergebnisse. Bei Qt Creator kriege ich da auch Quatsch raus.Bei Java ist es außerdem auch möglich auf Servern Applikationen zur Laufzeit zu patchen.
- Header-Dateien --> Bäh!
- Ändere etwas im Header und du bekommst plötzlich einen Quatsch-Zustand in deiner Software --> Rebuild!
- Muss ich jetzt für 32 Bit, 64 Bit, Windows oder Linux kompilieren? Das sind Fragen, die stellen sich jedes mal, wenn man für einen Kunden kompiliert.
- Ich muss nicht mal Java benutzen. Scala ist deutlich mächtiger, hat auch ein besseres Build-Tool, aber ich habe die Stärken der ausgereiften JVM.Java hat definitiv Schwächen, aber manche habe sich so sehr an die Schwächen von C++ gewohnt oder sind bereit darüber hinwegzusehen, dass es schon fast eine Beleidigung ist C++ als heiligen Gral darzustellen.
-
volkard schrieb:
Ethon_ schrieb:
Also meiner Meinung nach bieten Java/.NET oä. da schon gewaltige Vorteile. Statische Analyse ist bei C++ doch stark eingeschränkt.
Da fällt mir bei uns nur valgrind ein, das motzt, wenn im nativen Code Speicherfehler entdeckt werden.Ähm. Der C++-Stil ist, stets potentielle Fehler zu Compilerfehlern zu machen. Wer valgrind und Konsorten braucht, sollte sich von mir ein Buch anpassen lassen. Ich arbeite seit 10 Jahren fast ohne Debugger (ein Stündchen pro Monat) und das ist gut so und passt zu C++. Abgesehen davon, daß ich zu faul zum Debuggen bin, tut das C++-mäßige Erzwingen, das Herauspressen von Fehlern, dem Unternehmen grundsätzlich gut, weil Fehler auf dem eigenen Schreibtisch immer viel billiger sind als Fehler beim Kunden. Ich kenne keine andere Sprache (außer Lisp natürlich), die man so pressen kann im Sinne der Fehlervermeidung beim Kunden obwohl Tonnen von Code involviert ist, der historisch gewachsen ist.
Das ist die Idee. Funktioniert sicher auch super, wenn man alleine oder in einem sehr kleinen Team arbeit. Large Scale? Eher nicht, sagt die Praxis. Vor allem wenn dutzende C-Libraries in den Mix geworfen müssen, die teilweise fragliche Modelle haben.
ShadowClone schrieb:
Ich finde, die IDE-Unterstützung bei Java bis dato am Besten.
Wenn ich bei einer Java-IDE "Find Usage (of method/class)", dann bekomme ich wirklich genaue Ergebnisse. Bei Qt Creator kriege ich da auch Quatsch raus.Bei Java ist es außerdem auch möglich auf Servern Applikationen zur Laufzeit zu patchen.
- Header-Dateien --> Bäh!
- Ändere etwas im Header und du bekommst plötzlich einen Quatsch-Zustand in deiner Software --> Rebuild!
- Muss ich jetzt für 32 Bit, 64 Bit, Windows oder Linux kompilieren? Das sind Fragen, die stellen sich jedes mal, wenn man für einen Kunden kompiliert.
- Ich muss nicht mal Java benutzen. Scala ist deutlich mächtiger, hat auch ein besseres Build-Tool, aber ich habe die Stärken der ausgereiften JVM.Java hat definitiv Schwächen, aber manche habe sich so sehr an die Schwächen von C++ gewohnt oder sind bereit darüber hinwegzusehen, dass es schon fast eine Beleidigung ist C++ als heiligen Gral darzustellen.
Compilezeiten sind das nächste. 50 große Java-Projekte sind so schnell gebaut, dass man es nichtmal mitbekommt und nebenher arbeiten kann.
C++ sind die Buildzeiten teilweise echt übel. 16GB RAM im Arbeitsrechner sind einfach zu wenig, damit die Buildzeiten erträglich werden, will make gerne mal mit -j8 gestartet werden, dann geht der Speicherverbrauch für ld und gcc alleine schon auf deutlich über 10GB hoch. Java würden mir 4GB reichen, ohne dass es lästig und nervig wird.
-
Deshalb gibt es bald ein ordentliches Modulsystem, zwar bald, aber besser später als nie.
-
ShadowClone schrieb:
volkard schrieb:
Ethon_ schrieb:
Also meiner Meinung nach bieten Java/.NET oä. da schon gewaltige Vorteile. Statische Analyse ist bei C++ doch stark eingeschränkt.
Da fällt mir bei uns nur valgrind ein, das motzt, wenn im nativen Code Speicherfehler entdeckt werden.Ähm. Der C++-Stil ist, stets potentielle Fehler zu Compilerfehlern zu machen. Wer valgrind und Konsorten braucht, sollte sich von mir ein Buch anpassen lassen.
Welche Buch würdest du da empfehlen? Struppi?
Volki, welches Buch?!
-
k.A. an was volkard denkt, aber ich würde mal die ganzen Effective C++ Teile empfehlen.
-
ShadowClone schrieb:
ShadowClone schrieb:
volkard schrieb:
Ethon_ schrieb:
Also meiner Meinung nach bieten Java/.NET oä. da schon gewaltige Vorteile. Statische Analyse ist bei C++ doch stark eingeschränkt.
Da fällt mir bei uns nur valgrind ein, das motzt, wenn im nativen Code Speicherfehler entdeckt werden.Ähm. Der C++-Stil ist, stets potentielle Fehler zu Compilerfehlern zu machen. Wer valgrind und Konsorten braucht, sollte sich von mir ein Buch anpassen lassen.
Welche Buch würdest du da empfehlen? Struppi?
Volki, welches Buch?!
Anpassen! Dazu bräuchte ich die komplette Programmiervorgeschichte incl aller gelesener Bücher, die Schulnoten in den Hauptfächern seit dem 7. Schuljahr und die Schuhgröße und viel Zeit.
-
hustbaer schrieb:
k.A. an was volkard denkt, aber ich würde mal die ganzen Effective C++ Teile empfehlen.
Eher nur den ersten.
-
Ethon_ schrieb:
volkard schrieb:
Ethon_ schrieb:
Also meiner Meinung nach bieten Java/.NET oä. da schon gewaltige Vorteile. Statische Analyse ist bei C++ doch stark eingeschränkt.
Da fällt mir bei uns nur valgrind ein, das motzt, wenn im nativen Code Speicherfehler entdeckt werden.Ähm. Der C++-Stil ist, stets potentielle Fehler zu Compilerfehlern zu machen. Wer valgrind und Konsorten braucht, sollte sich von mir ein Buch anpassen lassen. Ich arbeite seit 10 Jahren fast ohne Debugger (ein Stündchen pro Monat) und das ist gut so und passt zu C++. Abgesehen davon, daß ich zu faul zum Debuggen bin, tut das C++-mäßige Erzwingen, das Herauspressen von Fehlern, dem Unternehmen grundsätzlich gut, weil Fehler auf dem eigenen Schreibtisch immer viel billiger sind als Fehler beim Kunden. Ich kenne keine andere Sprache (außer Lisp natürlich), die man so pressen kann im Sinne der Fehlervermeidung beim Kunden obwohl Tonnen von Code involviert ist, der historisch gewachsen ist.
Das ist die Idee. Funktioniert sicher auch super, wenn man alleine oder in einem sehr kleinen Team arbeit. Large Scale? Eher nicht, sagt die Praxis. Vor allem wenn dutzende C-Libraries in den Mix geworfen müssen, die teilweise fragliche Modelle haben.
Eher nicht, aber wenn überhaupt ein wenig, dann nur in C++, sagt die Praxis. Vor allem wenn dutzende Libraries in den Mix geworfen müssen, die teilweise fragliche Modelle haben.
-
volkard schrieb:
hustbaer schrieb:
k.A. an was volkard denkt, aber ich würde mal die ganzen Effective C++ Teile empfehlen.
Eher nur den ersten.
Was hältst du von "den Roten"?
Also Exceptional C++, More Exceptional C++, Exceptional C++ Style, C++ Coding Standards?An die kann ich mich ehrlich gesagt nicht mehr ausreichend erinnern als dass ich sie uningeschränkt empfehlen würde.
Sutter ist grundästzlich gut, aber das heisst ja nicht dass die Bücher alle gut sein müssen
-
Ich darf Volkard mal übersetzen: April April
---
Ich glaube Java ist über seinen eigenen Hype gestolpert. Die Sprache soll weniger fehleranfällig sein und man muss nicht mehr auf Resourcen achten. Mit dem Ergebniss dass sehr langsame Programme entstanden, da überall Objekte kopiert wurden, und dass trotzdem Java Programme mit sehr vielen unnötigen Fehler entstanden. Und gerade die langsame Geschwindigkeit einzelner Java Programme kam nicht gut an.
-
Bitte ein Bit schrieb:
Ich darf Volkard mal übersetzen: April April
Nicht im Geringsten.
-
Bitte ein Bit schrieb:
Ich darf Volkard mal übersetzen: April April
---
Ich glaube Java ist über seinen eigenen Hype gestolpert. Die Sprache soll weniger fehleranfällig sein und man muss nicht mehr auf Resourcen achten. Mit dem Ergebniss dass sehr langsame Programme entstanden, da überall Objekte kopiert wurden, und dass trotzdem Java Programme mit sehr vielen unnötigen Fehler entstanden. Und gerade die langsame Geschwindigkeit einzelner Java Programme kam nicht gut an.
Kopiert? In Java kopiert man seltener, ist ja sehr explizit eine Kopie zu erzeugen. Was richtig arschlangsam in Java ist, sieht man am Beispiel Minecraft, als sie doSomething(float x, float y, float z) zu doSomething(Vector3 vec) umgebaut haben, das ist in Java echt ein Problem, in den typischen Domänen aber nicht wirklich ein Szenario.
Die Werkzeug-Analogie halte ich immer noch für richtig, C++ für ein Spiel, Java EE für den Business-Server.
Trotzdem bin ich sehr gespannt wann die Value-Typen (aka C# struct) in Java kommen, Java 9 wohl nicht, und ob sie das Problem komplett beheben. Wäre super. Der Druck von IBM und anderen Big Playern ist ja massiv da.
-
@Ethon_:
Das waren Stilblüten bei Java. Gerade als man anfing in Java zu programmieren und man Call By Value, Call By Reference oder Objektkopien nicht verinnerlicht hatte.@volkard:
Du redest für meinen Geschmack zu abfällig, zu arrogant von Debuggern und anderen Tools.Fehlersicherheit bedeutet für mich einen hoffentlich sauberen Codestil, Testreihen, Black-Box Tests. Wann immer ich eine Debug Variante starte, wird mittels Assertions die korrekte Funktion sichergestellt.
Tools wie Valgrind, Application Verifier, Debug Diag als auch CppCheck sind da nette Tools welche nicht selten kleine aber böse Fehler finden. So ein kleiner Speicherüberlauf fällt nicht auf, wird aber unter sehr gewissen Umständen zu einem Fehler führen.
Und algorithmische Fehler finde ich nur mittels Debugger. Ich kann den Algorithmus in eine Zustand X fahren und danach mir den Zustand anschauen.
Ich habe einfach zu viele Fehler schon gesehen als dass ich Debugger verteufeln würde.
PS: Das gemeinste war einmal dass MyStruct.Counter = 1 nicht funktionierte sondern eine andere Variable änderte. Der Hintergrund war eine doppelte Struct Definition wodurch der Compiler durcheinander kam. Und für alle welche denken das wäre ein Sonderfall, sollte sich mal die Keil IDE anschauen.
-
Ethon_ schrieb:
Trotzdem bin ich sehr gespannt wann die Value-Typen (aka C# struct) in Java kommen, Java 9 wohl nicht, und
Da Java seit Anfang an immer wieder Sprachmottel von C++ jahrelang amlehnt und dann doch abkupfert, warum sich nicht jede Menge Arbeit sparen und gleich das Original nehmen?
-
Bitte ein Bit schrieb:
Ich glaube Java ist über seinen eigenen Hype gestolpert.
Java ist überhaupt nicht gestolpert, sondern eine äußerst erfolgreiche Sprache.
-
Gregor schrieb:
Bitte ein Bit schrieb:
Ich glaube Java ist über seinen eigenen Hype gestolpert.
Java ist überhaupt nicht gestolpert, sondern eine äußerst erfolgreiche Sprache.
Naja, so ein bisschen vielleicht schon. Als ich mit dem Programmieren anfangen wollte (Ende der neunziger) und mich umgehört habe, war Java damals allgegenwärtig. Es gab auch sehr viele Bücher zu Java, die sich mit Applets beschäftigt haben. Zumindest die sind schon mal ausgestorben. Und ansonsten gibts heute auch etwas mehr ernsthafte Alternativen und C++ ist auch wieder etwas interessanter geworden. Jedenfalls hatte ich damals den Eindruck, Java würde mindestens 90% ausmachen, und ansonsten gabs nur etwas Delphi und VB und dann noch C++ für Vollprofis. Ist heute zum Glück nicht mehr so einseitig.
-
Java ist doch ok. Man muss sich bei weiten nicht so doll mit der Programmiersprache beschäftigen wie bei C++ und die Ausführungsgeschwindigkeit reicht meistens aus.
Klar sind dann auch Entwickler zum Teil im Boot die nicht die Experten sind, aber solange der Kunde zahlt und zufrieden ist, ist das doch egal.
Entwicklungszeit zählt und auch dass man schnell Ersatz findet wenn ein Mitarbeiter weg fällt.
Ich selbst mache jetzt kein Java mehr, weil ich mich jetzt sehr auf C++ mit Qt freue. Aber Java hat mich immer schnell ans Ziel gebracht und Fehler wurden schnell gefunden.
Die Vielfalt ist doch gerade das Schöne.
-
Bjarne Stroustrup
In C++ ist es schwieriger, sich selbst in den Fuß zu schießen, aber wenn man es tut, dann ist gleich das ganze Bein weg
Mehr gibt es auch nicht zu sagen. Es mag ja C++ Entwickler geben die Ahnung haben, aber die sind rar gesät. Wie schwer der richtige Umgang mit C und C++ ist, sieht man schon an den unendlichen Sicherheitslücken. So gut wie jede C++ Software ist doch wie ein Schweizer Käse, bei dem man sich das Loch nur aussuchen muss.
Das ist nicht nur Schuld der Sprache, aber um mit dieser Sprache sicher und hochperformant zu programmieren, muss man schon ein C++-Oberprofi sein und wer ist das schon?
Je mehr C++ gemieden wird, und auf neue Sachen wie Rust oder so gesetzt wird, desto sicherer wird die IT-Welt. Leider ist Wahl für C++ meist keine freiwillige Entscheidung, sondern eher ein Muss wegen bestimmter Libs und Altprojekten.
C++ ist toll für Egoshooter und Grafikszeugs, aber C++ ist nichts für Sicherheit, egal wie viel da noch an die Sprache rangeflanscht wird. Da blickt doch kaum noch Jemand durch. Und ein Leute zu finden die wirklich kompetent ein C++-Projekt weiter entwicklen dürfte auch sehr schwer sein und immer schwerer werden, weil sich kaum noch Leute dieses Relikt aus den 80er antun wollen.
-
Eigentlich müsste man auch an diesem Forum hier sehen, dass das Interesse an C++ immer mehr zurück geht.
-
Ich weiß nicht wie es in der Industrie aussieht, aber beim Heimanwender geht ja so gut wie gar nichts mehr ohne Java. Android macht viele PCs obsolet. Es sei denn man arbeitet wirklich in der IT und brauch einen PC. Aber der Löwenanteil der Bevölkerung wird immer seltener einen vollwertigen PC brauchen.
