Java vs. Python

[BlackJack]

@Hyperion: Normalerweise hat man auf solchen Embedded-Geräten eine abgespeckte JVM, nicht die normale Java-Standardbibliothek, und wenig Speicher. Da läuft also nicht einfach alles drauf was auf dem Desktop funktioniert.

[Leonidas]

@mkesper: Sollte das nicht mit allen auf der JVM basierten Sprachen klappen?

Nein. Lejos ist eine so dermaßen löchrige Implementierung von Java SE, dass man sich wundert wie es überhaupt funktionieren kann. Oder um gc.c zu zitieren:

Code: Alles auswählen

void mark_and_sweep()
{

$TBD

}

Ich glaube nicht, dass Jython ohne GC sonderlich weit kommt.

[sma]

Viele Nachteile über die mangelnde Flexibilität von Java, die hier aufgeführt werden (und die ich durchaus teile), haben sich zu einem Vorteil in der Nische herausgestellt, die Java letztlich sehr erfolgreich besetzt hat. Ich finde, dass muss man anerkennen.

Im Geschäftsumfeld ist es ein Standard, der es ermöglicht, große Projekte mit großen Teams umzusetzen, bei denen nicht jeder Entwickler ein Rockstar ist. Beschränkungen und fehlende Ausdruckskraft helfen, den Code gleicher und für alle Verständlich zu machen. Hohe Investitionen in Werkzeuge und Laufzeitumgebung haben dazu geführt, die die Java Virtuelle Maschine das beste ist, was wir so haben. Moderne IDEs machen zudem die Programmierung (IMHO) recht angenehm und bieten eine großartige Unterstützung, was Stil und Konventionen angeht, die sich in den letzten 15 Jahren als sinnvoll herausgestellt haben. Insbesondere ist das inzwischen alles automatisch überprüfbar, das in großen Teams wieder hilft.

Ich möchte ehrlich gesagt, kein 50.000 Zeilen Python-Programm (ohne Tests) aufräumen müssen, hatte jedoch kein Problem damit, ein Java-Projekt der zehnfachen Größe mit einem Team anzugehen und sehr systematisch Umstrukturierungen durchzuführen und Tests ergänzen und Coding-Standards und andere Richtlinien durchzusetzen.

Als Einzelentwickler mag ich die Freiheit und Ausdruckskraft einer mächtigen Programmiersprache. Doch im Team schätze ich die Einheitlichkeit und (relative) Einfachheit von Java kombiniert mit Werkzeugen, die auch einem Anfänger sagen, wie seine Variablennamen, JavaDoc-Kommentare und die Einrückungstiefe und Methodenlänge auszusehen hat.

Solche Werkzeuge könnte man zum Teil auch für Python entwickeln (und Jetbrains hat es mit dem Wissen von Java getan), doch es fehlen statische Typen, mit denen ich automatisch überprüfbar Schnittstellen beschreiben kann und zumindest sicherstellen kann, dass die Programm-Module syntaktisch zusammenpassen.

Ich denke, Dart ist hier ein guter Kompromiss, da Dart allerdings JavaScript-Entwicklern gefallen will und auf die selben Enterprise-Programmierer wie Java, denen ein eleganter Wintergarten im Eigenheim möglicherweise wichtiger ist, als eine elegante Syntax mit Einrückung statt mit { }, wirkt diese Sprache "auf uns" langweilig und uninspiriert. Absichtlich, denn sie wollen den Erfolg von Java wiederholen. Ob das klappt, wird die Zukunft zeigen.

Da ich den Erfolg von Java in seiner Einfachheit (nicht im Sinne von leicht erlernbar sondern von wenigen "esoterischen" Features) sehe, bin ich auch skeptisch, dass Scala die Zukunft von Java ist. Ich würde daher auch nicht die Empfehlung, statt Java lieber Scala zu lernen, teilen. Wer ganz Hipp sein will, schaut vielleicht mal auf Kotlin (von Jetbrains) oder das sehr pragmatische Xtend (von itemis). Und natürlich gibt es Groovy, aber das ist so ein pragmatischer Bauchladen wie Perl und gefällt zumindest mir nicht sonderlich.

Übrigens, ein Typsystem zu entwerfen, welches nicht "nil", "null", "undefined" oder einen anderen "diese variable ist leer" als Element eines Typs erlaubt, ist extrem aufwendig, wenn man in der Sprache gleichzeitig noch Objekte haben will, deren Variablen man nacheinander initialisieren kann und dann auch noch Vererbung mit ins Boot wirft. Ich habe keine Quellen parat, aber vor 10 Jahren oder so gab es dazu eine ganze Reihe von wissenschaftlichen Artikeln, weil diverse Leute versucht haben, dieses Problem zu lösen. Leider werden diese Lösungen alle so kompliziert, das man letztlich immer ganz pragmatisch "null" erlaubt. Insbesondere, wenn man mit existierenden Bibliotheken interagieren will.

Ansonsten ist das auch aus meiner Erfahrung nach das größte Problem von Java. Tatsächlich lies sich schon bei Smalltalk beobachten, dass die Vermutungen der Befürworter statischer Typen, dass man doch laufend auf Fehler stoßen müsste, weil Variablen und Parameter keine Typen tragen, einfach falsch war. Das einzige nervige Problem war, dass man "nil" laufend Nachrichten schickte, die es nicht verstand, weil eben das erwartete Objekt fehlte. Das man einer Person eine Nachricht für eine Adresse schickte, kam praktisch nicht vor. Somit lösen viele statische Typsysteme ein Problem, das nicht existiert.

Was existiert, ist aber der Vorteil, das statische Typen Dokumentation sind und das sie von einer IDE benutzt werden können, um die mögliche Methoden aufzurufen, was wiederum hilft, mit viel Raten (der berühmte Educated Guess nach dem Prinzip der kleinsten Verwunderung) und wenig Wissen auch in umfangreichen Klassenbibliotheken navigieren zu können.

Übrigens, was ich ziemlich interessant fand, war das folgende Video vom Pycon, welches sich weniger um Java, die Programmiersprache, sondern Java, die Plattform dreht: http://pyvideo.org/video/685/what-pytho ... -from-java

Stefan