Das deutsche Python-Forum

zugegeben, *bekanntes* fuer demozwecke neu zu erfinden beeindruckt nicht. aber *unbekanntes* kapiert dann wieder keiner. ich weiss doch wie das ablaeuft.

aber was solls.

ein paar funktionale sprachen hab ich mir mal angesehen, einige davon (scheme) genauer.
ruby *hat* nette features, aber man schmeckt den perl-hintergrund sehr raus. ruby wird aber immer populaerer, also wuerde ich durchaus mehr in ruby investieren als in python, vor allem was webgefrickel angeht.
ruby on rails vs kein klarer gewinner im python lager... ror hat praktisch sturmfreie bude, weil sich die python frameworks gegenseitig die anhaenger streitig machen.

*meine* perfekte sprache gibts einfach nicht. schoen waers aber, wenn es eine sprache gaebe, die man sich syntaktisch und semantisch zurechtbiegen koennte... da faellt mir spontan nur die lispfamilie mit reader macros ein...

steve yegge hat die idee geaeussert, dass man die syntax einer sprache skinnen koennen sollte: irgendwo wird gesagt, in welchem "skin" der vorliegende code geschrieben wurde, aus skin-info und gegebenem quelltext macht dann der parser immer den gleichen abstrakten syntaxbaum.
und wenn man aus ASTs dann wieder in beliebige skins zuruecktransformieren koennte (ohne uebliche artefakte der transkodierung wie man sie beispielsweise in pyrex-c code findet), das waer doch was.

( edit doch lieber als neuer post... )

cracki hat geschrieben:zugegeben, *bekanntes* fuer demozwecke neu zu erfinden beeindruckt nicht. aber *unbekanntes* kapiert dann wieder keiner. ich weiss doch wie das ablaeuft.

Hehe, wie wahr, wie wahr ^^

schoen waers aber, wenn es eine sprache gaebe, die man sich syntaktisch und semantisch zurechtbiegen koennte

Hmm, was wäre der Sinn dabei? Ich sehe nicht wirklich einen Nutzen dabei die "Freiheit" zu haben sich eine Sprache X Syntaktisch und semantisch so anzupassen wie man das haben will. Vom Overhead mal nicht angefangen.

steve yegge hat die idee geaeussert, dass man die syntax einer sprache skinnen koennen sollte: irgendwo wird gesagt, in welchem "skin" der vorliegende code geschrieben wurde, aus skin-info und gegebenem quelltext macht dann der parser immer den gleichen abstrakten syntaxbaum.
und wenn man aus ASTs dann wieder in beliebige skins zuruecktransformieren koennte (ohne uebliche artefakte der transkodierung wie man sie beispielsweise in pyrex-c code findet), das waer doch was.

Kling im ersten Moment interessant, aber hier die gleiche frage und dann auch mit Berücksichtigung des Overheads. Ich glaube sowas würde sehr ausarten oder nicht? Wie soll man sich dann noch als Programmierer untereinander "verstehen" wenn jeder die Sprache X so definiert wie er sie haben will? 0o Schließlich fangen wir doch nciht auch alle an uns die Deutsche Sprache so Semantisch umzuformen wie es uns passt, mit dem Risiko das uns keiner mehr versteht

lg

cracki hat geschrieben:ruby *hat* nette features, aber man schmeckt den perl-hintergrund sehr raus. ruby wird aber immer populaerer, also wuerde ich durchaus mehr in ruby investieren als in python, vor allem was webgefrickel angeht.

Nein. PHP ist für "Webgefrickel" wesentlich populärer als RoR, ebenso der ASP-Kram. Dennoch würde ich mich nicht primär nach der Popularität richten, sondern danach, was es mir erlaubt, mein Ziel am besten zu erreichen. An dieser Stelle scheint mir Pythons Ansatz besser zu gefallen, also nehme ich ein Python-Framework. So einfach ist das.

cracki hat geschrieben:ruby on rails vs kein klarer gewinner im python lager... ror hat praktisch sturmfreie bude, weil sich die python frameworks gegenseitig die anhaenger streitig machen.

