Hey everyone,

Following is the p5p (Perl 5 Porters) mailing list summary for the past week. Enjoy!

Hey everyone,

Following is the p5p (Perl 5 Porters) mailing list summary for the past week. Enjoy!

This year I attended my fourth YAPC.  As always, here are my thoughts.  This time around, let’s start with ...

THINGS I LEARNED AT YAPC:

While being blocked from p5p I had to read a new outragious statement by a porter. Who is in reality not a porter like me, just some developer who happens to have no idea what he is talking about.

Re: OP_SIGNATURE

He struggles with his new super-op OP_SIGNATURE which is at second thought a better idea then the old way to assign lexical values from the call stack at the begin of subroutines, just that it cannot take the stack values, it has to go through an intermediate @_ copy, but that is just an implementation detail which can be optimized away, and goes then on like this:

Also, every op/optree related internals change now involves fixups to B and Deparse, so every change is that much more work.

If I could travel back in time and stop Malcolm B. writing B and friends, I would in an instant. Perl now would have been far, far better, and probably a lot more truly extensible than it is now.

The realisation that B (and B::C etc) were a failed experiment was one of the drivers of perl6. It's been an albatross round perl5's neck ever since.

Dear Dave, are you completely out of your mind?

I know that you all don't want to maintain your reflection API and AST. p5p was also not able to maintain B::C and the other 2 compilers, so I had to step up and fix it for them. Even if p5p is unwiling to fix the outstanding problems they create and is still doing more damage than good, B::C is a huge success story.

B::Generate, optimizer and types are not so easy to fix because there the damage done by p5p is too outragious that it can only be fixed in a forked version of perl. I still have to maintain patchsets in my perlall build suite (perlall build --patch=Compiler) to be able to create perls without those roadblocks. And to support windows, because p5p is not willing to export the needed API functions.

Nick Clark really claimed publicly that changing function bodies at run-time is too dangerous when used with concurrent threads. Let that be the problem of the optimizer, not yours. By further blocking dynamic optimizations B::Generate is worthless and type or profile based optimizations cannot be done. Do you have an idea why javascript, an even more dynamic language and worse language than perl could be optimized so much? Apparently not.

To the success

B::C passes the complete core testsuite. B::C compiled code is faster and smaller than uncompiled perl. Look at the B::CC and rperl benchmarks. We are close to v8 and in the next step we will be there.

B::C is successfully used in production by cPanel, which is in fact the largest and most successful company using perl. We just don't shout it out as loud as Booking.com, because we are privately held and we don't need to publish our numbers. Nevertheless cPanel is the facto one of the backbones of the internet, used by ca 70% of all webhosters worldwide, with compiled perl applications and its distribution based on CentOS.

We have to compile perl to have a low memory footprint for our daemons. They need to be smaller than apache and mysql at least, and they need to run on hosting VM's which are low on memory.

Even with p5p non-ability to come up with non-bloated versions of their releases, and their non-ability to come up with any improvements since 5.6, B::C is a huge success.

Dave and Nick, you are the real albatros around perl5's neck for years. Finally stop doing your destructive work, step back and let the people do the work who got a track record and have an idea what they are doing. You both got paid for years to work to improve perl5 and the results are hopeless. One year to fix eval in regex? My dear.

Still not a single feature written and discussed by p5p was ever successful, besides the trivial defined-or syntax. The only non-trivial improvement in the last years came from outside and was initially heavily critized and not understood. ("Why do we need another hash table implementation?") But will this lead eventually to an efficient implementation of classes, roles (mixins), polymorphism and types? Or a better runloop. For sure not. This is shot down since 2002, and everybody who was able to do that and was interested left p5p. Not about talking fixing the easy stuff like smartmatch, switch, given/when or even hash tables. You just gave up.

I have to do my work now behind closed doors.

Stop doing your destructive work, start listening to advice and maybe even implement a good feature or library. Like OP_MULTIDEREF which is nice. Even if it just tampers around the fact that the runloop is too big and slow.

Without B perl5 would have been more successful?

What a ridiculous statement. Inspecting the AST, the optree, how perl compiles its ops? Certainly totally outragious. Nobody would need that. You even refused to accept documentation for the optree. You are just bitching about your need for B::Deparse and B::Concise test updates. Who needs precise optree representations? It's just an implementation detail. The functionality needs to be tested not how it looks internally.

But maybe you'll eventually learn how the optree (i.e. the AST) looks like, when you are forced to update some B modules. I'll do the rest for you anyway for the parts you do not understand.

Realize that your work is looking worse than PHP.

The smartmatch operator (~~) introduced in Perl 5.10 (and borrowed from Perl 6) has been the subject of much criticism. Its behaviour changes based on the types of its arguments (arrays vs hashes vs numbers vs strings vs ...). perlop lists over twenty different behaviours based on different combinations of arguments. Although the operator normally does what you want, what people would want from certain combinations (%hash ~~ @arr anybody?) is nor always clear.

