Umstieg von Java zu Python

[deamon]

Ich schlage mich seit einiger Zeit mit Frameworks aus dem Java-Umfeld rum, aber so richtig freude kommt dabei nicht auf. Die Frameworks sind oft erschlagend und leiden manchmal unter "Over-Engineering". Ich beschäftige mich mehr mit Frameworks als mit der eigentlichen Arbeit.

Deshalb liebäugele ich damit, mich wieder mehr Python zuzuwenden, in das ich mich vor ein paar Jahren verliebt habe. Vor einiger Zeit hatte ich auch mal einen Anlauf mit Webframeworks in Python gemacht, aber glücklich bin ich damit auch nicht geworden. Folgende Eindrücke habe ich dabei gewonnen:

TurboGears: zu viele, drastische Änderungen -> keine gute Basis
Django: viel schwarze Magie im Hintergrund, schwaches ORM -> könnte man evtl mit leben
Pylons: sieht gut aus, aber da habe ich mich sehr über die Doku der darin verwendeten Bibliotheken (Paste) geärgert! Die ist für meinen Java-Geschmack doch ziemlich unvollständig. Was werden wo für Datentypen erwartet und welche zurückgegeben? Ich hasse so eine Doku! Das ist wohl _der_ Hinderungsgrund für mich.
CherryPy: angenehm schlank, aber auch da bin ich mit der Doku nicht glücklich.

Allgemein zu Python fallen mir im Vergleich zu meiner bisherigen Arbeit mit Java folgende Punkte ein:

pro
---
* Python ist geradliniger
* Entwicklungszeit ist kürzer
* Python macht tendenziell mehr Spaß
* Ausufernde XML-Konfiguration ist mir von Python-Frameworks nicht bekannt

contra
------
* unvollständige Doku, insbesondere fehlen Typinformationen
* Frameworks sind oft nicht so durchdacht wie bei Java. Sowas wie das Servlet-API gibt es z. B. bei Python nicht. WSGI ist lowlevel uns weniger umfangreich (z. B. keine Sessions).
* keine Interfaces, ok, machen bei Ducktyping auch nicht viel sinn, aber dann wäre optionale statische Typisierung gut
* Java ist bedeutend performanter
* In Python werden performance-kritische Teile gerne nach C ausgelagert, was ich absolut schrecklich finde! Erstens hätte ich selbst keine Lust, wieder mit C zu programmieren und zweitens reißt man sich die ganzen Probleme der C-Programmierung (Pufferüberläufe usw.) in sein Projekt.
* Externe C-Module erfordern möglicherweise weitere C-Bibliotheken. Software wird umständlicher zu installieren.
* Für Java sind mehr Bibliotheken verfügbar, aber ich denke, da wird es bei Python auch nicht knapp.
* Für Java gibt es mehr und bessere Entwicklungsumgebungen.

Programmiert von euch noch jemand in Java und welche Erfahrungen habt ihr im Vergleich Java<->Python gesammelt? Worüber seid ihr gestolpert, was findet ihr besser?

[lunar]

Du denkst imho noch zu sehr in Java. Du vermisst Typinformationen und statische Typisierung in Python und machst dir so sehr über die Performance sorgen, dass du sogar das Auslagern in Erwägung ziehst?

Python ist nun mal dynamisch, damit musst du zurecht kommen. Wenn du das nicht als Vorteil der Sprache erkennen kannst, wirst du gegen die Sprache programmieren und von Python nicht profitieren können, sondern eher darunter leiden.

Ähnliches gilt für die Typinformationen: Die Funktionsweise der meisten APIs ist – zumindest meiner Meinung nach – intuitiv verständlich, und falls nicht, existiert immer auch IPython zum Ausprobieren. Außerdem musst du wissen, dass Dokumentation auch in den Docstrings existiert, die im interaktiven Interpreter abgefragt werden können. Dadurch kann man Dinge interaktiv entwickeln, in dem man sich den Docstring anschaut und das Verhalten danach interaktiv ausprobiert.

Was die Performance angeht: Python ist ausreichend schnell für ein so großes Portal wie Ubuntuusers.de. Wenn du für eine Webanwendung in C auslagern musst, würde ich eher darauf tippen, dass dein Design fehlerhaft ist.

