Perl and Me, Part 1: The Road So Far

Lately, I’ve been pondering my relationship with Perl.  Every programmer has a different relationship with their language-of-choice, and it impacts how they approach many different aspects of coding, what features they like and which ones they hate, what they clamor for and what they disparage.  And these choices are always going to be challenged by our friends, our coworkers, and our open-source collaborators.  Which is a good thing, for the most part: being challenged is what keeps us honest, keeps us fresh.  Without constant challenge, we can lapse into dogma and cargo cult coding.  But we can’t properly defend our positions—can’t explain why we feel the way we do about certain things—unless we take the time to understand our relationship with our language.

So this is part 1 of an X-part series (we’ll just have to see how long it takes me to work through it all).  Primarily I want to explore this for my own self-awareness, but I hope it will be interesting to others as well.  And perhaps it will make some of my other blog posts make sense.

I begin at the beginning: how I came to Perl.

I got my first computer when I was fourteen or fifteen.  It was a Commodore 64 that my dad brought home to teach himself programming.  When that didn’t work out, he gave it to me, thinking maybe I could do something with it.  As it turned out, I could.

I became a BASIC programmer.  What I mean by that is, even though I learned some other languages during this period, BASIC was my language of choice.  When I sat down to write a program for myself (which is something I did, and still do, quite a lot), I reached for BASIC.  When I tried to understand how to code a solution to a problem, I thought in BASIC.  BASIC was my weltanschauung, my lens ... my matrix.

At age 20, I got my first professional programming job.  It was a job programming in C, even though I couldn’t speak the language.  They assumed I was a bright kid and I’d pick it up.  I did.

When you’re a BASIC programmer, there are only a few other languages you can learn that will make BASIC look good by comparison, and I learned two of them: assembly and FORTRAN.  But once you learn a real language (like C), you realize how primitive your matrix was.  The second I grokked pointers, I understood I had been programming in a toy language for my entire life as a programmer (which, remember, was a quarter of my life, at the time).

So then I was a C programmer.  Again, I learned some other langauges, but I was a C programmer, and I wrote a lot of C code.  This lasted for another five or so years, through my initial programming career, my return to college, and my part-time gigs as a hardware installer.  Then one day a friend at work told me about C++.  “It’s the hot new thing,” he assured me.  I asked what was so great about it.  “It has objects,” he said, as though this explained everything.

“What’s an object?” I asked.

“It’s ... well, it’s a ... well, it’s like a struct, right? only it has ... functions.”

I was completely nonplussed.

But I thought I’d see if I could figure out what all the fuss was.  So I got myself a C++ book—and not even that great of a book, as it turned out, but good enough to explain the basics of object-oriented programming.  And I read the book, and I didn’t get it, and I read the book, and I didn’t get it, and I read the book, and then, one day ... I got it.  And, lo, the heavens did open, and angels did descend upon the earth, blowing their golden trumpets, and I did see that Objects were Good.

So, by the time I started my own company at age 25, I was a C++ programmer.  I could still program in C (or BASIC, if I really had to), and I was still learning other languages, but I was well and truly a C++ programmer.  I became a member of Borland’s TeamB for C++; I participated in discussions about the evolving ANSI standard for C++; I subscribed to the C++ Users Journal.  I wrote a lot of C++ code, and in fact somewhat disdained other languages.

