Aversion gegen Java
-
Mirek schrieb:
Schließlich sind alle objektorientierten, C-basierten Sprachen Geschwister und keine Feinde.
Und gerade die sprachlich unbeholfenen kleinen Geschwisterchen von plumpem Erscheinungsbild werden ja hemmungslos gemobbt, weil sie sich nicht wehren können
-
Was ist eigentlich aus Rust geworden? Redet darüber noch jemand?
-
Rust schrieb:
Was ist eigentlich aus Rust geworden? Redet darüber noch jemand?
Ja klar, im Java-Forum.
-
Mirek schrieb:
hustbaer schrieb:
@Mirek
Jo weiss nicht. Destruktoren sind so ziemlich das coolste Feature von C++. Ohne Destruktoren wäre C++ mMn. komplett witzlos.Diese Aussage habe ich jetzt nicht erwartet. Aber gut, das liegt wohl an einem nicht vorhandenen GC.
Dann hast du von der C++ Welt wohl nicht viel mitbekommen. Nicht übel nehmen, will dich nicht bashen, ist einfach nur ne Feststellung. Anders kann ich mir einfach nicht erklären dass die Aussage für dich unerwartet war.
Woran es liegt kann wohl nur Stroustrup beantworten, da lasse ich mich mal nicht auf Spekulationen ein. Eins ist allerdings klar, und das ist dass der GC kein Ersatz für Destruktoren ist.
Der Knackpunkt ist dass ein GC wie er in Java, C# etc. vorhanden ist keine deterministische Finalisierung anbieten kann, sondern nur nicht-deterministische Finalisierung. D.h. die Java Runtime ruft dir schon irgendwann den Finalizer auf. Nur das passiert halt erst irgendwann. Garantiert ist bloss dass es nicht "zu früh" passiert, also nicht während das Objekt noch erreichbar ist. Es kann aber beliebig spät sein.
Dadurch ist der Mechanismus völlig unbrauchbar dafür bestimmte Resourcen freizugeben. Genaugenommen unbrauchbar dafür jegliche Art von Resources freizugeben ausser RAM.Deterministische Finalisierung garantiert dir dagegen dass genau zu dem Zeitpunkt wo ein Objekt "verschwindet" dieses auch finalisiert wird. Durch den Aufruf des Destruktors. Automatisch. Und das ermöglicht eben so ziemlich jede Art von Resourcen in Objekte einzuwickeln. Ohne dass man Dinge explizit freigeben/schliessen/... muss.
Die Anwendbarkeit von Destruktoren ist auch nicht auf das Freigeben von Zeugs beschränkt. Man kann damit viele Sachen sehr elegant lösen die aus einem "do" und einem "undo" Teil bestehen. Sowas wie
synchronized(Java) bzw.lock(C#) implementiert man in C++ einfach als Hilfsklasse (lock_guard, unique_lock, ...). Automatisches Rollback von Transactions wenn ein bestimmter Scope verlassen wurde ohne dass die Transaction davor committed wurde? In C++ kein Problem. Wo immer du in Javafinallyschreibst kannst du davon ausgehen dass man das selbe in C++ vermutlich eleganter lösen kann indem man ne kleine Hilfsklasse schreibt.Mirek schrieb:
Soweit ich weiß, existieren in C++ Idiome, die mittels Destruktoren eine Äquivalenz zu einem GC zu schaffen versuchen. Smartpointer und so. Ich bin diesbezüglich aber nicht so auf dem Laufenden.
Ja, es gibt Smartpointer. Und ja, mit Smartpointern kann man ähnliche Probleme lösen wie mit nem GC. Nur meistens besser
Wenn du mit shared_ptr arbeitest, dann bleibt die Finalisierung z.B. weiterhin deterministisch. Dort wo der letzte shared_ptr der auf ein bestimmtes Objekt zeigt zerstört bzw. auf ein anderes Objekt "verbogen" wird, wird exakt zu diesem Zeitpunkt und in diesem Kontext der Destruktor des Objekts aufgerufen.
-
Java & Endanwender schrieb:
Langsamkeit von Java (allein diese Gedenksenkunden beim Start von Java-Programmen...),
In Zeiten einer SSD? Klar!
Die Gedenksenkunden kommen doch eher dadurch zustande dass erstmal haufenweise Frameworkcode gejittet werden muss. Bzw. je nach JIT Engine auch erstmal jede Codestelle ein paar hundert bis tausend mal interpretiert wird bis der JITer beschliesst dass es jetzt Zeit wäre das Zeug mal zu jitten.
Und in der Phase läuft halt alles elending Langsam.
Bei Anwendungen die grössere Frameworks verwenden die z.B. viel Initialisierungscode haben, haut das schon ordentlich rein.Genau das ist auch der Grund dass Google die ART ("Android Runtime") gebaut hat, wo neuerdings Java Apps beim Installieren schon in native Code compiliert werden. Was dazu führt das Apps deutlich schneller starten.
-
Java & Endanwender schrieb:
Mehrfachvererbung ist auch ein Übel.
Ja. So direkt widersprechen will ich da nicht unbedingt. Mehrfachvererbung schafft wohl mehr Probleme als es löst.
Es ersatzlos zu streichen ist aber auch irgendwie doof. Nein, falsch, nicht ersatzlos, immerhin gibt es in Java Interfaces.
Aber wäre halt schön wenn Java noch zusätzlich z.B. Aspect Oriented Programming und Mixins unterstützen würde. (Gilt natürlich genau so für C#.)In C++ kann man viele Dinge wo man Aspect Oriented Programming bzw. Mixins brauchen würde zwar nicht schön machen, einige davon aber zumindest akzeptabel über Mehrfachvererbung lösen.
Die schönere Lösung wäre aber sicher echten Support dafür zu haben. Aber diese Tür ist ja für alle hier genannten Sprachen noch offen. Da weder Aspect Oriented Programming noch Mixins eine Änderung am Type-System erfordern würden, liesse sich das nachträglich noch schön dazubauen.
-
hustbaer schrieb:
Ich hab' das nicht selbst nachrecherchiert, aber ein Freund von mir der viel mit Java macht und sich mit der Entstehung/Geschichte dahinter befasst hat, hat mir erzählt dass der Java-Erfinder eine Sprache "für Doofe" machen wollte bei der man möglicht wenig falsch machen kann.
"Made for the shallow end of the gen pool"
-
EOP schrieb:
"Made for the shallow end of the gene pool"
FTFY
-
hustbaer schrieb:
EOP schrieb:
"Made for the shallow end of the gene pool"
FTFY
Hab das später auch gesehen, aber was willst du um 4 Uhr morgens schon erwarten? War zu faul und müde für ein edit.
-
Ist ja OK
Ist halt nur bei so einem Satz witzig, hoffe du verstehst das.
-
hustbaer schrieb:
Ich hab' das nicht selbst nachrecherchiert, aber ein Freund von mir der viel mit Java macht und sich mit der Entstehung/Geschichte dahinter befasst hat, hat mir erzählt dass der Java-Erfinder eine Sprache "für Doofe" machen wollte bei der man möglicht wenig falsch machen kann.
Das mag sein, aber man wird eben auch nicht schlauer, nur weil man C++ benutzt.
-
Hab ich ja auch nicht behauptet.
-
Arbeitet hier überhaupt jemand produktiv mit Java?
Ich entwickle beide Sprachen parallel und Java ist weitaus angenehmer und macht deutlich weniger Probleme. Aus dem Grund wird C++ auch nur selektiv eingesetzt.
Wenn es Probleme gibt, dann sind die meistens im C++ Code versteckt. Und versteckt trifft es gut.
-
Ich habe früher wie schon gesagt, produktiv mit Java gearbeitet. Und fand die Sprache überhaupt nicht angenehm.
-
@Ethon_
Ergibt sich irgendwie von selbst dass man bei Dingen die man deutlich seltener macht auch deutlich mehr Fehler macht
-
Ethon_ schrieb:
Arbeitet hier überhaupt jemand produktiv mit Java?
Ich entwickle beide Sprachen parallel und Java ist weitaus angenehmer und macht deutlich weniger Probleme. Aus dem Grund wird C++ auch nur selektiv eingesetzt.
Wenn es Probleme gibt, dann sind die meistens im C++ Code versteckt. Und versteckt trifft es gut.Mit geht es genau anders herum. Ich arbeite produktiv mit Java (hauptsächlich Backend) und stolpere regelmäßig über die, ich sag's mal, fehlende Ausdrucksstärke dieser Sprache (der Fairness halber muss ich aber auch eingestehen bin ich regelmäßig begeistert vom Umfang des Ökosystems).
Privat entwickle ich momentan ausschließlich C++ in den Bereichen Embedded, Tools und (seltener) GUI und freue mich immer wieder, wie vielfältig diese Sprache ist. Probleme habe ich dabei eher wenig. Hier und da mal ein kleiner Crash, weil ich eine lokale Variable per Referenz an ein Lambda gebunden habe :D, aber sonst... Und auch hier gilt zumindest für die genannten Bereiche ("Enterprise" ist sicher nicht der Hauptanwendungsfall für C++), dass es kaum etwas gibt, was nicht irgendwo jemand schonmal gemacht hat, meist sogar in Boost, welches ich sowieso immer verwende.
-
LordJaxom schrieb:
Privat entwickle ich momentan ausschließlich C++ in den Bereichen Embedded, Tools und (seltener) GUI und freue mich immer wieder, wie vielfältig diese Sprache ist. Probleme habe ich dabei eher wenig. Hier und da mal ein kleiner Crash, weil ich eine lokale Variable per Referenz an ein Lambda gebunden habe :D, aber sonst... Und auch hier gilt zumindest für die genannten Bereiche ("Enterprise" ist sicher nicht der Hauptanwendungsfall für C++), dass es kaum etwas gibt, was nicht irgendwo jemand schonmal gemacht hat, meist sogar in Boost, welches ich sowieso immer verwende.
Ja - betonung auf privat! Ich mag C++ ja auch und habe damit echt viel privat entwickelt, alles okay. Aber wenn 50 Leute auf einer Codebasis arbeiten dann sind Probleme weitaus häufiger als wenn das Ganze mit Java passiert. Meiner Erfahrung nach.
hustbaer schrieb:
@Ethon_
Ergibt sich irgendwie von selbst dass man bei Dingen die man deutlich seltener macht auch deutlich mehr Fehler machtOch, habe jahrelang nur C++ programmiert, an meinem Können soll es nicht scheitern.
-
@Ethon_
Wenn du glaubst.
Ich programmiere halt auch C++. Ich baue dabei aber so gut wie nie "versteckte Probleme".
-
Ich arbeite seit 15 Jahren beruflich mit Java.
Wie hier schon oft gefallen, ist das Ökosystem sehr gut ausgebaut. Man bekommt für alles was man braucht und nicht braucht eine Lösung. Das macht die gesamte Java-Welt sehr professionell.
Aber es gibt auch in der Sprache ein paar Dinge, wo man sich Workarounds bauen muss: täglich wird die Kapselung gebrochen! Und das von Profis, egal ob in Magazinen, Konferenzen und Real-Projekten. Weil es keine const-correctness wie in C++ gibt.
Workaround: Immutable Objects bauen oder diffensive Kopien benutzen!Dann gibts noch so Dinge wie die OSGi-Plattform, die ja ne nette Idee ist. Aber innerhalb der Eclipse-IDE immer wieder Ärger macht (Plug-ins werden beim Product-Export nicht gefunden, weil die Patch-Versionen sich nicht finden lassen). Und das Austauschen von Bundles/Plug-ins zur Runtime ist nur im Traum möglich.
Durch die fehlenden Destruktoren bleiben immer irgendwo Listener hängen, die nie abgeräumt werden.
Aber ich kann für C++ und jede andere Sprache genauso schlechte Beispiele aufführen. Bei C++ kotzt mich heute (nach vielen Jahren Java) das Header-System an. Es macht unnötig Mehrarbeit und widerspricht dem DRY-Prinzip!
Deshalb arbeite ich mit Java heute trotzdem gerne (war nicht immer so!).
-
Der C++-Standard vom nächsten Jahr wird meined Wissens nach ein Modulsystem beschreiben. Clang hat es jetzt schon drin.