[Darii]

* In Python werden performance-kritische Teile gerne nach C ausgelagert, was ich absolut schrecklich finde! Erstens hätte ich selbst keine Lust, wieder mit C zu programmieren und zweitens reißt man sich die ganzen Probleme der C-Programmierung (Pufferüberläufe usw.) in sein Projekt.

Ich sehe da keinen Nachteil. Es gibt nunmal Sachen dafür sind Python und auch Java zu langsam. Da die Anbindung von C Programmteilen relativ unkompliziert ist, kann man auch wirklich nur das nötigste auslagern.

Ich hoffe ja sehr auf pypy, dass das Python ordentlich beschleunigen wird.

[sma]

Ich mache jetzt nach knapp 10 Jahren Java seit etwa einem Jahr Python. Ich kann mit Django eigentlich ganz gut leben. Ich halte das Projekt für das bislang bestdokumentierte Python-Webrahmenwerk und sehe dafür auch über den schwachen ORM hinweg.

Ich mag bei Python, dass es einerseits sehr einfach und leicht erlernbar ist und andererseits auch gehobenen Ansprüchen an Metaprogrammierung genügen kann und somit auch den erfahrenen Entwickler nicht im Stich lässt.

Typinformationen fehlen mir keine. Vielleicht liegt das bei mir daran, dass ich vor Java mit Smalltalk und davor während der Unizeit mit Lisp gearbeitet habe und mich daher schon immer eher dem Lager der dynamisch typisierten Programmiersprachen näher zugehörig gefühlt habe.

Was du bei Java durchdacht nennst, ist für mich in der Regel eher "overengineered". Ich brauche keine Factories die Factories für Factories erzeugen. Das Servlet-API ist schlank und auf den Punkt. Aber vieles andere ist eher das Ergebnis, keine Meinung zu haben, es allen Recht machen und sich nicht festlegen zu wollen.

Java ist natürlich in der Laufzeit performanter, aber gerade bei Web-Anwendungen spielt das keine große Rolle. Viel wichtiger finde ich die Performance bei der Software-Entwicklung und hier gewinnt Python - und das sogar, obwohl es im Vergleich zu Java keine tollen IDEs gibt.

Die Auslagerung von performance-kritischen Teilen in C finde ich ebenfalls schrecklich - vielleicht weil ich von C schon vor über 15 Jahren geheilt wurde und ich es da das letzte Mal ernsthaft genutzt habe. Davor war ich ein begeisterter C-Hacker, weil ich es einfach nicht besser wusste.

Daher würde ich mir wünschen, dass Jython schneller, besser und fertiger wird und stärker Verbreitung findet. Zwar ist das Projekt nach langem todesähnlichem Schlaf wieder erwacht, nachdem Sun den Hauptentwickler eingestellt hat, aber offenbar ist die Codebasis und/oder das Projekt doch so komplex, dass es nicht wirklich schnell voran geht.

Manchmal denke ich mir da ja, das könnte ich doch besser... Zu mehr als einem unvollständigen Python 1.5-Clon habe ich es aber bislang nicht gebracht ;)

Vielleicht ist IronPython hier interessanter. Doch leider läuft das nur wirklich gut auf einem von mir inzwischen verlassenen Betriebssystem, auch wenn ich gerade neidisch auf das, was mit Oslo passiert, schaue. Vielleicht ist IronPython auf Mono ja irgendwann auch unter OS/X praktikabel. Auch, weil ich eigentlich C# 4 und die DLR-Idee recht schick finde.

Ansonsten verschließe ich aber erstmal einfach die Augen vor C-Erweiterungen, die meist recht einfach unter OS/X automatisch kompiliert und installiert werden. Einzig das ansonsten immer empfohlene lxml will nicht und daher strafe ich diese XML-Bibliothek mit Ignoranz.

Zur Zeit bedauere ich, dass ich nächstes Jahr wieder zurück zur Java-Entwicklung muss und hoffe, vielleicht Jython irgendwie in das Projekt integrieren kann. Andererseits soll man ja auch jedes Jahr eine neue Sprache lernen und Clojure wäre mein Kandidat für 2009. Ob dann noch Zeit für Python bleibt... ;)

