Hacker News new | past | comments | ask | show | jobs | submit login
Perl 6 Introduction (perl6intro.com)
192 points by bane on Nov 28, 2015 | hide | past | web | favorite | 105 comments



I've got to say, perl6 is really, really fun to play with. (and I say this as someone who had not used perl before)

So far I've gotten the impression it's made by a bunch of smart, friendly hackers who care about quality in their software.

To anyone reading this, I'd strongly recommend casting aside any preconceived notions about perl and giving perl6 an honest shot.


I'd like to take perl6 for a spin. However, other than playing with it I'm not sure how it compares to say python or ruby in terms of strong sides. I mean what are the cases perl6 would shine in comparison? (NOT TO FLAME! I'm asking for ideas to when perl6 would be an interesting tool for the job. AFAIK it had a good string manipulation ~ also I'm still reading the tut and currently it feels very bash and somewhat ugly (although helpful) with the % & @ prefixes).


A few upsides I perceive:

- optional, well-integrated gradual typing system.

- perl6 is the first mainstream(ish) dynamic language to not suffer from a GIL of some kind. You can do real concurrency and parallelism in perl6.

- perl6 is both equally as powerful, and much more simple than previous versions of perl.

- a bunch of good ideas stolen from other languages. go-routines are in there, pattern-matching, gradual typing, classes, etc. Plus, functional programming is a first-class-citizen of perl6. There's so much good stuff in there.

- overall, I think perl6 has the potential to become a very powerful (and yet robust and well engineered) hacker language, where you will not be constrained by implementation details of the VM the language runs on (I'm looking at you, GIL).

I'd also recommend reading Curtis Poe's answer to a similar question:

https://www.quora.com/Perl-programming-language-1/Should-I-b...


> - perl6 is the first mainstream(ish) dynamic language to not suffer from a GIL of some kind. You can do real concurrency and parallelism in perl6.

I went digging to try and understand what this meant, and seems it's referring to syntactic support for promises, which in at least the Rakudo implementation amount to a wrapper around a forking multiprocessing system (like the Python multiprocessing module).

From my perspective this concurrency isn't any more "real" than equivalents available in existing languages, but maybe I'm looking at the wrong thing - you mention global interpreter locks, and usually they refer to threading.

Does some implementation of perl6 have non-GIL threading?

edit: from <https://perl6advent.wordpress.com/2012/12/11/day-11-parrot-t...:

> The solution for these problems implemented in hybrid threads is to sidestep them altogether by disallowing write access to shared variables. The programmer (or in most cases the compiler) is obliged to declare a list of all shared variables before a newly created task is started. The interpreter would then create proxy objects for these variables which the task can use to access the data. These proxies contain references to the original objects. They use these references to forward all reading vtable functions to the originals. Write access on the other hand would lead to a runtime error.

> In other words, all data is owned by the thread creating it and only the owner may write to it. Other threads have only read access.

> For threads to be able to communicate with their creators and other threads, they still need to write to shared variables. This is where green threads come into play. Since green threads are light weight, it is feasible for a thread to create a task just for updating a variable. This task is scheduled on the interpreter owning this variable. To reduce latency, the task is flagged to run immediately. The data-owning interpreter will preempt the currently running task and process the new write task. Put another way, the data-owning interpreter is told what to write to its variables, so other threads don’t have to.


Hi. That blog post refers to parrot vm threads, which is not what the current MoarVM or JVM implementations use. Both these VMs support 'real' OS level threads without any global locking (beyond what is needed for GC). In case of MoarVM, that support is built on libuv. And there is a very interesting high-level interface built on these fundamentals.


Libuv is what node.js is built on, and I've seen some benchmarks of really impressive performance w/r/t MoarVM.[1]. https://github.com/perl6/mu/blob/master/examples/concurrency... Here is how "real" (i.e., not fake, spawn processing) concurrency is done in Perl 6.

Rakudo's had more testing since it's been around forever but MoarVM is where my hopes lie. Here's hoping user adoption isn't fractured that badly like D's Tango vs Phobos debacle (which only now it's recovering from, I'd argue largely due to Andrei Alexandrescu's charismatic persona, haha.) Perl 6 is a really interesting language and I'd encourage you all to play with it, but it's an entirely different beast than Perl 5. They should have just renamed it entirely.

[1] http://www.moarvm.org/features.html


"Rakudo's had more testing since it's been around forever but MoarVM is where my hopes lie" is a little confusing to me. Rakudo and MoarVM are not the same type of thing. Rakudo is a Perl 6 compiler with multiple backends. I don't follow this very carefully, but I think it used to have a Parrot backend, and currently has two maintained backends: one for the JVM and one for MoarVM.

Is that wrong? If not, did you mean "Rakudo on Parrot" or "Rakudo on the JVM" when you wrote just "Rakudo"?


