lichtkind+2007-11-12 20:20:39--

ptk: die idee gefällt mir, alerdings mit anderem syntax. 'x' steht in perl 6 für stringmanipulation und xx für arraymanipulation. ka wo noch ein zeichen frei ist :) aber das einzige was mir auf die schnelle einfällt ist:

Code (perl): (dl )

 repeat { } while $n--; 

denn do blöcke sind jetzt nur noch do once loops :)

Perl-Syntax hat bislang immer stark mit Assoziationen gearbeitet. foo for 1..$n versteht man auf Anhieb, auch weil man die Notation 1..$n schon mal im Matheunterricht in der Schule gesehen hat. foo x $n ist auch einleuchtend, weil "x" eben das Symbol für "times" ist (im Englischen vielleicht mehr als im Deutschen). mit foo for ^$n verbinde ich erst einmal gar nichts. Oder kannst du mir auf die Sprünge helfen? Und die repeat-Lösung sieht ja noch viel schlimmer aus :-)

man kannst du negantiv sein. natürlich ist die repeat lösung eher scherzhaft gedacht. for 1 .. $n ist intuitiver, aber es ging ja darum das '1..' rauszukürzen.

Ist zwar schon länger her aber ich hatte im mathunterricht noch einen Dachoperator gesehen, zumindest zu ostzeiten in der mathe ag haben wir den öfters verwendet. ich erinner mich grad schwach aber es ging da um genau das gleiche wofür er auch in perl 6 verwendet wird.

Und zu deinem anderen kommentar: ich glaube man kann perl 6 und 5.10 nicht vergleichen. bei perl 5 ist es normal das erstmal eine weile die stable version gepflegt wird und der dev branch kaum von sich hören macht. nach den problemen mit perl 5.8.0 war die erlebte releaspolitik genau was geplant war und die probleme auch gelöst hat.

Perl 6 ist damit überhaupt nicht vergleichbar. Vor allem weil Sprache und Implementation fast getrennt voneinander entwickelt werden. Parrot ist ungefähr 4 jahre dabei und sieht eigentlich schon ganz gut aus. Aber neben Will und seinen Leuten wird auf Patricks und Larry's Etage parallel gebaut. Dazu kommen "Nebenschauplätze" wie Pugs und kp6 weswegen Vorhersagen so schwer sind. Denn ja es dauert lange, ja es ist schwer aber ja perl 6 wird auch ne wundervolle Sprache sein die mit Parrot ein ganz neues Ökosystem bilden kann. Deswegen würd ich mir nicht so viel Gedanken wegen umsteigen machen, denn es wird noch dauern, auch wenns grad gut aussieht da Patrick auch von der Mozilla foundation bezahlt wird, aber vielleicht programmierst du ja in 5 jahren in Ruby 2.0 und benutzt trotzdem Parrot mit etlichen ruby und perl modulen ?

Nachtrag:

es heisst natürlich und nicht

meine nachlässigkeit

ptk+2007-11-12 20:22:29--

renee+2007-11-12 20:18:54--

ptk+2007-11-12 20:14:48--

Ich sehe ja nur, wie schwierig es ist, von 5.8.x auf 5.10.x zu kommen.

Inwiefern?

Wie lange hat es von 5.8.0 bis 5.10.0 gedauert? Mehr als fünf Jahre?

Ja, der Zeitraum ist wirklich zu lange. Aber ob es daran liegt, dass es schwierig ist von 5.8.x auf 5.10.x zu kommen?

Man hätte besser früher 5.10.x rausgebracht und M::B erst später in den core genommen. Die Änderungen der RegexEngine hätte auch in einem 5.12.x Platz gehabt. etc....

Der Code-Freeze geht eigentlich auch schon zu lange. Weil vieles "zu perfekt" sein muss... Im Prinzip fehlen nur noch die CPANPLUS und VMS Geschichten. Warum hat man nicht ein 5.10.x rausgebracht und einige Updates in 5.10.1 oder 5.10.2 gepackt?

Mit "schwierig" meinte ich eigentlich "langwierig". Note: der 5.9.x-Branch hat auch recht früh angefangen, das erste Release 5.9.0 gab es schon 2003.

Fall ich mich richtig erinnere, war einer der Ziele für 5.10.x die Modernisierung einiger altehrwürdiger Perl-Module, namentlich CPAN.pm (-> CPANPLUS) und Makemaker (-> M::B). Also durfte man eben diese beiden Module nicht weglassen (auch wenn ich sie persönlich ziemlich überflüssig finde).

Und wenn man noch die Regexp-Engine weggelassen hätte, wäre nicht sehr viel von 5.10 übrig geblieben. Nun gut, da sind noch say, given/when ...

Naja, das mit der Regex-Engine ist ja ziemlich neu. Ich habe 2003 noch kein P5P gelesen, aber war damals eine so starke Änderung der RegEx-Engine tatsächlich schon Thema??

Bei CPANPLUS hängt's ja anscheinend nur noch an M::B. Aber warum will man denn in einer x.0 schon alles drin haben? Ist doch ok, wenn gewisse Features (Module) erst später kommen!

Die Release-Zyklen sollten eindeutig kürzer werden...

Nicht falsch verstehen, ich finde die Arbeit von P5P und speziell den Pumpkings extrem gut, aber wenn man immer gleich in einer x.0 alles "perfekt" haben will, wartet man ewig.

