Warum programmiert ihr in Java?

Endlich mal wieder ein Sprachenbashing-Thread :smiley:

Die Antwort ist einfach und immer die gleiche: „Weil Java die besteste Sprache von der Welt sein tut!!!111einszwöf“

Eigentlich sind die Vor- und Nachteile speziell beim Vergleich zu C++ schon SO ausgelutscht, dass es schon fast langweilig wird. Aber da ich in letzter Zeit wieder etwas C++ machen durfte, sind mir die Vorteile von Java wieder (schmerzhaft) vor Augen geführt worden. (Immer, wenn ich C++ programmiere, bekomme ich Lust darauf, Raider zu essen und Cola aus 1-Liter-Glasflaschen zu trinken). In C++ werden dann erstmal 10 Klassen mit compilerspezifischen #ifdefs und inline-Assembler erstellt, um die (für alles, was über akademische Toy-Projekte hinausgeht) vollkommen unbrauchbaren Pointer hinter einer dicken Sicherhheitsschicht mit Reference Counting & Co zu verstecken, und wenn man das Wort „Java“ nur erwähnt, wird trotzdem noch über den Garbage collector geschimpft. Kein nicht-triviales Programm kommt ohne Boost C++ Libraries aus. C++ hatte bis version 11 nicht mal Threads (die es in Java seit 20 Jahren gibt), geschweige denn ein Memory Model. Buildprozesse und IDE-Unterstützung sind ein Witz, schon die Fragen „Wer ruft diese Methode auf?“, „Wird dieses #include hier benötigt oder nicht?“, oder „Welche Klassen erben von dieser hier?“ sind praktisch unbeantwortbar, außer mit einer Volltextsuche über den gesamten Code.

Das alles wäre schlimm genug. Richtig niederschmetternd finde ich, dass viele „eingefleischte C++ler“ zu glauben scheinen, dass das alles gut und richtig ist, so wie es ist.

Tipp:
[spoiler]
Das ist es nicht.

(Nur um das mal überdeutlich gesagt zu haben. Und wer das nicht glaubt, dem würde ich gerne mal eine Demo-Session geben, wie man in Eclipse ein kleines Projektchen erstellt. IN YOUR FACE :smiley: ).
[/spoiler]

Also mal im Ernst:

Java ist eine Sprache, die den (für mich) richtigen Trade-Off zwischen High-Level Konzepten und Low-Level Möglichkeiten* bietet, den (für mich) richtigen Trade-Off zwischen erzwungenen Konventionen** und schönen Abstraktionsmöglichkeiten bietet***, und mit der man sehr schnell und sehr leicht in vieler Hinsicht gute Programme schreiben kann.

(Wer meint, er könne gut C++ programmieren, möge sich bei mir melden. (Bisher hatte noch niemand die Eier, das zu tun)).

  • Mehr Low-Level Möglichkeiten wären gut. Es wäre schön, wenn man JCuda oder JOCL nicht bräuchte. Es wäre auch gut, wenn man bessere Repräsentationen von „rohem Speicher“ und „value objects“ hätte. Aber NUR dafür auf C/C++ zu schwenken wäre ein mieserabler Tausch. Wenn man in C++ eine Zeile sieht wie int y = x * 3; dann weiß niemand, was diese Zeile macht - und, was fast noch schlimmer ist: Es gibt keine praktikable Möglichkeit, herauszufinden, was diese Zeile macht!. Vielleicht ist der Zuweisungsoperator von „int“ so überladen, dass er MineSweeper startet. Man weiß es einfach nicht.

** Mit „Konventionen“ meinte ich hier z.B. die 1:1-Korrespondenz zwischen Packages und Verzeichnissen, und dass jede public class „X“ in einer Datei Namens „X“ liegen muss. Wenn man in einem C+±Projekt eine Klasse „Namespace::Foo“ hat, und sie dann in einem Verzeichnis „Your\Princess\Is\In\Another\Castle.cpp“ findet, läuft es einem kalt den Rücken runter.

