Python in C - Warum?

[BlackVivi]

Stell mir grade vor, wie man Python auf C++0x portieren würde =D

[mq]

Stell mir grade vor, wie man Python auf C++0x portieren würde =D

Man könnte ein C++-Backend für pypy schreiben :P

[sma]

Ich würde ja sagen, C wurde einfach als kleinster gemeinsamer Nenner gewählt. Definitiv war Anfang der 90er C++ noch nicht so verbreitet wie heute - falls es heute denn gegenüber C so verbreitet ist. Würde man jetzt einen Interpreter für eine Sprache schreiben, könnte man sicherlich auch C++ wählen. Rubinius (Neuimplementierung von Ruby) macht das so.

Portabilität wird IMHO ansonsten überbewertet. Solange man sich an den GCC hält, läuft's dort, wo dieser läuft und das sind schon eine ganze Menge Plattformen. Man könnte sich somit auch für eine Sprache als Implementierungssprache entscheiden, die selbst wieder C(++) für den GCC (als portable Assemblersprache) erzeugt und erreicht die selbe Portabilität.

1993 war ich in einem Projekt, das einen CommonLisp nach C Compiler baute und das Ergebnis lief dann sogar auf meinem mit 4 MB Hauptspeicher ausgestattetem PC - und nicht nur auf unseren Sun-Workstations mit immerhin 16 MB Hauptspeicher. Ein Python in Lisp hätte sich wahrscheinlich viel einfacher formulieren und warten lassen (jedenfalls für Leute, die Lisp verstehen) und ebenfalls übersetzen lassen. Scheme-Compiler wie z.B. Gambit oder Bigloo gehen ähnlich vor und man könnte diese ebenfalls benutzen.

Ich glaube, dass es prinzipiell eine gute Idee ist, Interpreter oder Compiler für Hochsprachen (wie Python) auch in einer Hochsprache - und nicht in C - zu schreiben, aber leider sind meist die Leute, die es auch durchhalten, eine neue Sprache zu entwerfen auch die, die lieber eine maschinennahe Sprache bevorzugen. Vielleicht liegt es an der dadurch bereits trainierten Leidensfähigkeit ;)

C für Python zu benutzen hat definitiv den Vorteil, dass man relativ einfach in C bereits existierende Bibliotheken anbinden kann. Das wäre bei z.B. OCaml als Implementierungssprache wahrscheinlich schwieriger.

Ansonsten fände ich es natürlich schön, wenn schon längt PyPy der Standardweg für die Referenzimplementierung wäre.

Stefan

[sehbaer]

Liebe Pythoffels.

Es geht wohl auch anders herum. Ein C Compiler in Python geschrieben:
http://people.cs.uchicago.edu/~varmaa/mini_c/

This is a compiler for a subset of the C programming language. It was written in Python during the spring of 2004.

habe ich auf pythonmania.de entdeckelt.

[lunar]

Portabilität wird IMHO ansonsten überbewertet. Solange man sich an den GCC hält, läuft's dort, wo dieser läuft und das sind schon eine ganze Menge Plattformen.

Der Compiler ist nicht so sehr das Problem wie die Bibliotheken.

Ein Python in Lisp hätte sich wahrscheinlich viel einfacher formulieren und warten lassen (jedenfalls für Leute, die Lisp verstehen)

Nicht nur das "Leute, die Lisp verstehen" nicht auf Bäumen wachsen, ist es auch bestimmt abenteuerlich, C++-Bibliotheken über Lisp an Python anzubinden. Das hört sich an wie in Hotshots: "Sie müssen über den Hintern, um von hinten dann infernal an die Augen heranzukommen."

[sma]

Nicht nur das "Leute, die Lisp verstehen" nicht auf Bäumen wachsen, ist es auch bestimmt abenteuerlich, C++-Bibliotheken über Lisp an Python anzubinden.

Würde Lisp als Implementierungssprache für Interpreter populär genug, wären C++ Bibliotheken nicht das Problem, denn diese wären auch alle in Lisp geschrieben ;)

Stefan

[lunar]

Nicht nur das "Leute, die Lisp verstehen" nicht auf Bäumen wachsen, ist es auch bestimmt abenteuerlich, C++-Bibliotheken über Lisp an Python anzubinden.

Würde Lisp als Implementierungssprache für Interpreter populär genug, wären C++ Bibliotheken nicht das Problem, denn diese wären auch alle in Lisp geschrieben

Gnade uns Stallman, elisp ist schon schlimm genug

[Leonidas]

Gnade uns Stallman, elisp ist schon schlimm genug

Elisp ist vielleicht die Ausnahme, aber Lisp-Dialekte sind eigentlich recht cool. Aber zugegeben, sich mit etwas anderem als Common Lisp, Scheme (und evtl. Clojure) zu befassen ist sicher nicht so sonderlich lustig. Hat jedes ihre Stärken und Schwächen aber für Metaprogrammierung ists nett.

Jemand hat auch behauptet das man sich für jedes Problem in Lisp eine eigene Sprache schreibt (DSL) und mit dieser dann das Problem löst

[lunar]

Hat jedes ihre Stärken und Schwächen aber für Metaprogrammierung ists nett.

Programmierung um der Metaprogrammierung willen ist irgendwie eine Art informationstechnischer Onanie, reine Selbstbeschäftigung

Auch wenn das im Akademischen jetzt vielleicht weniger gilt, aber letztendlich will man mit einem Programm ja irgendwo was erreichen, dann reicht es nicht mehr, wenn die Sprache nett für Metaprogrammierung ist

[Leonidas]

Auch wenn das im Akademischen jetzt vielleicht weniger gilt, aber letztendlich will man mit einem Programm ja irgendwo was erreichen, dann reicht es nicht mehr, wenn die Sprache nett für Metaprogrammierung ist

Dann schau dir mal UnCommon Web (CL) oder Fluxus (Scheme) an. Die sehen auch aus Python-Sicht interessant aus und bei dem was bei fluxus rauskommt wird man mit Python und Pygame richtig neidisch.

[sma]

Jemand hat auch behauptet das man sich für jedes Problem in Lisp eine eigene Sprache schreibt (DSL) und mit dieser dann das Problem löst :)

Was ich für im Gegensatz zu lunar auch den richtigen Ansatz halte. Extrem ist in dieser Hinsicht Forth, wo man sich ja wirklich solange Worte, mit denen man den Satz baut, der das Problem löst, aus einfacheren Worten zusammenbaut, bis man abstrakt genug ist, auch die Lösung in einem Satz auszudrücken. Man vergleiche auch Guy Steeles legendären OOPSLA-Vortrag, Growing a Language.

Man geht in jeder Programmiersprache so vor, doch viele Programmiersprachen erlauben es nur, neue Funktionen (oder Operationen) selbst zu definieren, nicht jedoch auch neue Kontrollstrukturen. Hier sind Forth oder aber eben auch Lisp-Dialekte anders. Eigene Kontrollstrukturen (allgemein "special forms") sind dank Makro-Programmierung ebenfalls möglich. CommonLisp geht mit seinem Objektsystem sogar so weit, dass auch andere eigene Objektsysteme dank Metaobjekt-Programmierung möglich sind.

Stefan