Larry Wall, primary author of Perl, on productizing Perl 6

raiph · 2 days

With a couple of exceptions, I think most Perl 6 grant money has been spent well.

I think it may make sense to consider funding a release manager when the productization phase nears completion, but certainly not at the moment.

raiph · 2 days

No one is paid to do the releases, so it's ultimately when someone feels like it.

For the Rakudo compiler this has translated to one month skipped in the last 4 years.

For Star (which bundles the compiler with modules) this has translated into at least quarterly releases, with some periods (like this year so far) seeing releases most months. (The one exception was the 6 month gap due to the twin complications of Patrick's wife's cancer and the nom branch.)

raiph · 2 days

They skipped March (so there were releases in jan, feb, april, may).

raiph · 2 days

Right. Star releases typically come out a few days after a monthly Rakudo compiler release but add modules etc. So in most cases most users are better off waiting for the subsequent Star release.

raiph · 2 days

"Exposing real pre-emptive threading with shared mutable data structures to application programmers is wrong". (From http://www.tbray.org/ongoing/When/200x/2009/09/27/Concur-dot-next)

Do you agree?

raiph · 2 days

Fwiw, Larry, last year, on #perl6: "we're also trying to make it possible to write in an Erlangish message passing style, which is a different approach to concurrency".

raiph · 2 days

In my lexicon, concurrency is about programming expression, whereas parallelism is something the runtime does, if it can, to speed things up. So concurrency meets parallelism when the manager decides to clone a waiter and assign one clone per table.

I'm going to mostly punt on answering your question about whether Perl 6's focus is concurrency or threading, partly because you've defined threading as a form of parallelism, which is itself terminologically problematic for me. I'll say this: Perl 6 contains what I've termed pervasive implicit concurrency and there are also multiple Perl 6 related efforts to support various forms of threading.

raiph · 2 days

Why have it all, when you can have less of something, but it's fast enough and it works.

Why not use perl 5? (Or any other existing production language that you like.)

I really don't mind the regexes to be the same as in .. say perl-5.16.0

Then why not use perl-5.16.0, or any other language that uses the PCRE that corresponds to perl-5.16.0?

Bottom line, I'd go for a pragmatic approach, make something that works with what you have, release it, and the features that didn't go in this release will eventually find their way in another release.

That's precisely what all the Perl 6 dev teams have been doing for years. For example, there have been over 50 monthly releases of the Rakudo compiler.

Just making something that works and is available for everyone is like raising the flag and saying "Hey ! Use it, it's ready.." and it's a big morale booster and more awesome than hiding behind various reasons for not finishing it.

Right. No one has been doing any hiding. The dev teams have done exactly what you suggest.

I'm curious. Have you tried Perl 6?

uYKUUHNxcQ · 3 days

Fwiw, please note that Perl 6 has always taken FP seriously and has stolen several key ideas from Haskell. At least two key Perl 6 hackers are Haskell hackers too.

raiph · 3 days

I'm doubtful it will ever be performant on that platform.

One response to this common concern is that it doesn't matter. The Rakudo team has a path on to other VMs.

Another response is that I am confident Parrot will eventually come up to snuff anyway even though the path there has included a rough patch.

The Niecza project seems to bear that out. Am I mistaken, or did essentially one guy build a much faster implementation that covers nearly the same amount of the language in a fraction of the time that Parrot/Rakudo has been in development?

Yes and no. Yes, sorear wrote Niecza in about 2 years whereas Rakudo's been under development for about 5 years. But Rakudo is generally more complete and since the Rakudo team landed the new object model branch (which was primarily about speed even if some think it was about portability) Rakudo has begun to catch up or overtake Niecza.

raiph · 3 days

Heh. I wrote that the spec around concurrency was not stable, but I didn't mean to paint the picture in your mind that you've expressed!

Concurrency is indeed a big issue in Perl 6: the world is moving toward a greater diversity of hardware, much of it multi-core, and software, especially OS kernels, and programmers increasingly want or need to take advantage of concurrency. So it's a really big issue and p6l (perl6.language mailing list) and #perl6 (freenode irc channel) have often discussed all the languages you mention, and many others, some known especially for their concurrency capabilities (eg. Erlang or GHC).

I've been following the Perl 6 design process from the start in 2000. I'd say Perl 6 has a great and timely concurrency story, even if some pages say "This space intentionally left blank".

Perhaps the most noteworthy result is pervasive implicit concurrency -- concurrency baked into common idioms. You just write code. Some of the code you've written -- lists, junctions, hyperops, feeds, gather/take, etc. -- delivers safe concurrency automatically. You don't even have to know you're writing concurrent code.

raiph · 27 days

Look who wrote that code sometime. History of rewrites.

I'm curious what you're getting at.

Where should I look? I picked oo.c as a starting point, but browsing its history shows little evidence of rewrites, so I'm guessing I'm not looking where I would need to look.

Btw, even if I knew where to look, I don't understand what I'd be looking for and why it would be relevant. Aiui the problem in 2010 is that a rewrite was needed and wasn't happening; why would the presence or lack of prior rewrites make any difference?

raiph · 1 month

but maybe your definition of "practical" includes "faffing about with macros and junctions".

Junctions were in before the first Rakudo Star was released. I am not aware of particularly significant effort being spent on junctions since, "faffing" or otherwise.

You may downplay the practical importance of macros, but I think you're wrong and I'm very glad to see them being developed, whether that's "faffing" or not.

"We're not writing our own VM, wink wink, just laying the groundwork so that someone can do it, but if someone were to do it, here's a proof of concept you could use, wink wink"

Huh? Are you talking about 6model and NQP? The Parrot object model was so broken it stalled the GSOC attempt at a Python implementation. In contrast 6model has been so well received by the Parrot devs that they want to backport it into Parrot.

"Let's try to keep the test suite passing 100%."

Well they can't focus on keeping it at 100% before they get to 100% in the first place. They've been making steady progress in that direction, with Rakudo currently passing over 21k of 24k tests.

raiph · 1 month

no substantial packaging improvements, several rewrites of the module installer, and several cycles of invention, lack of adoption, bitrotting, bitrot rescuing, and abandonment of ecosystem components including the packaging system, external modules, and bridges to external systems such as Perl 5 and shared libraries.

I don't see what you see. I see what Larry calls whirlpool dev, and a nice evolution of the ecosystem.

I don't see how the external lib bridge Zavolaj could be much sweeter.

While the Perl 5 bridge blizkost is weak and hasn't improved much since it was started, it hasn't bitrotted either. It awaits someone with Perl 5 guts knowledge and tuits to help out.

Plans are afoot to cross link tadzik's nice module smoker with http://modules.perl6.org.

raiph · 1 month

in [the last couple years] there have been no substantial documentation improvements

That's not true.

The Perl 6 equivalent of Perl 5's bible, Programming Perl, is Official Perl 6 Documentation. While the index and Overview pages haven't changed much in 2 years, try comparing the other chapters. For example the current S02 vs the last archive.org snapshot of S02. Almost all the changes, including the new look, sub-heads, and 350 content commits have happened in the last 2 years.

I think the over 400 Rosettacode examples count as doc, and most of those have been added in the last 2 years.

The last 300 or so commits to the Perl 6 Book have been applied in the last 2 years.

Parts of the Tablets, such as the Tablets index are shaping up.

I don't think Perl 6 has a good doc story yet -- perhaps tadzik's recent integration of pod6 parsing into the Rakudo compiler is going to be a breakthrough on that front -- but there have been substantial improvements over the last 2 years to move Perl 6 doc in the right direction.

raiph · 1 month

there've been one or two funded developers doing almost all of that work

You are ignoring the full breadth of the Perl 6 / Parrot endeavor, and thus ignoring prolific contributors such as Larry Wall, Coke, sorear, fglock, and dozens of others.

But fair enough. Let's just focus on the Rakudo compiler and it's distribution package, Rakudo Star.

There are five or six main Rakudo devs, not one or two.

The lead architect is/was pmichaud. He has received Hague grants. He has been a main dev for years with the key exception of the unanticipated year or so lost thus far due to his wife's illness. Four other Rakudo devs have received Hague grants, and have been prolific contributors for years right on thru today: jnthn, colomon, moritz, and masak.

There are another half dozen folk making continuous and substantial contributions to Rakudo Star.

raiph · 1 month

I'm not saying that the Perl 6 atmosphere is bad, per se. It's great, but it's clearly focused on exploration, research, further language design, and solving interesting problems in novel ways. Unfortunatly, although fun, that focus does not lead very directly to a fast and usable Perl 6 release.

Although this myth is understandable (why else would Perl 6 have taken so long? how else do you explain #perl6 comfort with -Ofun?), it is a myth which is hurting Perl 6. I rebutted it in my prior comment and feel disappointed that you chose to repeat it, pretty much as if I had said nothing.

Why focus on an additional backend if Parrot is dedicated to Rakudo?

Exactly! The hope is that whiteknight's vision will pan out and Rakudo won't be left high and dry. That's probably why the Rakudo devs are NOT focused on switching the backend!

That said, as they finish the rewrites triggered by 6model, they are naturally doing the work that enables extra back ends. Doing anything else would be absurd.

If you still find this confusing, despite having read the post by whiteknight which I just linked, especially the part about 6model, well, please at least realize that "the core Perl 6 team appears to still be focused on things other than practicality" is about appearances, not reality.

raiph · 1 month

Hey fabreston,

There isn't a single Perl 6 team. Just as folk work on what they want to work on, they also join whatever team(s) they choose to join. Someone could suggest sorear and friends stop working on Niecza, but sorear is not going to work on one of the other compilers, so you'd just lose sorear and Niecza. A similar story applies to fglock and friends developing the perlitos, audrey et al and PUGS, and jnthn et al and Rakudo.

exploration, design tweaking, and research

No one is going to stop anyone exploring things and doing research.

Tweaking the design is a whole different thing. To the extent it's happening, it's almost exclusively to fix things that need fixing -- features that looked great on paper but turn out to be wrong or impractical when the compiler teams try to implement them -- or adding things that need to be added -- such as fleshing out concurrency features.

Finally, I think it's worth taking a closer look at the compiler team that uses Parrot as its back-end, namely Rakudo.

While the Rakudo team is focused on Parrot as their back-end, practical concerns have forced them to look at their options, including the two you suggest. The strategy they adopted in 2011 was two fold. First, to try persuade the Parrot devs to focus on Rakudo's needs -- in effect to become part of the Rakudo project. Aiui they succeeded and current Parrot devs now explicitly consider Perl 6 in general and Rakudo in particular to be the only "client" that really matters for the foreseeable future for Parrot. Second, to rewrite the parts of the Rakudo/Parrot combination that were killing performance. For example, 6model, which Parrot devs have said they plan to back-port into Parrot. These rewrites will hopefully be completed later this year, at least on the Rakudo side of things.

raiph · 1 month

Troo. I wanted to highlight your stuff but ended up editing stuff down to the wrong effect. Corrected in original post.

Your new site is not only darn useful but SO cute. Are you planning to use more variants of red for failed buids? Publish under smoke.perl6.org/modules or whatever? Gonna blog about it?

raiph · 1 month

For the convenience of other readers I'll quote jnthn and pmichaud more fully on QAST:

jnthn: "I had a design session with pmichaud++ on QAST, the successor to our current AST. The new nodes will integrate far better with 6model and bounded serialization, give us better native type handling and be much more memory efficient due to being able to use natively typed attributes in them. This is also a key part of our work towards getting Rakudo up and running on an extra back end."

And from pmichaud's blog post about the Oslo hackathon: "jnthn++ and I were able to spend some much needed time plotting out the next moves for the AST implementation, currently called QAST. QAST is part of the nqp implementation, and is the successor to PAST (part of the Parrot repository). Some of the refactors we’ll be able to make in QAST look like they will enable huge improvements in speed, readbility, and writability of compilers in NQP."

raiph · 1 month

To answer my own question, I know Perl 6 is NOT Earl(y) Grey. I find Earl Grey gets bitter if you steep it for more than 20 seconds or so. To me Perl 6 is more like, say, Ginger tea, something that becomes more nutritious and delicious the longer it steeps...

raiph

TROPHY CASE

you'll need to login or register to do that

create a new account

login