Das deutsche Python-Forum

Laut dem TechWorld-Artikel Open source Ruby, Python hit rocky ground at Microsoft sind die Entwicklerteams von IronPython und IronRuby deutlich geschrumpft -- im Fall von IronRuby auf nur noch einen Entwickler der teilzeit daran arbeitet.

Ehrlich gesagt bezweifle ich dass das einen großen Verlust darstellt.

DasIch hat geschrieben:Ehrlich gesagt bezweifle ich dass das einen großen Verlust darstellt.

Naja, beides sind doch recht populäre Sprachen bei denen man imho Interesse haben sollte, diese für seine Laufzeitumgebung nutzbar zu machen. Speziell wo sich Oracle mit dem Kauf von Sun sicherlich vermehrt für die JVM einsetzn dürfte, dem wohl einzigen Konkurrenten für Microsofts .NET.

Andererseits gabs ja wohl auch mit JRuby Probleme...

@DasIch: Technisch und persönlich sehe ich das auch nicht als grossen Verlust, weil ich nicht unbedingt ein Fan von .NET bin. Es werden aber Anzugträger Entscheidungen treffen die nicht technisch begründet sind, sondern einfach weil den beiden Sprachen die Unterstützung von Microsoft fehlt.

Naja, wir Pythonistas können ja bei solchen Leuten immer noch Google als Argument anführen.

Eigentlich finde ich .NET ja gar nicht mal schlecht. IMHO das beste Stück Software von Microsoft. Allerdings fand ich die dynamischen Scriptsprachen in .NET schon immer irgendwie fehl am Platz, egal wie sie heißen. .NET hat nunmal einen statischen Unterbau. Einzige Ausnahme ist vielleicht Boo, weil die auch statische Typisierung kennt. Soll jetzt aber kein Flamewar pro/contra dynamische Typisierung werden

burli hat geschrieben:Allerdings fand ich die dynamischen Scriptsprachen in .NET schon immer irgendwie fehl am Platz, egal wie sie heißen. .NET hat nunmal einen statischen Unterbau.

Und wie genau äußert sich das jetzt für die konkrete Sprache? Bei Jython schreibe ich doch einfach Python-Code - ob da in der JVM unten drunter irgend welche statischen Typisierungen zur Design-Time vorgenommen wurden tangiert mich da doch nicht wirklich. Oder irre ich hier?

Ja, ich weiß, die CPU selbst ist im Prinzip auch statisch typisiert, wenn man so will. Letztendlich kommt es auf's gleiche raus. Was mich "stört" ist einfach nur die zusätzliche "Zwischenschicht". IronPython kann von dem JIT von .NET auch nicht wirklich profitieren. Im Gegenteil, der Ressourcenhunger ist sogar teilweise deutlich höher, zumindest nach meinem letzten Kenntnisstand.

Einzige Vorteile sind doch nur die Möglichkeit, die .NET Bibliothek verwenden zu können und das man Python in Umgebungen wie Silverlight verwenden kann. Naja, vielleicht auch noch die Möglichkeit, C# oder VB Programme um Python oder Ruby Scripting erweitern zu können. Oder übersehe ich da einen entscheidenen Faktor?

CPython hat da auch eine "zusätzliche" Zwischenschicht, wieso stört dich die gleiche Zwischenschicht bei IronPython?

burli hat geschrieben: Einzige Vorteile sind doch nur die Möglichkeit, die .NET Bibliothek verwenden zu können und das man Python in Umgebungen wie Silverlight verwenden kann. Naja, vielleicht auch noch die Möglichkeit, C# oder VB Programme um Python oder Ruby Scripting erweitern zu können. Oder übersehe ich da einen entscheidenen Faktor?

Nuja, das klingt jetzt so nach "wenig". Ist aber imho durchaus eine tolle Sache. Ich kann mit Jython auf beliebige Java-Libs zugreifen, ohne mir einen Wrapper schreiben oder die Lib nach Python portieren zu müssen. Ist durchaus eine prima Sache.

Und zum Thema Speed: Oftmals spielt der doch keine wirkliche Rolle. Und wenn Du bei CPython auf Probleme stößt, müßtest Du ja auch etwas nach C auslagern. Hier wäre es dann eben ggf. Java bzw. C#.

Insofern würde ich diese "Zwischenschicht" nicht wirklich als so ein Dilemma oder so "hemmend" ansehen, im Vgl. zu CPython.

DasIch hat geschrieben:CPython hat da auch eine "zusätzliche" Zwischenschicht, wieso stört dich die gleiche Zwischenschicht bei IronPython?

Ich meine eine zusätzliche zu der, die sowieso schon vorhanden ist

@burli: Das ist doch vollkommen irrelevant. Wir leben schließlich nicht mehr in der Steinzeit. Moderne Prozessoren drehen doch eh meist nur Däumchen, insofern schadet es nicht, um den Preis einiger Taktzyklen die Entwickler zu entlasten. Es ist nämlich bestimmt wesentlich einfacher, einen Python-Interpreter in C# zu schreiben als in C.

Mag sein, aber geht nicht der Vorteil der .NET Plattform durch die dynamische Typisierung verloren? Nämlich das für alle Sprachen einheitliche Typensystem. Oder wird da versucht, zur Laufzeit die Typen entsprechend anzupassen?

Typisierung hat mit der .NET Plattform doch nichts zu tun.