Wir wollen mal nicht vergessen, dass RoR mit Nitro und Basecamp durchaus auch Konkurrenz hat. Wenn ich Ruby einsetzen müsste, dann würde ich durchaus mal darüber Nachdenken, eine Rails-Alternative zu nutzen.

cracki hat geschrieben:steve yegge hat die idee geaeussert, dass man die syntax einer sprache skinnen koennen sollte: irgendwo wird gesagt, in welchem "skin" der vorliegende code geschrieben wurde, aus skin-info und gegebenem quelltext macht dann der parser immer den gleichen abstrakten syntaxbaum.

Mehr oder weniger soll sowas ja mit Parrot erreicht werden.

cracki hat geschrieben:und wenn man aus ASTs dann wieder in beliebige skins zuruecktransformieren koennte (ohne uebliche artefakte der transkodierung wie man sie beispielsweise in pyrex-c code findet), das waer doch was.

Ich sehe grade den Sinn des zurücktransformierens nicht (also einen wirklichen sinn, nicht einfach nur weil es geht, was natürlich ein Grund ist). Wenn ich eine Funktion habe, die ich in meiner Sprache wie eine ganz normale Funktion agiert, dann kann es mir egal sein, wie diese Funktion letztendlich implementiert ist.

parrot ist doch ne vm, keine "sprache" im herkoemmlichen sinne.

mit skin meine ich wie der code aussieht. mit AST meine ich die semantik des codes. der gleiche code kann in php so aussehen, in js anders und in python wieder ganz anders. so verstaendlich?

sape: es gaebe bekannte "skins", die wie dialekte gehandhabt werden. du hast dann eben eine maechtige universalsprache, fuer die du dann eben nur skins je nach anwendung benutzt. eine datei wuerdest du dann mit

Code: Alles auswählen

#!supersprache -skin schiessmichtot

einleiten

muss noch was loswerden. wenn man in einer sprache ausdruecken koennte, dass die argumente vor dem call nicht evaluiert werden sollen, sondern als callable oder AST, dann koennte man sowas machen:

Code: Alles auswählen

# macro() nimmt ne funktion, macht ein macro draus
while = macro( (condition, block) {
    loop = {
        if (condition()) {
            block()
            loop()
        }
    }
    loop()
})

a = 0
while(a < 10,
    print a**2
    a += 1
)

das bringt natuerlich wieder ganz andere probleme mit sich (bloecke muessten dann expressions sein, usw), ich weiss. waere aber ne ueberlegung wert, hm?

sape hat geschrieben:Hmm, was wäre der Sinn dabei? Ich sehe nicht wirklich einen Nutzen dabei die "Freiheit" zu haben sich eine Sprache X Syntaktisch und semantisch so anzupassen wie man das haben will. Vom Overhead mal nicht angefangen.

Solche Sprachen gibt es schon, wie cracki sagte bietet die Lisp-Familie eben das. Ruby macht es teilweise ebenso, eben auch in Rails. Dort werden Ruby-DSLs verwendet, um gewisse DInge einfacher zu machen.

sape hat geschrieben:Kling im ersten Moment interessant, aber hier die gleiche frage und dann auch mit Berücksichtigung des Overheads. Ich glaube sowas würde sehr ausarten oder nicht? Wie soll man sich dann noch als Programmierer untereinander "verstehen" wenn jeder die Sprache X so definiert wie er sie haben will? 0o Schließlich fangen wir doch nciht auch alle an uns die Deutsche Sprache so Semantisch umzuformen wie es uns passt, mit dem Risiko das uns keiner mehr versteht

In Ruby kann man besipeilsweise eingebaute Klassen bearbeiten und zum Beispiel die Addition als Subtraktion definieren, was ziemlich viel Code kaputt macht. Das ist eben ein zweischneidiges Schwert. Man kann vieles Kaputtmachen, man kann aber auch ziemlich elegante Dinge damit machen. Wenn man eine Funktion definiert, die etwas mit Strings macht, dann ist es nur logisch, dass diese Funktion Teil der Klasse String wird. Etc, etc.