At age 29, I was forced by financial necessity to take a consulting gig working in C again, doing maintenance on a large codebase for a large corporation (they were #1 in their space, but you likely would never have heard of them).  The person who’d had the job before me was moving on, not to another company, but to start up some newfangled thing called an “intranet.” For his first project, he decided to take this large C codebase (which he knew pretty intimately, after all) and create a set of web pages where all the code would link to each other: for instance, every #include "something.h" line could be a link to that include file, and so forth.  That’s old hat these days, but it was pretty radical stuff back then.  To create this set of HTML pages, he had cobbled together a lot of awk scripts.  Until he reached the limits of awk (which of course didn’t take all that long), and then he used a2p to convert it all to Perl.

And this was what he brought to me.  Yes, the first time I ever saw Perl code, it was Perl 4,* automatically generated from awk scripts.  It was not pretty.  And yet there was ... something.  Something about it that tweaked my interest.  Before too long, we got Perl 5, and it had the most exciting thing: you could make function calls without using &.  Oh, and objects.  Those were nice too, if a bit clumsy.

And I began using Perl more and more.  First just at this gig, then for other clients on other projects that my company worked for.  But I didn’t become a Perl programmer.  For the first time in my programming life, I became bilingual.

See, when you’re a BASIC programmer and you learn C, you don’t look back.  BASIC is not really a language you ever pine for.  And when you’re a C programmer and you learn C++, there’s no point in looking back, because everything you could do in C, you can do in C++ (practically by definition).  But C++ and Perl are different.  They’re both good ... just in different ways.  So, for the first time in my life, when I sat down to write a program for myself (which, remember: I do a lot), I would have to stop and think about which language I wanted to write it in: C++, or Perl?

Sometimes the choice was very clear.  If I had a clear need for run-time speed, or I really needed objects, I would go for C++ in a heartbeat.  But, more and more, Perl was my choice for getting the program done quickly.  More and more often, on those occasions when I decided I really did need to write the program in C++, I would mentally groan to myself.  When you’re a C++ programmer, you spend a lot of your life writing libraries for things.  But when you’re a Perl programmer, you spend a lot of your life Getting Shit Done.

I can tell you exactly when I became a BASIC programmer, and I can tell you exactly when I became a C programmer, and I can tell you exactly when I became a C++ programmer.  But I can’t tell you exactly when I became a Perl programmer.  It happened gradually.  I continued to be bilingual for a long time.  I taught other C++ programmers how to code in Perl, and I even taught a few Perl programmers how to code in C++.  If you’d asked me what my “perfect” language was, I would have told you it was a mythical concoction, where Perl and C++ had somehow been fused together.**

But eventually I just got tired of always writing something so I could write something else so I could write a program, and, by the time I was 35 or so, I was writing Perl full-time, and C++ was just a (mostly) fond memory.  The last two years of running my own company, as well as the ten years and three jobs beyond that, have been Perl almost exclusively.***

So now I’m a Perl programmer.  And I’m very happy being a Perl programmer.  But, unlike my previous transitions, I do look back sometimes.  There ain’t much I miss about C++, but the sheer ease of creating classes is definitely one.  For a long time, Perl wasn’t even in the same ballpark as far as that goes.  Now we have Moose, and that puts us sort of ballpark-adjacent—tailgating in the parking lot, I suppose—and p5-mop will likely get us even closer, but still sometimes I think back to how natural it was to just whip out objects left and right in C++.

Why that’s important will be our topic for next week.


* Looking back at the dates, Perl 5.002 would have been out by then, but we didn’t have it.  Our sysadmins probably considered it too bleeding edge.


** Although I didn’t know it at the time, the “perfect language” in my head looked a lot like how Perl 6 would eventually turn out.


*** Well, I still write a decent amount of bash, and quite a bit of SQL, but little else.


4 Comments

You might like D. It's basically a re-write of C++, in a similar way to how Perl6 is a re-write of Perl5.

Also since you know C you could help improve the Perl internals, if your not too busy.

> It looks interesting; it seems to solve several of C++'s more egregious problems (e.g. garbage collection).

Actually, I consider garbage collection to be the main mistake in D. In such a low level language, I don't want garbage collection. RAII offers far better control over when memory is freed.

There are a couple of reasons I haven't ever pursued working on the Perl internals despite my C background, and time is certainly a big one. I've picked up a enough perlguts to know that learning how the interpreter works is a major undertaking, and I've just never wanted anything in core badly enough to justify the time investment. Although certainly that could change one day.

Actually I don't program in C, but my first patch to Perl was in C.

It was to make while(readdir $dir){...} behave more like while(readline $dir){...}. That is it becomes more like while(defined($_ = readdir($dir))){...}

Leave a comment

About Buddy Burden

user-pic 7 years in California, 17 years in Perl, 26 years in computers, 46 years in bare feet.