*** Mehr Abstraktionsmöglichkeiten wären gut. Das Typsystem ist wirklich nicht so mächtig, und der Vergleich von Generics mit C++Templates wirkt wie der Vergleich eines Bobby-Cars mit einem Formel1-Rennwagen. Aber auch dort gilt: Wenn das (eigentlich tolle!) System der „Concepts“ bei C++ erst durch Concept Check Library - 1.57.0 einen Hauch von Sinn bekommt, scheint beim grundlegenden Design und der Evolution der Sprache etwas SO grundlegend falsch gelaufen zu sein, dass ich mir anmaße, in Frage zu stellen, ob diejenigen, die dafür verantwortlich sind, sich überhaupt „Informatiker“ (oder „Computer Scientists“) nennen dürfen.

YMMD :smiley: Ich lese auch ab und in C++ Foren und den Leute nach zu urteilen ist nur mit C++ der Stein der Weisen zu modellieren. Die Arroganz sucht da oft seines Gleichen. Wenn ich mich dann so bei den Jobs und den Projekten und auch in Fachzeitschriften umschauen ist C++ so gut wie nie ein Thema, so als wenn das eine tote Sprache wäre, die niemand mehr spricht. Wir wir alles wissen ist dem nicht so, aber ich hoffe das Sprachen wie Rust uns von diesem wirklich sehr hässlichen C++ irgendwann befreien.

Vielleicht ich das hier ein wenig in Sprachbashing abgedriftet, aber wo wenn nicht in einem Forum für eine Programmiersprache, kann man denn mal seinen Frust über C++ ablassen und erzählen wie schön es sich dagegen in Java programmieren lässt. Wenn ich halt mal was brauchen sollte was es nicht gibt, oder zu langsam ist, dann nehme ich halt für diesen kleinen Teil was mit JNI.

[QUOTE=The-Last-Ninja]
Am meisten hat mich wirklich C++ genervt. Ich habe viele teure Bücher gekauft und es wirklich die letzten 6 Jahre immer mal wieder probiert zu lernen. Ich habe auch in der Zeit einiges Begriffen und auch Erfolge gehabt, aber irgendwie ist das Entwickeln mit Java tausendmal entspannter. Ich habe zuletzt noch ein wenig C++11 gelernt und habe mich dabei erwischt wie ich tagelang nur darüber nachdachte ob ich die C+±Klasse jetzt so einigermaßen hin bekommen habe(Da gibt es ja so viele Regeln und Feinheiten und und und). Dann habe ich vor ein paar Tagen wieder mit Java angefangen und war sofort im alten Projekt wieder drinn, weil ich den Quellcode auch gleich wieder verstand und konnte einfach loslegen. Klingt vielleicht alles blöd und subjektiv. Ich will hier auch nicht C++ schlecht machen, da es für viele Anwendungen einfach viel Sinn macht C++ zu nehmen, aber ich habe vor der Sprache kapituliert. Ich bin anscheinend zu dumm für C++ und wer Java mag ist eh kein echter Programmierer, so kommt da jedenfalls immer in deren Foren rüber.[/QUOTE]

Noch kurz dazu: Ich stimme dir zu, und kann das nachfühlen. Es gibt genug Leute, die auf einer pervertierten Form von pretentiöser Geekiness heraus meinen, behaupten zu müssen, sie würden C++ programmieren. Tendenziell geht das, was die dann machen, in eine von zwei Richtungen: Über-Abstrahiert abgehoben-praxisfernes Template-Magic-Metaprogramming, oder sowas wie FILE *fp = fopen("test.txt", "r"); (also dass Leute C programmieren, und meinen, es wäre C++, weil sie es in ein class Foo { ... } einwickeln). Und meiner Erfahrung nach drängt sich auch oft der Eindruck auf, dass diese schon fast „aus Prinzip“ Java-Programmierer für unfähige Idioten halten. Mein Tipp dazu: Dunning-Kruger-Effekt – Wikipedia lesen und gaaanz locker durch die Hose atmen :smiley:

Natürlich gibt es auch Leute, die aus gutem Grund die richtigen Teile von C++ pragmatisch und zielorientiert einsetzen, und dabei guten Code erstellen. Und es gibt sicher mehr schlechte Java-Programmierer als schlechte C+±Programmierer - ganz einfach weil jeder Id!ot an der Uni „Java macht“, und sich dann „Java Programmierer“ schimpft, und schlecht ist. Aber schlechten Java-Code kann man lesen, verstehen, und weg-wrappen oder refactorn. Schlechten C+±Code kann man in den Müll werfen. Umgekehrt: Es gibt mit Sicherheit auch mehr gute Java-Programmierer, als es gute C+±Programmierer gibt (weil ich immernoch in Frage stelle, ob es letzere überhaupt gibt (traut euch - meldet euch! :D)).