Wenn wir uns alle so über Overhead sorgen würden, dann wären viele Dinge nicht existieren. Zum Beispiel Attribut-Lookup zur Laufzeit: Bringt viel Flexibilität und kürzt den Quellcode, aber produziert Overhead.

cracki hat geschrieben:parrot ist doch ne vm, keine "sprache" im herkoemmlichen sinne.

Natürlich. Aber wenn du sie als Sprache ansiehst (okay, wenn du ihren Bytecode an Sprache ansiehst) und dann die Programmiersprachen wie Ruby, Perl oder Python als Skins, dann hast du nachezu das was du haben wolltest. Bis auf das Rücktransformieren.

ich sags besser nochmal:

skins sind die syntax, die semantik bleibt unangetastet.

beispiel fuer "php" und "c" skins:

Code: Alles auswählen

for ($i = 0; $i < 10; ++$i)
    echo $i;

Code: Alles auswählen

int i; for(i = 0; i < 10; ++i)
    printf("%d", i);

natuerlich sorgt das skin auch fuer die offensichtlichen transformationen (echo vs printf, variablen instantiieren).

Leonidas hat geschrieben:Wir wollen mal nicht vergessen, dass RoR mit Nitro und Basecamp durchaus auch Konkurrenz hat.

Basecamp ist ein Produkt von 37signals, bei dessen Entwicklung RoR entstanden und extrahiert worden ist.

Das quasi-Monopol von Rails verschafft Ruby zwar einen Hype, aber zum Einen hat ersteres auch Nachteile, zum Anderen hat Ruby noch lange nicht die Anerkennung für den Produktionseinsatz, die aber Python mittlerweile in ausreichendem Maße erhalten zu haben scheint. Vor einigen Wochen oder Monaten hatte ich darüber gelesen, wenn ich mich nicht irre sogar bei Joel (richtig: Language Wars).

Und da Ruby auch noch relativ langsam ist und eine leichte Antipathie gegenüber Unicode zu haben scheint, steht Rails (momentan) nicht gerade auf dem besten Fundament.

Leonidas hat geschrieben:
cracki hat geschrieben:parrot ist doch ne vm, keine "sprache" im herkoemmlichen sinne.
Natürlich. Aber wenn du sie als Sprache ansiehst (okay, wenn du ihren Bytecode an Sprache ansiehst) und dann die Programmiersprachen wie Ruby, Perl oder Python als Skins, dann hast du nachezu das was du haben wolltest. Bis auf das Rücktransformieren.

Hmm, bin nicht sicher ob ich das verstehe. Du meinst also so einen Superinterpreter der "alle" Sprachen (die als Skins vorliegen) interpretieren kann und auch ein Mischmasch aus allen Sprachen in einem sourcecode vorkommen kann?

cracki hat geschrieben:skins sind die syntax, die semantik bleibt unangetastet.

beispiel fuer "php" und "c" skins:
Code: Alles auswählen
for ($i = 0; $i < 10; ++$i)
    echo $i;
Code: Alles auswählen
int i; for(i = 0; i < 10; ++i)
    printf("%d", i);

Aber wozu das ganze, wenn man mal die optimale Form gefunden hat??? IMHO sind weder php, oder die c Variante wirklich schön gelöst.

jens hat geschrieben:[...]IMHO sind weder php, oder die c Variante wirklich schön gelöst.

Finde ich auch. Am schönsten sieht es immer noch so aus:

Code: Alles auswählen

for i in xrange(10):
    print i

Ich habe cracki wohl falsch verstanden. Aber wenn die Semantik immer gleich bleiben soll, dann finde ich das eigentlich ziemlich uninteressant.

sape hat geschrieben:Hmm, bin nicht sicher ob ich das verstehe. Du meinst also so einen Superinterpreter der "alle" Sprachen (die als Skins vorliegen) interpretieren kann und auch ein Mischmasch aus allen Sprachen in einem sourcecode vorkommen kann?

Was meinst du? In einer Datei? Nein, natürlich nicht. Wäre zwar möglich, aber sehr unangenehm zu nutzen.
Aber sagen wir mal, ein Modul in Ruby zum implementieren und ein anderes In Python und dann von Python auf die Ruby-Klasse zugreifen, als wäre sie in Python geschrieben ist schon eher möglich. Macht IronPython in .NET mehr oder weniger auch so, auch wenn dort einige Einschränkungen sind zum Beispiel wenn es um Overloading geht. Jedenfalls wird der Python-Code von IronPython in IL kompiliert, und kann nun von jeder .NET-Sprache ganz normal verwendet werden.

sape:
Er meint quasi, dass aus verschiedenen Programmiersprachen der gleiche Bytecode erzeugt wird, so dass man die Programmiersprache selbst wählen kann, aber zum gleichen Ergebnis kommt.

Letztlich macht es IMHO aber mehr Sinn, direkt eine neue Sprache zu erschaffen, die eine saubere Syntax mit den Sprachfeatures der unterstützten Sprachen vereint, da letztere ja ohnehin implementiert werden müssen. Von den unterschiedlichen Denkweisen (ob forciert, ermöglicht oder zu bevorzugen) beim Programmieren noch abgesehen.

sape hat geschrieben:Am schönsten sieht es immer noch so aus:
Code: Alles auswählen
for i in xrange(10):
    print i

Nein, ich finde

Code: Alles auswählen

for i in 0..9:
    puts(i)
end

bis auf das 'end' klarer. Aber in Python gibt es keinen Syntactic Sugar für Range-Datentypen.

puts ist eine verdammte Altlast, die die Lesbarkeit vermindert. Und hast du nicht erst kürzlich gegen Altlasten gewettert?

Aber ja, die (aus Perl bekannten?) Ranges über a..z und dergleichen anstelle einer Funktion zu erzeugen ist schon angenehm, kompakt und intuitiv, hätte ich manchmal auch gerne.

Y0Gi hat geschrieben:puts ist eine verdammte Altlast, die die Lesbarkeit vermindert. Und hast du nicht erst kürzlich gegen Altlasten gewettert?

puts ist zumindest in Python keine Altlast, weil es das in Python gar nicht erst gibt. Aber gut, dann müssten wir die Funktion print mit puts überschreiben und fertig. Damit haben wir dann eine print-Funktion, die so in Python derzeit nicht einmal möglich ist.
An dieser Stelle hätte ich aber auch print(i) verwenden können, das stimmt, lediglich wären dann die Newlines verschwunden. In Ruby wird puts() für solche Dinge generell favorisiert, weil es sich so wie in Python aus print gewohnt verhält.

Aber mir gings in diesem Beispiel nicht um den Namen der Anzeigefunktion (und wenn wir dabei sind, ist weder puts och print ein Name, der die Funktionsweise exakt beschriebt), sondern um die Range-Syntax.

Leonidas hat geschrieben:
sape hat geschrieben:Am schönsten sieht es immer noch so aus:
Code: Alles auswählen
for i in xrange(10):
    print i
Nein, ich finde
Code: Alles auswählen
for i in 0..9:
    puts(i)
end
bis auf das 'end' klarer. Aber in Python gibt es keinen Syntactic Sugar für Range-Datentypen.

Sowas vermisse ich für Listen

Ich wünsche mir öfters sowas...

Code: Alles auswählen

li = [1..100]

anstat:

Code: Alles auswählen

li = [x for x in xrange(100)]

kommt das mal irgendwann für Python?

Kennt hier nicht jemand Guido persönlich und sagt ihn mal wir wollen alle [X..Y] haben?

...

Y0Gi, danke nun hab ichs verstanden.

lg

sape hat geschrieben:Sowas vermisse ich für Listen Ich wünsche mir öfters sowas...
Code: Alles auswählen
li = [1..100]
anstat:
Code: Alles auswählen
li = [x for x in xrange(100)]

Nimm doch li = range(1, 101)

Leonidas hat geschrieben: Nimm doch li = range(1, 101)

OK, aber was mache ich wenn ich a bis z haben will? li = [a..z] wäre da geil oder gleich li = [a..z..] + [A..Z] + [1..100]

alles andere ist nicht so elegant finde ich...

RTFM, mein Junge

Schau dir mal die Konstanten im Modul `string` an.

Das deutsche Python-Forum

Weiterentwicklung von JavaScript orientiert sich an Python