Perl 5 has certainly paid the bills. I have taught it to hot-shot C programmers and mainframe Cobol programmers alike in a community college.

Perl 5, by any modern standard, is, at best, a 'quaint' language.

Perl 6 is literally everything I wanted Perl 5 to be. The incremental data typing is very exciting. The regular syntax is going to make it even easier to teach. And there are so many other well considered and awesome features.

And I just get giddy when I think of the amazing things that really smart people are going to make with Perl 6. It's powerful from the top of its head to the bottom of its feet. And I think that it's going to be a very fast language too.

Thank you, Perl. Thanks to the many people who have made it possible. May my 13+ years of high hopes not be in vain!

Would you say people like me should be looking hard at Perl 6? I'm curious what the benefits would be.

Assuming you are akin to 'Jill Sysadmin' or 'Joe Devops', I would honestly say that Perl 6 won't be more compelling than Perl 5 for a while.

And, by the way, Perl 5 has grown enormously in the past 10 years. I would say that if you haven't taken a look in a while, give it another shake.

I honestly struggle to imagine the really cool things that will start to come out of Perl 6 acceleration. It has some really novel concurrency concepts, far more interesting than goroutines, for instance.

And once again, I believe Perl 6 will turn into a very fast language.

this. I can hack a bit in Perl 5, but "modern Perl" is virtually a unique language that just so happens to be written using the same words I use. I haven't had a chance to really learn modern practices, I keep telling myself I'm going to sit down and do it, but I haven't had a chance. But what I've seen is really pretty different than what I grew up with.

It's pretty amazing.

Very exciting.