Bei IDEs bin ich letztlich bei TextMate gelandet - hauptsächlich weil ich mir dort am einfachsten einen Django-Mode selbst bauen und den Python-Mode nach meinen wünschen erweitern konnte. Davor habe ich vim benutzt. Der passt aber nicht mehr zum Mac.

Für Eclipse gibt es pydev und das DLTK, beides hat mich aber nicht wirklich überzeugt, ebenso wie Komodo-Edit (für Komodo-IDE war ich zu geizig, das soll aber besser sein). Für Netbeans 6.5 gibt es seit wenigen Tagen ein gar nicht so schlechtes Plugin für Python, allerdings wäre meine erste Wahl für IDEs immer noch (mit Hinblick auf Java) IDEA, dann Eclipse und dann erst Netbeans. Und für IDEA gibt es leider nix. Die sind offenbar gerade mit RubyMine beschäftigt und finden nicht die Zeit, die eigentlich für IDEA 8 angekündigten Python-Support fertig zu bauen. Für PyCharm sind immer noch drei Bugs in deren Issue-Tracker offen bis zur EAP-Version. RubyMine sieht nett aus, wenn so etwas inklusive Debugger und Django-Support auch für Python erscheint, würde ich das gerne für $99 kaufen. Ach ja, man könnte natürlich auch den Emacs benutzen, aber der hat IMHO noch mehr als VIM den Anschluss an die heutigen Editor-Konventionen verpasst und wirkt auf mich daher eher archaisch. Wieder muss ich neidisch auf Oslo, speziell IntelliPad schauen.

Viel Spaß mit Python. Versuch's einfach.

Stefan

[Leonidas]

* unvollständige Doku, insbesondere fehlen Typinformationen

Guess what, Python ist dynamisch typisiert und akzeptiert alle Typen, die ein bestimmtes Verhalten aufweisen.

* Frameworks sind oft nicht so durchdacht wie bei Java. Sowas wie das Servlet-API gibt es z. B. bei Python nicht. WSGI ist lowlevel uns weniger umfangreich (z. B. keine Sessions).

Bei Sessions gibt es auch keinen Königsweg. Sessions können etwa komplett über Cookies laufen, mit Session-IDs die auf dem Server auf Sessions gemappt werden und außerdem wie sollen die Sessions abgespeichert werden? RAM? Datenbank (welche?)? Flatfiles?
In Python nimmt man etwa die WSGI-Middleware Beaker und fertig, Sessions nachrüsten war letztens 15 Minuten Arbeit.

* keine Interfaces, ok, machen bei Ducktyping auch nicht viel sinn, aber dann wäre optionale statische Typisierung gut

Wozu? Java-Interfaces sind Traits unterlegen und Traits kann man sich mit NotImplementedError in Python selbst basteln, allerdings zur Laufzeit und ohne Typchecken.

* Java ist bedeutend performanter

Ja. Aber die Webapp würde mich interessieren wo die Geschwindigkeit von Python gegenüber von Java ein Problem wäre.

* In Python werden performance-kritische Teile gerne nach C ausgelagert, was ich absolut schrecklich finde! Erstens hätte ich selbst keine Lust, wieder mit C zu programmieren und zweitens reißt man sich die ganzen Probleme der C-Programmierung (Pufferüberläufe usw.) in sein Projekt.

Pyrex, Cython existieren.

* Externe C-Module erfordern möglicherweise weitere C-Bibliotheken. Software wird umständlicher zu installieren.

Das ist aber in Java auch nicht groß anders. Spätestens wenn du über JNI oder ähnlichem auf C-Libraries zugreifen willst hast du das gleiche Problem. Aber Bibliotheken zu installieren ist auf vernünftigen Systemen eine Sache von einem einzelnen Befehl. Java hat kein ein Paketmanagement, Python schon.

* Für Java sind mehr Bibliotheken verfügbar, aber ich denke, da wird es bei Python auch nicht knapp.

Ehrlich? Vor allem im FOSS-Umfeld wage ich da zu wiedersprechen. Im Cheeseshop gibt es 5000 Pakete, noch dazu einiges an älterem und nicht erfassten Code. Wenn ich eine Library finde und Bindings brauche ist es meiner Erfahrung nach wesentlich warscheinlicher welche für Python zu finden als für Java. Subjektiv würde ich was Bindings angeht Java sogar hinter Perl und Ruby ansiedeln, weil die Entwickler von freier Software generell von Java nicht begeistert sind und dass die JVM lange Zeit propietär war, hat das ihre getan.

