Re: v5, a reimplementation of P5 (was Re^5: A "Perl-7" that I could actually USE right now)

[BrowserUk]

Why do you summarily reject a project that so perfectly matches what you suggest?

You should take time out and study the backlash effects of misleading advertising.

[chromatic]

But but but some guy is on the same IRC channel with the author of that project, and he said maybe it's time to think seriously about productizing the project. After all, all of the readme file of the project is written in the enterprise-class English language which has proven its worth over centuries of use for serious business.

You too can join the fun, if you're not a nattering nabob of negativity, if you join the #whatever IRC channel. As raiph himself predicted over four years ago, it's right on schedule to start getting actual users who are interested in contributing to this fun and important project which some other guy has called "vital to the healthy and continued future of BOTH Perl 5 and Perl 6!".

Even better, the author if this project is currently exploring ways to make it more interesting than the calculator app included with your phone.

As you can see, it is both practical and fun, and it is further more inevitable that this time, a Perl 6 project will deliver something useful.

[raiph]

I was responding to the comment:

It would indeed be a really interesting experiment to create something that’s compatible with most non-abusive uses of p5, but is better defined and cleaner on the inside.

I thought and still think that v5 perfectly matches those words. (With the exception that it's not an experiment; it's another step toward completion of the overall P6 vision; but it still matches Ralesk's description). So I mentioned v5.

Folk can and often will twist whatever is said to match their worldview. But I will not be ruled by the fear that chromatic's P6 wounds might still not have healed, nor will I put much store in AM trolls that get negative votes. (I take all feedback into account, but let the silent word of the monastery, in the form of votes, guide me more than anything else.)

[chromatic]

I thought and still think that v5 perfectly matches those words.

No XS means no DBI and no DateTime. No XS also means no POSIX, no Fcntl, no Data::Dumper, no Storable, no Encode, no List::Util, and no Socket, to name a few core modules.

I don't know what kind of software you write, but without those modules most of the stuff I've written won't even load, let alone run, including some one-liners.

I'm sure it's a fun experiment for the author, but I could only write toy programs with it. I think I am not so alone in this.

I will not be ruled by the fear that chromatic's P6 wounds might still not have healed...

I shouldn't have to keep telling #perl6 this, but I recommend you spend a lot less time caring about how you imagine I might feel and more time understanding the technical concerns of people you're trying to market to.

[snoopy]

Over on Backcompat is holding us back! you state:

"Breaking XS would be awful, but it's probably necessary for the kinds of internal changes that produce either dramatic speed gains or allow further experiments on the CPAN. Unfortunately, it breaks most of the CPAN."

And Stevan Little replies:

"Actually the XS problem is easily fixed (for some definition of easy). Stop exposing the Perl guts via a macro layer and provide a real API (aka - level of indirection). Of course, then you need to convert all XS modules over to use it, but with a sensible deprecation cycle (of like 2+ years) that should be do-able (not to mention that it will shake out all the old crusty XS modules that no one maintains or cares about)."

It could be that Moe and Perl6 are hitting similar issues with Perl5 integration/compatibility and they may have a common resolution.

[raiph]

Yes, my understanding is also that XS support is vitally important for the vast majority of legacy and contemporary uses of P5, even one-liners.

The future is very hard to predict, but I'd guess that this general picture is likely to continue for the next decade. That said, I think v5 on Android, and custom v5 slangs, eg one making multicore processing convenient, might start to shift things.

The P6 strategy has long been to support multiple bridges between P5 and P6, including both v5 and a libperl+XS bridge. See my recent Perl 6 <-> Perl 5 bridges PerlMonks comment for a few more details.

I agree with your emphasis on technical concerns and that's generally my focus.

However, we're all irrational creatures at heart and that seems to be particularly relevant in your case. Your continual disparagement of Larry Wall and those working with him ("I'm sure it's a fun experiment for the author") and what I see as wilful twisting of the P6 viewpoint (everywhere I've ever looked in the 13 years of the P6 project, the importance of CPAN and XS has been explicitly consistently recognized) suggests to me that you are either angry or contemptuous or both. I don't want anyone to be constantly angry or contemptuous about anything and especially not when it's directed towards Larry Wall and folk working for the betterment of Perl. So I spend time imagining about how you might feel so I might find a way to avoid triggering you. If there is not some underlying wound, please, please imagine how Larry Wall feels when you're considering what to write.

[BrowserUk]

My post was carefully measured to avoid the "rabidly anti-P6" charge, which if you take the time to look, I am not.

Disillusioned, disheartened, twice 10 times shy and skeptical maybe; but not anti-P6.

I thought and still think that v5 perfectly matches those words.

