Aversion gegen Java



  • Artchi schrieb:

    Am Ende ist das Ökosystem einfach für Enterprise einfach super.

    Außerdem ist Java in diesem Bereich besser als die Alternativen.

    Man denke an PHP. hust, hust....

    Und JavaFX 2 (ist was anderes als das ursprübgliche JavaFX 1) ist auch eine sehr interessante GUI-Technik, die das elend langsame Swing ablöst! Vor 15 bis 20 Jahren konnte man regelrecht zu sehen, wie sich eine Swing-GUI aufbaut. Mit Java FX 2 ist man auf einem komplett anderen Planeten. 👍

    Dank Hardwarebeschleunigung die JavaFX 2 verwendet.
    Auf alter Hardware ist es allerdings ne größere Qual als Swing.

    Nein, der große Vorteil von JavaFX sind die Möglichkeiten der API selbst.
    Swing Oberflächen muss man in Java coden, bei JavaFX kann man Designer und Grafiker an XML und CSS Dateien herumarbeiten lassen umd die GUI zu verändern.
    Da ist ein großer Vorteil, weil man dann für die gestalterischen Aufgaben keine Programmierer benötigt.
    Das spart kosten und beschleunigt die Entwicklung.



  • Mirek schrieb:

    Das deckt sich durchaus mit dem was ich so gehört habe. Zu der Zeit gab es schon C++. Und erste Erfahrungen mit dieser Sprache, waren recht ernüchternd. Java war angetreten, das zu beheben. Manuelle Speicherverwaltung, Pointerarithmetik, Typecasting von allem in jedes, Destruktoren und Mehrfachvererbung, wurden als Ursachen des Übels ausgemacht.

    Mehrfachvererbung ist auch ein Übel.

    Gegen Pointerarithmetik, Typcasting und Destruktoren hab ich nichts, man muss halt wissen was man tut. Aber Mehrfachvererbung ist doof, das ist wie GOTO. Es neigt zu schlechtem Programmierstil, bzw. in diesem Fall genauer Klassendesign.



  • 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 Java finally schreibst 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 macht 😉

    Och, 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".


Anmelden zum Antworten