A Curious Programmer

Last time, I linked to some example code that forks a bunch of processes and communicates with them via pipes. This is the main feature of the code I’m interested in, but the explanation is the article is kinda sparse so you can consider this to be supplemental.

As usual, the perl doco is pretty good for covering this stuff.

• fork()
• IO::Pipe

Creating a child process (a kid) involves two pipes, one for the parent to send data to the kid, and one for the kid to send data back to the parent.

One probably obvious thing to note, you can’t directly send a reference down a pipe, (well, not in any reasonable way and that’s a feature, not a bug), so you’ll be interested in serialisation modules. I’ve mentioned them in passing before and I generally use JSON::XS these days.

Another hopefully obvious thing is if the writer is buffered and the reader is waiting for something specific, there will probably be some deadlock in your future. Remember to unbuffer the writer.

I made a couple more J – comments inline:

sub create_kid {
    my $to_kid = IO::Pipe->new;
    my $from_kid = IO::Pipe->new;

    # J - Fork returns undef for failure, 0 for the child, and the
    # J - child PID for the parent

    # J - Handle fork error
    defined (my $kid = fork) or return; # if can't fork, try to make do

    unless ($kid) { # I'm the kid
      # J - The kid reads from $to_kid and writes to $from_kid
      $to_kid->reader;
      $from_kid->writer;

      # J - unbuffer writing to the pipes.  Otherwise may deadlock
      $from_kid->autoflush(1);

      # J - Reset all of the signal handling
      $SIG{$_} = 'DEFAULT' for grep !/^--/, keys %SIG; # very important!
      do_kid($to_kid, $from_kid);
      exit 0; # should not be reached
    }

    # J - parent here...
    # J - The parent reads from $from_kid and writes to $to_kid
    $from_kid->reader;
    $to_kid->writer;

    # J - unbuffer writing to the pipes.  Otherwise may deadlock
    $to_kid->autoflush(1);

    $kids{$kid} = [$to_kid, $from_kid];
    $kid;
}

It’s hard to objectively measure Perl’s popularity compared to Python or Ruby. Even before nerds-central used job availability as a measurement, the ease of finding a job was a key requirement for me.

Who cares if I love Ruby if I can’t use it for the 10 hours a day I’m working?

Anecdotal evidence

In the last twelve years I’ve had no difficulty finding plenty of Perl work. In the past couple of years, I’ve had a few calls about Python jobs, but probably ten times fewer than the number of Perl calls I get. Hold the front page – Perl is ten times more popular than Python.

Well, no. Of course I get a lot more Perl calls. I’m a Perl programmer, and my résumé mentions Perl all over the place. Anyone calling about Python must really be desperate!

But I notice that a lot of Python programmers working at Python-centric firms apply similar logic. All the folks they work with do Python, clearly no-one does Perl anymore. Thank goodness – Python is finally the winner it always deserved to be.

Why do people care?

Network effects are important. All other things being equal, a language with more users will get more libraries, will have more companies using it, will get more users, will get more libraries, etc. vs a language with fewer users. And, popularity aside, none of the big three scripting languages has a huge advantage over the others.

Except of course that Perl was the first mover.

So, what can you do if you don’t have a real advantage you can point to? That’s right – you trash-talk the leader, hope you can convince enough people there is a real problem and when they jump ship hopefully you’ll be the one left with the positive feedback loop.

Michael Murdock doesn’t believe in anti-Perlism. Of course he has to indulge in some of his own.

I find it hard to understand French but I don’t go round saying it is a speak-only language.

You couldn’t make it up. Or was the irony intentional?