Maintenance Costs of a Shared Resource

| 1 Comment

Suppose the only thing Perl ever really needed were a method keyword. If it were implemented correctly—with the associated tests and documentation and a discussion period to see how it fits in with existing code—the cost of adding this feature would be relatively small: it's not much code, it's a simple feature, and it has very few possibilities to interfere with existing code.

That's not the only thing Perl needs, for some definition of need.

(I believe Perl 5 lacks a unified and coherent development vision, which makes this entire discussion both more interesting and less useful. Yet even an idealist has to deal with the world as it is sometimes.)

If you accept that Perl needs (or "could use" or "would benefit from" or "really ought to have") a few more features, you have to answer at least two procedural questions in addition to the technical questions of "What is it?", "How should it work?", "How do we build it?", and "How do we know it works correctly?":

  • Who will build it?
  • Who will maintain it?

By way of analogy, consider the case of an appealing albatross in Parrot, specifically the compiler named IMCC. In Parrot's earliest days, the VM only ran bytecode. An assembler written in Perl turned Parrot's assembly source code PASM into bytecode for Parrot to run.

Melvin Smith wrote an experimental intermediate compiler which added some syntactic sugar to PASM and produced Parrot bytecode either as output or directly in memory for Parrot to run. Parrot needed something like this.

It wasn't long before Melvin's IMCC found itself grafted onto the side of Parrot and used as the primary invocation and compilation mechanism. I hope I'm not mischaracterizing Melvin's opinion as including dismay that his code was a proof of concept which made assumptions and took shortcuts and wasn't exactly what he would have submitted for a shipping product. (I don't blame him one bit for writing prototype code—that's exactly what I would have done.)

Melvin stopped contributing to Parrot shortly after that point, but IMCC lives on to this day. (Again, this was prototype code which needed at least another round or two of severe refactoring before it was suitable for the sort of duties Parrot expected. As an example, I found a register use analysis algorithm which looked to have O(n12) complexity. That exponent of 12 is not a typo. Let me type it again: twelve. One dozen. Ten plus two. I managed to get it down to four in most cases.)

The problem is simple: someone (not Melvin!) dumped a big wad of code into the wrong directory in version control and now everyone has to maintain that code.

Perhaps marking this code as experimental would have helped, but other people (including me) added features and built onto it. (Dan's apologia for leaving Parrot mentions that his strategy of checking in messy code and hoping that would lure new people to help clean it up didn't work out as well in practice as he had hoped.)

In terms of Perl, it's important (as many people point out) to consider the question "Who will maintain this code?" That task shouldn't have to fall to the pumpking or a Nick Clark or Dave Mitchell by default, but it does.

The deeper question that Perl needs to answer is "How can p5p make the whole of Perl easier to maintain?"—not just to make it easier to add and support new features but to reduce the maintenance burden of existing features and to attract new contributors to help maintain code.

You can see this for yourself; open up almost any core module and see if you want to do the work to find and fix a bug. If that's not technical friction, I don't know what is.

1 Comment

Thanks for writing this blog, I learn so much from it!

I started programming in Perl just as people were starting to realize that the smart-match wasn't what people had hoped and that the given/when is confused by it too. From what I read, part of the problem was that it wasn't well described first. It seems to me that there is already a `method` keyword being worked out by the `MooseX::Method::Signatures` and `Method::Signatures` projects, which are mostly compatible with each other. If a new Perl keyword `method` were to be added, why fight it: use the [quote]standard[/quote] which is emerging from it?

At first allow `method () { #invokant as $self; ... }` and the `()` is just an optional compatibility null-op. From there the standard from those modules can be added as able.

Further I have been wondering if Perl5 could take a step forward if Jeffrey Kegler's preliminary Marpa parser of Perl (included as an example in the dist) would be taken that extra step, to passing the suite? Could that be the next leap that Perl needs? A smarter parser? His examples seem very exciting.

Again, I am shooting from the hip here, but those are my $0.02.

Modern Perl: The Book

cover image for Modern Perl: the book

The best Perl Programmers read Modern Perl: The Book.

affiliated with Modern Perl Whitepapers



About this Entry

This page contains a single entry by chromatic published on November 25, 2011 11:46 AM.

Parallelism and Test Suites was the previous entry in this blog.

Solving Problems or Absorbing Design Patterns is the next entry in this blog.



Powered by the Perl programming language

what is programming?