Von offensichtlicherTroll am Mo, 21. Mai 2012 um 18:25 #
Nach einem Jahr Entwicklung hat die Perl Foundation Perl 5.16.0 freigegeben. Vor über einem halben Jahr hatten die Perl-Entwickler nochmals bekräftigt, dass es jedes Jahr im Frühjahr eine neue Version von Perl 5 geben soll. Es wird keine Ablösung von Perl 5 durch Perl 6 geben, da Perl 6 trotz der Namensähnlichkeit längst als vollständig neue Sprache angesehen wird.
Ich will mir keine Illusionen machen, aber es wäre schön, wenn die Entwickler stattdessen an Rakudo und Parrot arbeiten würden und Perl5 sterben lassen würden. Aber vermutlich kann man genauso hoffen, dass die PHP-Entwickler jegliche Arbeiten einstellen.
Was soll es. Wünsch ich mir einfach, dass die verschwundenen Entwickler nun an Rakudo, Parrot oder Ruby 2 arbeiten.
Bis Perl6 an Perl5 heran kommt dauert es noch lange. Perl5 ist extrem Optimiert und weitgehend sehr Fehlerfrei. Etwas ähnliches mit Perl6 zu erreichen dauert noch mindestens 5-7 Jahre. Aber ich sehe ganz klar das Perl5 von der Syntax und den historischen Altlasten an seine Grenzen kommt. Das bedeutet aber nicht das man sofort die Entwicklung von Perl5 einstellen soll. Viele Ideen und Anregungen aus Perl6 wandern nach und nach zu Perl5 (Smartmatch, verbesserte RegExp-Engine etc.) Das befruchtet auch Perl6, denn in Perl5 kann man direkt testen was in Perl6 noch implementiert werden muss.
Zudem ist der ganze Perl5 Code nicht ganz einfach nach Perl6 zu Portieren. Denk allein an Cpan. Perl5 wird es noch sehr lange geben und parallel zu Perl6 existieren.
Von offensichtlicherTroll am Di, 22. Mai 2012 um 18:05 #
Das tragische ist ja, das Parrot als VM an sich schon heute bessere Performance und richtige Garbage-Collection mitbringt statt Referenzenzählung. Von der Leistung ist Parrot schon nah an der JVM. Perl5 nicht, Python 3 nicht, Ruby 1.9 noch nicht, falls das wirklich eine Entwicklerversion zu 2 werden soll und PHP sowieso nicht. Vor allem an Zweiterem soll Perl 5 erstmal feilen, bevor hochtrabend irgendwelche Optimierungen für Regexes n Shit gebaut werden.
Die selben die Perl5 entwickelt haben, fingen an Perl5 von seinen Altlasten zu befreien, neue Fähigkeiten hinzuzufügen und ordentlich zu strukturieren. Das nannten sie Perl6. Das sich die Sprachspezifikation einen solchen Sprung machen würde war damals nicht klar. Ich halte es Legitim das noch als Perl zu bezeichnen, denn es folgt den Ideen von Perl.
Selbst wenn man es als Fork ansieht, so ist der Name doch in Ordnung.
Perl find ich immer noch die schönste Sprache von allen. Das man den Variablen ein $ vorne hin setzt, denn Arrays ein @ und den Hashes ein % ist eine so simple Regel und macht den Source Code gleich enorm übersichtlicher und einfacher zu lesen. Man weiss einfach immer gleich was was ist. Klar, man kann mit Perl (5) hässlich programmieren wenn man will, aber das st nicht Perl's schuld sondern die des Entwicklers.
Schade das Perl 6 immer noch nicht richtig fertig ist. Wenns jetzt noch zu Perl 6 gute Qt-Bindings gäbe würd ich sofort wieder mehr damit arbeiten. Momentan kann ichs leider nur für kleiner Scripte gebrauchen.
Ich find das macht den Code einfacher lesbar, weil mit den Sonderzeichen am Anfang noch eine wichtige Information mitgegeben wird.
Oha... über Sinn und Unsinn von Ungarischer Notation kann man natürlich vortrefflich streiten - aber Typen in wirren Zeichen zu kodieren erhöht die Mapping-Abstraktion im Gehirn ja wieder um eine Ebene... Ok, wenn man Skat oder Doppelkopf-Fan ist, stört einen das vermutlich auch nicht
Und TIMTOWTDI trägt allgemein imho nicht grad zur guten Lesbarkeit von Code bei...
Aber nicht alles sind Skalare, Arrays oder Hashes. Bei Referenzen hört es dann schon auf. Und da diese doch sehr häufig zum Einsatz kommen, zieht sich das Prinzip auch nicht durch. IMHO macht die häufige Verwendung von Sonderzeichen Code auch weniger lesefreundlich.
Ansichtssache. Eine Referenz ist ein Scalar. @$wert erklärt sich doch.
Es ist ein allgemeines Missverständnis. Das Präfix zeigt an was der Programmierer haben will, nicht was es ist. Perl meldet sich, wenn der Wunsch des Programmierers nicht mit dem Programm überein stimmt.
Meiner Meinung nach sollte man Perl nun in dem Zustand lassen wie es ist und alle zukunftszugewandten Bemühungen in Ruby2 stecken. Wer sich ein bisschen mit Ruby beschäftigt, wird sehr schnell merken, dass Ruby "Best of both worlds" von Perl und Python ist. Ruby rockt!
Von offensichtlicherTroll am Di, 22. Mai 2012 um 18:10 #
Bei Lua auch. Und auch da hat sich noch niemand beschwert. Man könnte natürlich auch das perfekte System umsetzen, d.h. nur ein Befehl pro Zeile, aber dann wäre das Geschrei wieder groß.
Über das "best of" lässt sich aber nun einmal trefflich streiten. Für den ein oder anderen ist die klare Lesbarkeit als wichtiges Idiom von Python *zusammen* mit "there should be one obvious way to do it" einfach unverzichtbar. Da eckt Ruby dann doch das ein oder andere Mal an
Aber ich stimme Dir zu, dass ich Ruby insgesamt als schöneres Gesamtsystem wahrnehme als Perl. Perl ist halt alt und gewachsen. Das ist Vor- und Nachteil zu gleich. Ein Perl6 halte ich für unnötig, da es - wie bereits angesprochen - sinnvollere Alternativen gibt. Perl5 hingegen wird über Jahre hinaus als wichtiger Bestandteil der IT-Welt bestehen bleiben, bis es irgend wann einmal (vielleicht?!) verschwindet...
Perl war, ist und wird auch in Zukunft wichtig sein. Aber die Sprache ist ausgereizt. Man sollte Perl einfach einfrieren und nur noch Fehlerbehebungen und ggf. Optimierungen(Unicode!) veröffentlichen. So ziemlich alle in Perl machbaren Ansätze wurden m.E. bereits auch gemacht. In letzter Zeit habe ich den Eindruck, dass nur noch um der Änderung Willen geändert und erweitert wird. Ein stabiles, verlässliches Perl in dem nicht weiter gebastelt wird, sich dann auch noch lange Zeit bewähren können.
Von offensichtlicherTroll am Di, 22. Mai 2012 um 18:17 #
Es wirkt irgendwie künstlicher, wenn du die Warnung vor den Satz stellst. Selbst wenn ich nahezu alles auf einmal erfasse.
Aber nein, Ruby und Python sind keine billige Asiatenkopien und auch keine Modesprachen. Sowas wie Smalltalk ist eine Modesprache oder wie C#, ObjectiveC oder Java , wo die Leute das mal kurz gut finden, solange es gute IDEs dazu gibt und sich dann die Augen reiben, wenn sie das mal im Editor abtippen müssen.
Python deckt heute die Hälfte des Distributionsskripting ab und Ruby ist die Goldgrube vieler Webunternehmen.
Aber was willst Du denn an Perl grandioses ändern? Führe eine starke Typisierung ein, Entferne die Typ-Zeichen-Syntax, gehe weg von TIMTOWTDI und verleihe der Sprache ein von Anfang an sinnvolles Objektmodell. Huch, da sind wir dann ja bei Python oder Ruby
Wenn Du grundlegende Spracheigenschaften ändern willst, dann erschaffst Du vermutlich einen Clone einer bereits etablierten Sprache - den braucht aber keiner, weil es die ja schon gibt. Und brichst Du die Kompatibilität zu Perl 5, so schaffst Du ja erst den Raum, alte Perl-Scripte durch neue, in einer anderen Sprache geschriebene Scripte zu ersetzen.
Ob Parrot da alleine ausreicht... hm... ich bin skeptisch. Die JVM hat da vermutlich schon zu viele (Markt-)Anteile weggeschnappt...
"Perl 5 kompatibel" hat da eher Chancen, da Nutzer alte Scripte nicht neu schreiben müssen - damit kommst Du dann aber wieder in die Bredouille, keine wirklich stichhaltigen Neuerungen einbauen zu können...
Nach einem Jahr Entwicklung hat die Perl Foundation Perl 5.16.0 freigegeben. Vor über einem halben Jahr hatten die Perl-Entwickler nochmals bekräftigt, dass es jedes Jahr im Frühjahr eine neue Version von Perl 5 geben soll. Es wird keine Ablösung von Perl 5 durch Perl 6 geben, da Perl 6 trotz der Namensähnlichkeit längst als vollständig neue Sprache angesehen wird.
Ich will mir keine Illusionen machen, aber es wäre schön, wenn die Entwickler stattdessen an Rakudo und Parrot arbeiten würden und Perl5 sterben lassen würden. Aber vermutlich kann man genauso hoffen, dass die PHP-Entwickler jegliche Arbeiten einstellen.
Was soll es. Wünsch ich mir einfach, dass die verschwundenen Entwickler nun an Rakudo, Parrot oder Ruby 2 arbeiten.
Bis Perl6 an Perl5 heran kommt dauert es noch lange. Perl5 ist extrem Optimiert und weitgehend sehr Fehlerfrei. Etwas ähnliches mit Perl6 zu erreichen dauert noch mindestens 5-7 Jahre.
Aber ich sehe ganz klar das Perl5 von der Syntax und den historischen Altlasten an seine Grenzen kommt. Das bedeutet aber nicht das man sofort die Entwicklung von Perl5 einstellen soll. Viele Ideen und Anregungen aus Perl6 wandern nach und nach zu Perl5 (Smartmatch, verbesserte RegExp-Engine etc.) Das befruchtet auch Perl6, denn in Perl5 kann man direkt testen was in Perl6 noch implementiert werden muss.
Zudem ist der ganze Perl5 Code nicht ganz einfach nach Perl6 zu Portieren. Denk allein an Cpan. Perl5 wird es noch sehr lange geben und parallel zu Perl6 existieren.
Das tragische ist ja, das Parrot als VM an sich schon heute bessere Performance und richtige Garbage-Collection mitbringt statt Referenzenzählung. Von der Leistung ist Parrot schon nah an der JVM. Perl5 nicht, Python 3 nicht, Ruby 1.9 noch nicht, falls das wirklich eine Entwicklerversion zu 2 werden soll und PHP sowieso nicht.
Vor allem an Zweiterem soll Perl 5 erstmal feilen, bevor hochtrabend irgendwelche Optimierungen für Regexes n Shit gebaut werden.
LOL, Perl hat sich selbst geforkt, aber dabei vergessen den Namen zu ändern. Was für ein FAIL.
Was für ein Deutsch. Auch wenn dich dein Alter von 11 Jahren noch entschuldigt, solltest du vorsichtiger mit solchen Mutmaßungen sein.
Wieso? Hat er nicht Recht?
Nein, er hat nur unter Beweis gestellt das er keine Ahnung hat!
Das kannst du wodurch untermauern? Abgesehen von der etwas loligen Ausdrucksweise hat der Thread opener doch durchaus Recht.
Da DU offensichtlich auch keine Ahnung hast, würde ich dir die Posts von "wer" empfehlen.
Die selben die Perl5 entwickelt haben, fingen an Perl5 von seinen Altlasten zu befreien, neue Fähigkeiten hinzuzufügen und ordentlich zu strukturieren. Das nannten sie Perl6. Das sich die Sprachspezifikation einen solchen Sprung machen würde war damals nicht klar. Ich halte es Legitim das noch als Perl zu bezeichnen, denn es folgt den Ideen von Perl.
Selbst wenn man es als Fork ansieht, so ist der Name doch in Ordnung.
Es werden Dollar und andere seltsame Zeichen eingesetzt. Close enough.
Perl find ich immer noch die schönste Sprache von allen.
Das man den Variablen ein $ vorne hin setzt, denn Arrays ein @ und den Hashes ein % ist eine so simple Regel und macht den Source Code gleich enorm übersichtlicher und einfacher zu lesen. Man weiss einfach immer gleich was was ist.
Klar, man kann mit Perl (5) hässlich programmieren wenn man will, aber das st nicht Perl's schuld sondern die des Entwicklers.
Schade das Perl 6 immer noch nicht richtig fertig ist.
Wenns jetzt noch zu Perl 6 gute Qt-Bindings gäbe würd ich sofort wieder mehr damit arbeiten. Momentan kann ichs leider nur für kleiner Scripte gebrauchen.
Ich fühle mich grad wie Sheldon und schwanke, ob ich den Sarkasmus jetzt erkenne oder falsch liege...
Bazinga?
Ja das frag mal den Lucas von oben
Ich bin mir unsicher, ob er das nun ernst meint oder nicht... ich hoffe "oder nicht"
Ich meins ernst..
Ich find das macht den Code einfacher lesbar, weil mit den Sonderzeichen am Anfang noch eine wichtige Information mitgegeben wird.
Natürlich bin ich vorbelastet weil Perl meine erste Programmiersprache war
Weil das Gehirn ja sonst völlig überlastet wäre, ein Objekt ohne Dollar zu erkennen.
Und TIMTOWTDI trägt allgemein imho nicht grad zur guten Lesbarkeit von Code bei...
Java ist viel besser:
char a=dingsbums.erstesKindDasKeineBesonderenEigenschaftenHatAberMehrAlsEinenWert().ersterWertDessenErstesZeichenEinBuchstabeIst.ersterBuchstabe();
Diese "selbsterklärenden" MethodenNamenTreibenMichNochMalInDenWahsinn()!
:-)
Like!
Aber nicht alles sind Skalare, Arrays oder Hashes. Bei Referenzen hört es dann schon auf. Und da diese doch sehr häufig zum Einsatz kommen, zieht sich das Prinzip auch nicht durch. IMHO macht die häufige Verwendung von Sonderzeichen Code auch weniger lesefreundlich.
Ansichtssache.
Eine Referenz ist ein Scalar.
@$wert erklärt sich doch.
Es ist ein allgemeines Missverständnis. Das Präfix zeigt an was der Programmierer haben will, nicht was es ist. Perl meldet sich, wenn der Wunsch des Programmierers nicht mit dem Programm überein stimmt.
Meiner Meinung nach sollte man Perl nun in dem Zustand lassen wie es ist und alle zukunftszugewandten Bemühungen in Ruby2 stecken. Wer sich ein bisschen mit Ruby beschäftigt, wird sehr schnell merken, dass Ruby "Best of both worlds" von Perl und Python ist. Ruby rockt!
Und Pascal. Begin/End lassen grüßen.
Bei Lua auch. Und auch da hat sich noch niemand beschwert.
Man könnte natürlich auch das perfekte System umsetzen, d.h. nur ein Befehl pro Zeile, aber dann wäre das Geschrei wieder groß.
Über das "best of" lässt sich aber nun einmal trefflich streiten. Für den ein oder anderen ist die klare Lesbarkeit als wichtiges Idiom von Python *zusammen* mit "there should be one obvious way to do it" einfach unverzichtbar. Da eckt Ruby dann doch das ein oder andere Mal an
Aber ich stimme Dir zu, dass ich Ruby insgesamt als schöneres Gesamtsystem wahrnehme als Perl. Perl ist halt alt und gewachsen. Das ist Vor- und Nachteil zu gleich. Ein Perl6 halte ich für unnötig, da es - wie bereits angesprochen - sinnvollere Alternativen gibt. Perl5 hingegen wird über Jahre hinaus als wichtiger Bestandteil der IT-Welt bestehen bleiben, bis es irgend wann einmal (vielleicht?!) verschwindet...
Perl war, ist und wird auch in Zukunft wichtig sein. Aber die Sprache ist ausgereizt. Man sollte Perl einfach einfrieren und nur noch Fehlerbehebungen und ggf. Optimierungen(Unicode!) veröffentlichen. So ziemlich alle in Perl machbaren Ansätze wurden m.E. bereits auch gemacht. In letzter Zeit habe ich den Eindruck, dass nur noch um der Änderung Willen geändert und erweitert wird. Ein stabiles, verlässliches Perl in dem nicht weiter gebastelt wird, sich dann auch noch lange Zeit bewähren können.
Deshalb wird ja an Perl 6 gearbeitet!
Man will auch keine grossen neuartigen veränderungen mehr an Perl 5 vornehmen.
(Achtung Flame)
Perl hat immer noch eine grössere Verbreitung und Akzeptanz als die billige Asiaten-Kopie Ruby!
Es wirkt irgendwie künstlicher, wenn du die Warnung vor den Satz stellst. Selbst wenn ich nahezu alles auf einmal erfasse.
Aber nein, Ruby und Python sind keine billige Asiatenkopien und auch keine Modesprachen. Sowas wie Smalltalk ist eine Modesprache oder wie C#, ObjectiveC oder Java , wo die Leute das mal kurz gut finden, solange es gute IDEs dazu gibt und sich dann die Augen reiben, wenn sie das mal im Editor abtippen müssen.
Python deckt heute die Hälfte des Distributionsskripting ab und Ruby ist die Goldgrube vieler Webunternehmen.
Wenn Du grundlegende Spracheigenschaften ändern willst, dann erschaffst Du vermutlich einen Clone einer bereits etablierten Sprache - den braucht aber keiner, weil es die ja schon gibt. Und brichst Du die Kompatibilität zu Perl 5, so schaffst Du ja erst den Raum, alte Perl-Scripte durch neue, in einer anderen Sprache geschriebene Scripte zu ersetzen.
Ob Parrot da alleine ausreicht... hm... ich bin skeptisch. Die JVM hat da vermutlich schon zu viele (Markt-)Anteile weggeschnappt...
"Perl 5 kompatibel" hat da eher Chancen, da Nutzer alte Scripte nicht neu schreiben müssen - damit kommst Du dann aber wieder in die Bredouille, keine wirklich stichhaltigen Neuerungen einbauen zu können...