Das deutsche Python-Forum

Hallo,

ich habe mich jetzt schon mal in Python eingearbeitet (meine erste richtige (Programmier)Sprache nach JavaScript, xHTML und CSS - welche ich perfekt kann) und bin nun auf der Suche nach einer guten "Ergänzungssprache", mit der man evtl. Python ergänzen kann und evtl. auch in irgendeiner Weise zusammenarbeiten.

Was könnt ihr mir hier empfehlen?

Danke!

So direkt als "Partnersprache" zu Python würde ich C sagen. Dann kann man bei leistungskritischen Sachen entweder Erweiterungsmodule für Python in C schreiben, oder Bibliotheken schreiben und die mit `ctypes` anbinden. Selbst wenn man die Bibliotheken nicht selber schreiben möchte oder braucht, sind C-Kenntnisse bei der Verwendung von `ctypes` nützlich bis wichtig.

Danke, dann werde ich wohl C als nächstes anpacken...

Ich möchte noch D erwähnen. Kann auch mit Python zusammenarbeiten.

Wie wäre es mit Jython + Java? Durch die Wiederbelebung des Jython-Projekts kann dies eine echte Alternative zu CPython werden, wenn man (beruflich) in einem Java-Umfeld unterwegs ist.

Stefan

Allerdings ist Java nicht unbedingt spaßig, wenn man von Python kommt. Ganz ehrlich: Ich würde Java meiden, wenn man nicht unbedingt muss ... Wenn eine derartige Kombi gewünscht ist, würde ich mir eher IronPython ansehen, und C# lernen. C# 3.0 ist nämlich das bessere Java, und kennt zumindest einige, dem Pyhton-Programmierer vertraute Dinge wie Listen-Literale oder Lamda-Ausdrücke. Außerdem existieren für die CLR eine Menge sehr interessanter Sprachen, die von Python inspiriert sind. Boo und Cobra beispielsweise ...

Java spielt aber die wesentlich größere Rolle in der "Industrie" - scheint mir jedenfalls so. Und während es richtig ist, dass C# 3.0 interessante Syntaxkonstrukte hat, ist es doch die wesentlich komplizierte Sprache im Vergleich zu Java (Scala schlägt wiederum C# 3, was die Interessantheit angeht). Das ist zwar auch nicht mehr so einfach wie vor 10 Jahren, aber doch einfacher als C# (oder VB.NET). Und ich würde auch behaupten, die Werkzeuge für Java - die man leider zwingend braucht, um nicht an Frustration umzukommen - sind besser. Mein kurzer Ausflug zu VS2008 hat mich jedenfalls schnell wieder zu Eclipse JDT, Intellij IDEA und Co zurückkehren lassen (Fehlende IDE-Unterstützung lässt mich auch noch vor Scala zurückschrecken). Bei VS musste ich explizit kompilieren - wie archaisch ist das denn? Und die Refactoring-Möglichkeiten von VS2008 sind nichts im Vergleich zu Intellij. Vielleicht hat mich aber auch die Gewohnheit beeinflusst.

Die Menge der (experimentellen) Scriptsprachen für Java ist glaube ich auch größer als die für C#. Etwas wie Boo, das auf den ersten Blick wie ein statisch getyptes Subset von C# mit Python-Syntax wirkt, könnte man für Java auch bauen. Gerade gestern habe ich über so etwas nachgedacht, als ich bei einem Ausflug in die Java-Welt laufend die runden Klammern für if und while vergessen hatte und immer noch einen ":" hinzufügen wollte. Wer sich jedoch in die Welt der statischen Typsysteme begibt, kommt darin um... man schaue sich nur mal Scala als Beispiel an für ein java, das gerne ein Haskell sein möchte, wie ein "echtes" Typsystem aussieht. Vielleicht hat C# da aber mehr Pragmatismus bewiesen. Javas aktuelles Typsystem wirkt irgendwie unfertig. Ich hasse es, dass man manchmal die Warnungen einfach nicht los wird.