* Für Java gibt es mehr und bessere Entwicklungsumgebungen.

Ja. Ich nutze in python aber keine IDE, so wichtig wie in Java sind sie in Python nicht.

Programmiert von euch noch jemand in Java und welche Erfahrungen habt ihr im Vergleich Java<->Python gesammelt? Worüber seid ihr gestolpert, was findet ihr besser?

Uh, ich habe schon seit längerem kein Java mehr gemacht, erst letztens wieder und muss sagen dass so wie Scala Spaß macht, so fluche ich über Java jedes mal. Sicher, es hat auch seine guten Seiten, aber freiwillig mache ich damit gar nichts. Es gibt so viele interessante Sprachen oder weniger interessante Sprachen bei denen man aber immerhin etwas lernen kann, Java ist aber IMHO keines von beiden.

Darii, ich glaube du schätzt PyPy falsch ein. PyPy ist eigentlich kein Python-Interpeter sondern eher ein Framework zum experimentieren mit den theoretischen Aspekten dynamischer Sprachen u.A. auch der Optimierung. In erster Linie also eher ein Forschungsprojekt.

[Darii]

Darii, ich glaube du schätzt PyPy falsch ein. PyPy ist eigentlich kein Python-Interpeter sondern eher ein Framework zum experimentieren mit den theoretischen Aspekten dynamischer Sprachen u.A. auch der Optimierung. In erster Linie also eher ein Forschungsprojekt.

Ja ich weiß. Pypy ist ein Intepreter-Generator-Framework. Aber man darf ja wohl noch hoffen, denn ich denke nicht, dass sich auf der CPython Seite viel tun wird.

[audax]

Ach ja, man könnte natürlich auch den Emacs benutzen, aber der hat IMHO noch mehr als VIM den Anschluss an die heutigen Editor-Konventionen verpasst und wirkt auf mich daher eher archaisch.

Was genau meinst du mit den heutigen Editor-Konventionen? Große bunte Knöpfe und wenig Komfort, dafür sehr geringe Einarbeitungszeit?

btw: http://weblog.jamisbuck.org/2008/10/10/ ... ome-to-vim

Ich will dich nicht konvertieren, aber dass vim und emacs nicht zeitgemäß sind ist eine schwere Anmaßung

[deamon]

Was du bei Java durchdacht nennst, ist für mich in der Regel eher "overengineered". Ich brauche keine Factories die Factories für Factories erzeugen.

Ich auch nicht! Es ist gerade dieses Over-Engineering, das mich stört. Während der Java-Entwickler noch an der Xten Abstraktionsstufe bastelt ist der Python-Entwickler schon dreimal fertig und ändert im Zweifelsfall einfach den Quellcode.

Die Auslagerung von performance-kritischen Teilen in C finde ich ebenfalls schrecklich [...]
Daher würde ich mir wünschen, dass Jython schneller, besser und fertiger wird und stärker Verbreitung findet.

Ich finde es aber eigentlich vom Prinzip schon unelegant, wenn man überhaupt eine zweite Sprache braucht. Das finde ich bei Java gerade schön, dass alles wirklich nur von der JVM abhängt. Ich habe mal versucht, irgendein Python-Framework zu installieren und das ist an der Abhängigkeit irgendeines externen C-Moduls gescheitert.

Viel Spaß mit Python. Versuch's einfach.

Ja, vielleicht sollte ich mich einfach mal auf die andere Welt einlassen.

[deamon]

* unvollständige Doku, insbesondere fehlen Typinformationen

Guess what, Python ist dynamisch typisiert und akzeptiert alle Typen, die ein bestimmtes Verhalten aufweisen.

Gut, einverstanden, aber dann möchte ich, dass das erwartete Verhalten irgendwo beschrieben wird und genau das ist oft nicht der Fall!

Bei Sessions gibt es auch keinen Königsweg. Sessions können etwa komplett über Cookies laufen, mit Session-IDs die auf dem Server auf Sessions gemappt werden und außerdem wie sollen die Sessions abgespeichert werden? RAM? Datenbank (welche?)? Flatfiles?