Rakudo is an implementation of Perl 6 built on top of NQP (Not-Quite-Perl. a pseudo lang that implements the easier parts of Perl 6 that can be targeted and optimized by VMs), and MoarVM is a C-based NQP interpreter. There is also an NQP back-end for the JVM, which is now Rakudo runs on the JVM. Think of NQP as an intermediate language (kind of like java bytecode but much higher level).

It's like this: Rakudo -> NQP -> MoarVM

or like this: Rakudo -> NQP -> NQP-JVM implementation -> JVM

Want to get Perl 6 running on the .Net CLR? Implement an NQP interpreter (which is supposed to be fairly easy) and you're 99% done (at least that's my understanding).


Strictly speaking, MoarVM is not an NQP interpreter - it runs MoarVM bytecode.

Sure, MoarVM is by design semantically close to NQP, but if you look at

    $ nqp-m --stagestats -e ''
    Stage start      :   0.000
    Stage parse      :   0.003
    Stage ast        :   0.000
    Stage optimize   :   0.000
    Stage mast       :   0.005
    Stage mbc        :   0.000
    Stage moar       :   0.000
you get mostly the same steps as on the JVM

    $ nqp-j --stagestats -e ''
    Stage start      :   0.000
    Stage classname  :   0.045
    Stage parse      :   0.067
    Stage ast        :   0.000
    Stage optimize   :   0.009
    Stage jast       :   0.145
    Stage classfile  :   0.010
    Stage jar        :   0.000
    Stage jvm        :   0.003
except that MoarVM bytecode files do not get bundled into JARs and there's no need to do the extra processing that happens in the 'classname' stage.


Fair enough. MoarVM is just another interpreter targeted, but it just happens to have been designed with NQP and Perl 6 in mind, so it maps extremely well.


GIL stands for the Global Interpreter Lock, which python has been criticized for a lot. I don't know whether perl5 or other languages have one, really.


> GIL stands for the Global Interpreter Lock, which python has been criticized for a lot.

It's pretty clear the GP knows what a GIL is, he's wondering if Perl 6 is truly GIL-free, or if it "just" abstracts out the GIL using language primitives for a forking multiprocess system (already, that's a nice step, but it's not "GIL-free").

I'd like to know the same thing.


(Side remark: it seems the comment has been edited, expanding it a lot. It was not clear to me initially. And anyway, it is good to have acronyms expanded for other readers.)


To be fair the GIL is only an issue if you are doing CPU bound thread-based parallelism in Python. There are way to do real parallelism in Python, for example via several processes.


Parrot VM hasn't been supported for quite some time. I'm pretty sure that it's been mostly abandoned.

The current VMs are MoarVM, JVM, and some are working on a JavaScript backend.


Has the Parrot VM project been abandoned, or just Perl 6 support for it?


A little of each, and technically neither.

Parrot isn't wholly abandoned, but Reini Urban is the only person still hacking on it. On the other hand, he is the person most likely to bring Parrot back around to being a good backend for Perl 6, so it has that going for it.

Currently no implementation of Perl 6 targets Parrot. Rakudo used to (indeed, was born on Parrot), but suspended support for Parrot in connection with the push to get Rakudo-on-MoarVM up to 6.0.0 quality by Christmas. The Rakudo team were careful not to say they were writing Parrot off, but they also gave no particular criteria for when they would unsuspend it.

(I in no way speak for Rakudo or anyone else, but I suspect the implicit criteria for unsuspension are three: Parrot must demonstrate, in code, that being a good backend for Perl 6 is a higher priority than being a good backend for entirely hypothetical other clients; it must undertake, survive, and complete a major decrufting if not re-architecting; and of course, it must be more interesting, for enough people, to target Parrot than to hack Perl 6 on Moar, JVM, JS, Mono, the perl5 VM, p2, WebAssembly, native code, the Factor VM, or whatever else.)

There are also those who view MoarVM as the new Parrot -- Parrot as it would have been if its implementation hadn't started until it was clear what Perl 6 would really need under it. (Aaaaaand without the technical or political fallout of "let's make a VM for ALL the dynamic languages!")


Hm. Your opinions don't match my recollections.

Aaaaaand without the technical or political fallout of "let's make a VM for ALL the dynamic languages!"

I remember Larry being really keen on that idea. The quote went something like "If everyone complains that CPAN gives Perl an unfair advantage, let's give everyone access to CPAN."

http://www.perl.com/pub/2003/07/16/soto2003.html


I didn't say Larry wasn't keen on a multi-language VM in 2003.[1] I said that Parrot's pursuit of that goal contributed to (an intricately braided series of) technical and political conflicts with Rakudo, culminating in a breakdown of relations between them across 2013-2015.

Why would I think that? I am aware of your recollections. I have read everything you blogged about the collapse of Parrot.

I have also read everything several other people wrote about the inception of MoarVM and the suspension of Parrot support, including key figures from both sides and several third-party observers. I have read the IRC logs of Parrot design meetings, including negotiations with the Rakudo leads, for the period leading up to the rupture. I have read key announcements by Parrot and Rakudo lead designers from earlier than this, wherein I think I see the seeds of the breakdown sown.