Doch die gibt es. Wundert mich selbst. In einer Firma in der ich war gab es ein .Net Produkt, welches auf einem C++ Produkt aufgebaut hat. Der C++ Teil war ein hoch performanter Service um Dateien abzuspeichern und zu lesen. Als Speichermedien konnten da verschiedene Storage-Systeme zum Einsatz kommen. Also enthielt das Teil auch Driver-Code.

Das war ein schönes Stück Software das zuverlässig und schnell funktionierte. Jahr ein, Jahr aus. Das konnte man leider nicht vom .Net-Teil behaupten.

[ot]Zuverlässigkeit und Geschwindigkeit sind - idealistisch betrachtet - eine Art „Null-Linie“ - also die Minimalanforderung. Erweiterbarkeit, Flexibilität (auch im Sinne von Evlolvierbarkeit), Verständlichkeit des Codes, SOLID-Pronzipien etc. sind Dinge, die da auch dazugehören. Aber ich gehe davon aus, dass klar war, dass meine Aufforderung eine Art „Provokation“ war. Angeblich (HÖCHST unfundiertes Gerücht) soll Stroustrup seine C+±Fähigkeiten auf einer Skala von 1 bis 10 mal bei 7 eingeordnet haben :wink: [/ot]

[QUOTE=Marco13](Wer meint, er könne gut C++ programmieren, möge sich bei mir melden. (Bisher hatte noch niemand die Eier, das zu tun)).[/QUOTE]Diese Eier hätten sicher Programmierer von Java-Just-In-Time-Compilern, aber die haben es nicht nötig!

Tja, warum Java? Wie in deinem ersten Post zu lesen ist, empfindest du C/C++ gegenüber anderem auch recht kompliziert. Ich bringe ja immer das Argument, dass sich sehr gute C/C+±Programmierer nur dort finden, wo sehr gute Just-In-Time-Compiler programmiert werden, mitunter gehört Java zu diesen Sprachen. Wieso also nicht von der Arbeit wirklich guter C/C+±Programmierer profitieren und es einfacher haben. Kümmer dich in Java mal um Speichermanagement und vergleich den Aufwand mit C/C++. Andere Beispiele gibt es zwar auch, aber keines dürfte so extrem ausgebildet sein, wie besagtes Speichermanagement. Und dank der wirklich guten C/C+±Programmierer wird einem mit Java inzwischen eine Sprache geboten, die C/C++ (also der Grundlage ihrer „Engine“) in Sachen Geschwindigkeit zu Aufwand und Nutzen in nichts nachstehen. Selbiges gilt mitunter auch schon für C#. Das Potential hat MS btw. nicht nur erkannt, sondern anno dazumal wohl auch fast 1:1 kopiert, weswegen C# sich halt kaum von dem „eingestampften“ J# oder gar Java unterscheidet. Eigentlich musste MS damals ja nur ihre eigene MS-JVM ein wenig abändern. Kann sich eigentlich noch einer daran erinnern, warum MS diese JVM ebenfalls einstampfen durfte?

Kurz und gut: Wo C/C+±Leute Recht haben, haben sie Recht. Der Stein der Weisen kann nur mit C/C++ und ein wenig Assembler programmiert werden. Dieser Stein der Weisen heisst btw. Just-In-Time-Compiler und sowas können halt ca. nur 30% der C/C+±Programmierer, die sich für die Besten halten. Ausserdem: Die wenigsten, die meinen ausschliesslich C++ (und das sehr gut) zu schreiben, verwenden trotzdem noch C-Fragmente und merkens nicht mal. :smiley:
Versuch mal einen Java-Programmierer vorzuwerfen, er würde andere Sprachfragmente ausser Java verwenden… wäre ja, als wenn man z.B. Scala programmiert, innerhalb dieser Umgebung aber nur Java-Fragmente nutzt.

