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?
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.
Aiui Larry Wall believes it will be significantly easier for Perl 6 to evolve than for Lisp to do so, without falling in to the Lisp Curse trap.
IMHO, it was coherent. But the syntax is wierd (may be usage of symbols $%@{}[] ) for people unfamiliar with it.
I haven't done big projects with perl in the last 12 years. But when I need it, it is like riding a bike.
I'm really afraid that Rails is going the same way, that the DRY mantra is going to eventually lead to a Huffman encoding only parseable by Rails experts, and then no one new will want to get on board.
I have some issues with Ruby "helpfully" letting you leave out more and more syntax, like parentheses from multi-argument function calls, or saying you don't need {} if the last argument is a hash, which are easy to grok if you already know Ruby but can be yet-another-confusing-rule for newbs. But those are relatively minor.
as far as the hash, you can always inspect the actual arguments being passed, which doubles as a nice learning exercise for beginners.
Most of Perl 5's syntax comes from well established (for perhaps a decade) UNIX culture, from shell, awk, sed, and C syntax conventions. Vanishingly little is actually novel to Perl.
Rails, which is obviously not a peer to Perl, but which you bring up as "going the same way," does similarly have a huge emphasis on convention. But most of its conventions are de novo, made up within the Rails/Ruby community.
You can hate Perl (5) all you like; no accounting for taste and all. But if you find parts of it unfamiliar, it's probably because you are ignoring (or ignorant of) where it came from.
* $_ means "it" * @_ means "args" * $! means "current exception/error" * $/ means "last match" * $0 means $/[0], the first captured value of the last match
All other system variables have understandable English names, eg:
* $IN means the STDIN object/handle $OUT means the STDOUT object/handle %ENV means a hash (dict) of system environment variables $PID means the system process id $*KERNEL means the operating system kernel running under
Etc.
Standard Perl 6 has just these non-English variables:
- $_ means "it"
- @_ means "args"
- $! means "current exception/error"
- $/ means "last match"
- $0 means $/[0], the first captured value of the last match
All other system variables have understandable English names, eg:
- $IN means the STDIN object/handle
- $OUT means the STDOUT object/handle
- %ENV means a hash (dict, associative array) of system environment variables
- $PID means the system process id
- $*KERNEL means the operating system kernel running under
Etc.
Similarly (same laptop), I can get perl to print its version (5.16.2) in about 0.01 secs (2nd time), but java (1.8.0_11-b12) takes about 0.11 secs (2nd time).
Most of my work is in Java, but it gets to be a tyrannical hammer that must be used for everything in some minds :-(
Again: Parrot having to compete with the JVM makes me sad.
Even with the MoarVM backend, Rakudo takes a lot more time and RAM to startup than the compiler for most mainstream languages. It handily beats the JVMs devs use but that's not saying much.
On the third hand, a few devs have said they are regularly using Rakudo at $work, including for one-liners.
If anyone wants to try P6 I recommend RakudoBrew:
> Meanwhile perl's incoherence makes it very hard to write large programs and solve hard problems ...
I've been on teams writing very large systems solving very hard problems in Perl 5 for more than 20 years. I know that some of that stuff that was written in the 90s is still under active development and maintenance today, even though it's several developer generations in the past.
Perl 5 may or may not be 'incoherent'. It is certainly somewhat idiosyncratic. But so is JavaScript, perhaps to a lesser degree.
Perl 5 in the large requires some somewhat different (but not too difficult) disciplines.
But that's not so different than most other languages.
> In many ways I'd say it was the go of its day.
This made me smile! Thank you again.
I think if "it's not a lot worse than Javascript" is the best you can say in its favour...
> Perl 5 in the large requires some somewhat different (but not too difficult) disciplines. But that's not so different than most other languages.
The problem I always saw was that libraries would follow their own styles, so once you had a project that depended closely on several different libraries you'd be forced to cut against the grain of several of them. It's a problem that's lessened in a language with a single standard way of doing OO, a single standard way to do event-driven I/O, or even trivial things like code formatting. Maybe the perl community has found more of a consensus in recent years.
Nowadays I work almost completely in scala, which some people compare to perl, so I'm concerned about not repeating perl's decline in popularity.
The Perl 6 language design directly addresses this problem. The intent is to avoid throwing out the baby (making both timtowtdi and long term language evolution practical) with the bath water (lack of composability of the various ways to do things and of new features that emerge). The Rakudo implementation is most of the way there.
I also think the Parrot VM project added a few years to P6's gestation.
When you say "overly formalized", perhaps you mean the early break out of mailing lists and especially the Parrot project? I don't think "overly formalized" fits the last decade of Perl 6 development -- Pugs (2005 - 2007) was distinctly anarchistic.
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.
> It's almost anti-academic in the approach
> Perl 6 is supposed to take these ideas and
> expand on them
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.
($v1, $v2) =~ /a(b|c)d(e)/;
[1]: http://en.wikibooks.org/wiki/Perl_6_Programming/Grammars
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
Rather consult this instead, which is maintained: http://faq.perl6.org/#features
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.
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/ [1] http://www.colm.net/open-source/ragel/ [2] http://cython.org/
A perl6 Grammar is a first-class object.
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.
The grammar is just a special class with the rules as methods, so rules with non-standard parsing logic can be implemented using Perl 6 code. Reusing standard rules from custom rules is simply a matter of calling the corresponding method.
The best example of this is probably the EXPR rule in the NQP compiler (which is in turn used by Rakudo's parser), which inserts an operator precedence parser into the recursive descent of the rest of the grammar.
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.
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.
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/FROGGS/p6-Slang-Tuxic/blob/master/README....
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
Finally, if you are familiar with Perl 5, there's special documentation for you at http://perlgeek.de/en/article/5-to-6
... have been copied to Nimrod (now called "Nim") -- even with native C performance and native Perl syntax.
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++.
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
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++.
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:
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.
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.
Unfortunately the one thing Ruby didn't steal from Perl was its speed.
Of course, most apps are I/O bound, objects in the heap are larger than they appear, blah blah blah.
*at least for my definition of "good"