I made a detailed study of all this last spring, when I learned about the suspension. I have also been checking in intermittently on Parrot since 2002, and on every Perl 6 implementation I could find since the post-Pugs revival. And since last spring I have been kept aware of your position in particular through sundry comments here and on Reddit; you are a reliable presence whenever someone mentions Perl 6 or Rakudo without condemning it.

I can't speak to specific differences between my opinions and your recollections, since you did not see fit to say what those were. But I am hardly uninformed and I know of no error in what I said (viz., the actual words that I typed).

[1] If I wanted a document to make my point for me, I could hardly do better than the 2003 State of the Onion. Here's where Larry's head was in 2003: Yes, he thought a multi-language VM was just what Perl needed. He also thought that the Perl 6 design was basically done. He clearly didn't think there would be too much difference in kind between Parrot and the p5p runtime, as shown by his speculating that Ponie could be ready to support 5.10 and could entirely replace p5p by 5.12. He had not yet written the Apocalypse on the object system; its release in 2004 is really when it became clear how deep and structural the changes from 5 to 6 would be, and consequently it's also when it really became clear what a VM would need to provide to be good for Perl 6. Heck, in 2003 Larry thought "slow progress" meant a couple of major redesign documents a year, and he thought slow progress was just coming to an end. About the only thing that address was right about is that Larry didn't know very much. (Well, that and the switch statement.) If I'm saying reality disproved early conceptions about the realization of Perl 6, SotO 2003 is Exhibit A.


I made a detailed study of all this last spring

I think that's part of the problem--there are too many post-hoc justifications for why things happened the way they did that ignore what actually happened and why people made the decisions they did.

Dan's Parrot postmortem is still accurate: there just wasn't the will to turn P6 into a real, stable, shipping product, and there wasn't the honest acknowledgement that P6 wouldn't be a realistic replacement for Perl until far too late.


I studied what people said, at the time they decided, about what they decided and why, and I studied the environment in which they decided it. I'm not sure how that adds up to buying into someone's post-hoc justification. But you're welcome anytime to stop merely announcing that you disagree with me and explain what about. I will not belabor that invitation further.


> - perl6 is the first mainstream(ish) dynamic language to not suffer from a GIL of some kind. You can do real concurrency and parallelism in perl6.

Admittedly, not everyone would define it as mainstream... but Tcl doesn't have a GIL and has had threading for a good, long time.


> - perl6 is the first mainstream(ish) dynamic language to not suffer from a GIL of some kind.

GILs are features of implementations, not languages; Ruby has implementations (most notably JRuby) without a GIL. And Clojure doesn't have a GIL, and seems to be approaching mainstream.

And Perl 6 isn't mainstream yet (it hopes to be, but then so do most languages.) And there's plenty of not-currently-mainstream dynamic languages without GILs in their primary implementations; many in the Lisp/Scheme family.


Let's not forget what perl was created for; it's a practical extraction and report language.

Initially it was used to extract tables from text documents, and its always had a strong focus on text manipulation and regular expressions.

Its implicit variables and syntax mean you can write very, very concise code. Yet by following stylistic guidelines of your choice, you can write code that looks sane and maintainable.

I really like the fact you can import os commands and call them as a part of the language. It makes writing scripts a breeze. In fact writing anything in perl is a breeze. Check rosetta code, you'll see Perl 6 is one of the most concise at every turn.

As much as I really like python, I find that calling system commands is a pain.. calling os.system is obviously far from great, and calling subprocess can get cumbersome.

I haven't played with perl in a while, but my past experiences with perl was always getting a lot done, with very little work.


Just to note that it's not all puppies and unicorns. There are a lot of low-level commands that are all tied up in different modules in Perl. Like having to remember where what you want falls into the File::* namespace... or maybe what you need is in Cwd.

I worked with Perl for 4 years, and while it's not the gauntlet of pain that people make it out to be, there were several annoyances (like needing to always hit the docs for that stuff).


The biggest problem I have programming Perl 5 is discovery of what the best current module is to get past the pain points of the past, and the best way I know of that is to keep current with community discussions. E.g. Path::Tiny is awesome for automating a lot of the file ops you could want to do into one simple, useful, well structured place. As soon as you're exposed to it, you'll immediately want to scrap the use of 3-4 other modules you might have been using in lieu of it. What's the best way to learn about it? Possibly reading Perl community blog posts. It's unfortunate, but with a couple decades worth of modules on CPAN, it can be hard to find the gems of the bunch without some help.


That's what the mstpan posts on http://shadow.cat/blog/matt-s-trout/ are for; I'll be doing more starting Dec 1.



Yeah, I'm aware of Task::Kensho (although I forget about it all too often). But even that is at this point more a point-in-time snapshot of what was relevant a year or two ago. In most cases, they are still relevant and some of the best choices, but there are new items that aren't on the list (e.g. Path::Tiny) that I would argue really should be.