That's where the falseness comes in. It implies that you've taken "use" to mean 'play with', 'experiment', 'try out'. That isn't "use".

And the v5 project shows the same naivety and unnecessary flexibility that has hallmarked every one of the sub-projects that surround and make up P6.

Why is it necessary (or even useful) to have it enabled at block scope?

That just makes it 10 times more complicated than if it was done on a per-file basis. If existing P5 modules could be loaded and interoperate with P6 code, that would answer everyones prayers. And it might actually be doable in a reasonable time-frame. I see no benefit (beyond maybe a little one-off wow factor) of mixing P5 and P6 code in the same file. Makes no sense.

Another example of misleading information

The SameFringe example posted at Rosetta. Does any one of the various P6(ish) implementations run that example lazily?

Any of them? Even semi-lazily (batched) as hinted at in the writeup?

Or is every current implementation of take & gather, just push to a hidden array and then iterate that array?

[raiph]

I did not mean to suggest you are anti P6, rabidly or otherwise. ¹

You say I've "taken "use" to mean 'play with', 'experiment', 'try out'". No, not if the context is serious use. Yes, if the context is a project that is at an early stage in its development, even if the end goal is serious use. You say "that isn't "use"." I disagree. ²

v5 being able to work at the block level is simply part of Larry Wall's slang design. ³ Whether it's naive and unnecessary (your view) or brilliant and pragmatic (mine) it's nothing specific to v5 and it's 100% Larry's responsibility, not FROGGS'. It's also basically sunk cost. So I don't think it's productive to talk further about the cost of building P6 or v5 this way.

I understand the point you were trying to make with "another example of misleading information", but please know that I currently entirely reject the notion that any information I have provided thus far is misleading, including my comments about v5, so I find talk of "another" example completely unreasonable.

According to jnthn (Rakudo's architect) Rakudo's gather/take implementation is lazy, non-batching. According to Larry Wall, Niecza's is lazy and probably non-batching. (Sorear, Niecza's original author did not answer my request for clarification; he's now busy working on Rakudo so it's mostly a moot point.)

I couldn't tell, but it seemed like you might be thinking that batching is sort of laziness-lite. The P6 design specifies four levels of laziness: strictly lazy, mostly lazy, mostly eager, strictly eager. Consider a one million line file. Eager processing will read the whole file in one go. So instead you might want to process it lazily. But do you really want to read it strictly lazily, one line at a time, or would you really prefer a mostly lazy mode that reads lines in batches (even though it still delivers it to your consuming code one item at a time)? Sometimes you really will want to read one line at a time, other times batching is best; the P6 design allows you to control which strategy to use.

---

¹ If my memory of the last couple years here at PM serves me right you've kept your P6 comments mostly focused on what you would want from P6; have focused attention on your personal top issues, with CPU bound speed being one I remember (and threads being another from a recent comment); and have otherwise generally held a healthily (primarily technically) skeptical view. I applaud all of this.

² sundialsvc4's original post is clearly focused on serious use. However, it makes no sense to me that, if there were a project with the goal of achieving what he wants, he would not consider using early (or even late) versions of that project to provide feedback. Such usage would not properly be described as serious use but rather as trying it out or playing with it. The seriousness is about the intended usage once the project has delivered on its goal(s), not how one uses it before it gets there. That said, I did not respond to sundialsvc4.

Ralesk's comment specifically focused on an "experiment". Although I'd say "experiment" is not a suitable tag for v5 (3 month old project is better, though that ignores the years of foundation work it builds on), I thought its goal perfectly fit Ralesk's project description. Ralesk responded that he could not actually use v5. First he talks of an experiment, then suddenly it has to be finished even though no other such finished project exists? I think he may have been kidding, but this leads to another problem.

PerlMonks is supposed to be a resource for the silent majority, newcomers to the Perl world, random googlers, and more. A lot of folk who've heard of P6 inaccurately think it's a dead or struggling project that hasn't shipped software. Comments like Ralesk's reinforce that false viewpoint. If I think a commenter is obviously a troll, I generally leave it alone. If it's an obvious joke, I might reply in kind. If not, I sometimes try to figure out a response to set the record straight.

³ Slangs aren't about mixing P5 and P6. They are about recursing into arbitrary sub-languages at any point. P6 itself consists of a series of slangs for general code, regexen, strings, and so forth. Programmers will remain oblivious of this internal reality when first learning P6, and may choose to always ignore it, but the slang architecture is one of several pieces that give Perl, via P6, the capacity lisp has had since the 1950s for supporting continual, fluid evolution and innovation (in lisp's case, by writing s-expressions, in Perl's by writing Perl).