
Perl 6 developers will attempt to make a Version 1.0 release by Christmas 2015 - eperoumal
http://blogs.perl.org/users/shadowcat_mdk/2015/02/fosdem-2015-its-christmas.html
======
muraiki
If you want to have an idea of what makes Perl 6 compelling, check these
slides that were submitted a few days ago, "Perl 6 for Mere Mortals" (which is
also another talk at FOSDEM):
[https://news.ycombinator.com/item?id=8953368](https://news.ycombinator.com/item?id=8953368)

I hate to repeat a comment of mine, but for the sake of emphasizing just how
different Perl 6 is, here's a version of Fibonacci in Perl 6:

    
    
      subset NonNegativeInt of Int where * >= 0;
    
      proto fib (|) is cached returns NonNegativeInt {*}
      multi fib (0) { 0 }
      multi fib (1) { 1 }
      multi fib (NonNegativeInt $n) { fib($n - 1) + fib($n - 2) }
    
      say fib(100)
    

Edit: Another good recent talk is "Adventures in Perl 6 Asynchrony," which
shows off promise combinators, channels, and supplies:
[http://jnthn.net/papers/2014-yapceu-
async.pdf](http://jnthn.net/papers/2014-yapceu-async.pdf)

~~~
Estragon
Why would I learn this rather than Haskell?

~~~
wantarray
> Why would I learn this rather than Haskell?

You wouldn't.

That is to say: You might learn Haskell if you want do write 100% functional
code, and Perl 6 if you want to write imperative/procedural/OO code with
functional idioms mixed in here and there (in places where that facilitates a
more elegant approach).

I.e. the two languages are not really competing in the same category.

Even though Perl 6 has first-class code objects, closure semantics, basic
pattern-matching, lazy lists, immutable data types, and so on, a lot of the
syntax and default behaviors are geared towards stateful programming styles,
which - combined with the lack of static typing - means that strictly sticking
to functional programming in Perl 6 will be awkward and you'd be better off
using a dedicated functional language if that's what you want.

~~~
raiph
> lack of static typing

A key feature of Perl 6 is optional static nominal typing:

[http://www.reddit.com/r/perl6/wiki/gradualtyping](http://www.reddit.com/r/perl6/wiki/gradualtyping)

~~~
wantarray
That looks like strict nominal run-time type checking to me, not static
typing.

~~~
raiph
Thank you for replying.

    
    
        my Int $age = 40;
    
        $age = "old";
    

That will generate a __compile-time __error. (Because the "old" bit is a
string literal which is interpreted in this case as being of nominal type Str
which isn't compatible with the nominal type Int).

Do you have any tips for me on how to make it clearer on the page I linked
that this is compile-time checking? Or, more simply, did you just not believe
the "compile-time" comment on the page I linked or did you just miss it,
perhaps because it's "commented out"? Would it make sense for me to
incorporate some of what I write below?

\----

Perl 6 supports more than just static nominal typing. You can add arbitrary
constraints:

    
    
        my Int $school-age where 5..18 = 40;
    

The code that comes after the 'where' (the '5..18' bit) can be arbitrary code.
It is tested against any value that would be assigned to the $school-age
variable.

Most folk will just like the convenience of this construct and won't care
whether it results in a check at compile-time or run-time.

But some will care.

So, while __nominal __typing is a compile-time checking affair, what about
these arbitrary constraints? Do these result in checks at compile-time or run-
time? Well, it depends.

Key quotes from the relevant language design doc[1] are:

> A where clause is considered static if it can be applied to the types to the
> left of it at compile time to produce a known finite set of values.

The line of code we're looking at:

    
    
        my Int $school-age where 5..18 = 40;
    

can clearly be reduced to the set of integers from 5 to 18. And the compiler
code to successfully make that analysis is fairly straight-forward, so it
could fairly easily be implemented in Rakudo today.

However, for 6.0.0 (by which I mean the suite of 35K+ tests that are
supposedly going to reach beta status by September and the Rakudo compiler
that is supposedly going to reach gold status by the end of the year) there's
this:

> for 6.0.0 any structure type information inferable from the where clause
> will be ignored

In other words, the line we've been looking at with the `where` clause will
result in a run-time check for 6.0.0.

\----

[1]
[http://design.perl6.org/S12.html#Multiple_constraints](http://design.perl6.org/S12.html#Multiple_constraints)

------
perlgeek
I'm a Perl 6 core developer (compiler, test suite, docs, design documents,
infrastructure). Ask me anything :-)

~~~
xiaq
IIRC the new VM (MoarVM) is around for quite a short time and it replaced
Parrot in a dramatically short time. What are the advantages of MoarVM over
Parrot and why were we stuck at Parrot for so long before giving it up?

~~~
brrt
I'm the developer of the MoarVM JIT (but not the developer of the MoarVM
bytecode specialisation framework, which is typically seen as part of the
JIT).

The weakness of Parrot VM was it's ambition - to be an efficient VM for _all_
dynamic languages. This may have seemed possible in the past but recent work
(i.e. v8, luajit2, etc) has invalidated that; it's much better (and much
easier) to build a VM for a specific target than for all possible targets, as
there are simply fewer points where you need abstraction. (For instance, NaN
is false in javascript boolean context, but not in Perl6). More importantly,
MoarVM has been designed and developed by a small set of developers applying
all the lessons learned from parrot, while parrot was in many ways an
experiment by committee.

~~~
chromatic
You say potato, I say "Parrot was designed to implement the semantics of both
Perl 5 and Rakudo in the same process."

You say "It's better to build a specialized VM", I say "Emscripten, Clojure,
Niecza, Truffle, and Jakudo."

~~~
brrt
Well, that's a good point, really. The JVM and the CLR do run many (dynamic)
languages quite efficiently. On the other hand, that is in no small part due
to the man-centuries spent trying to optimise both the JVM JIT and the
language-to-JVM compiler.

And as a counter-example, luajit2 was built by one man (mostly) over the
course of a few years, and runs very efficiently indeed, in no small part due
to the lua-specific choices that have been made.

So what I'm trying to say is that there is a second tradeoff, somewhere
between programmer efficiency, runtime efficiency, and running time, and that
MoarVM is making a better tradeoff for perl6 than parrot is.

~~~
themgt
Thanks, I think this basic "you go to code with the developer resources you
have, not the developer resources you might want or wish to have at a later
time" is desperately under-appreciated in software architecture

~~~
chromatic
_you go to code with the developer resources you have, not the developer
resources you might want or wish to have at a later time_

Ha! My experience with Rakudo was "you go to the developer resources you have,
tell them not to change anything, then tell them you're going to throw away
their work in favor of something you haven't written yet" and then complain
when they leave.

------
pcunite
The first line of code I ever wrote was in Basic. It was copying something in
a book. Then I wrote routines on a Ti calculator for school. Then I found
Perl. I felt all grown up! Maybe, just maybe I could be a "real" programmer.
Thank you Perl.

------
JadeNB
I can't find it right now, but I like how this harks back to the original
announcement that Perl 6 would be ready in time for Christmas—just with no
commitment to _which_ Christmas.

~~~
chromatic
This original announcement, which said "18 to 24 months, with a prerelease
targeted for [July 2001]"?

[http://use.perl.org/use.perl.org/articled5d3.html?sid=00/07/...](http://use.perl.org/use.perl.org/articled5d3.html?sid=00/07/19/161217)

~~~
FROGGS
And at that point they found out that Perl 6 will be a complete rewrite and
not just a cleaned up Perl 5. I also guess that the Second System feeling
already arrived in some minds, the problem IMO is more that the 'by Christmas'
joke has been kept alive for so many years, without specifying a year.

------
mfrager
I hope Perl 6 has better runtime speed and memory efficiency because those are
the only downsides of Perl 5. However I seriously doubt that will be the case.
Perl 6 will most likely be more bloated and slow, but I very much hope that
I'm wrong.

Just for reference my company's software is all built with Perl 5 and runs
great. Most of the execution time is within the database calls so there is no
impact from using Perl over a marginally faster runtime like Python or Java.

~~~
SwellJoe
When did Python become faster than Perl 5?

I'm not trying to be argumentative, but the last realistic comparisons I did
had Perl running quite a bit faster. For example comparing ack to grin, which
are very similar projects in Perl and Python respectively...at the time,
admittedly several years ago, ack was an order of magnitude faster than grin.
I also wrote a few log parsers in both Perl and Python (at a time when I was
working in a Python shop, so they preferred everything be done in Python). The
Perl parsers were _much_ faster than the Python variant, for exactly the same
work (again, an order of magnitude difference). Perhaps this is just an
example of Perl's domain of expertise...processing text is a big part of its
origin story, and has always been a big part of what people use it for. Or,
perhaps Python has made remarkable performance improvements in those
intervening years. I haven't worked with Python in that time, so haven't
followed development. Perl 5 has gotten faster in that time, too, though, so
I'd be surprised if Python is dramatically faster for the same real world
tasks.

~~~
latk
Perl5 has a lot of historical baggage that makes certain things difficult to
do efficiently. For example, how objects work. There is an insane amount of
indirection involved for a simple method call, and this indirection can't
generally be removed if we want Perl5 to stay highly backwards-compatible.
Numerics aren't particularly efficient either. Perl5's opcodes are very high-
level. That makes each individual opcode pretty fast, but makes it difficult
to inline stuff. Variables can have “magic” attached that can change their
semantics substantially. While this is very flexible and allows to do some
amazing things, this also requires this magic to be checked on each access. So
Perl5 has a lot of features that rank high on “clever”, but low on “can be
optimized”. Perl5 never got JIT support, and only has a couple of very
experimental Perl-to-C transpilers.

What is fast is string handling and log mangling. Perl was created for that;
everything else is bolted on.

~~~
SwellJoe
I understand all that (though it's useful to cover it for folks who might not
know). But, is Python faster? It carries some baggage of its own. I guess PyPy
may be able to make some sorts of problems faster, and it was still nascent at
the tail end of when I was using Python; I think it existed, but was nothing
more than a proof of concept. Even now, I think it's a pretty limited subset
of Python deployments that use PyPy.

And, you speak of numerics, which is a good example of Python's wheel house.
When I worked in Python it was at Enthought (the company run by the folks who
created Numeric, SciPy, and who sponsors a lot of scientific computing Python
projects). Perl definitely doesn't have the numbers performance of a hybrid
Python+Fortran or Python+C++ system, like you can build with Python, Numeric,
SciPy, etc.

So, even back then, Python was (probably) faster than Perl in that category
(Perl has science and bioinformatics libraries, which may have been comparable
back then, but certainly aren't now), and I guess it's unfair to compare
Perl's strength to Python's weakness, and vice versa.

Nonetheless, I suspect Perl is not slower than Python in the general case. One
would probably have to talk about specific tasks and implementations to figure
it out.

------
Diederich
As I said over on perl.org: From the bottom of my heart, thank you. I have
been keenly looking forward to this for a long, long time.

I think there's a good chance that Perl6 will not only become 'relevant in the
large', once again, but also, once again, be a driving force in the overall
improvement of our industry.

~~~
DonHopkins
I agree: Perl could lead the industry by example to slow down and take 15
years to ship everything. Then everybody wouldn't have to work overtime so
hard and so often, toil late into the night burning the midnight oil, and
ignore their families, pets and social life.

~~~
kbenson
I want to downvote you for the played out jab, but your sentiment on the
industry in general is worth being heard.

------
pekk
Wow, pre-congratulations! Let's hope this inspires some renewal in the Perl
community.

It never made any sense to me that some people would rather see Perl stagnate
and die and complain from the peanut gallery than they would _help it move
forward._

~~~
chromatic
_some people would rather ... complain from the peanut gallery than they
would_ help it move forward.

That's not entirely fair. Some of us doubters spent a lot of time, energy, and
resources trying to help it move forward before deciding it wasn't worth it.

~~~
kbenson
Have you been checking it out at all again, or are you considering it? It's
been my secret hope for a long time that you would get involved again, if not
at the compiler level then at the community and ecosystem level. Your blog[1]
was always insightful and a good read, and I think the community is worse
without it being active. I'm talking about Perl 6 here, but I could say the
same for Perl 5 and it would be at least as true.

1: [http://modernperlbooks.com/](http://modernperlbooks.com/)

~~~
chromatic
_Have you been checking it out at all again, or are you considering it?_

No. I have my doubts about yet another announcement and nothing I've seen
since I stopped contributing suggests that the project will provide anything I
need that I can't get better elsewhere.

------
cwyers
It says a lot about the history here that Perl 6 gets a 1.0 release, not a
6.0.

~~~
eCa
That is because it _is_ version 1.0 of Perl 6. The '6' is not a version: 'Perl
6' is the name of the language.

Meanwhile, Perl 5 will have its 22.0 release this May.

~~~
cwyers
People can say that as much as they like, calling the thing that comes after
Perl 5 "Perl 6" certainly SOUNDS like a version number, and the reason it
sounds like it's supposed to be a new version of Perl is because once upon a
time it was going to be.

~~~
kbenson
Maybe at the point of the 1.0 release, a naming change could take place. I
think any time before then would be a mistake though, as it would maximize the
baggage and minimize the usefulness of the new name. I'm torn on whether a new
name, if it happened, would be better off explicitly referencing Perl (e.g. NG
Perl), or leave it out entirely for something new.

~~~
emmelaich
My guess is that "perl6 1.something" will be followed by "perl 6.something".
But that would require an enormous amount of compatibility with perl5.

~~~
kbenson
Well, with Inline::Perl5 and "use p5", that may not be entirely unfeasible.
You can read more about Inline::Perl5 here[1], but the TL;DR is that it uses a
Perl 5 interpreter along with Perl 6 to pass code back and forth, allowing
pure perl modules _and modules that interface with libraries_ to run fairly
smoothly in Perl 6. There's also an Inline::Python that works the same way...

1:
[http://niner.name/talks/Leapfrogging%20the%20bootstrap/Leapf...](http://niner.name/talks/Leapfrogging%20the%20bootstrap/Leapfrogging%20the%20bootstrap.pdf)

------
bonif
I got my first job in 2000 because I knew Perl. Perl 6 was coming. Fast
forward .. 15 years have passed.. Please stop insulting us ...

~~~
caoilte
Give them a chance. Duke Nukem Forever came out eventually, after all.

~~~
vacri
And what a disappointment that was. It turned out that DNF was socially more
valuable as vapourware than as the actual product.

------
nemo
Good on them, really hope they make the release.

------
mseepgood
In hexadecimal?

------
smegel
They are seriously running the "done by Christmas" line again? They are
holding us in contempt.

------
lisa_henderson
No joke, this time Charlie Brown is really, really, really going to kick that
football.

------
melling
"Perl 6 Developers will attempt to make a development release of Version 1.0"

We are upvoting non-news? It'll be a great announcement if they ship it, but
it's just hype now. Also, consider all they are announcing is a version for
developers.

~~~
kbenson
That's not what it says:

"Larry has announced that the Perl 6 Developers will attempt to make a
development release of Version 1.0 of Perl 6.0 in time for his 61st Birthday
this year and a Version 1.0 release by Christmas 2015."

------
jackmaney
I have a fondness for Perl 5, as it was the first general-use programming
language in which I became proficient. But let's not kid ourselves: Perl 6 is
the Half Life 3 of programming languages.

------
runn1ng
Yes, Virgina, there really is a Santa Claus.

------
lawnchair_larry
Ugh, I hoped we had all moved past perl.

------
trollian
15 years late...

~~~
wantarray
Late for what, exactly?

Do people no longer write code? Because if they do, some of them might might
choose to use Perl 6 for that, and that's all the success a programming
language can hope for.

I see no reason why Perl 6 can't find its niche among people who prefer the
Perlish over the Pythonic way to approach problems, but want a modern,
consistent, cruft-free language (which Perl 5 is not).

~~~
alexandre_m
If they wanted a modern, consistent and cruft-free language then those people
most likely already moved to something better.

I'm not against Perl or its evolution, but I don't see the point to learn this
today when you have so many better scripting language alternatives with
established community and rich libraries available.

~~~
muraiki
Modern scripting languages with... parametric polymorphism, built-in
parallelism/concurrency, grammars, constraint-based multiple dispatch, etc.?

Yes, it will be very important to build up a Perl 6 community and an ecosystem
of libraries. That being said, if you want to talk about modern scripting
languages, Perl 6 seems like a good choice. Ok, to be fair to functional
programmers a lot of these things are old features. But for the mainstream
scripting languages, these are really new and powerful tools -- tools worth
learning.

~~~
chromatic
_Modern scripting languages with... parametric polymorphism, built-in
parallelism /concurrency, grammars, constraint-based multiple dispatch, etc.?_

Not everyone thinks that ticking off a list of feature checkboxes satisfies
the most important adoption criteria.

~~~
kamaal
True, but at the same time If I'm writing a code base that will likely have a
>5 year life. I'd rather write it in a feature rich backwards compatible
language. Else you are left with a Python 3 like scenario where you will have
to undergo a decade plus migration path just to get a few improvements over a
for loop and a print statement.

~~~
chromatic
_If I 'm writing a code base that will likely have a >5 year life_

... then don't write it in a language with negligible documentation,
negligible tooling, barely-there library support, nearly zero users, and a
roadmap based on the promise that, after almost fifteen years of working on
the "It'll be ready when it's ready!" principle, sufficient volunteer mindset
will change to "Let's ship a production-ready release to meet a hard
deadline!"

