Java vs. Python

[BlackJack]

@Dragonfire: Funktionen sind in Python, wie *alles* was man an einen Namen binden kann, Objekte. Es ist also trivial eine Funktion dynamisch aufzurufen. Wenn man gerne eine andere aufrufen möchte, dann übergibt man halt eine andere.

[lunar]

@DasIch: Haskell kennt "undefined" und "error" als typtheoretisches Äquivalent zu "null". Beides sind Werte eines Unit-Typen, der wiederum Untertyp aller möglichen Typen ist, und repräsentieren einen undefinierten Wert, beziehungsweise im Falle von Java eine undefinierte Referenz, dessen Auswertung zur Terminierung des Programms führt. Zudem kennt auch Haskell Ausnahmen, die nicht im Typsystem repräsentiert werden (e.g. "1 `div` 0"), und die folglich ebenfalls zur Terminierung des Programms führen.

Natürlich legen sowohl Haskell als auch Java nahe, bei undefinierten Werten konkrete, vom Typsystem forcierte Ausnahmen auszulösen, als checked exceptions bei Java, und Maybe-Werte bei Haskell. Haskell unterscheidet sich von Java lediglich dadurch, dass Maybe verhältnismäßig angenehm benutzt werden kann, da es monadisch ist und daher syntaktische Unterstützung der Sprache erfährt. Gäbe es diese Monaden nicht, wäre Maybe ebenso lästig wie checked exceptions in Java.

Dennoch können weder Haskell noch Java auf undefinierte Werte verzichten, sei es in Form von undefinierten Werten oder außerhalb des Typsystems befindlichen Ausnahmen. Keine turing-vollständige Sprache kann das, da die Menge der berechenbaren Funktionen alle partiellen, nicht-totalen Funktionen einschließt. Mithin sind undefinierte Werte, die das Ergebnis einer Funktionsanwendung auf Argumente außerhalb deren Definitionsbereich repräsentieren, unvermeidbar. Aus der Unentscheidbarkeit des Halteproblems für Turing-Maschinenen folgt zudem, dass man nicht statisch entscheiden kann, ob eine Funktion nicht-total ist.

Mithin kann kein Typsystem die "NullPointerException" überflüssig machen, sondern dem Kind lediglich andere Namen geben. Zwangsläufig muss es in jeder Sprache Ausnahmen geben, die zwar zur Laufzeit ausgelöst werden, aber im Typsystem nicht repräsentiert sind. Typsysteme, die mehr versprechen, sind nicht entscheidbar, und mithin nicht wirklich praktikabel.

Wichtig ist vor diesem Hintergrund vor allem, dass eine Sprache ihre eigenen Abstraktionen schützt, und der Auswertung undefinierter Werte nicht undefiniertes Verhalten folgen lässt (so wie C), sondern das Programm vielmehr ordentlich terminiert. Das aber garantiert auch Java.

Ähnliches gibt auch für Typsysteme, die versuchen, die Integrität von Datenstrukturen sicherzustellen. Derartige Ansätze führen fast immer zu unentscheidbaren Typsystemen-

[BlackJack]

Ich denke ein Problem bei ``null`` in Java ist, dass jede Variable, ausgenommen die von primitiven Typen, diesen Wert annehmen kann, und einem die `NullpointerException`\s deshalb oft an einer sehr unerwarteten Stelle um die Ohren fliegen, da man nicht damit gerechnet hat wo so ein ``null``-Wert innerhalb des Programms überall hin propagiert werden könnte. Einige JVM-Sprachen verbieten deshalb ``null``-Werte solange man das bei der Variablendeklaration nicht explizit erlaubt hat. Ich glaube ich habe das bei Nice das erste mal gesehen. Da muss man bei der Deklaration ein Fragezeichen an den Typ hängen wenn man auch ``null``-Werte erlauben will. Sonst meckert schon der Compiler wenn er erkennt, dass irgend etwas ``null`` werden kann, das man nicht dafür gekennzeichnet hat. So behält man als Programmierer einen besseren Überblick welche Werte man vor der Verwendung prüfen muss, damit das Programm zur Laufzeit nicht über ein ``null`` stolpern kann.

Man denkt dann auch mehr über die Verwendung von ``null`` nach und ist vielleicht eher geneigt einen „Null”-Wert des entsprechenden Typs einzuführen, wenn das möglich ist, und damit einen Spezialfall weniger zu haben.

[mkesper]

Um mal einen Vorteil von Java zu nennen: Ich kann Java-Code kompilieren und z.B. eine JVM auf einem Lego Brick laufen lassen, die dann Java-Programme ausführt. Neid!

[Hyperion]

@mkesper: Sollte das nicht mit allen auf der JVM basierten Sprachen klappen? Damit ginge es auch in Jython. Zudem gibt es da auch etwas für CPython.

[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