Gar nicht wahr, Perl ist die besteste Sprache der Welt!!! :aetsch:

Aber im Ernst, für Desktop-Applikationen gefällt mir Java auch besser als C++, einfach weil bei Java schon sehr viel vorgegeben ist, so daß ich selbst weniger Arbeit habe. Aber Java und C++ sind ja nun beileibe nicht die einzigen Sprachen, und vor allem sind Desktops nicht die einzigen Plattformen. Ich selbst beschäftige mich eher mit eingebetteten Systemen (unterhalb der DVD-Player-Leistungsklasse), und dort kann man mit Java nicht viele Blumentöpfe gewinnen. Da hat C(++) auf jeden Fall die Nase vorn, nicht nur weil man damit auch mal Hardware ansteuern kann, sondern vor allem auch weil C(++)-Code berechenbarer ist - egal ob’s um Rechenzeit, Speicherplatzbedarf oder Energieverbrauch geht.
Irgendwie habe ich das Gefühl als hätten Java u.ä. Sprachen C++ zwar vom Thron der Desktop-App-Programmierung verdrängt, aber als sei dieser Thron nicht mehr allzu erwähnenswert. In Zukunft werden ES viel interesanter sein, und da sehe ich noch nicht, das Java - entgegen der Hoffnungen der Namensgeber - Fuß fassen konnte.

Und jetzt zu etwas völlig anderem: Der eigentlichen Frage des TE.
Ich selbst nutze Java gerne als Universalsprache für Desktop-Programme, einfach weil Java von Haus aus schon sehr viele Bibs mitbringt und diese einheitlich aufgebaut sind. Und das bedeutet: Weniger Arbeit für mich.
Daneben nutze ich, je nach Anwendungsbereich, aber auch gerne Perl, Matlab, Haskell, oder was immer, und zwar aus genau den gleichen Gründen.

Ach, und was ich noch sagen wollte: Nur ewig gestrige Leute programmieren noch Desktop-Apps! wegrenn

PS @TheDarkRose : Hast du zufällig auch schonmal mit Klee gearbeitet? Ich frage mich gerade ob man sich da einigermaßen einfach in den Source einklinken kann um eigene Kriterien zu analysieren. Schwanke noch zwischen Klee, Frama-C und CiaoPP. Hast du da vielleicht 'n Tipp für mich? :slight_smile:

Sehr interessante Meinungen.

Die guten C+±Programmierer gibt es auf jeden Fall, aber selbst die können, so wie jeder Mensch, auch nicht ohne Fehler entwickeln. Da sind Sprachen wie Rust genau richtig. Dort lässt der Compiler schon eine Vielzahl der gefährlichen Fehler erst gar nicht zu. Das Mozilla die zukünftige Browser-Engine in Rust entwickelt ist eine gute Sache, da somit so einige Sicherheitslücken(nicht alle) sich von allein in Luft auslösen, einfach weil Rust sie gar nicht zulässt. Ich würde mir auch wünschen, dass eine JVM in Rust neu geschrieben werden würde, denn die Sicherheitslücken in Java, die auch für den schlechten Ruf gesorgt haben, die haben wir auch allein der Tatsache zu verdanken, dass C++ verwendet wurde, eben weil nichts anderes Performantes da war.

Es wird wirklich Zeit, dass C++ abgelöst wird von Sprachen wie Rust und was da noch alles kommen mag. Das es performant und sicher geht hat Rust bewiesen und ich hoffe beim Release im März/April wird auch IDE und mehr Libs kommen(obwohl schon viele Bindings von CLibs in der mache sind). LLVM macht es einfach neue Sprachen mit guter Performance zu entwickeln. Ich habe auch gehört dass ein einen Java Frontend gearbeitet wird. Vielleicht gibt es dann, wie für Android mit dem neuen ART, auch eine kompilierte Javawelt für den Desktop, mal schauen.

Mir liegt leider Rust auch nicht so, da mir das Pattern Matching und die funktionale Programmierung an sich sehr fremd ist. Im Moment bin ich auch noch nicht dabei mir solch eine Lernhürde aufzubürden.

Gestern habe ich wieder eine Weile in Java programmiert und bin endlich wieder vorangekommen. Ich wollte was umbauen und dank dem guten Refactoring war das kein Problem. Genau so etwas brauche ich.