I understand it's a trade off. We don't have a large standard library in Perl like Python does, and that means there's a bit of searching required to find what to use, but that's often a benefit as well as a drawback. Would we have Path::Tiny if we had something that provided some but not all of the capability, and not as well? Would we have DateTime (or would it be popular) if we had a core DateTime-like module that was problematic, but mostly worked? Part of the beauty of having a small core set of libraries and an large and vibrant set of extended libraries is that the constant churn leads to newer and better things. Really what I'm lamenting, is that while there are these benefits to the churn, it still does lead to some painful situations where you find you've been using a poor choice for your needs just because you didn't know of the better choice that was out there. It's acceptable if it leads to DBIC, DateTime, Path::Tiny, etc, but it still sucks some times.


I'm right there with you. Having a small core has several drawbacks.

Having a LARGE core does as well, and mostly that any modules in the Perl core seem to also have their API and features frozen in time. Even if those features and API are not so good - it's in core! So, there's a reason to keep them how broken they are for backwards-compatibility sake.

I've also felt the burn of a core module that's then removed, and the new maintainer now going absolutely wild changing things. I understand exactly why they want to change things, and would not disagree with their ideas in a vacuum, but it causes great grief to me when I'm supporting apps that relied on in-core modules that have been upgraded out of core.

I wanna say that this problem is being used as a lesson for Perl 6 - that the core for the, "official/main/whatever" distro is going to be kept very spartan, but it's going to be encouraged to build upon that distro for your own Perl 6 releases. So, if you want the, "Web Framework" release, it'll come with all the bits and pieces you need to get that going - however editorialized that selection will be.

Moritz talks about this concept, here:

http://perlgeek.de/blog-en/perl-6/how-core-is-core.html

Although this post is pretty old, and I'd hate to say that their line of thinking now.


Note, however, that Perl6 is a completely different language with a different set of standard libraries and ecosystem and pros-and-cons. You'd be as well off comparing Perl6 to Ruby as you would Perl5.


I only used it for small scripts. I'd think twice before using it for anything more significant.

What did you use it for, if I may ask? What how big a project are we talking about?

I would have thought hitting the docs wouldn't be a part of the annoyances list. Did you feel you had to hit the docs more than with any other language?


> As much as I really like python, I find that calling system commands is a pain.. calling os.system is obviously far from great, and calling subprocess can get cumbersome.

Have a look at the 'sh' python module to ease your pain: http://pypi.python.org/pypi/sh


I think having to use/install something is precisely the pain people are talking about.


Especially for the kind of glue scripts we're talking about, having to install new language packages across a heterogeneous environment consisting of thousands of boxes is not an easy option.

For me the greatest advantage of the Perl5/shell integration is that you can use Perl's sane data structures, flow control, and code organization features instead of their bash equivalents which have endless pitfalls and can be less portable than basic Perl5.


That's useful, thanks.


Perl 6 continues linguist Larry Wall's vision of making a very expressive language that matches the way humans think.

To me the most unique aspect is Perl 6's unicode string handling which is probably the best unicode support of any language out there. I could see it catching on in niches that need to do heavy cross-characterset text processing.


Great (basic) introduction with exception to the regex chapter because it felt like an introduction to regex instead of the regex features of perl6.

Some things I found interesting (in addition to what s_kilk mentioned and linked to and others have already mentioned some of them) * Gradual typed! * Multi subroutine * Hyphen in variable names * @numbers.=sort * .WHAT * Catch blocks * .defined * Unless

It will be fun :)

I however don't understand the reason for the naming of eg elsif, my, slurp/spurt?? (instead of else if or local or fread/fwrite) Is it a perl culture thing? Because they mention in the tutorial that Perl 6 belongs to the C-family languages (and then call the "for" loop in C "loop").


Let me address your last paragraph and expand a bit on what username223 said. elsif is historical from Perl 5; I think it may be related to the fact that C-style ifs require curly brackets in Perl.

my is Perl 5, is different than local, and is gloriously short. Nicest way I've ever seen to declare a variable. :)

slurp/spurt are routines to read/write an entire file at once. slurp is pretty standard in other languages, I believe, and spurt was chosen to be a natural opposite to it. Perl 6 still has open / close / read / write, etc. Though to be fair, honestly I usually use lines, which (with no other arguments) gives you a lazy list of the lines in standard input / files specified on the command line.

for in Perl 5 was some weird combo which could be iterating over an array or a C-style for. In Perl 6, those have been separated. Because iterating over an array is vastly more common, that gets the shorter keyword. The C-style loop got the loop keyword.


> I however don't understand the reason for naming of eg elsif, my, slurp/spurt??

Yes, it's for historical reasons. "elsif" is spelled that way in Perl 5. Perl 5 has both "my" and "local" to specify lexical and dynamic scoping, respectively, so Perl 6 using "local" for lexical scope would be confusing. "slurp" is a common term for reading the entire contents of a file at once.


"my" is shorter than "local" or "let" and fairly evocative. Maybe you should ask why other languages don't use "my", instead. :P