Genau das sollte aber für die Anwendung transparent und nur eine Einstellung im Server sein. Deshalb gehört meiner Meinung Sitzungsverwaltung als Schnittstelle in eine Spezifikation wie WSGI.

Wozu? Java-Interfaces sind Traits unterlegen und Traits kann man sich mit NotImplementedError in Python selbst basteln, allerdings zur Laufzeit und ohne Typchecken.

Kannst du das an einem Beispiel verdeutlichen? Würde man sich eine Klasse mit NotImplementedErrors in den Methoden schreiben in Klassen, die diese verwenden zur Laufzeit prüfen, ob sie von dem Typ der Trait-Klasse sind?

* Externe C-Module erfordern möglicherweise weitere C-Bibliotheken. Software wird umständlicher zu installieren.

Das ist aber in Java auch nicht groß anders. Spätestens wenn du über JNI oder ähnlichem auf C-Libraries zugreifen willst hast du das gleiche Problem.

Bloß, dass man diese Krücke in Java fast nie braucht.

* Für Java sind mehr Bibliotheken verfügbar, aber ich denke, da wird es bei Python auch nicht knapp.

Ehrlich? Vor allem im FOSS-Umfeld wage ich da zu wiedersprechen. Im Cheeseshop gibt es 5000 Pakete, noch dazu einiges an älterem und nicht erfassten Code.

Ich bin mir sicher, dass es im Java-Umfeld mehr Bibliotheken gibt. Viel mehr! Ich vermute sogar, dass es in keiner anderen Sprache so viel Bibliotheken gibt, aber egal, das führt uns letztlich nicht weiter. Ich denke, dass es bei Python jedenfalls auch genug Bibliotheken gibt.

Du hast mir interessante Wege aufgezeigt, die in der Python-Welt gegangen werden - Danke.

[audax]

Also wenn es jetzt um die Anzahl guter Bibliotehken geht...dann pack ich hie aber gleich mal Perl aus

[Leonidas]

Ich finde es aber eigentlich vom Prinzip schon unelegant, wenn man überhaupt eine zweite Sprache braucht. Das finde ich bei Java gerade schön, dass alles wirklich nur von der JVM abhängt.

Wie greifst du dann auf Libraries zu, die es nur in C gibt? Xlib, GTK+, gstreamer etc.? Vor allem systemnähere Sachen.

* unvollständige Doku, insbesondere fehlen Typinformationen

Guess what, Python ist dynamisch typisiert und akzeptiert alle Typen, die ein bestimmtes Verhalten aufweisen.

Gut, einverstanden, aber dann möchte ich, dass das erwartete Verhalten irgendwo beschrieben wird und genau das ist oft nicht der Fall!

Das kann man aber eher den Entwicklern als der Sprache vorhalten. Natürlich, nicht jede Dokumentation ist umfangreich oder vorhanden, aber gegen Entwickler die nichts dokumentieren ist kein Kraut gewachsen.

Wozu? Java-Interfaces sind Traits unterlegen und Traits kann man sich mit NotImplementedError in Python selbst basteln, allerdings zur Laufzeit und ohne Typchecken.

Kannst du das an einem Beispiel verdeutlichen? Würde man sich eine Klasse mit NotImplementedErrors in den Methoden schreiben in Klassen, die diese verwenden zur Laufzeit prüfen, ob sie von dem Typ der Trait-Klasse sind?

Typen prüfen widerspricht dem Prinzip von Duck Typing. Man prüft also nicht ob eine eine Klasse vom Typ der Trait-Klasse ist, sondern man schaut ob sie das API implementiert.

Code: Alles auswählen

class TraitLookalike(object):
    def __init__(self, name):
        self.name = name

    def whoami(self):
        print 'My name is %s.' % self.name

    def say(self):
        raise NotImplementedError('You need to implement say()')

class Dog(TraitLookalike):
    def say(self):
        print 'Woof, woof!'

d = Dog('Waldi')
d.whoami()
d.say()
t = TraitLookalike('Hasso')
t.whoami()
t.say()

* Externe C-Module erfordern möglicherweise weitere C-Bibliotheken. Software wird umständlicher zu installieren.

