Why is Parrot afraid of Perl?

Or -- provocative title aside -- why does Parrot want to move away from Perl in its build process?

Yesterday, Jim Keenan asked me a question about a Windows bug in some Perl code used in Parrot configuration. My suggestion was to use a function from IPC::Cmd instead, since IPC::Cmd is core in Perl 5.10 and thus already well-tested across a wide range of platforms.

In his reply, he mentioned that Parrot configuration targets Perl 5.8 with only core modules (except things distributed with the Parrot source) and he added this as well:

I'm sure there's more to the issue, but as I don't follow Parrot discussions all that closely, my first reaction is that it seems unwise to me. ((Unless the goal is to have Parrot completely bootstrap itself from existing Parrot binaries, which might actually be a decent thing.))

The advantage of Perl for configuration is that it's already portable -- so you can configure the same way on Windows as you would on Unix. Take away Perl and then you're stuck with MSYS or cygwin, or other ports of Unix tools to Windows, none of which are as easy to use as, say, installing Strawberry Perl.

That Parrot ticket suggests using autoconf. Really?!? Google for "autoconf windows". Here's a example of what you get: I hate autoconf. Plus, you need Perl for autoconf anyway, so this approach layers a unix-y tool on top of Perl to build makefiles to build Parrot. That's a lot of places for things to break across platforms.

I'd rather just have Perl.

In fact, I'll go further in my rant and point out that even Perl can't be automatically configured on Windows because it depends on shell scripts. Instead, configurations are maintained and edited by hand in the Perl source, and anyone building on Windows has to hand edit them again for any local customization.

I think that one of the reasons that Strawberry Perl has kept its momentum and frequent releases is that the build process got coded up into Perl::Dist, so that all the custom configuration needed to build a Windows Perl binary could be automated with Perl.

So, maybe as an "outsider" to the Parrot project my opinion doesn't count for much, but I think if they really want to be more portable and more automated, they should be looking to use more Perl, not less.

5 Comments

> I think that one of the reasons that Strawberry Perl has kept its momentum and frequent releases is that the build process got coded up into Perl::Dist, so that all the custom configuration needed to build a Windows Perl binary could be automated with Perl.

It's even worse than that. Even though I wrote most of Perl::Dist, Strawberry itself is really a group effort. Most of the stuff in Perl::Dist is me taking the explicit instructions from someone with actual skills off a blog or email on some topic, and then automating their instructions.

Without Perl::Dist in the middle to automate the knowledge of many different people, NOBODY involved in Strawberry individually have either the knowledge or skill to build Strawberry by hand.

Without it, it wouldn't be the case that Strawberry would die because it took too long. It would die because nobody would actually know how to build it at all.

chromatic: I think that's a great goal in the long run. In the short run, however, I think saying "we won't use CPAN" just makes your collective jobs harder, since you're re-inventing the wheel in the Parrot source -- and in Perl, no less -- in the meantime.

The bug I was asked about related to some commits that broke detecting the presence of 'perldoc' on Windows. Detecting an executable? IPC::Cmd. It's a solved problem.

I'd much rather see Parrot contributors working on bigger Parrot tasks than mucking around with configuration with one arm tied behind their backs.

If you look at Parrot's intended goal, which is to equally host all dynamic languages, this move makes sense. We can't say that we both depend on Perl for our entire build process, and rely on CPAN for our entire distribution model, it's going to be hard for Parrot to make the case to other non-perl languages that we intend to be language agnostic. We don't want the Python people, or the Ruby people, or the PHP people to say "We won't use Parrot because it's a Perl thing".

If Parrot really wants to be language agnostic, and I suggest that this is a very important goal, they can't make it look like they're Perl people with a Perl agenda. The alternative to removing Perl would be to duplicate the configuration system in other languages like Python and Ruby, so that users of those languages can configure Parrot "natively".

The vast majority of the Parrot build process is not related to configuration: Large amounts of code files are processed and automatically generated by Perl when they do not need to be. Only a very small amount of work really needs to be done by Perl for now in the configuration system, and good bootstrapping system will eventually be able to handle those.

"Plus, you need Perl for autoconf anyway, so this approach layers a unix-y tool on top of Perl to build makefiles to build Parrot. That’s a lot of places for things to break across platforms."

Think big: One day Perl will be running on top of Parrot, so why require the Perl layer when we have the Parrot binary available first? Sounds like an extra place where things can go wrong to me.