
Perl 6 in 2011 - A Retrospection - perlgeek
http://perlgeek.de/blog-en/perl-6/perl-6-in-2011.html
======
skyheights
In a couple of important places Rakudo really stalled in the last half of 2011
due to the unfortunate absence of pmichaud++, its 'pumpking'. Jnthn++ and
moritz++ have been able to recover some of the lost territory, but I'd say
there's been almost a 50% drop-off in the rate of overall progress. I'm afraid
the bus number is too low for expectations to be too high.

------
mjs
So there are now three Perl runtimes/compilers/interpreters--Rakudo (+ Parrot
VM), Niecza (CLR), Perlito (?)--none of which yet implements the full Perl 6
spec? (Which itself is not yet complete, although "2011 was a rather quiet
year in terms of spec changes.")

~~~
perlgeek
That's correct. They all approach Perl 6 from different angles, and with
different goals and techniques.

I'm sure you also know that the specifications of Java, C, C++, python,
Haskell and other languages are still being developed too.

~~~
squiggly101
So when does work start on the one that will be angled for use in the real
world, you know like Java, C, C++, python, Haskell and other languages?

~~~
masak
I'm trying to think of a way to read your question that doesn't make it
dismissive and condescending. Why wouldn't the current three implementations
be angled for real-world use?

I'm using Perl 6 "in the real world". I use it on my spare time. I use it at
work. I have production code running in Perl 6. I use Perl 5 even more
heavily, but with each month I use Perl 5 a little less and Perl 6 a little
more.

~~~
jlarocco
"Why wouldn't the current three implementations be angled for real-world use?"

Because going to perl.org -> Download says "We recommend that you always run
the latest stable version, currently 5.14.2." [1] and doesn't even mention
Perl 6.

And when you do find a page that has Perl 6, it says "If you are looking for
production ready code please use Perl 5" [2]

[1] <http://www.perl.org/get.html>

[2]<http://dev.perl.org/perl6/>

~~~
bryanlarsen
When somebody asks you "What's the latest version of C?" Do you answer
"C++11"? Of course not.

Perl 5 and Perl 6 are two different languages that happen to share a similar
style and history. The latest version of Perl5 will never be 6.something.

And yes, Perl6 is not recommended for production use, since the specification
has not been finalized. By the same argument, C++0x should not have been, yet
many people did.

~~~
chromatic
_By the same argument, C++0x should not have been, yet many people did._

I see little equivalence; despite the flux of the C++0x specification, many
C++ useful and usable compilers existed and implemented several portions of
the specification.

Put another way, the draft status of portions of the Perl 6 specification say
nothing about whether "Just compile git HEAD yourself!" is the preferred
distribution and deployment mechanism, nor about whether the right approach to
supporting real users involves slapping a TODO tag on regressions to appease
the test suite.

~~~
bryanlarsen
Despite the flux of the Perl6 specification, many Perl6 useful and usable
compilers exist and implement several portions of the specification.

~~~
chromatic
_... many [Perl 6] useful and usable compilers exist and implement several
portions of the specification._

My company was working on a product based on Perl 6 two years ago. We planned
to release it to paying customers at the time of the Rakudo Star release. We
officially scuttled it several weeks ago when it became obvious that Rakudo's
development process would continue to be incompatible with _shipping a working
product_ for as far as we could predict (and two of us have commit access to
most or all of the Rakudo stack, so it's not like we're disconnected from the
development of Perl 6).

The words "useful" and "usable" do not reflect the reality of the situation.

~~~
microtherion
This is rather surprising, coming from you. In past years, you vehemently took
the opposite side of that argument (e.g.
<http://news.ycombinator.com/item?id=1737504>).

Could you explain what happened to change your perspective?

~~~
chromatic
_Could you explain what happened to change your perspective?_

Certainly. Rakudo Star wasn't what everyone hoped it would be, but I figured
another few months of tuning and releases would let it stabilize to the point
where our customers could rely on it as a significant part of the product.
That was my understanding of Rakudo Star, sort of the Perl 6 version of Debian
Testing versus the Debian Unstable monthly compiler releases.

Performance _wasn't_ a huge concern; the five to ten percent monthly
improvements we were getting were sufficient for our projections, if they
continued. (They did.)

Around December 2010, some of the Rakudo discussion turned to rewriting the
main implementation language used to bootstrap Rakudo (and part of the
discussion was "Hey, this'll be a great opportunity to consider targeting
additional backend VMs!"). Scopes creep and rewrites produce regressions and
remove stability.

Rakudo forked its development into "The old stuff that used to be Rakudo Star
but won't get any updates or even releases" and "The new branch which will
become the main branch even though it won't see any releases and has huge
regressions" and they're starting to address regressions now.

As you might expect, the release schedule for Rakudo Star slipped from "every
month" to "every three months" to "whenever things get stable".

In the absence of project discipline to release stable code every month--in a
culture which believes it's okay to tell people "Sure, it's useful and usable,
just track Git HEAD for multiple components"--you can't deploy a product
without heroics. I'm not going to risk my business on heroics.

In short, they stopped delivering a stable product and I stopped believing in
their ability or their desire to do so.

~~~
microtherion
Thanks, that is a very clear explanation!

As an outside observer of Perl 6 development since its conception, I feel that
this pattern (Scope creep and massive rewrites / depreciation of current
infrastructure whenever one component was in "danger" of becoming useful) has
played out over and over again throughout the life of the project.

This went back at least to the original Parrot announcement. Arguably, even
the _birth_ of Perl 6 was based on the idea of a massive rewrite, superseding
the much more modest Topaz effort (After about two years of development, Topaz
had not yet delivered fully working code. The original announcement of Perl 6
promised working code in 18 months).

<http://use.perl.org/~masak/journal/40451>

~~~
chromatic
Parrot and Perl 6 really suffered until Pugs started producing a standalone
test suite. If Perl 6 on Parrot had had that in 2000 or 2001, things might
have turned out differently.

I normally agree that throwing away working code and starting anew is the
wrong approach, but trying to rewrite the Perl 5 internals to support Perl 6
would have taken at least as long as Parrot and Rakudo have taken; it's really
that impenetrable in places.

Your phrase "in danger of becoming useful" is quite perceptive though; I wish
I'd thought of it.

------
restofus
The good thing about perl 6 is that lots of ideas from there are getting back
into perl 5 and believe it or not Haskell got a bit of a boost because of perl
6 (when the pugs project was in full swing).

Even if one of the projects implements the full perl 6 spec that exists today,
there are very few perl 5 devs that will switch over ,If I were asked to guess
it would be less than 5 %. Perl 6 as a language has to start at the bottom
with other programming languages . The name perl6 was used because one of the
reason (I am not sure of this) was to retain the name to get perl5 devs to
move to the next version of the language and at that time perl5 was a dominant
language.

Another perspective to look at is that perl6 was announced in early 2000
clojure came around 2007 , scala appeared around 2003. There are other
languages like go and dart which have google backing that have come out.

So IMHO if you want to learn language design and the other things around it
perl6 is a good playground you will learn and easy to get into the community
but you will not get a job because of it. If you are a user of programming
language who wants to use a language for solving a real world problem today
(with libraries and get questions answered) or learn a language which will get
you a job you will be better off with perl5 , php, ruby, python, scala,
clojure or <insert your lang>

------
spidaman
Back in the day, I was an avid mod_perl user and Perl 5 enthusiast.

I recall being optimistic that Perl 6 would come out of the oven in 12 to 18
months. Sadly, that was in 2004. My feelings about Perl 6 are like those about
a Microsoft OS that is stable, secure and performant: a nice idea that has
grown into a myth. Sorry to dump on Perl, I still have many friends who use
Perl 5 on daily basis. I think for a lot of folks, the real "Perl 6" is...
Ruby.

~~~
chromatic
_I think for a lot of folks, the real "Perl 6" is... Ruby._

That doesn't make sense; why would a "real Perl 6" be measurably worse than
Perl 5?

~~~
spidaman
A "ruby vs. perl" fight is the furthest from my mind, I'm just speaking
anecdotally about what my friends who, like me, were heavy perl users are
using in it's place now. If the "measurably" bit refers to how the runtimes
benchmark, yes, absolutely, it doesn't make sense.

~~~
chromatic
_If the "measurably" bit refers to how the runtimes benchmark..._

That and language stability, ecosystem, internal coherence, library
availability, release process, compatibility, deployment concerns, tooling....