Interessant bei Java ist die Unmenge an freien Bibliotheken - speziell für die Serverprogrammierung - und die Plattformunabhängigkeit. Bei C# muss man auf Mono zurückgreifen, wenn man nicht Windows hat. Das empfinde ich als großen Nachteil. Bei Java hat man Linux, Solaris und Windows-Support aus einer Hand und wenn Apple weniger halbherzig Java unterstützen würde, auch hier die selbe Java-Version (leider haben sich sie entschlossen, Java 6 nur für 64-bit-Intel-Systeme freizugeben und das schließt meinen Mac-Mini aus wofür ich sie verachte; ich hoffe aber auf eine OpenJDK-Version). Ach ja, Java ist komplett opensource (siehe IceTea von Redhat).

Schießlich halte ich die Hotspot-VM-Technologie für führend und somit Java-Anwendungen - speziell im Vergleich zu Mono - für die schnellere Alternative - falls das eine Rolle spielen sollte.

Wenn es entscheidend sein sollte, dass Boo oder Cobra ein "def" benutzen, um Funktionieren zu defineren, dann kann man auch JRuby oder eben Scala erwähnen, die machen das auch. Wenn es darum geht, dass man per Einrückung Blöcke bilden kann, dann stimmt der Vergleich schon eher. Aber wie gesagt, es gibt keinen technischen Grund, warum es etwas wie Boo nicht auch für die JVM geben könnte - wenn denn das Interesse da wäre.

Stefan

sma hat geschrieben:Java spielt aber die wesentlich größere Rolle in der "Industrie" - scheint mir jedenfalls so.

Mit sowas wäre ich immer sehr vorsichtig ... wie groß die Bedeutung einer Sprache in der "Industrie" ist, erschließt sich einer Einzelperson kaum.

Und während es richtig ist, dass C# 3.0 interessante Syntaxkonstrukte hat, ist es doch die wesentlich komplizierte Sprache im Vergleich zu Java (Scala schlägt wiederum C# 3, was die Interessantheit angeht).

Ich bitte dich, welche Sprache ist schon einfach? Und ob C# nun komplizierter ist als Java, wage ich zu bezweifeln. Versuch mal einem Anfänger anonyme lokale Klassen als Ersatz für Methodenreferenzen nahezulegen

Die Menge der (experimentellen) Scriptsprachen für Java ist glaube ich auch größer als die für C#.

Was außer Jython, JRuby und Scala gibt es denn da noch? Wobei ich die ersten beiden kaum als "experimentell" bezeichnen würde, sind es doch nur Portierungen anderer Sprachen.

Etwas wie Boo, das auf den ersten Blick wie ein statisch getyptes Subset von C# mit Python-Syntax wirkt, könnte man für Java auch bauen.

Fakt ist aber, dass es Boo und Cobra nicht für die JVM gibt. Aus der Wahl der CLR als Basis würde ich außerdem darauf schließen, dass die CLR gut dokumentiert und einigermaßen einfach zu nutzen ist verglichen mit der JVM.

Vielleicht hat C# da aber mehr Pragmatismus bewiesen. Javas aktuelles Typsystem wirkt irgendwie unfertig. Ich hasse es, dass man manchmal die Warnungen einfach nicht los wird.

Ich sagte ja, C# ist das bessere Java

Interessant bei Java ist die Unmenge an freien Bibliotheken - speziell für die Serverprogrammierung - und die Plattformunabhängigkeit.

Das stimmt wohl. Bei der Menge an Bibliotheken kann C# aktuell wohl noch nicht mithalten. Allerdings sind viele dieser Bibliotheken auch klar auf Webprogrammierung im J2EE Umfeld ausgerichtet, und J2EE würde niemals jemandem empfehlen. Ein wunderbares Beispiel für den Hang zu überkomplizierten Bibliotheken, den Java irgendwie nicht loswird.

Bei C# muss man auf Mono zurückgreifen, wenn man nicht Windows hat. Das empfinde ich als großen Nachteil.

Das kommt darauf, was man programmieren möchte.