(Wait, or is this the plot of Phantom of the Opera? I'm bad at musicals.)

It would be so nice to have easy threads in this language.

http://irclog.perlgeek.de/perl6/2014-11-05#i_9617218

[1] https://github.com/TimToady

I'm working on it for a week already and cannot promise to be finished until Jan 31, 2015.

But the other 2 backends, jvm and moar, are doing fine.

But on the other side I just fixed the GC bug, so it looks good now even on parrot.

However, Linux on the Desktop (almost) already had its time, and it passed. It was around 2009, Ubuntu was at its pinnacle, it was the time of Compiz and Gnome 2 and transparent terminals and themes and whatever. A lot of my (non-technical) friends were suddenly interested in Linux (well, distros of GNU+X11+Desktop Environment+Free/Open Source applications). This was a free alternative to Windows, better than Vista or XP, actually easier to use for many tasks ("I can't believe that it is so easy to install new fonts, I never knew how to do that on Windows"). This was before all of the experimentation (Gnome 3, Unity, ...) that, while in principle a good thing, the way it was executed effectively killed the old lineages (Gnome 2). When it comes to languages: Python 2.7, and on-topic: Perl 5. This was also before all the annoying in-fighting for mostly political reasons (systemd cough but there are many more examples). I don't know whether politics is an issue for Perl.

But that there is no golden way of transitioning to a new version in the FOSS world definitely is a problem that is harming so many projects.

You find this on the kernel level, where old and new APIs sit side by side. But higher up it seems like egos override pragmatism. Or "perfect is the enemy of good".

http://www.themukt.com/2014/10/30/china-will-uprade-pcs-linu...

Long time GNU/Linux user since 1995.

With a bluetooth keyboard and mouse I could work much more comfortably than with the exact same hardware running Cyanogenmod. Being able to do Perl/Ruby development and run a real RDBMS is possible on Android, but it's not natural. When webOS came out GUI was also more pleasant than Android or iOS for a lot of things and definitely better at multitasking, but they couldn't compete in the market. Luckily some of the webOS UI folks ended up at Google and Apple (and some had come from there), so things like the Android notification system benefited.

Perl has cpan but I think the Perl community is really small, the great exodus happened long ago. Perl can make you feel as a real hacker, also J, but cryptic syntaxes is no longer buying you anything.

How can anyone seriously take any credibility to a calendar when Perl 6 has been delayed for ever.

Perl 6 is not the gift that Perl 5 was hoping to receive, Perl 6 is a modest advance not a revolution.

Today, now, we need much more. I wish Perl 6 the best, but I doesn't believe it will gets much traction.

Edited: Grammar. Summary: Too little, too late, there is no longer confidence.

Perl built an awesome foundation because in the beginning, that was all there was so you had 1000's of regular contributers to the core and cpan. I don't think any language will ever see that kind of activity again.

Perl6 has a lot going for it though. I believe with its new OO system, concurrency similar to Go, and the ability to compile to a binary, might take this new language to places where Ruby, Python, Perl5 can't go.

And in the similar perl5 fashion, it will be the programmers and not the corporates that own it. Therefore one is only limited by their imagination and not their pocket book.

Because NPM (for Node.js) has a cool way to browse the recent updates at 100/page at https://www.npmjs.org/browse/updated and so far today over 500 modules have been updated.

We live in a much bigger world than Perl was, so that's not surprising. The huge trouble is that these hackers don't talk much to each other.

http://act.yapc.eu/ye2014/talk/5704

https://www.youtube.com/watch?v=enlqVqit62Y

(He mostly talks about his travels.)

Correct. That's why Debian is not in this list of Free GNU/Linux Distributions: http://www.gnu.org/distros/free-distros.html

The policy is if the official repos have non-free software. You can always install non-free on any of the FSF listed distros also. Also I think the world has moved past FSF when you just look at the distro names. Very small communities.

When Python 3 came around, I thought it was a good idea and that everyone would want to migrate as soon as possible. What we got instead is 3 more parallel installs of language versions. Beside Py-2.7 (which will apparently never go away), you will need Py-3.3, 3.4 AND 3.5 because every project wants a different one. Why would anyone want the same drama with Perl?

So you took a 'quick' look at the massive Perl 6 specification there is and already made decisions over it.

>>I don't see why anyone would bother.

A great deal of the programming world still runs on Perl. That includes the Internet itself. Plus a whole lot of new Perl projects are started everyday. There are companies which have pretty big Perl code bases running in production. And Perl has one of the most biggest following any language can boast of.

I am sure there are several who wouldn't just bother but use it do all kinds of awesome stuff.

>>Why would anyone want the same drama with Perl?

Because Perl 5 and Perl 6 aren't even the same languages. Python 3 was a just print statement and a for loop refactor over Python 2. The reason why there was so much friction in Python adoption was no one saw why they were supposed to deprecate a whole code base just for a print statement and a for loop.

Perl 6 is a whole new language, Only retaining some of its Perl 5 roots. Apart from these, they are two different languages in their own regard. No one is going to rewrite Perl 5 applications in Perl 6.

Some cool libraries and framework ideas from the Perl 5 world are going to seep into Perl 6 but that is that. For nearly all the cases there are Perl 6 is going to be used for new projects.

Meanwhile Perl 5 is developed and maintained at a good pace and will be continued to. Perl 5 and 6 will co exist, neither will go away. Unlike Python's case, where the 2.x cycle won't be developed and maintained anymore.

Yet they lie at the very heart of what the language is, to many people -- to such an extent that to do without them in Perl 6 would have violated one of the key design principles from its earliest days: "Perl 6 should still be Perl."

"Overuse" is subjective. If you are you suggesting that some use is good, can you give an example of usage you think is good and usage you think represents overuse?

That said, I didn't like some specific things about use of symbols in P5 and the problems have been fixed in Perl 6.

And of course there is more than one way to do it, for example this is one way to write the Ackermann function in P6 using Unicode names (symbols) for parameter/argument identifiers:

proto A(Int \𝑚, Int \𝑛) { @[𝑚][𝑛] //= {} }

multi A(0, Int \𝑛) { 𝑛 + 1 } multi A(1, Int \𝑛) { 𝑛 + 2 } multi A(2, Int \𝑛) { 3 + 2 𝑛 } multi A(3, Int \𝑛) { 5 + 8 * (2 𝑛 - 1) }

multi A(Int \𝑚, 0 ) { A(𝑚 - 1, 1) } multi A(Int \𝑚, Int \𝑛) { A(𝑚 - 1, A(𝑚, 𝑛 - 1)) }

(Based on http://rosettacode.org/wiki/Ackermann_function#Perl_6)

  proto A(Int \𝑚, Int \𝑛) { @[𝑚][𝑛] //= {} }

  multi A(0, Int \𝑛) { 𝑛 + 1 }
  multi A(1, Int \𝑛) { 𝑛 + 2 }
  multi A(2, Int \𝑛) { 3 + 2 𝑛 }
  multi A(3, Int \𝑛) { 5 + 8 * (2 𝑛 - 1) }

  multi A(Int \𝑚, 0) { A(𝑚 - 1, 1) }
  multi A(Int \𝑚, Int \𝑛) { A(𝑚 - 1, A(𝑚, 𝑛 - 1)) }

Now on a more serious note, the perl community has always had a goal of backwards compatibility. When was the last time you heard someone having to update their perl5 interpreter to get something to work? Perl6 will be similar I assume, it can even in a limited way run perl5 code.

I've stuck with perl through the years just because of this. So you use perl to avoid those same issues you speak of.

I'm curious what limits you are referring to.

(Are you aware of https://github.com/niner/Inline-Perl5?)

Just to be clear for any others reading along:

* One can run (a subset of) Perl 5 code directly on any of the Rakudo backends (thus even on the JVM) by using v5, a Perl 5 compiler written in Perl 6.[1] I think it will be many years, if ever, before v5 parses all of Perl 5 and becomes a good choice for running arbitrary legacy Perl 5 code without tweaks, but it's probably going to be a key piece of technology bridging to Perl 5 in 2015. In particular, there's been talk recently of combining it with Inline::Perl5, discussed next, to provide improved sugar for P5 <-> P6 combinations.[2]

* Any host that can run arbitrary C code can run just about any Perl 5 code (including modules that use XS) via libperl, an embedded version of the stock Perl 5 interpreter. Inline::Perl5 uses this approach to allow the Rakudo Perl 6 compiler to run P5 code under P6 control without significant limitations. Inline::Perl5 allows one to pass P5 objects to P6 code that can then alter said objects and pass them back. And vice-versa, with P6 objects passed to P5 for manipulation back in P5 land. One can also create P6 sub-classes of P5 classes, thus using P6 code to tweak or extend P5 code. This already works out-of-the-box for Rakudo Star with the MoarVM backend; it's just a SMOP to make it work likewise for other backends.

(There are other nice pieces related to having P5 and P6 work together, but this is already a long comment.)

[1] https://github.com/rakudo-p5/v5

[2] http://irclog.perlgeek.de/perl6/2014-10-12#i_9494778

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.

> 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.

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.

http://moarvm.org/

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:

https://github.com/tadzik/rakudobrew

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.

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.

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.

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.

* $_ 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.

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.

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.

  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.

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

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++.

http://en.wikipedia.org/wiki/Perl_6_rules

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://tunnelvisionlabs.com/products/demo/antlrworks

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"

It took 6 years for Python 3 to reach a decent level of usage and recognition (http://python3wos.appspot.com/), and that was with mostly minor language changes.

Perl 6 has been 14 years in the making and still doesn't have a stable version. Mindshare will be very hard to come by at this point.

Perl 6 is drastically different from Perl 5 (though clearly in the same lineage). Not only the language is quite different, but so is the design of the implementation.

So it's not much comparable.

Small changes = slow adoption.

Large changes = ?

While this does not apply to every situation, unless Perl 6 somehow manages to create a huge wave of hype, I'm not going to bet on it :)

I'm not convinced having all the features will do it, but there are certainly a lot of things to like about Perl 6. It is among the most powerful languages on nearly every axis I can think of.

Most English devs have no idea just how bad things are with current langs.

A quick experiment.

First, translate "Practical" in to Thai: ปฏิบัติจริง (https://translate.google.com/#en/th/Practical)

Next, see Unicode Inspector: (http://apps.timwhitlock.info/unicode/inspect?s=ปฏิบัติจริง)

Note that ปฏิบัติจริง is 9 somethings or 11 something elses.

Finally, move the cursor along the "characters" in either google translate's output field (it's fiddly but works if you are patient) or the Unicode Inspector.

Note that there are SEVEN movements.

What sort of elements are these cursor movements moving over?

Graphemes.

There aren't 7 Code Points. Or 7 Code Units. Or 7 Bytes.

There are 7 Graphemes.

Graphemes are defined in the Unicode consortium's glossary as "What a user thinks of as a character."

http://www.unicode.org/glossary/#grapheme

There really couldn't be a more fundamentally important aspect of text processing for half the planet than dealing with text at the grapheme level ("what a user thinks of as a character") BY DEFAULT, unless the dev wants to do tricky stuff.

But almost all current langs (including Python 3.x) get this stuff terribly wrong in all sorts of ways.

Perl 6 takes graphemes seriously.

From Synopsis 15 (https://raw.githubusercontent.com/perl6/specs/master/S15-uni...):

* Perl 6 by default operates on graphemes

* Perl 6, by default, stores all strings given to it in NFG form, Normalization Form Grapheme. It's a Perl 6-invented character representation, designed to deal with un-precomposed graphemes properly.

* The Perl 6 C<Str> type, and more generally the C<Stringy> role, deals exclusively in NFG form.

* By default regexes operate on the grapheme (NFG) level, regardless of how the string itself is stored.

So, as far as graphemes ("what a user thinks of as a character") are concerned, Perl 6 gets this basic aspect of text processing right when almost all others get it terribly wrong.

(There are a couple other langs that seem to have made an effort to take graphemes seriously enough. For example, the .length function for strings in Elixir (related to Erlang) returns the count of graphemes by default. And a few like Clojure take graphemes seriously, just not seriously enough.)

So, a significant and rapidly growing chunk of the planet's programmer population are likely to end up interested in at least playing with P6 to see if it gets this bit right (and they'll find it does).

Perhaps in specification, the feature comparison matrix suggests that NFG is Not Yet Implemented in any implementation in practice:

http://perl6.org/compilers/features

I wonder if that "significant and rapidly growing chunk of the planet's programmer population" will find that an untested and partially implemented feature suffices for their needs in the real world.

Since then, our clients have been using Python, Groovy and Powershell code for the same set of tasks.

What does that tell us about the state of the industry? Exactly nothing.

If so, what for? General scripting tasks?

It was on a corporation that was replacing their HP-UX/Perl/C++/CORBA infrastructure with JEE/Java/Red-Hat Linux.

The new sysadmins (newly grads) just started replacing the existing, battle tested Perl scripts with Groovy ones.

The only reason pointed out was that they couldn't grok Perl.

As for its use in general, here in Germany it seems to have been replaced by Scala/Clojure.

When Rails was hype, the JUGs around my area used to be full of Grails and other Groovy related sessions. Nowadays it seldom comes up in the agenda.

Overall, use Groovy

* if you're still using Grails

* for quick scripts that your certain won't need to scale

* in Gradle but stick to the DSL syntax

It's literally:

GParsPool.withPool { def result = [1, 2, 3, 4, 5].collectParallel {it * 2} }

Why oh why people still torture themselves with pure Java.

  [1,2,3,4,5] X* 2

Customer requirements.