Eine einfache Sprache, mit tollen Standardlibs, guter Doku und einer super IDE-Unterstützung.

Ich bin in einem Interview mal gefragt worden wieso Java mein Favorit ist, Antwort war damals (und die würde ich heute auch noch unterschreiben):

I used to program in C++ for a long time and actually my first contact with Java was back in the old Java 1.2 days. Everybody looking back on that time probably remembers hating it. At that time it was what people still think of Java: memory consuming, slow, in one word, unusable.

I switched back to C++ and had to look again at Java at the end of 1.5 / beginning of 1.6 area thanks to a project. My expectations were totally blasted after the first days in that completely new world.

The answer to the “why” itself then is pretty simple:
Java, as a language, was designed from to be more readable than writeable. Knowing that it means it is very verbose but still we read code way more often than we write it!

On the other hand Java, as a platform – the JVM, is an amazing, ever evolving piece of genius work. A lot of the best performance engineers working on it and a lot of different languages running on top of the JVM – there’s at least one language for everybody, I’m pretty sure of.

Es gab schon so viele gute Alternativen zu C++, die sich alle nicht durchgesetzt haben. Selbst solche No-Brainer wie D von Digital Mars, die nur Vorteile gegenüber C++ bieten, ohne großartig mit der Syntax zu brechen. Nichts gegen Rust, die Sprache ist nicht schlecht, aber warum sollte es ihr besser ergehen als den Vorgängern? Der durchschnittliche C+±Programmierer scheint aus unerfindlichen Gründen wild entschlossen zu sein, auch als selbiger zu sterben (oder wie es dort heißt, auf void* gecastet zu werden).

Ich spiele gerade mit D rum, baue damit eine native Update Application (embedded ARM platform), die Sprache gefällt mir richtig gut, viel viel besser als C++ und ist unglaublich mächtig :slight_smile:

Warum ich an Rust glaube? Nun, weil jeder Zweite bald ein Rust-Programm täglich nutzen wird. Die neue Browser-Engine Servo vom Firefox wird in Rust geschrieben und wird dann Gecko in Rente schicken. Servo soll jetzt schon viel schneller laufen als Gecko. Wenn sich dann noch wirklich herausstellt, dass Servo signifikant weniger Sicherheitslücken als das C++ Gecko hat, dann wird das schon die IT-Welt beeindrucken. Bei D fällt mir jetzt kein Programm ein was so jeder kennt, wo man sich wirklich mal ein Bild von einem Produkt der Sprache machen konnte.

Was Rust fehlt, das sind IDE, Community und Libs. Erst dann kann es eng für C++ werden. Ein guter Kandidat ist Rust auf jeden Fall. Ich weiß nicht wie sehr auch diese neuen Paradigmen wie Funktional + Triats und Pattern Matching etc. ankommen und ob sich das Programmieren generell in diese Richtung entwickelt. Wenn dem aber so ist, dann hat Rust auch dort eine gute Position.

Auf jeden Fall werde ich Rust dieses Jahr im Auge behalten und mich vielleicht auch doch mal mit funktionaler Programmierung beschäftigen. Ich glaube einfach nicht, dass die Welt bis auf alle Ewigkeit C und C++ als Systemsprache nutzen wird.

[QUOTE=The-Last-Ninja]Warum ich an Rust glaube? Nun, weil jeder Zweite bald ein Rust-Programm täglich nutzen wird. Die neue Browser-Engine Servo vom Firefox wird in Rust geschrieben und wird dann Gecko in Rente schicken. Servo soll jetzt schon viel schneller laufen als Gecko. Wenn sich dann noch wirklich herausstellt, dass Servo signifikant weniger Sicherheitslücken als das C++ Gecko hat, dann wird das schon die IT-Welt beeindrucken. Bei D fällt mir jetzt kein Programm ein was so jeder kennt, wo man sich wirklich mal ein Bild von einem Produkt der Sprache machen konnte.

Was Rust fehlt, das sind IDE, Community und Libs. Erst dann kann es eng für C++ werden. Ein guter Kandidat ist Rust auf jeden Fall. Ich weiß nicht wie sehr auch diese neuen Paradigmen wie Funktional + Triats und Pattern Matching etc. ankommen und ob sich das Programmieren generell in diese Richtung entwickelt. Wenn dem aber so ist, dann hat Rust auch dort eine gute Position.