Schießlich halte ich die Hotspot-VM-Technologie für führend und somit Java-Anwendungen - speziell im Vergleich zu Mono - für die schnellere Alternative - falls das eine Rolle spielen sollte.

Ob die Hotspot-VM dem Jit-Compiler des .NET-Frameworks wirklich noch so überlegen ist, wage ich zu bezweifeln. Mono muss da sicherlich noch aufholen ...
Allerdings wird Performance den OP wohl kaum brennend interessieren, schneller als Python ist Mono allemal.

Aber wie gesagt, es gibt keinen technischen Grund, warum es etwas wie Boo nicht auch für die JVM geben könnte - wenn denn das Interesse da wäre.

Es gibt boo aber nicht für die JVM. Sprachen für die CLR zu schreiben scheint offenbar einfacher zu sein, als solche für die JVM zu implementieren. IronPython ist Jython voraus, und es gibt sogar IronScheme.

@lunar: Ich denke Du fällst da ein bisschen auf Microsoft's Marketing für .NET/CLR herein. Auch für die JVM gibt's einen Haufen Sprachen. Eine Liste gibt's beispielsweise hier: http://www.is-research.de/info/vmlanguages/

Von Scheme und Lisp gibt's auch mehrere Implementierungen: http://www.is-research.de/info/vmlangua ... andco.html

lunar hat geschrieben:Allerdings wird Performance den OP wohl kaum brennend interessieren

Hallo lunar!

Außer Geschwindigkeit, gibt es doch kaum einen Grund, eine andere Programmiersprache als Python einzusetzen.

Ich denke mal, dass einem als Python-Programmierer ein wenig C nicht schaden kann. Mit diesem Zusatzwissen kann man sich leichter Zusatzbibliotheken mit PYREX http://www.cosc.canterbury.ac.nz/greg.e ... hon/Pyrex/ und CYTHON http://www.cython.org/ zusammenbasteln.

Somit bringe ich PYREX und CYTHON als interessante Zusatzsprachen mit ins Spiel. Denn wenn man unbedingt mehr Performance braucht, dann kann man sich damit wirklich gut behelfen.

Pyrex-0.9.8.4.tar.gz (242215 bytes, 2008-06-11)

The latest release of Cython is 0.9.8 (released 2008-06-12)

Wie man sieht, werden beide Sprachen weiterentwickelt. Auch wenn ich nicht weiß, worin der Unterschied zwischen Cython und Pyrex besteht.

lg
Gerold

Pyrex schien eine ganze Weile "tot" zu sein. Der Autor beschränkte sich darauf Patches und Bugfixes von dritten ein zu pflegen.

Cython wird aktiv entwickelt, mit dem Ziel mehr Python-Konstrukte zu unterstützen, zum Beispiel Generator-Ausdrücke, und mehr Optimierungen durch zu führen. Und soweit ich weiss würden die Autoren auch als Maintainer zur Verfügung stehen, falls Cython in die offizielle Python-Distribution aufgenommen würde.

Das es von Pyrex neulich ein Update gab, hat mich etwas überrascht.

@lunar, außer in reinen Microsoft-Shops ist mir C# (serverseitig) noch nicht untergekommen, Java hingegen ist allgegenwärtig. Da ich seit 15+ Jahren in der "Industrie" bin, wage ich schon so eine Prognose.

Robert Tolksdorfs lange Liste von Sprachen (meist Interpretern und damit eben eher experimentell) enthält nicht nur ein Scheme (aber auch für .NET gibt es bestimmt ein halbes Dutzend Versuche) sondern mehr als 20. SISC ist dabei ein vollwertiges Scheme, ABCL ein recht gutes CommonLisp. Recht viel Aufmerksamkeit hat gerade Clojure, gelistet unter "Functional". Fan ist übrigens neben Scala die zweite Sprache, die ich kenne, die sowohl für .NET als für JVM funktioniert (mal Bigloo-Scheme außen vor lassend). Was das Portieren angeht: Dies ist kein Markel, sondern IMHO eher positiv, denn wie gesagt, ist die Community einer Sprache auch wichtig. Neue Sprachen ohne Anwender könnte man sonst mit einem Parsergenerator deiner Wahl erstellen.