"my" arrived after "local". The former is true lexical scoping, the latter isn't quite.


Right. As gp says, "local" is dynamic scoping.

It's available as long as the declaration stays on the call stack. It more-or-less allows globals to be temporarily redefined.


Think locally, act globally.


I am so happy they've included kebab-case identifiers :-) I've always thought they made more sense than camel or snake, because there's no shift key involved. It also brings fond memories of fun in lisp land.


I'm so happy to learn the term kebab-case (and agree that it's very usable and supremely typable)


I really like the fact that Perl6 has a proper type system.

I like even more that you can mix static and dynamic typing, so to speak. After taking their sweet time, I am not overly confident about adoption of Perl6, but I hope I'm wrong.

At least, from what I can tell so far, Perl6 manages to keep the spirit of Perl, while fixing a number of things that were wrong, or at least problematic, in Perl5.


I wish programmers could break away from "tutorials" and "introductions" that are just lists of syntax and keywords.

I want short examples, brief explanations of those, and then some problems to solve.


Have you looked at the synopses (1)? That's how I've learnt Perl 6, and I've never been convinced by any other kind of Perl 6 documentation. To me the synopses are complete and explanatory enough. As far as problems to solve, there are the various entries in rosettacode (2).

1. http://design.perl6.org/

2. http://rosettacode.org/wiki/Category:Perl_6


learnxinyminutes.com solves your problem about how the language works, but doesn't give you problems to work with.


monthly-salary = daily-rate * working-days

Wow. This will make a few people happy who think underlines and camel case are ugly.


That's a poor example for the documentation to use. In a case like that, kebab notation leads to visual ambiguity when reading code, especially within an expression performing math operations. It becomes harder, at a glance, to tell if the "-" is the kebab connector or if it's subtraction or negation.

Kebab notation makes sense in other contexts, like DOM IDs and CSS class names. It does not make sense in a case like that.


Adding the missing $ sigils will uglify it quite a bit, though.


That's a matter of perspective. If adding sigils makes that line's intent and action much more obvious, then the sigils are doing what they are for. Once you accept them for what they are, which is hinting to the programmer, they make more sense.

Sigils denote the nouns of the language. They are there for your benefit,not the compiler's.


They don't need to be "missing". my \working-days = 200; Creates a working-days variable that you can't change.


Isn't that sort of a mis-feature that we don't expect to see in code very much? I thought mainly people would be using sigils, and ideally the correct sort of sigil to indicate if it is a single thing, list of things, hash of things, callable thing, etc.


I wouldn't call it a misfeature. I think especially in math stuff it would be useful. I've used Δ in my math for Color module and it both has the natural mathematical meaning and must not change after I calculate it: https://github.com/zoffixznet/perl6-Color/blob/master/lib/Co...

What is a mis-feature is you can't assign-create to these variables when they're part with sigil-bearing variables, so, for example, here I ended up using a sigiled-Δ, which isn't as pretty :) https://github.com/zoffixznet/perl6-Color/blob/master/lib/Co...


Aiui it's for any time a coder prefers that a noun's name does not emphasize/convey the basic nature of the thing the noun refers to.

Fwiw you can assign to such "raw" nouns if you declare that the raw noun you're declaring refers in turn to a rw container. For example, a plain `$` is a container (an anonymous Scalar):

  my \Δ = my $ = 100;
  Δ = 200;
I came up with the following idiom when pondering snippets on twitter and the fundamental problem that twitter treats strings of the form `@foo` as twitter handles which messes up the formatting of tweets containing `@` sigil'd nouns:

  my \array =@= 1,2,3; array[2] = 200; say array;
displays

  [1 2 200]


I see it as a natural part of Perl 6's gradual typing approach, ie. a feature, not a mis-feature.

It can be mis-applied. It arguably has been mis-applied in this example. But I can also argue it the other way. It depends on whether the intro's goal is to address overly simplistic general criticisms ("sigils are ugly and unnecessary!") or to inculcate mature understanding from the get go.


Does Perl 6 have fundamental features that don't exist in other languages ? Just curious.


I don't know if any of these features are really unique, but the combination of having them all is certainly unique:

* Strings that are made of Unicode grapheme clusters instead of codepoints or bytes. This means that a substr() operation for example can't even accidentally rip a apart a base character and a combining character on top of it

* Grammars as a language feature

* Gradual typing

* A built-in meta object protocol

