Aversion gegen Java
-
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. (Wobei "für Doofe" jetzt nicht übermässig abwertend gemeint ist, gemeint sind Programmierer die sich sowohl von den Fähigkeiten als auch der Motivation im unteren Bereich des mittleren Drittels bewegen. Also die Leute mit denen grosse Firmen notgedrungen auch arbeiten müssen.)
Und dass er daher auch das Featureset entsprechend beschnitten/künstlich klein gehalten hat. Weil's halt immer unübersichtlicher wird je mehr Features/Sprachkonstrukte man hat. Ist aber wie gesagt hörensagen.
C# 1.0 war ja ähnlich - da waren ja auch nur ein paar wenige Dinge mehr enthalten als in damals aktuellen Java Version.Später wurden beide Sprachen dann erweitert - wobei C# die Vorreiterrolle übernommt hat, aber darum geht's ja eigentlich nicht.
Durch das "möglichst einfach halten" ergeben sich bei Java mMn. ein paar krass schlimme Dinge - die ich ganz bei den Gründen warum ich Java nicht mag vergessen hatte
z.B. "default access" sollte mMn. "private" sein, und nicht "internal". Oder die "alles ist virtual" Sache. Auauauauweh. Gut, es gibt final, aber auch hier wieder: falscher Default.Andrerseits könnte ich C++ da genau so kritisieren. Dass Klassen per Default copyable sind und Konstruktoren per Default "implicit" finde ich auch doof.
-
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 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.
Das war in der Anfangszeit. Aber inzwischen hat sich viel getan.
-
Mirek schrieb:
Destruktoren
Das ist mein größter Kritikpunkt.
-
@Mirek
Jo weiss nicht. Destruktoren sind so ziemlich das coolste Feature von C++. Ohne Destruktoren wäre C++ mMn. komplett witzlos.Umgekehrt sehe ich den schlechten Support für deterministische Finalisierung auch als riesen Problem in der ganzen "managed" Welt (C#, Java, ...).
Klar, IDisposable/AutoClosable helfen. Aber das Gelbe vom Ei is des auch net.
EDIT: Das Interface heisst AutoClosable, nicht IAutoClosable. Peinlich. Aber hey, ich bin ja kein Java-Mann, ich muss das nicht wissen
-
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. 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.
-
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. 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.
umgekehrt. java versucht, sofort zuschlagende destruktoren zu etablieren.
-
volkard schrieb:
umgekehrt. java versucht, sofort zuschlagende destruktoren zu etablieren.
Du sprichst von WeakReference/SoftReference, oder was meinst du?
-
[quote="Mirek"]
hustbaer schrieb:
Diese Aussage habe ich jetzt nicht erwartet. Aber gut, das liegt wohl an einem nicht vorhandenen GC. Soweit ich weiß, existieren in C++ Idiome, die mittels Destruktoren eine Äquivalenz zu einem GC zu schaffen versuchen.
Eher andersherum. Das IAutoCloseable Feature von Java versucht sich RAII anzunähern. Wobei GC und RAII unterschiedliche Ziele haben.
-
Techel schrieb:
Das IAutoCloseable Feature von Java versucht sich RAII anzunähern. Wobei GC und RAII unterschiedliche Ziele haben.
Tja, letztlich ist es doch auch gut, dass Java von seinen Verwandten lernt und sich weiterentwickelt. Schließlich sind alle objektorientierten, C-basierten Sprachen Geschwister und keine Feinde.
-
Mr X schrieb:
Es gibt zwar wohl reichlich Software, die intern in irgendwelchen Unternehmen läuft, aber Endbenutzer treffen eher selten drauf.
Der TV-Browser dürfte die bei Endbenutzern die am meisten verwendete Anwendung neben Minecraft sein.
Es ist also nicht so, dass niemand Java installiert hätte.Mit Minecraft kommen da sehr viele Millionen User zusammen.
Der TV-Browser dürfte in halb Europa verwendet werden, wobei dessen Nutzen mit sinkendem TV Konsum natürlich abnimmt.
Aber eine bessere Alternative zum TV Browser gibt es nicht.Entsprechend kann man den meisten Computernutzern nur zur Deinstallation von Java raten, zumal sich das Ding einigermaßen tief ins System einnistet.
Das macht .Net auch.
Soweit ich weiß, hat auch das BSI schon zur Deinstallation von Java geraten, wenn man es nicht braucht.
Das ist doch Blödsinn. Das kann man nämlich zu jeder Software sagen.
Software die man nicht braucht, die installiert man besser erst gar nicht.
Denn man kann ja nie wissen, ob eine Software doch mal eine Hintertür oder Schwachstelle etc hat.
Je mehr Software auf dem Rechner installiert ist, desto größer ist natürlich die Wahrscheinlichkeit, dass etwas schief läuft.Ich hab hier schätzungsweise seit mehr als 5 Jahren kein Java mehr installiert - vermissen tue ich es nicht.
Du schaust auch weder Fernsehen noch spielst du Minecraft.
Oder vielleicht spielst du kein Minecraft, aber gehörst zu den alten, die noch regelmäßig in eine Fernsehzeitung schauen und sei es nur die Beilage der Tageszeitung.
Woran kann das liegen?
Java Bytecode lässt sich leichter disassemblieren.
Es sind die Ängste der Entwickler, dass ihre Felle davonschwimmen. Mehr ist das nicht.Langsamkeit von Java (allein diese Gedenksenkunden beim Start von Java-Programmen...),
In Zeiten einer SSD? Klar!
-
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 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