burli hat geschrieben:Mag sein, aber geht nicht der Vorteil der .NET Plattform durch die dynamische Typisierung verloren? Nämlich das für alle Sprachen einheitliche Typensystem. Oder wird da versucht, zur Laufzeit die Typen entsprechend anzupassen?

Meinst Du das?

@lunar: Die Zwischenschicht ist nicht irrelevant. Sie ist halt komplett "nutzlos" dazwischen, weil sie so dynamische Sprachen wie Python nicht unterstützt. Man muss dadrauf halt alles nochmal implementieren und kann nicht viel von der Infrastruktur verwenden.

Ich kenne mich da mit .NET nicht genug aus, aber bei der JVM ist es schon ein Unterschied ob man mit dem Strom der statischen Typisierung schwimmt, oder die Introspection benutzt, oder sein Typsystem komplett neu schreibt und auf der JVM laufen lässt. Wünschenswert wäre halt eine VM wo man als Entwickler von dynamisch typisierten Programmiersprachen nicht das Gefühl hat, man würde gegen das System schreiben und versuchen da einen Fremdkörper irgendwie reinzubügeln.

@DasIch: Natürlich hat Typisierung was mit der .NET Plattform zu tun. Die Plattform hat ein Typsystem, Grundtypen, und gibt eine gewisse Semantik vor was Klassen und Vererbung angeht. Viele statische .NET Sprachen sind einfach nur syntaktischer Zucker über diesem Typsystem. VB.NET zum Beispiel ist einfach nur eine syntaktisch andere Art C#-Programme zu schreiben und unterscheidet sich stark von "klassischem" VB.

Je mehr man davon abweicht, desto weniger kann man von der Plattform wiederverwenden und desto mehr muss man sich anstrengen eine Brücke zu anderen Sprachen, also zum Beispiel zu den .NET Grundtypen zu schlagen. Und da wollte Microsoft ja in eine Bibliothek investieren, die dynamischeren Programmiersprachen entgegenkommt. Deshalb hatten sie unter anderem IronPython und IronRuby unterstützt.

@BlackJack: so sehe ich das auch. Einige Sprachen wie VB wurden wegen dem Typsystem komplett umgekrempelt, damit es einheitlich wird. Auf der anderen Seite bleiben die dynamischen Sprachen wie sie sind und müssen sich da irgendwie reinquetschen.

IMHO ist die einzige .NET taugliche dynamische Scriptsprache immer noch Boo, da sie speziell für CLI entwickelt wurde und eben sowohl dynamische als auch statische Typisierung kennt. Es sei denn, es gibt noch eine Sprache, die ich nicht kenne. Boo hat als einzige (mir bekannte) Sprache einen Interpreter und einen Compiler für .NET, lässt sich also auch interaktiv nutzen wie Python, aber alternativ auch compilieren wie C# oder VB.NET

Sprachen wie Python oder Ruby auf Plattformen wie .NET oder Java zu quetschen ist zwar ganz nett, aber ... naja, ich weiß nicht ... nur eingeschränkt sinnvoll?

burli hat geschrieben:@BlackJack: so sehe ich das auch. Einige Sprachen wie VB wurden wegen dem Typsystem komplett umgekrempelt, damit es einheitlich wird. Auf der anderen Seite bleiben die dynamischen Sprachen wie sie sind und müssen sich da irgendwie reinquetschen.

Ja und? C basiert auch auf einem statischen Typsystem und muss sich irgendwie in das Komplett fehlende Typsystem vom darunterliegenden Assembler reinquetschen. Ich seh da jetzt kein Problem.

burli hat geschrieben:IMHO ist die einzige .NET taugliche dynamische Scriptsprache immer noch Boo,

Die nicht dynamisch ist, insofern ist das irgendwie komisch.

burli hat geschrieben:da sie speziell für CLI entwickelt wurde und eben sowohl dynamische als auch statische Typisierung kennt.

Dieses Ducktyping das Boo da macht, sieht für mich eher vergleichbar zu den Implicit Conversions aus Scala aus.

burli hat geschrieben:Boo hat als einzige (mir bekannte) Sprache einen Interpreter und einen Compiler für .NET, lässt sich also auch interaktiv nutzen wie Python, aber alternativ auch compilieren wie C# oder VB.NET

Also IL wird ja eh überall generiert, von dem her machen es IronPython und IronRuby da ja ganz ähnlich. Was anderes kann die VM ja auch gar nicht ausführen. Wobei man erwähnen muss dass Microsoft mit der DLR mehr für dynamische Sprachen auf seiner Platform gemacht hat als Sun in den letzten 5 Jahren und vmtl Oracle in den nächsten 5 Jahren tun wird.

burli hat geschrieben:Sprachen wie Python oder Ruby auf Plattformen wie .NET oder Java zu quetschen ist zwar ganz nett, aber ... naja, ich weiß nicht ... nur eingeschränkt sinnvoll?

Inwiefern? Ich bin persönlich definitiv kein Fan der JVM, weil dieses Teil mir persönlich mehr im Weg steht als irgendwas anderes tut, aber ich kann mir durchaus vorstellen dass es Leute gibt die davon profitieren. So kann man etwa sowohl mit IronPython als auch mit Jython RoboCode-Roboter programmieren. Das ist sicher angenehmer zu lehren als Leuten das in Java zu erklären.