Auf jeden Fall werde ich Rust dieses Jahr im Auge behalten und mich vielleicht auch doch mal mit funktionaler Programmierung beschäftigen. Ich glaube einfach nicht, dass die Welt bis auf alle Ewigkeit C und C++ als Systemsprache nutzen wird.[/QUOTE]

Ja das stimmt, leider ist bei D nichts bekanntes unterwegs. Ich weiß aber, dass es bei einigen (Spiele-)Firmen im Backend (also serverseitig) eingesetzt wird, da der Code massiv besser wartbar ist als C++ (halt ähnlicher Grund wie bei Java) und es trotzdem viele Freiheiten bietet wie z.B. GC ja/nein, native compile, operator overloading, … :slight_smile:

IDE technisch hab ich bisher das Plugin für Xamarin Studio (früher MonoDevelop) und Eclipse getestet, beide sind … lala :smiley:

Sprachen wie D, Rust und was da noch kommen mag an Systemsprachen sollte man aber auch nicht unterschätzen. Die können auch eine Weile im Dornröschenschlaf verweilen und dann wie ein Zäpfchen abgehen. LLVM ist so ein guter Backend, dass ja selbst die Frontend für C++ usw teilweise bessere Ergebnisse liefern als mit G++ etc. Nicht umsonst ist Apple da komplett seit vielen Jahren auf LLVM umgestiegen.

Und ewig C++ mit neuen Flicken versehen macht der Kern auch nicht sicherer. Die Sicherheit hängt zu sehr vom Entwickler ab und der macht Fehler usw.

Ich bin ja sehr auf Java unter LLVM gespannt, wenn da der Frontend irgendwann mal fertig werden sollte. Java komplett mit LLVM kompiliert und dann noch mit unsafe Blocks(Erlaubnis zur Pointer-Arithmetik usw.) wie Rust könnte ich mir auch als C++ Killer vorstellen. Dann muss man Speicher-Fehler nur noch in unsafe-Blöcken suchen. C++ ist ja ein einziger unsafe-Block.

Kann das funktionieren? Das würde ja dann außerhalb einer JVM laufen.

GCJ: The GNU Compiler for Java - GNU Project - Free Software Foundation (FSF)

Hm, sehr esoterischer Ansatz. Eine VM verlinken aber die Hauptapplikation trotzdem in Maschinencode übersetzen. Der letzte News-Eintrag ist bald 6 Jahre her. Soll das bei dem LLVM-Frontend auch so funktionieren oder anders?

Ab Android 5 wird jede Java-App gleich beim Installieren native kompiliert, da ist dann auch keine JVM mehr wie im alten Dalvik dazwischen, die neue Runtime nennt sich ART. Der GC und Rangechecks etc ist natürlich alles in der Runtime drin, es gibt aber kein Bytecode mehr, sondern nur noch Maschinencode und die Java-Runtime. Das ist ja auch das schöne an Java, es gibt so viele Möglichkeiten es laufen zu lassen.

Mit enormen Einschränkungen, das Ding war schon eine Totgeburt (aus dem GCJ Link):

It has been merged with GNU Classpath and supports most of the 1.4 libraries plus some 1.5 additions.

Wüsste auch nicht wozu, schneller wird es dadurch nicht.

Ja, bei ART macht das natürlich Sinn. Da hat man es mit einer Embedded-Maschine zu tun. Dalvik litt auch sehr an Heap-Fragmentation was das System langsam machte und anfällig für OutOfMemory-Exceptions. Zudem ja beim Start schon der ganze Dalvik-Code, auch der von den verwendeten Libs, vorliegt. Der wird dann kompiliert und installiert. Da ist nichts mehr übrig von einer Java VM, du hast nur noch ELF-Files.

In Android konnte die VM nie ihre Stärken ausspielen und war defacto langsamer als nativer Code. Eh klar. Ein Java Cardlet ist auch langsamer als das ganze in Assembler. Umso kleiner das ganze umso mehr wirkt sich der VM-Overhead aus. Aber für große Maschinen erscheint mir das nicht sinnvoll.