Deine Schlussfolgerung, dass es für die CLR leichter ist, eine Sprache zu bauen, halte ich für falsch. Sowohl die CLR als auch die JVM sind gut und vor allem exakt dokumentiert. IL hat einige Features mehr als der Bytecode der JVM - speziell gibt es eine Instruktion für tail-calls, doch bei Bigloo hat man festgestellt, dass dieser die Programme langsamer macht. Somit ist das kein echter Vorteil. Den anderen "Vorteil" der CLR, auch nicht-sicheren Code mit Pointer-Operationen erzeugen zu können, halte ich für keinen und niemand nutzt das AFAIK.

Microsoft hat durch das Extrahieren von Generator-Code aus IronPython unter dem Namen DLR (Dynamic Language Runtime) es ein bisschen einfacher gemacht, Bytecode bzw. IL dynamisch aus einem AST zu generieren, doch das bleibt immer noch recht schwer. Ähnlichen Code könnte man auch aus JRuby und wahrscheinlich auch aus Jython ziehen - und ich hoffe, dies passiert auch. Traditionell ist die Java-Community offener und eher zu opensource-Projekten bereit als .NET-Anwender. Somit glaube ich, dass Groovy, JRuby und auch Jython-Entwickler da etwas zusammen machen werden.

Microsofts Vorteil ist nur, dass sie von Anfang an behauptet haben, die CLR wäre für mehrere Sprachen (die als semantische Zwillinge von C# sein müssen, damit es einigermaßen einfach klappt) während Sun darauf beharrt hat, das Java als Sprache für die JVM ausreicht und ein Vorteil ist, wenn alle die selbe Sprache sprechen. Erst kürzlich mit dem "Erwerb" von JRuby und Jython hat Sun hier einen Wandel vollzogen.

Java EE != nur EJB. Java EE umfasst auch Servlets und die sind eigentlich recht praktisch und IMHO Grund für den Erfolg von Java auf der Serverseite. Viele Rahmenwerke (denn wenn es eines in Java gibt, dann sind das Webrahmenwerke) nutzen nur Teile von Java EE, Wicket etwa ist ein nettes komponentenbasiertes System - ein kleines bisschen so wie Seaside für Smalltalk.

Ich glaube von mir, dass ich mich recht gut mit VM- und JIT-Technologien auskenne und daher bleibe ich bei meiner Behauptung, dass Hotspot das Beste ist, was zur Zeit existiert. Das ganze basiert auf der Forschung von 1995 zur Self-VM (Self ist ein Smalltalk-Dialekt und als Prototyp-basierte Sprache Inspiration für JavaScript gewesen) die natürlich öffentlich ist und auch von Microsoft implementiert werden kann und vielleicht schon wurde. Dennoch, mein Stand ist, dass Microsoft .NET eher Richtung Client (also z.B. schneller Kaltstart) optimiert hat, während Hotspot das Eile, aber nach einer Weile Prinzip verfolgt.

Das IronPython Jython voraus ist, ist nicht wirklich verwunderlich, wenn man berücksichtigt, dass bei Microsoft der Entwickler von Jython fulltime und zusammen mit einem ganzen Team von Entwicklern an IronPython arbeitet, während Jython vor einigen Jahren in den vergifteten Apfel gebissen hat und erst kürzlich wieder wachgeküsst wurde und auch jetzt nur von ein- oder zwei Leuten entwickelt wird.

Microsoft pumpt da deutlich mehr Ressourcen rein - schon allein deswegen, um für Silverlight ein paar Scriptsprachen als Argument gegen Flash zu haben. Flash bedeutet zur Zeit nur ActionScript und die Idee, .NET-IL in ABC (Action Script Bytecode, das, was bei Flash die Tamarin-VM versteht - die übrigens richtig fix ist, wenn man ihre Größe berücksichtigt) zu konvertieren, ist AFAIK auch nur eine Idee geblieben. Da aber sowohl Tamarin als auch der Flex-ActionScript-Compiler Opensource sind, könnte man auch dort weitere Sprachen ergänzen.

Stefan

gerold hat geschrieben:Auch wenn ich nicht weiß, worin der Unterschied zwischen Cython und Pyrex besteht.

Siehe http://wiki.cython.org/DifferencesFromPyrex.

Andrew Dalke hat auf der EuroSciPy-Konferenz die Frage gestellt, was man denn nun nehmen solle: Pyrex oder Cython.

Auf den Mailinglisten wurde der Autor von Pyrex vor einiger Zeit hart angegangen, weil Pyrex nicht wirklich "offen" ist. Problem war, dass G. Erwing, der Autor von Pyrex, nicht wußte wie man z.B. ein svn repository für das Projekt online stellt, bzw. das nicht wollte. CPython ist die Antwort darauf: Eine offene "Fortentwicklung von Pyrex" unter Einbeziehung von Erwing, der aber sein "Kind" Pyrex wohl nicht einfach aufgibt.

Tenor auf der Konferenz war, dass man - vor die Wahl Pyrex oder Cython gestellt - lieber Cython nehmen solle.

Gruß,
Christian

PS Hoffe ich habe das korrekt zusammengefasst - falls nicht: Ich hatte nicht die Absicht da jemanden auf die Füsse zu treten.

edit: Rechtschreibung

gerold hat geschrieben:Außer Geschwindigkeit, gibt es doch kaum einen Grund, eine andere Programmiersprache als Python einzusetzen.

Naja, wie die funktionalen Programmiersprachen Erlang und das erst in letzter Zeit publik gewordene Clojure (wurde schon vom sma erwähnt und der Autor promotet es zurzeit sehr stark) beweisen gibt es durchaus einen Markt für Programmiersprachen die Parallelität groß schreiben. Clojure ist etwa ein neues Lisp welches auf der JVM aufbaut um die Vorteile der HotSpot-VM zu verwenden aber durch immutable Typen und spezielle Erleichterungen für das Handhaben von Zustand (State) von den üblichen Common Lisps und Schemes sich abgrenzt (obwohl PLT 4 nun auch stärker auf immutable Typen setzt). Insbesondere der zweiteilige Screencast ist durchaus sehenswert und persönlich schaut es für mich etwas freundlicher aus als Erlang. Hat natürlich auch momentan noch Nachteile wie geringe Userbasis und fehlende Tail-Call-Optimization aber es sieht eigentlich recht vielversprechend aus. Noch dazu kombiniert mit der aus Lisp üblichen Metaprogrammierung ist das durchaus eine Sprache die für einige Dinge mit Python konkurrieren kann. Achja, von der Performance soll es vergleichbar mit normalen Java sein, JRuby und Jython vermutlich hinter sich lassen.

CM, ja das habe ich auch so verstanden und würde dem auch im groben und ganzen auch so zustimmen. War ja auf dem Talk von Stefan Behnel, der einer der Cython-Maintainer ist und es stark pusht. Vor allem mit lxml und den Sage-Leuten im Rücken ist bei Cython auch wesentlich mehr Entwicklung zu verzeichnen.

Clojure habe ich bislang noch nie ausprobiert und kann zur Performance nicht viel sagen. Da es aber im Gegensatz zu Jython und JRuby erfordert, lokale Variablen zu definieren, müssen diese nicht in Dictionaries verwaltet werden, sondern können wie bei Java-Methoden auf dem Stack gehalten haben und daher würde ich ebenfalls die Einschätzung teilen, dass es schneller ist als diese beiden Scriptsprachen.

Clojure sagt, Software Transactional Memory als Abstraktion für Prozesskommunikation zu benutzen. Dies ist ein fundamental anderer Ansatz als Erlang ihn mit seinen Prozessen hat. Näher an Erlang ist Scala mit seiner Actor-Bibliothek. STMs könnten aber besser zum Memory-Modell der JVM passen - ich meine, da mal entsprechendes gelesen zu haben.

Stefan