(Aside: in Perl 6 which has a stronger type system, the behaviour of smartmatch is more predictable.)

For this reason, it has been proposed that the smartmatch operator be simplified, or perhaps even removed in a future version of Perl 5. To this end, Perl 5.18 has introduced some warnings about its experimental nature.

This is part 12 of an ongoing series where I explore my relationship with Perl.  You may wish to begin at the beginning.

This week we look at how to start putting it all together.

Last week I talked about the trade-offs of DWIM, and wondered if it might be time to try to make sense of all the various parts and perspectives.  Thus, this is the end of the beginning.¹  This is the convergence of all my reminiscences.

Within the past year, I started a new job, again.  This is something that many of us programmers do on a semi-regular basis.²  When you first start a new job, you spend a few days or a few weeks or a few months figuring out what’s going on.  Part of this is learning new concepts, new vocabulary: even if you’re working in an industry you’ve worked in before, every company accretes its own terminology over time, words and ideas that only make sense to the people who work there.  But a big part of it is learning the codebase.  This may have been growing for years—sometimes a decade or more—and it may have been touched by dozens of hands, but still there will be patterns, consistency even in the inconsistencies.  Once you’ve been working there a while, you will know this codebase in a fundamental and almost inexplicable way—there will still be plenty of code in it that you’ve never seen before, but, when you finally do see it, it’ll feel familiar.  Codebases build up character.  It’s not always a good character, but you learn to recognize it, and live with it, and even feel fond of it, in a weird sort of love-hate way.

Good morning, this will be about GCL (my attempt to make WxPerl programming fun) and I want alsohear from you if its allright to talk about that at this stage of development on Perl Workshop (one month to go so a lot will change).

This is part 11 of an ongoing series where I explore my relationship with Perl.  You may wish to begin at the beginning.

This week we look at trade-offs in expressivity.

Last week I told a story about a CS professor who was inexplicably afraid of recursion.  Other than the obvious moral of “don’t be afraid of things that use underlying complexity to make your external code simpler,”¹ what exactly does this have to do with Perl?

We’re programmers.  Nearly every single decision we make involves a trade-off of some sort.  This way will be more efficient, but harder to maintain.  This algorithm will be faster, but use more memory.  This piece of software is more widely used, and therefore easier to find people to work on it, but feature-wise it sucks ass and can’t hold a candle to this other piece of software, which is dead brilliant but almost entirely undocumented and nobody’s ever heard of it.  If we upgrade, we risk introducing bugs and downtime from weird backcompat issues; if we don’t, we risk becoming outdated, insecure, and left behind in the marketplace.  There’s always some trade-off, and it’s our job to pick one.  We don’t always pick the right one.  In fact, most of the time there isn’t really a “right” one.  What seems right may end up being wrong, and what’s actually right today may end up becoming wrong tomorrow.  But we do the best we can.  And when the benefits outweigh the consequences, that doesn’t make the consequences go away.  It just means we have to learn to live with them.

This is part 10 of an ongoing series where I explore my relationship with Perl.  You may wish to begin at the beginning.

This week we look at DWIMmery.¹

Last week we talked about the awesome productivity of Perl without really asking why it’s so good at it.  For one answer to that, we’ll need to look at a new spectrum.

There are several different spectra in Perl.  In fact, one of the coolest things about Larry is that he’s not only given us a cool language to play with; he’s also given us cool new ways to think about the languages we play with.  Along one spectrum we have the tripartite concept of laziness, impatience, and hubris.  This series has only touched on these indirectly: laziness drives the language be legible, impatience drives it to be productive, and hubris drives it to be closer to a natural language.²  Along another spectrum, we have the orthogonal concepts of manipulexity and whipuptitude, which we just discussed last week.

But there’s another spectrum to look at, which includes the twin concepts of TMTOWTDI and DWIM.³  TMTOWTDI is closely linked to context, which we covered pretty thoroughly.  But what about DWIM?

This is part 8 of an ongoing series where I explore my relationship with Perl.  You may wish to begin at the beginning.

This week we look at the ongoing evolution of Perl.

Last week I closed with the observation that it’s difficult for other languages to evolve beyond Perl because Perl keeps evolving.  And it does: it evolves at quite a bewildering pace, compared to other languages.  Take a look at the evolution of C, for instance.  Oh, sure: we can talk about C++, and C#, and D, and even Java, as evolutions of C, but they are different languages, far more so than Perl 6 is a different language than Perl 5.  If you look at the C language itself, it’s changed several times throughout its history, but the C we have today doesn’t look that different from the original K&R.  It’s no more different than, say, American English is to British English.¹