* Concurrency based on high-level primitives (promises, queues, supplies, ...) with syntactic support (instead of threads and locks; which are still available if necessary, but discouraged, because they don't compose well).

* Lazy lists


Yea, grammars looks simple-the-unique thing other languages don't have in 2015, 2016 and, I bet, 2017 too. Maybe even longer :)


That's only at level 1, until you realize Perl 6 code is parsed by a grammar written in Perl 6.

Its power is amplified by the part Perl 6 regexes are better than anything there is out there.

Even better, this extends beyond ASCII and applies to Unicode too. And will work with other powerful control structures.

I'd fix that date to something like 2027.


While Grammars as a language feature aren't mainstream (yet!) they're not a unique feature either.

For eg. See the parse dialect which is a TDPL that comes with Rebol / Red

- http://www.rebol.com/docs/core23/rebolcore-15.html

- https://en.wikibooks.org/wiki/REBOL_Programming/Language_Fea...

- http://www.red-lang.org/2013/11/041-introducing-parse.html


Grapheme-cluster strings are neat, and the decision to normalize makes sense in that context. But how does Perl 6 handle filenames, which can't be safely round-tripped through grapheme strings?


It turns out that the same NFG mechanism developed to support graphemes works for this non-grapheme scenario too:

"... POSIX doesn’t promise you’ll get UTF-8, or even ASCII. It promises ... a bunch of bytes. We can now cope with this properly – surprisingly enough, thanks to the power of NFG. We now have a special encoding, UTF-8 Clean-8-bit, which turns bytes that are invalid as UTF-8 into synthetics, from which we can recover the original bytes again at output. This means that any filename, environment variable, and so forth can be roundtripped through Perl 6 problem-free. You can concat “.bak” onto the end of such a string, and it’ll still work out just fine."

From https://6guts.wordpress.com/2015/11/21/what-one-christmas-el...


Thank you


[minor syntax/markup edits]

One that has caught my fancy are various uses of the "Whatever Star". This appears as a * in a few contexts. In many it is really a shortcut for the "Whatever" class, so you can use it in function signatures to enter sort of "automatic mode".

  @shuffled_names = @names.pick(*) # randomly pick... however many you have. whatever.
But I think more interesting and different than that is using whatever-star as an automatic lambda thing.

  @nums.map(*/2 + 3)              # expression-lambda from context around a whatever-star
  @nums.map( -> $n { $n/2 + 3 } ) # equivalent with a real stabby arrow lambda
  @nums.map( { $^n/2 + 3 } )      # $^n is a generated alphabetical-positional argument
I suppose this isn't really fundamental... but is definitely different.


I'm pretty sure that the "expression-lambdas" were inspired by Haskell, where you get a lambda simply by writing an operator with one or more missing operands.

In Perl 6, detecting that an operand is "missing" isn't possible due to the existence of prefix/infix/postfix operators with the same names, so it expects a "whatever" star in place of the missing operand... :)


This guide is gorgeous; the choices made for fonts, styling, and formatting are just perfect. I wish more online documentation looked this good.


Peeping at the source code, looks like this may have been generated by http://asciidoctor.org (in case you would like something similar for yourself).

For Perl-folk, there is a module to convert between POD and Asciidoc:

https://metacpan.org/pod/Pod::AsciiDoctor


I'm looking for several Perl developers in Berlin for a full-time permanent position:

http://valbonne-consulting.com/job/perl-or-lua-software-deve...


At first sight I find amusing comparing Ruby to Perl 6. (a=. sort) (a.sort!) (a.what) (a.class) (say a) (puts a) (for @a=>item) (a.each {|item| ..} ) and the similarities, push, shift, splice, ...

I see nothing new here. But I must say that Perl 6 seems to be easier to learn than Perl 5 for beginners.


This is just a little intro cheat sheet, it's not supposed to be scary - quite the opposite, in fact. Easy things should be easy.

The magic is in the more advanced parts of the language. The, "hard things should be possible" parts.


Show me the more advanced parts of the language, are they transducers, monads, functors, natural transformations, auto-compilers, self-replicating systems, high AI in action, ML, NLP. What is the honey spot for this new language?



A lot of the advanced stuff is internal work leading to a simple exterior (at least in principle, modulo bugs and optimization work). Think "tormenting implementors on behalf of users".

For example, in Perl 6 a character at the language level is a grapheme. This is per a proper understanding of the Unicode standard. It seems that most folk (and language designers/designs, including eg gvr/py3) don't/didn't realize that Unicode always intended graphemes as the obligatory ultimate destination for modelling "characters" and providing truly clean Unicode text handling. (Swift has attempted the same thing but their current character iterating implementation and API are clearly inappropriate long term for a performant text manipulation focused language so they'll surely have to redo that part of Swift over the coming years.)

Another example is the parallelizing, async, and concurrency features in Perl 6. These are all surprisingly simple to use and performant but took a lot of design talent, and engineering talent under the hood, to get right internally and simple externally.

Sticking to positive stuff for a moment longer, some features bring important concepts from decades past in to this century. Most notably, afaict, Perl 6 provides a universal unrestricted grammar[1]. Aiui this could put help put "string rewriting", a relatively neglected mathematically proven isomorphism to the lambda calculus and turing machine models of computation, back on the map. It will be interesting to see what happens as Perl 6 matures.

The biggest downside I see, beyond widespread negative associations with the name 'Perl', is immaturity. Perl 6 has lots of bugs, poor doc, is currently slow as molasses for a lot of stuff, and so on.

[1] https://en.wikipedia.org/wiki/Unrestricted_grammar


I haven't been using Perl 6 lately, but, as of a few years ago when I did, some of the more notably unusual features or planned features were:

* Grapheme-level string processing, even when there's no pre-composed Unicode codepoint for the grapheme. I think Swift is now doing this, too, but I'm not sure if anyone else is.

* Perl 6's grammars are to an extension of parsing expression grammars what the regular expressions in Perl 5/Ruby/JavaScript/etc. are to an extension of regular expressions. One can use PEGs (or other grammar formalisms) in any language with a library or code generator, but, with a few exceptions like Parsec, it's usually not nearly as convenient.

* Roles, similar to the traits concept developed by Nathanael Schärli, Stéphane Ducasse, Oscar Nierstrasz, and Andrew P. Black (and present under that name in e.g. Squeak Smalltalk and PHP since 5.4). Roles/traits are similar to mixin-style multiple inheritance, except that, when including multiple traits with conflicting methods, the including class must explicitly resolve the conflict. Mixin-style systems use an implicit linearized method-resolution order, which is more fragile because newly added methods in earlier mixins can silently override methods of the same name from another mixin that the caller was actually intending to call.

* Multiple dispatch is not unique to Perl 6, but it's not especially common, and it's very convenient.

* Configurable object representations. For example, a class can be defined to use the default P6opaque representation, which is I think usually implemented as a pretty standard struct-like representation with properties at fixed offsets. Other possibilities might be a hash table representation, where an object is represented by a hash table and attribute access is done by accessing the values of appropriate keys in the hash table. If one wants to forgo the optimizations allowed by fixed representations, one can even define a class with `is repr(*)` to allow individual objects of the class to be created with different representations.


It may be Perl 6, but it's still Perl - and Perl is good for, "Getting Your Shit Done"


I love that Perl 6 has a proper REPL now.


A note of caution; it's way better than nothing and will get where it needs to be one day, hopefully in 2016, but it currently uses some awful hacks that make it suck for a lot of stuff.


I know but I am really glad that they went this route.


For perl5 I'd commend unto you Reply, which manages to learn from most of the mistakes I made in Devel::REPL


When is Perl 6 going to be a standard installed package for the Linux distributions (Debian, CentOS, Ubuntu)?


I don't think anybody can predict the future well enough to answer that.

Languages become part of the standard installation by having very commonly used toos written in them.

I might be wrong, but I'm pretty sure ruby isn't part of a standard Debian installation, and neither is lua, for example. Ruby is very popular for web apps, but you don't need web apps to boot the computer, start a GUI and install packages, so it's not part of the standard installation.

But it's only an 'apt-get install ruby2.1' or so away, and so is rakudo (the current Perl 6 implementation). The debian package in stable is outdated, but work on newer versions is in progress. (Don't know about CentOS, sorry).


I am curious, what's the use of learning perl6 in 2015?


Well, I can tell you what's the use of learning Perl 5 and that I suspect most of it will apply to Perl 6 as well:

Perl, more than any other language I know, sacrifices nearly every other property in the name of being useful. It's not a conceptually clean language, or an elegant one, or a simple one, but if you need to get stuff done, now, there is very little that can compete with it. (At least for some rather specific values of "stuff" - Perl, IMHO, really shines at small-ish scripts that need to convert data from some format to another, or merge data from different sources, especialy when lots of text-handling are involved). Parsing a log file, or matching user accounts from a Windows domain with employee records in an ERP system's database are two examples that come to mind because I had to do those things not too long ago.)