Das ist aber in Java auch nicht groß anders. Spätestens wenn du über JNI oder ähnlichem auf C-Libraries zugreifen willst hast du das gleiche Problem.

Bloß, dass man diese Krücke in Java fast nie braucht.

Weil? Jetzt angenommen ich will GooCanvas nutzen um ein (dank Cairo sogar hardwarebeschleunigtes) Canvas in meiner Applikation zu haben. Aus C heraus habe ich kein Problem, GooCanvas ist in C geschrieben, kein Thema. Aus C++ habe ich auch kein Problem, es gibt einen Wrapper. Aus Python gibt es PyGooCanvas, direkt von GNOME (und auch wenn nicht, ctypes und gobject-introspection/pybank bieten da Mittel und Wege darauf zuzugreifen). Wie sieht es mit Java aus?

[lunar]

Genau das sollte aber für die Anwendung transparent und nur eine Einstellung im Server sein. Deshalb gehört meiner Meinung Sitzungsverwaltung als Schnittstelle in eine Spezifikation wie WSGI.

WSGI ist dafür nun mal nicht gedacht, ebenso wenig wie CGI oder ähnliche Konventionen. WSGI kümmert sich nur um die Anbindung einer Python-Anwendung an den Webserver. Alles andere fällt in die Anwendung.

Im Übrigen sind Session nicht Bestandteil des Webservers, auch bei Java nicht. Sie sind Bestandteil des Applicationsservers und eben den gibt es bei WSGI nicht.

Sessions sind Bestandteil des entsprechenden Frameworks. Man kann eine Pylons-Anwendung mit die Features des Frameworks schreiben, und dann einfach installieren und starten. Das ist sicherlich anders als die Servlet-API, aber es führt nicht zu höherer Komplexität, und das zählt imho.

* Externe C-Module erfordern möglicherweise weitere C-Bibliotheken. Software wird umständlicher zu installieren.

Das ist aber in Java auch nicht groß anders. Spätestens wenn du über JNI oder ähnlichem auf C-Libraries zugreifen willst hast du das gleiche Problem.

Bloß, dass man diese Krücke in Java fast nie braucht.

Als Anwendungsentwickler braucht man das unter Java sicherlich nicht. Nun, das gilt aber auch für Python, da muss man als Anwendungsentwickler auch keine C-Module schreiben (höchstens noch mit Cython).

Als Bibliotheksentwickler dagegen ist das essentiell, sowohl unter Python als auch unter Java. Was glaubst du denn, wie QtJambi oder SWT implementiert wurden? Oder die xapian-Bindings?

Die pauschale Aussage, dass man eine native Anbindung unter Java nicht bräuchte, ist schlicht falsch. Genauso wie die Aussage, dass man die Python-C-API als Anwendungsentwickler bräuchte.

[deamon]

Wie greifst du dann auf Libraries zu, die es nur in C gibt? Xlib, GTK+, gstreamer etc.? Vor allem systemnähere Sachen. Meistens braucht man das nicht, weil es entsprechende Java-Bibliotheken gibt. Ich hatte jedenfalls noch nie das Bedürfnis JNI zu verwenden.

[ In Python werden Schnittstellen eher mit Worten beschrieben, als technisch festgelegt.]

Das kann man aber eher den Entwicklern als der Sprache vorhalten. Natürlich, nicht jede Dokumentation ist umfangreich oder vorhanden, aber gegen Entwickler die nichts dokumentieren ist kein Kraut gewachsen.

Bloß nach meinem Eindruck ist die unvollständige Dokumentation von Schnittstellen bei Python eher die Regel als die Ausnahme. Da ist es schon besser, wenn die Schnittstelle Teil des Programmcodes ist und somit explizit beschrieben werden muss.

Typen prüfen widerspricht dem Prinzip von Duck Typing. Man prüft also nicht ob eine eine Klasse vom Typ der Trait-Klasse ist, sondern man schaut ob sie das API implementiert.

Aus meiner Sicht zögert das eigentlich nur das finden von Fehlern durch falsche Typen hinaus. Es kracht dann vielleicht irgendwann in einem seltenen Fall zur Laufzeit, weil irgendwo ein Objekt verwendet wird, was eine Methode eben nicht implementiert hat. Bei einer statischen Typisierung oder regelmäßigen Typprüfung zur Laufzeit, hätte man das Problem nicht bzw. vermindert.

Ich glaube, Python-Programmierer denken einfach anders. Vielleicht muss man einfach beide Welten mal länger testen und sich so selbst ein Bild machen.

[sma]

Wie greifst du dann auf Libraries zu, die es nur in C gibt? Xlib, GTK+, gstreamer etc.? Vor allem systemnähere Sachen.

Der Java-Entwickler sieht die JVM als Betriebsssystem an. Systemnahe Sache sind nicht Teil seiner Welt. Für Xlib oder GTK (oder GooCanvas) gibt es Java-eigene Lösungen wie Java2D (auch Hardware-beschleunigt) oder Swing. Gstreamer hat was mit Audio zu tun? Da hat's auch irgendwelche Libs, selbst wenn die nicht so gut sind. Was du aufzählst, ist alles betriebssystemspezfisch. Bei Java ist nach wie vor ein Wert darin, dass die JVM betriebssystemübergreifend (außer beim Mac, wo Apple zu langsam ist. Grummel).

Typen prüfen widerspricht dem Prinzip von Duck Typing.

Bisschen zu pauschal. Man möchte u.U. schon wissen, ob etwas "Enumerable" ist und nicht jede Methode einzelnd prüfen müssen. Ich würde eher sagen, man denkt eher in Struktur-Typen.

Und daemon, gibt dich erst gar nicht der falschen Illusion von besseren Programmen dank statischer Typisierung hin. Nicht bei Java. Lass mich erst gar nicht anfangen, über NullPointerException, ArrayStorageException und ähnliches zu lästern. Wenn's kompiliert heißt nicht dass es läuft. Es ist ungefähr der gleiche Test, als wenn mein Texteditor erfolgreich eine Datei abgespeichert hat. Das ist eine sehr falsche Sicherheit.

Lunar, weder Webserver noch Applicationserver kümmern sich bei Java um die Session, sondern der Servlet-Container. Aber das meintest du wahrscheinlich. (JavaEE-)Applicationserver ist halt nur viel mehr als ein Servlet-Container.

Stefan

[Leonidas]

Der Java-Entwickler sieht die JVM als Betriebsssystem an. Systemnahe Sache sind nicht Teil seiner Welt. Für Xlib oder GTK (oder GooCanvas) gibt es Java-eigene Lösungen wie Java2D (auch Hardware-beschleunigt) oder Swing.

Also zumindest das was Swing im OpenJDK bei mir auf dem System veranstaltet ist übel. Entweder sind dieSchriften total verwaschen oder der Cursor wird in Eingabefeldern bei fetten Buchstaben zu wenig nach rechts verschoben. Oder die Eingabefelder werden erst wenn ich den Fokus rausnehme aktualisiert. Da ist ja schon Tkinter von der Nutzbarkeit besser. Vielleicht wird das in kommenden Versionen vom OpenJDK ausgebessert, aber momentan ist es furchtbar.

Und Java-Audio ist auch negativ aufgefallen. Das JMF hat in der aktuellen Version keine Unterstützung für MP3 mehr und das nachzuinstallieren ist mit trotz mehreren Stunden probieren nicht gelungen.

Lunar hat es so ausgesprochen wie ich das auch meinte: man muss unter Python ebensowenig C-Module schreiben wie man mit Java normalerweise JNI etc. braucht. Man nimmt einfach das, was vorhanden ist. Ich hatte nie das Problem, ein Python-Modul in C schreiben zu müssen. Und wenn dann würde ich erst abwägen: zu langsamen Code auslagern: Cython. C-Bindings erstellen: ctypes. Mit C selbst muss ich mich da nicht befassen.

Typen prüfen widerspricht dem Prinzip von Duck Typing.

Bisschen zu pauschal. Man möchte u.U. schon wissen, ob etwas "Enumerable" ist und nicht jede Methode einzelnd prüfen müssen. Ich würde eher sagen, man denkt eher in Struktur-Typen.[/quote]
Jein. Einer Methode ist ja egal ob das was sie bekommt Enumerable ist, solange sie sich wie ein Iterator verhält und eine for-Schleife durchläuft ist sie zufrieden. Oder eben Indexzugriffe erlaubt oder was auch immer, hängt eben ab was man will. Wenn du das als Struktur-Typen bezeichnest, dann sind wir einer Meinung