Deswegen finde ich die letzte Überlegung von RGS auch gar nicht so schlecht CPANPLUS wieder rauszunehmen...

CPAN.pm ist ja nicht wirklich schlechter als CPANPLUS, oder habe ich was verpasst? Das ist ja anscheinend entstanden, als Andreas lange Zeit nichts an CPAN.pm gemacht hat.

Und M::B und CPANPLUS sind in meinen Augen nicht die "Killerargumente" für Perl 5.10.x, sondern tatsächlich "use feature" (given, when, say, ~~, err,...) und die RegEx-Engine!

lichtkind+2007-11-12 21:52:04--

Ist zwar schon länger her aber ich hatte im mathunterricht noch einen Dachoperator gesehen, zumindest zu ostzeiten in der mathe ag haben wir den öfters verwendet. ich erinner mich grad schwach aber es ging da um genau das gleiche wofür er auch in perl 6 verwendet wird.

Versuch mal ne Referenz dazu zu finden, das würde meine Akzeptanz für diesen Operator ziemlich erhöhen...

Quote

aber vielleicht programmierst du ja in 5 jahren in Ruby 2.0 und benutzt trotzdem Parrot mit etlichen ruby und perl modulen ?

Bestimmt nicht, ich bin zu alt, um eine neue Sprache zu lernen :-)
Wie sieht es eigentlich mit der Performance von Perl6 auf parrot aus? Wird man zumindest die Geschwindigkeit von perl5 erreichen?

renee+2007-11-12 23:24:16--

Naja, das mit der Regex-Engine ist ja ziemlich neu. Ich habe 2003 noch kein P5P gelesen, aber war damals eine so starke Änderung der RegEx-Engine tatsächlich schon Thema??

Der damalige Pumpkin Hugo van der Sanden wollte die Regexp-Maschine ändern, aber leider ist er dazu nicht gekommen. Rafael hat den Pumpkin übernommen, demerphq hat die Regexp-Maschine umgebaut.

Quote

CPAN.pm ist ja nicht wirklich schlechter als CPANPLUS, oder habe ich was verpasst? Das ist ja anscheinend entstanden, als Andreas lange Zeit nichts an CPAN.pm gemacht hat.

Ich glaube, dass CPANPLUS ein riesiges Missverständnis ist... M::B hat wenigstens eine Daseitsberechtigung, nämlich dass man beim Bauen von Perl-Modulen nicht abhängig von einem externen Tool (make, nmake) ist.

ptk: da mein vater mathelehrer war hab ich noch die ganzen ostbücher, werd mal reinsehen.

zum thema geschwindigkeit: alles was ich sagen kann wahrscheinlich schnelle als perl mit kleinem p. lassen wir uns nicht von dem sonderfall blenden in dem parrot schneller als der gcc ist noch vom dem fall a parrot gegen cpython bei der ausführung einfacher pythonscripte verlor. auch wenns vorbei ist, konnte man die ergebnisse auch zugunsten parrot werten der mehr einzeltest gewonnen hat als cpython. mangels realistischer benchmarkzahlen begründe ich meine antwort mit theoretischen überlegungen:

* parrot kann compilierten bytecode in dateien ausgeben die einiges schneller starten.
* parrot hat einige feature die bytecode sehr schnell machen können wie abbildung von VM register auf prozessor register wenn möglich
* viele feature die perl später bekam oder noch nicht hat wurden in parrot von anfang an vogesehen was eine sauberere und daher auch schnellerere lösung ermöglicht. da möcht ich besonders hervorheben der wechsel zwischen threads oder subroutinen mittels continuations ist für parrot intern die bewegung eines masterregisers mit dem alle register sofort auf andere inhalte zeigen. (zumindest ungefähr :))
* durch seine modulare bauweise kann in parrot vieles einfacher nachträglich optimiert werden, der compilierungsprozess hat eine bytecodeoptimierungsphase die nachträglich ausgebessert werden kann und auch die die parser selber werden in zwischenschritten compiliert die nachträgliche optimierung und alternative targets zulassen.
* wenn alles aufgeht wird es ja auch nicht nur deswegen mehr coreentwickler geben weil es einfacher wird mitzumachen, sondern weil auch interessenten an anderen sprachen die parrot ausführen kann mitmachen werden

ich spekulier ungern, pugs lässt mich selbst bei 2 zeile code 5 sec warten und parrot wird noch nach version 1.0 schneller werden aber ich wäre nicht allzusehr überrascht wenn perl 6 schon von beginn an gleich mit perl 5 ungefähr gleich liegen würde.

perl5 besitzt auch die Möglichkeit, Bytecode von der Platte auszuführen. Nur leider bringt es keine Geschwindigkeit. Als Begründung habe ich mal gehört, dass das eigentliche Parsen bei perl5 sehr schnell ist und die Zeit bei den vielen malloc-Operationen verloren geht. Das wird bei parrot auch nicht anders sein. Es sei denn, man arbeitet mit Memory-Dumps.

Threads bei perl5 sind unbenutzbar, ja.

Ich habe auch das Gefühl, dass perl5 gerade deswegen so schnell ist, weil die Interna so "unsauber" sind. Statt die Interna orthogonal auszulegen, hat man den Interpreter für die üblich auftretenden Fälle schnell gemacht. Das ist nur ein Gefühl, ich kann es nicht belegen.