Perl 5 has problems though, especially when it comes to writing large-ish programs. While you can write readable und unreadable code in any language, Perl makes writing unreadable, unmaintainable code easier than, say, Python. Perl 6 tries to fix a lot of this while remaining as useful as Perl 5 (or at least trying to).


> Perl, more than any other language I know, sacrifices nearly every other property in the name of being useful.

Another factor that mattered back during Perl's heyday was the insane lengths it went to for maximum portability. The Perl porters shouldered the burden of making it run on DOS/Windows, Mac OS, VMS, and all the weird Unices that existed at the time. This doesn't matter as much nowadays, but it was crucial back then.

If you had a text-munging or scripting problem, and wanted to solve it once and for all, Perl was the perfect tool.


Oh yes. The Perl documentations comes with things like perlos400 or perlvms that details the specific problems or advantages people looking to run Perl on that particular platform will face, and the list of these OS-specific documents is really impressive. There are systems on it that run Perl that I have never heard of (or only in whispering, at a New Moon).

Perl lets you pretend that Windows know how to fork. That alone still amazes me in a way.

During my training, I had to set up BIND 9 on IBM mainframes running z/OS and configure TSIG (cryptographically verified zone transfers), which among other things required changing the (shared) keys on a regular basis (about once per month, I think) and distributing them across about half a dozen systems. Fortunately, at that precise point in time, I stumble across a news headline that IBM just released Perl 5.8 for z/OS and managed to get the sysprog to install it.

