9 ms·

What's supposed to be so great about Perl 6? I associate Perl with inscrutable cat-walked-on-the-keyboard programs and little else. Can someone in the know expl

by tormeh 12y ago

What's supposed to be so great about Perl 6? I associate Perl with inscrutable cat-walked-on-the-keyboard programs and little else. Can someone in the know explain?

deleted 12y ago
[deleted]
Tepix 12y ago
You may want to read the Apocalypse documents ( http://perl6.org/archive/doc/apocalypse.html http://perl6.org/archive/doc/apocalypse.html ) and the Exegeses ( http://perl6.org/archive/doc/exegesis.html http://perl6.org/archive/doc/exegesis.html ). Perl 6 improves upon Perl 5 in countless ways. One of the strongest parts of perl, the regular expressions, have received further improvements. Check out https://en.wikipedia.org/wiki/Perl_6_rules https://en.wikipedia.org/wiki/Perl_6_rules Finally, if you are familiar with Perl 5, there's special documentation for you at http://perlgeek.de/en/article/5-to-6 http://perlgeek.de/en/article/5-to-6
- progman 12y ago
  > One of the strongest parts of perl, the regular expressions ... ... have been copied to Nimrod (now called "Nim") -- even with native C performance and native Perl syntax. http://nimrod-lang.org/re.html http://nimrod-lang.org/re.html Perl had its time and lost many of its users (including me) "thanks" to the inacceptable delay. Meanwhile the competitional advantage of Perl 6 is completely gone because many new features have also been implemented in other languages (Rust for instance), even in dinosaurs like Java and C++.
  - raiph 12y ago
    PCRE wrappers like the module you linked don't give other langs the nice regex integration available in Perl 5, they just give them support for "Perl Compatible Regular Expressions" (hence PCRE), a rough equivalent of P5's regex functionality: http://en.wikipedia.org/wiki/Perl_Compatible_Regular_Expressions http://en.wikipedia.org/wiki/Perl_Compatible_Regular_Express... But PCRE is 1990's parsing technology. Who cares if Nim copies parts of P5 regex via PCRE? The page you linked says "Consider using the pegs module instead.". PEGs, invented in 2004, are more powerful than regex, PCRE ones or otherwise: http://en.wikipedia.org/wiki/Parsing_expression_grammar http://en.wikipedia.org/wiki/Parsing_expression_grammar Perl 6 has Perl 6 rules, a unification of PEGs, regex, and lexical closures, built right in to the language. There's nothing like them in Nim, Java, or C++. http://en.wikipedia.org/wiki/Perl_6_rules http://en.wikipedia.org/wiki/Perl_6_rules
    - progman 12y ago
      > There's nothing like them in Nim, Java, or C++. Are you sure? Nim supports direct access to the AST so macros can be used to define new programming constructs like in Lisp. Also other languages support things like that (as library), Java for instance: http://www.antlr.org/ http://www.antlr.org/ http://tunnelvisionlabs.com/products/demo/antlrworks http://tunnelvisionlabs.com/products/demo/antlrworks
      - raiph 12y ago
        > Nim supports direct access to the AST so macros can be used to define new programming constructs like in Lisp. Nim macros can't modify Nim's syntax. That constraint makes perfect sense for Nim but not Perl 6. > ANTLR ANTLR has switched from LL(star) parsing to what they call Adaptive LL(star) for v4. P6 Rules have been what Larry has called "LL(star) with kludges" (by which he means the same thing) for about a decade. So ANTLR has caught up with that aspect and indeed ANTLR v4 is nice tech. But P6 Rules are built in to P6. Its grammar is defined in P6 Rules. User code can modify the language on the fly by modifying the rules. Java (or whatever) + ANTLR is nothing like Perl 6 and Perl 6 Rules.
        progman 12y ago
        > Nim macros can't modify Nim's syntax. Nim macros can extend Nim's syntax (additional "repeat ... until" for instance). They cannot change the built-in syntax of Nim. A macro system should never be allowed to change the core syntax of a language because that could lead to very strange errors. If Perl 6 is actually able to do that then it is a dangerous feature.
mike-cardwell 12y ago
explicit strong typing proper parameter lists active metadata on values, variables, subroutines, and types declarative classes with strong encapsulation roles full OO exception handling support for the concurrent use of multiple versions of a module extensive introspection facilities (including of POD) LL and LR grammars (including a built-in grammar for Perl 6 itself) subroutine overloading multiple dispatch named arguments a built-in switch statement hierarchical construction and destruction distributive method dispatch method delegation named regexes overlapping and exhaustive regex matches within a string named captures parse-tree pruning incremental regex matching against input streams macros (that are implemented in Perl itself) user-definable operators (from the full Unicode set) chained comparisons a universally accessible aliasing mechanism lexical exporting (via a cleaner, declarative syntax) multimorphic equality tests state variables hypothetical variables hyperoperators (i.e. vector processing) function currying junctions (i.e. superpositional values, subroutines, and types) coroutines lazy lists strong module and language versioning concurrent object pipes http://www.perl6.org/archive/faq.html http://www.perl6.org/archive/faq.html
- perlgeek 12y ago
  There's a reason this has "archive" in its URL :-) Rather consult this instead, which is maintained: http://faq.perl6.org/#features http://faq.perl6.org/#features
- tempodox 12y ago
  Is that “perl poetry” or does it mean anything?
thristian 12y ago
I'm not a Perl hacker, but there's one thing that I've wanted a bunch of times in other languages: Perl 6 does for PEGs (Parsing Expression Grammars) what Perl 5 did for regexes: they're part of the core language, you can execute Perl expressions when a PEG rule is matched, that kind of thing. In Python when I have some data and it grows just a bit too irregular for regexes, I have to start manually writing state-machines or add a dependency on a third-party library and spend an afternoon explaining parsing theory to my co-workers.
- nly 12y ago
  I want to see Perl 6 push the boundaries but the world isn't quite like it was when Perl 5 made using regex seemless. Competition is much more stiff. Even in C you can use something like Ian Piumarta's PEG generator[0] that let's you embed semantic actions written in C. For regular grammars, scanners and lexers you have powerful tools like Ragel[1] (which targets 7 languages) I'm not a Python person, so if the Python libraries proved inadequate I'd probably resort to these tools and then push out a Python module using Cyphon[2]. Personally I'm not a fan of using semantic actions for AST construction. I generally prefer the 'attribute' approach taken by libraries like Spirit (C++) which make the process feel a lot more like deserialization. SAs are still useful however for rejecting or accepting rules based on complex requirements (like "is this IP address routable"?). [0] http://piumarta.com/software/peg/ http://piumarta.com/software/peg/ [1] http://www.colm.net/open-source/ragel/ http://www.colm.net/open-source/ragel/ [2] http://cython.org/ http://cython.org/
  - rurban 12y ago
    With perl6 the peg backend is built-in, so you can compile and execute grammars on the fly. A bit like lua's lpeg. A perl6 Grammar is a first-class object.
    - nly 12y ago
      Sure, but what happens when someone needs something other than PEG/recursive descent, like expression parsing with a custom precedence table? Will Perl6 add that to the core language as well? Where do you draw the line? LPeg is a library, Spirit X3 (for C++, not yet complete) is a library. Both achieve pretty seamless integration with your code. I think in a library is where this stuff should be.
lmm 12y ago
Perl was, in its day, a breath of fresh air. It had an emphasis on practicality that made easy things very easy: regex literals, default arguments like $_, minimal syntax overhead, with things that would be syntax in other languages hoisted to interpreter args (-e, that arg that means "run this as an awk-style loop"), and so on. More than that, the project worked as a holistic ecosystem, rather than just a language and some tools: these days every language has something like CPAN, but it was a huge innovation at the time. Perl also pioneered a lot of the unit-testing infrastructure that we take for granted these days; every project in CPAN was expected to have tests, using the same libraries, and they ran as part of the install process. A cynic might say that perl innovated here out of necessity; lacking static typing and not having VM isolation means good unit tests are a necessity. But still, the resulting infrastructure is very good, and some very solid programs are written in perl. In many ways I'd say it was the go of its day. The downside of the emphasis on practicality was that the language always suffered from incoherence; with no principled foundation it's been slow to adapt as the practical things users want to do change (e.g. I'd argue string manipulation is a lot less important than it used to be - if you were writing perl today, you might give json manipulation the same prominence as regexes). Perl 6 may have been an effort to fix this, but went too far in the opposite direction; overly formalized, with a premature separation between VM and language that massively slowed development. There's a lot of good stuff about modern perl - Moose and the like - but IMO it's too little, too late; other languages have been able to improve their infrastructure to (mostly) match perl for easy things. Meanwhile perl's incoherence makes it very hard to write large programs and solve hard problems, where languages with a firmer theoretical foundation and stronger stylistic principles have a huge advantage.
- mst 12y ago
  Every time I try to write ruby or python code, as soon as I need to write classes I realise just how much boilerplate they require compared to Moose and how depressing not having first-class attributes, method modifiers and roles is, and end up back writing perl5.
  - fennecfoxen 12y ago
    As someone who has written both Perl and Ruby (in that order), you might be interested in this Ruby gem to alleviate at least some of those problems: https://github.com/solnic/virtus https://github.com/solnic/virtus
JonnieCache 12y ago
If you've ever enjoyed anything about ruby the chances are that it comes from perl.
- skywhopper 12y ago
  I'd put it a different way: Ruby stole all the useful syntactic shortcuts from Perl and ignored all the cruft and ugliness. Unfortunately the one thing Ruby didn't steal from Perl was its speed.
  - sigzero 12y ago
    Hasn't that change in 2.X series?
    - JonnieCache 12y ago
      It's definitely a lot faster. I still wouldn't call it fast. Of course, most apps are I/O bound, objects in the heap are larger than they appear, blah blah blah.
- untothebreach 12y ago
  I think most of the good* features of Ruby came from Smalltalk, though you can definitely see the Perl influence. *at least for my definition of "good"
  - JonnieCache 12y ago
    Indeed the object model is from smalltalk. I don't know why I didnt make that caveat.
oftenwrong 12y ago
>I associate Perl with inscrutable cat-walked-on-the-keyboard programs and little else. That's because Perl had a lot of "convenient" shorthand and quirks in the language that could be abused, leading to unreadable, "cat-walked-on-keyboard" code. However, that is just a stereotype. One could also force Perl to straighten its posture with a strict pragma, making much of the eccentricity disappear. I have worked on several large Perl 5 codebases that were/are clean and easy to understand and maintain.
- bane 12y ago
  Yeah, the default Perl is more of a slang dialect. Lots of implicit assumptions made about you, the language and your job. Once you turn on strict and use some common sense your code reads more like an school essay, but strangely is just about as easy to work in. Just like real languages have different modes to communicate in, Perl has it's own modes. I've worked on a couple large-ish Perl codebases too and with some decent code standard found them really easy to work on and extend.
  - raiph 12y ago
    Perl 6 claims saner defaults. For the strict pragma, it's off by default for one liners and on by default for everything else. A much bigger relevant change is Perl 6's support for hygienic lexically scoped "slangs". These can be used to relatively cleanly package composable dialects, DSLs, language tweaks etc. Slangs make it practical for a group to establish a default local policy (policies include anything from switching some language tweak on or off to switching to another language entirely) and for an individual programmer to extend or alter that policy in a cooperative manner. Slangs aren't yet nearly as easy as they supposed to be, but they're getting there. A couple examples are v5 (which switches to another lang entirely) and Tuxic (a tiny idiosyncratic tweak to standard Perl 6): https://github.com/rakudo-p5/v5/blob/master/README.md https://github.com/rakudo-p5/v5/blob/master/README.md https://github.com/FROGGS/p6-Slang-Tuxic/blob/master/README.md https://github.com/FROGGS/p6-Slang-Tuxic/blob/master/README....
sigzero 12y ago
The Perl community really frowns upon that kind of code now.
bane 12y ago
Perl is a fundamentally different approach to language design. It's almost anti-academic in the approach and more linguistic. It's superficially like any other curly braced language but there was lots of thought put into how statements are constructed and making things easy to humans to write rather than for computers to process. So it features all kinds of implicit actions and context sensitive approaches to the language and how it works. It's also an amalgamation of several preceding tools and ideas, and in that sense is almost an "English" of the programming world. Perl is almost more of a human language than a programming language, and like any other human language, once you learn it and some dialects it makes all kinds of natural sense. Even if you're away from it for a long time it comes back like a second language does and you're up and running really quick. It feels less like programming and more like you're having a conversation with your computer friend. Even small things that you get used to in Perl turn into huge pains in other languages, things like having regexes be a literal type (rather than trying to shoehorn the syntax into a string like in almost every other language) makes wanting to use them and using them second nature and really natural. Having a state machine you can type up in a few characters and be a first class citizen of the language is incredibly powerful. Perl 6 is supposed to take these ideas and expand on them, lots of clever new language constructs and first-class grammars are exciting new promising notions. It'll be like going from the language a child speaks to the language an educated adult uses. I'm concerned Perl 6 has missed it's window, but there's enough interesting stuff going on in the Perl 5 community and there's some really smart people working on it that I'm hopeful it'll be more than another language curiosity.
- zzzcpan 12y ago
  > It's almost anti-academic in the approach I'd say academic approach to programming languages is anti-scientific and therefore anti-academic on itself. They just don't realize it yet. > Perl 6 is supposed to take these ideas and > expand on them The problem is we already have lots of features in Perl 5 that nobody really needs, they just complicate things, raise entry cost, split community, make it impossible to address performance and deployment issues. So, approach on expanding feature set is flawed and frankly always was. Instead, Perl 7 maybe should get rid of all the unneeded features, restrict feature set, restrict coding conventions, make it easier for newcomers, make it easier for everyone to understand each other's code, make it faster, easy to compile and deploy without having to install interpreter and so on. These issues are much more important, than language features. And yet no one seems to understand that.

by tormeh 12y ago

What's supposed to be so great about Perl 6? I associate Perl with inscrutable cat-walked-on-the-keyboard programs and little else. Can someone in the know explain?

deleted 12y ago

[deleted]

Tepix 12y ago

You may want to read the Apocalypse documents ( http://perl6.org/archive/doc/apocalypse.html http://perl6.org/archive/doc/apocalypse.html ) and the Exegeses ( http://perl6.org/archive/doc/exegesis.html http://perl6.org/archive/doc/exegesis.html ). Perl 6 improves upon Perl 5 in countless ways. One of the strongest parts of perl, the regular expressions, have received further improvements. Check out https://en.wikipedia.org/wiki/Perl_6_rules https://en.wikipedia.org/wiki/Perl_6_rules Finally, if you are familiar with Perl 5, there's special documentation for you at http://perlgeek.de/en/article/5-to-6 http://perlgeek.de/en/article/5-to-6

progman 12y ago
> One of the strongest parts of perl, the regular expressions ... ... have been copied to Nimrod (now called "Nim") -- even with native C performance and native Perl syntax. http://nimrod-lang.org/re.html http://nimrod-lang.org/re.html Perl had its time and lost many of its users (including me) "thanks" to the inacceptable delay. Meanwhile the competitional advantage of Perl 6 is completely gone because many new features have also been implemented in other languages (Rust for instance), even in dinosaurs like Java and C++.
- raiph 12y ago
  PCRE wrappers like the module you linked don't give other langs the nice regex integration available in Perl 5, they just give them support for "Perl Compatible Regular Expressions" (hence PCRE), a rough equivalent of P5's regex functionality: http://en.wikipedia.org/wiki/Perl_Compatible_Regular_Expressions http://en.wikipedia.org/wiki/Perl_Compatible_Regular_Express... But PCRE is 1990's parsing technology. Who cares if Nim copies parts of P5 regex via PCRE? The page you linked says "Consider using the pegs module instead.". PEGs, invented in 2004, are more powerful than regex, PCRE ones or otherwise: http://en.wikipedia.org/wiki/Parsing_expression_grammar http://en.wikipedia.org/wiki/Parsing_expression_grammar Perl 6 has Perl 6 rules, a unification of PEGs, regex, and lexical closures, built right in to the language. There's nothing like them in Nim, Java, or C++. http://en.wikipedia.org/wiki/Perl_6_rules http://en.wikipedia.org/wiki/Perl_6_rules
  - progman 12y ago
    > There's nothing like them in Nim, Java, or C++. Are you sure? Nim supports direct access to the AST so macros can be used to define new programming constructs like in Lisp. Also other languages support things like that (as library), Java for instance: http://www.antlr.org/ http://www.antlr.org/ http://tunnelvisionlabs.com/products/demo/antlrworks http://tunnelvisionlabs.com/products/demo/antlrworks
    - raiph 12y ago
      > Nim supports direct access to the AST so macros can be used to define new programming constructs like in Lisp. Nim macros can't modify Nim's syntax. That constraint makes perfect sense for Nim but not Perl 6. > ANTLR ANTLR has switched from LL(star) parsing to what they call Adaptive LL(star) for v4. P6 Rules have been what Larry has called "LL(star) with kludges" (by which he means the same thing) for about a decade. So ANTLR has caught up with that aspect and indeed ANTLR v4 is nice tech. But P6 Rules are built in to P6. Its grammar is defined in P6 Rules. User code can modify the language on the fly by modifying the rules. Java (or whatever) + ANTLR is nothing like Perl 6 and Perl 6 Rules.
      - progman 12y ago
        > Nim macros can't modify Nim's syntax. Nim macros can extend Nim's syntax (additional "repeat ... until" for instance). They cannot change the built-in syntax of Nim. A macro system should never be allowed to change the core syntax of a language because that could lead to very strange errors. If Perl 6 is actually able to do that then it is a dangerous feature.

mike-cardwell 12y ago

explicit strong typing proper parameter lists active metadata on values, variables, subroutines, and types declarative classes with strong encapsulation roles full OO exception handling support for the concurrent use of multiple versions of a module extensive introspection facilities (including of POD) LL and LR grammars (including a built-in grammar for Perl 6 itself) subroutine overloading multiple dispatch named arguments a built-in switch statement hierarchical construction and destruction distributive method dispatch method delegation named regexes overlapping and exhaustive regex matches within a string named captures parse-tree pruning incremental regex matching against input streams macros (that are implemented in Perl itself) user-definable operators (from the full Unicode set) chained comparisons a universally accessible aliasing mechanism lexical exporting (via a cleaner, declarative syntax) multimorphic equality tests state variables hypothetical variables hyperoperators (i.e. vector processing) function currying junctions (i.e. superpositional values, subroutines, and types) coroutines lazy lists strong module and language versioning concurrent object pipes http://www.perl6.org/archive/faq.html http://www.perl6.org/archive/faq.html

perlgeek 12y ago
There's a reason this has "archive" in its URL :-) Rather consult this instead, which is maintained: http://faq.perl6.org/#features http://faq.perl6.org/#features
tempodox 12y ago
Is that “perl poetry” or does it mean anything?

thristian 12y ago

I'm not a Perl hacker, but there's one thing that I've wanted a bunch of times in other languages: Perl 6 does for PEGs (Parsing Expression Grammars) what Perl 5 did for regexes: they're part of the core language, you can execute Perl expressions when a PEG rule is matched, that kind of thing. In Python when I have some data and it grows just a bit too irregular for regexes, I have to start manually writing state-machines or add a dependency on a third-party library and spend an afternoon explaining parsing theory to my co-workers.

nly 12y ago
I want to see Perl 6 push the boundaries but the world isn't quite like it was when Perl 5 made using regex seemless. Competition is much more stiff. Even in C you can use something like Ian Piumarta's PEG generator[0] that let's you embed semantic actions written in C. For regular grammars, scanners and lexers you have powerful tools like Ragel[1] (which targets 7 languages) I'm not a Python person, so if the Python libraries proved inadequate I'd probably resort to these tools and then push out a Python module using Cyphon[2]. Personally I'm not a fan of using semantic actions for AST construction. I generally prefer the 'attribute' approach taken by libraries like Spirit (C++) which make the process feel a lot more like deserialization. SAs are still useful however for rejecting or accepting rules based on complex requirements (like "is this IP address routable"?). [0] http://piumarta.com/software/peg/ http://piumarta.com/software/peg/ [1] http://www.colm.net/open-source/ragel/ http://www.colm.net/open-source/ragel/ [2] http://cython.org/ http://cython.org/
- rurban 12y ago
  With perl6 the peg backend is built-in, so you can compile and execute grammars on the fly. A bit like lua's lpeg. A perl6 Grammar is a first-class object.
  - nly 12y ago
    Sure, but what happens when someone needs something other than PEG/recursive descent, like expression parsing with a custom precedence table? Will Perl6 add that to the core language as well? Where do you draw the line? LPeg is a library, Spirit X3 (for C++, not yet complete) is a library. Both achieve pretty seamless integration with your code. I think in a library is where this stuff should be.

lmm 12y ago

Perl was, in its day, a breath of fresh air. It had an emphasis on practicality that made easy things very easy: regex literals, default arguments like $_, minimal syntax overhead, with things that would be syntax in other languages hoisted to interpreter args (-e, that arg that means "run this as an awk-style loop"), and so on. More than that, the project worked as a holistic ecosystem, rather than just a language and some tools: these days every language has something like CPAN, but it was a huge innovation at the time. Perl also pioneered a lot of the unit-testing infrastructure that we take for granted these days; every project in CPAN was expected to have tests, using the same libraries, and they ran as part of the install process. A cynic might say that perl innovated here out of necessity; lacking static typing and not having VM isolation means good unit tests are a necessity. But still, the resulting infrastructure is very good, and some very solid programs are written in perl. In many ways I'd say it was the go of its day. The downside of the emphasis on practicality was that the language always suffered from incoherence; with no principled foundation it's been slow to adapt as the practical things users want to do change (e.g. I'd argue string manipulation is a lot less important than it used to be - if you were writing perl today, you might give json manipulation the same prominence as regexes). Perl 6 may have been an effort to fix this, but went too far in the opposite direction; overly formalized, with a premature separation between VM and language that massively slowed development. There's a lot of good stuff about modern perl - Moose and the like - but IMO it's too little, too late; other languages have been able to improve their infrastructure to (mostly) match perl for easy things. Meanwhile perl's incoherence makes it very hard to write large programs and solve hard problems, where languages with a firmer theoretical foundation and stronger stylistic principles have a huge advantage.

mst 12y ago
Every time I try to write ruby or python code, as soon as I need to write classes I realise just how much boilerplate they require compared to Moose and how depressing not having first-class attributes, method modifiers and roles is, and end up back writing perl5.
- fennecfoxen 12y ago
  As someone who has written both Perl and Ruby (in that order), you might be interested in this Ruby gem to alleviate at least some of those problems: https://github.com/solnic/virtus https://github.com/solnic/virtus

JonnieCache 12y ago

If you've ever enjoyed anything about ruby the chances are that it comes from perl.

skywhopper 12y ago
I'd put it a different way: Ruby stole all the useful syntactic shortcuts from Perl and ignored all the cruft and ugliness. Unfortunately the one thing Ruby didn't steal from Perl was its speed.
- sigzero 12y ago
  Hasn't that change in 2.X series?
  - JonnieCache 12y ago
    It's definitely a lot faster. I still wouldn't call it fast. Of course, most apps are I/O bound, objects in the heap are larger than they appear, blah blah blah.
untothebreach 12y ago
I think most of the good* features of Ruby came from Smalltalk, though you can definitely see the Perl influence. *at least for my definition of "good"
- JonnieCache 12y ago
  Indeed the object model is from smalltalk. I don't know why I didnt make that caveat.

oftenwrong 12y ago

>I associate Perl with inscrutable cat-walked-on-the-keyboard programs and little else. That's because Perl had a lot of "convenient" shorthand and quirks in the language that could be abused, leading to unreadable, "cat-walked-on-keyboard" code. However, that is just a stereotype. One could also force Perl to straighten its posture with a strict pragma, making much of the eccentricity disappear. I have worked on several large Perl 5 codebases that were/are clean and easy to understand and maintain.

bane 12y ago
Yeah, the default Perl is more of a slang dialect. Lots of implicit assumptions made about you, the language and your job. Once you turn on strict and use some common sense your code reads more like an school essay, but strangely is just about as easy to work in. Just like real languages have different modes to communicate in, Perl has it's own modes. I've worked on a couple large-ish Perl codebases too and with some decent code standard found them really easy to work on and extend.
- raiph 12y ago
  Perl 6 claims saner defaults. For the strict pragma, it's off by default for one liners and on by default for everything else. A much bigger relevant change is Perl 6's support for hygienic lexically scoped "slangs". These can be used to relatively cleanly package composable dialects, DSLs, language tweaks etc. Slangs make it practical for a group to establish a default local policy (policies include anything from switching some language tweak on or off to switching to another language entirely) and for an individual programmer to extend or alter that policy in a cooperative manner. Slangs aren't yet nearly as easy as they supposed to be, but they're getting there. A couple examples are v5 (which switches to another lang entirely) and Tuxic (a tiny idiosyncratic tweak to standard Perl 6): https://github.com/rakudo-p5/v5/blob/master/README.md https://github.com/rakudo-p5/v5/blob/master/README.md https://github.com/FROGGS/p6-Slang-Tuxic/blob/master/README.md https://github.com/FROGGS/p6-Slang-Tuxic/blob/master/README....

sigzero 12y ago

The Perl community really frowns upon that kind of code now.

bane 12y ago

Perl is a fundamentally different approach to language design. It's almost anti-academic in the approach and more linguistic. It's superficially like any other curly braced language but there was lots of thought put into how statements are constructed and making things easy to humans to write rather than for computers to process. So it features all kinds of implicit actions and context sensitive approaches to the language and how it works. It's also an amalgamation of several preceding tools and ideas, and in that sense is almost an "English" of the programming world. Perl is almost more of a human language than a programming language, and like any other human language, once you learn it and some dialects it makes all kinds of natural sense. Even if you're away from it for a long time it comes back like a second language does and you're up and running really quick. It feels less like programming and more like you're having a conversation with your computer friend. Even small things that you get used to in Perl turn into huge pains in other languages, things like having regexes be a literal type (rather than trying to shoehorn the syntax into a string like in almost every other language) makes wanting to use them and using them second nature and really natural. Having a state machine you can type up in a few characters and be a first class citizen of the language is incredibly powerful. Perl 6 is supposed to take these ideas and expand on them, lots of clever new language constructs and first-class grammars are exciting new promising notions. It'll be like going from the language a child speaks to the language an educated adult uses. I'm concerned Perl 6 has missed it's window, but there's enough interesting stuff going on in the Perl 5 community and there's some really smart people working on it that I'm hopeful it'll be more than another language curiosity.

zzzcpan 12y ago
> It's almost anti-academic in the approach I'd say academic approach to programming languages is anti-scientific and therefore anti-academic on itself. They just don't realize it yet. > Perl 6 is supposed to take these ideas and > expand on them The problem is we already have lots of features in Perl 5 that nobody really needs, they just complicate things, raise entry cost, split community, make it impossible to address performance and deployment issues. So, approach on expanding feature set is flawed and frankly always was. Instead, Perl 7 maybe should get rid of all the unneeded features, restrict feature set, restrict coding conventions, make it easier for newcomers, make it easier for everyone to understand each other's code, make it faster, easy to compile and deploy without having to install interpreter and so on. These issues are much more important, than language features. And yet no one seems to understand that.