[deamon]

Ich möchte diese interessante Diskussion noch mal um zwei Punkte erweitern, nämlich Depency Injection (DI) und aspekt-orientierte Programmierung (AOP).

Mir scheint es so, als wäre in der Python-Welt der Bedarf nach einem Framework für DI nicht so vorhanden, obwohl es dort auch welche gibt. Warum ist das so?

Ähnlich ist es mit AOP. Ich habe sogar mal die Aussage gelesen, dass AOP eine Erfingung aus dem Reich der statisch typisierten Sprachen wäre und man sowas bei Python mit seinen Möglichkeiten zur Metaprogrammierung gar nicht bräuchte. Wie seht ihr das? Ich halte AOP auch bei Python für sehr interessant!

[DasIch]

Zum Thema Typprüfung sind eventuell Abstract Base Classes interessant.

[keppla]

Ich möchte diese interessante Diskussion noch mal um zwei Punkte erweitern, nämlich Depency Injection (DI) und aspekt-orientierte Programmierung (AOP).

Zu DI kann ich gerade nichts sagen, weil ich es glaube ich gerade mit ein paar anderen Konzepten verwechsele.

Zur AOP mal als Beispiel logging:

Code: Alles auswählen

def log(func):
  def wrapper(*args, **kwargs):
    print 'called %s' % func
    return func(*args, **kwargs)
  return wrapper

@log
def greet(name):
   print "hello, %s" % name

Weil man jede Funktion und jede Methode "wrappen" kann, werden viele der Aufgaben, um die sich in anderen Sprachen AOP-Frameworks kümmern würden, überflüssig.[/code]

[BlackJack]

@Leonidas: Javaianer greifen nicht auf Bibliotheken zu, die es nur in C gibt. Sie sind viel schlauer: Sie programmieren das lieber alles noch einmal in Java nach.

@daemon: Diese Angst, dass unter seltenen Umständen etwas kracht weil ein falscher Typ übergeben wurde, wird IMHO überbewertet. Für ein grösseres, robustes Projekt muss man sowieso Unit-Tests schreiben, die möglichst den gesamten Code abdecken, da fallen solche Missgeschicke in der Regel auf, und die Unit-Tests lassen einen auch über Fehler stolpern, die eine statische Typprüfung auch nicht gefunden hätte.

Was meinst Du mit "regelmässiger Prüfung zur Laufzeit"? Zur Laufzeit wird regelmässig zumindest der "duck type" geprüft. Ist ja nicht so, dass Python untypisiert wäre.

Habe mal kurz nachgelesen was DI ist. So im kleinen kann man das Java-Beispiel auf Wikipedia ja problemlos in Python umsetzen. Nach dem Beispiel habe ich mich gefragt wozu man dafür wohl ein Rahmenwerk braucht und habe entsprechend nach Python-Rahmenwerken gesucht. Die zwei die ich gefunden habe, hatten in der Beschreibung was von XML-Konfigurationsdateien stehen. Da habe ich nicht weiter gelesen und entschieden, dass ich das in Python nicht brauche.

@sma: Gtk, GooCanvas, und Gstreamer würde ich nicht als betriebssystemspezifisch bezeichnen.

[lunar]

@Leonidas: Javaianer greifen nicht auf Bibliotheken zu, die es nur in C gibt. Sie sind viel schlauer: Sie programmieren das lieber alles noch einmal in Java nach.

Klar, ist doch logisch ... die existierenden Bibliotheken wurden ja alle in so veralteten Sprachen wie C geschrieben. Das will doch kein Mensch nutzen

Habe mal kurz nachgelesen was DI ist. So im kleinen kann man das Java-Beispiel auf Wikipedia ja problemlos in Python umsetzen.

Also ich finde an diesem Beispiel zwei Dinge toll: Zum einen ist das für eine so simple Sache erstaunlich viel Code, zum anderen finde ich den Sarkasmus in diesem Beispiel lustig: "EnterpriseFactoryObserverFactoryCreator" ist ein passender Name für Java und seine Entwurfsmusteritis