The alternative would have been REXX. I looked at it, quickly, and then looked away, very determinedly. I was really glad Perl was available on those machines.


FWIW perl currently builds and passes tests on z/OS, under straight EBCDIC: http://www.nntp.perl.org/group/perl.perl5.porters/2015/11/ms...


And this is why Perl is awesome: IBM mainframes are the opposite of sexy, but some people use them, and Perl will work there.


A lot of that has to do with Perl being multi-paradigm. C++ is another (though lower-level) example of that. On the one hand, there's a strong argument in favor of designing a "clean" paradigm and sticking to it.

On the other hand, there's an equally strong argument to "pick the right paradigm for the task". It's taken me many years to appreciate the elegance in that approach, as it requires a thinking in multiple models at the same time. On a totally subjective note, I find it more "human" as our creativity lets us what's suitable for the task, without trying to mold everything into the same uniform mold. That may appeal to certain personalities more than others.


It all sounds good but I can do almost everything in Python too right? That too with the cleaner syntax and easy to debug/read code. I hardly see any job openings that requires perl these days unless it's for some legacy Perl project.


I don't know Perl 6. But here's the reasons why I've considered dusting off my Perl 5:

- Subjective, but in my experience, the Perl community is more full of smart yet practical people than any other dynamic language community I've participated or dipped my toe in (and most popular static manifestly typed language communities to boot). I don't say this to trash Ruby or Python (or even JavaScript and PHP, which have plenty of smart users and participants); I just mean that I often learn more from engaging with the Perl folks.

- Kindof a corollary, but Perl 5 seems one of the few places where industry's reflexive treadmill dash towards the newly-formed but usually isocapable turned into a careful reflection on using the existing power at hand wisely and the best marginal gains from key additional features.

Place two jobs in front of me, one of them working on a new Go project, the other on a new Perl 5 project, my bet is going to be that the latter would be part of a more satisfying overall experience.

Now, Perl 6, this is starting to look like a language where they are going to make a number of things easy that most programmers didn't even know were hard, a number of things possible that most programmers didn't even know were possible, where recent PL research is going to meet further practicality, where unicode might even actually be reasonably comfortable to work with.


Same use as in learning any other language.

We could very well have asked what was the use in learning Go in 2010, but look how that turned out.

Perl6 is currently a very interesting language with a relatively weak module ecosystem. Which is a position many languages have been in before.

Let's not dismiss it out of hand.


I wonder what ever happened to the dream of Perl 6 running (or interfacing with) Perl 5 code out of the box, and thus having access to all of CPAN from the get-go. Does anyone know if that is still a goal?

I always thought that would make a world of a difference.



v5 isn't in a usable state right now.


Perl6 is such a completely different language and implementation that calling Perl5 is no different than calling Ruby or Python -- they all involve effectively embedding or calling out to the other language.

Here is a gist where I'm calling out to some Python. It is not done in the magical future way (which is in progress) of just doing "use matplotlib::pyplot:from<python2>" or similar, but not too bad.

https://gist.github.com/awwaiid/ef3f0abcfa96e34977b4

(I wrote this some months ago -- it can be a bit cleaner now)


Apparently Inline::Perl5 works well enough: https://github.com/niner/Inline-Perl5/


If you'd learned Perl5 in 1994, you'd have had twenty years of exceptionally fun employment and community out of it.


Well I'm not doing it anymore, but I was using bioperl extensively when I was in biotech, but there were some gotchas and it wasn't as fast as it could be. With better concurrency, that certainly could reduce analysis time.

Currently, I am also using a monitoring tool called Argus (http://argus.tcp4me.com/) which is completely written in perl. It doesn't seem super well maintained, but I really like it, so I have been reading through the source and have been thinking about doing something similar in Elixir, but Perl6 would be a perfect update for it.

Perl is largely a sysadmin tool, in that many of us sysadmins are not formally trained in programming, but we often need to get shit done, and perl enables that. When bash, awk, and sed start to falter, we tend to use python and perl, so that's another use case. Simpler syntax and better threading would certainly help with that.


So I've written some Bio stuff for Perl 6 and unfortunately Rakudo is still way too slow for super heavy computational lifting. On average stuff is 10x slower than Perl 5 and worse case 100x. I strongly believe this will improve next year to the point it's competitive though. Shaped native arrays just came on the scene which means a list in Perl 6 can act in memory exactly like a C array which opens up the ability for the JIT to use SSE instructions. That said I've been using Perl 6 at work for basic file manipulation just because its so nice and quick. Anything that's 100sMB rather than 100sGB finishes up in acceptable times and sometimes Grammar support is super helpful.


Have you compared the MoarVM and JVM backends recently? Is one substantially faster than the other for your applications?


For those looking to get started with Perl6 in Docker -- here is the related Docker Hub page:

https://hub.docker.com/_/rakudo-star/

And its GitHub repo:

https://github.com/perl6/docker




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: