Perl and Me, Part 7: The Most Powerful Weapon Which You Can Use to Change the World

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

This week we meander around the topic of education hoping to come to a point about Perl.

So far we’ve learned that I’m an English major, that Perl has a lot of linguistics baked into it, and that (at least in my opinion) creativity is good for programmers.  What does all that mean?  Well, for me, one of the things it means is that I lack some of the computer science background of my peers.  I never had to take a class in compiler design, for instance.1  In fact, there’s a lot of stuff that CS majors had to learn that I never did.  Oh, sure—I picked some of it up along the way.  But it’s still true that when I read certain very technical programming blogs (like Jeffrey Kegler’s excellent articles on Marpa), I have to skim over a bunch of parts.  But I also have an analogy I’m fond of breaking out:

You don’t have to understand how the internal combustion engine works in order to drive a car.

Now, there are some bits of car maintenance that will be helpful, surely.  It’s probably good if you understand that gasoline is required to keep the thing moving.  You should know enough about how your brakes work that you can recognize the feeling you get when your brake pads are low.  Maybe some understanding of aerodynamics, that sort of thing.  After all, in this analogy I’m no Sunday driver, no little old lady from Pasadena.  Some people think that computer programmers are more like the mechanics and computer users are like the drivers.  Not true at all: the hardware geeks are the mechnics.  There are guys out there who can strip your computer down to the boards and overclock it, modify it, add chips and even solder crazy shit onto it.  There are people who can build you a machine from spare parts that would put a big box store’s offerings to shame.  I’m not that guy though.  Hardware frustrates me; I like software because you can fix a software problem with nothing but your brain.  (Whereas when hardware has a problem, you typically have to buy something to fix it.)  So, no, programmers aren’t the mechnics: programmers are the Indy car drivers, the guys who soup up their rides and then take them down to the tracks and run them around at mad speeds trying to see how fast they can go before they top it out.  I’m a very good driver (in the analogy2), and I can drive about two to three times faster than the average Joe Schmoe on the street, but I’m still just a driver.  And I don’t have to understand how all the hardware works, or even how the compilers are put together.

You don’t have to know grammar to write a story either, just as you don’t have to be able to read music to be a rock star.  But it helps.  Understanding the underlying structure of things is helpful, when you’re a creator.  So I’ve spent some time trying to work out these things.  I spent some time with lex and yacc.3  And I keep reading the Marpa articles, even when they’re just a little bit over my head.  I think knowing how your language is put together is not necessary, but it will help you understand things.  And I definitely believe in comparative language study, which is a bit like studying linguistics.  I took a couple of linguistics courses myself—not to the extent Larry did, but enough to get the basics down—and, in linguistics, you study foreign languages without learning how to speak them.  So it is with us programmers.  We can program well in some languages (those are like the natural languages we’re fluent in), and we can program a bit in others (those are like the ones we can speak a few phrases in, enough to get by while traveling, perhaps), and then we have a few that we know how they handle objects, perhaps, or we understand the extensive macro system, or we have a grasp on how they scope their variables or do their garbage collection, but we can’t actually write a program in them.  That’s like the amount of Japanese that I know: I remember a few interesting bits about word order and how to turn an indicative into an interrogative, but I never learned any actual useful phrases.4  For instance, I learned Lisp the same way I learned Russian: I had a friend taking a class in it, and I had to learn enough myself in order to be able to help them pass.5  Today I remember little of either, except that they were both difficult and neither looked like something I wanted to pursue personally.

There were three sets of classes that I think helped me in my programming career.  Out of all the classes I took in 4 years of high school and 5 years of college, only 3 sets of classes that I think were actually really useful in terms of giving me practical knowledge that I use every day.  And none of them were CS courses (of which I took a few, primarily because they were easy A’s for me).  The first was typing, which I took a year of in high school.  My mother talked me into it, and I have never regretted it.  If there are any young programmers out there reading this, it’s actually the best piece of advice I can give you: learn to touch-type.  Seriously.  If your fingers can’t keep up with your brain, you’re never going to be as effective as you could be.

The second was logic, which I had two semesters of as Philosophy courses.  No reason I took the first one, really, but I took the second one quite deliberately after I realized what a goldmine the first semester was.  Boolean algebra is what computers run off of, you know.  I can’t tell you how useful it is to have learned De Morgan’s theorem.  And the second semester got into set theory, which is all you need to know to understand SQL.

The final one were my writing classes.  Now, I had to take more writing classes than your average college matriculant, because my particular English major had a concentration in Writing.6  I took 7 writing courses, in fact, and nearly all of them featured workshopping.  That means that we not only had to write stuff and have it critiqued by the professors, but we also had to pass around our work to our fellow students and critique each other.  There’s something you learn, both in how to accept criticism gracefully, and how to give it constructively, that I have found immeasurably helpful in programming in team environments (particularly those where we did code reviews).  I wish more of my coworkers had had the same experience.

In fact, I’ve often wondered if the fact that all our computer science programs offer BS degrees is really the right approach.  I’ve done quite a bit of teaching in my career as well, and I enjoy it nearly as much as the programming.  Sometimes I daydream about founding the first BA program in computer programming.  Aside from the two (or even four) semesters in logic, and the four or so writing workshop classes, I think I’d mandate a communications theory course (my Comm 110 class didn’t give me tools I use every day, but understanding sender/receiver/message/noise is pretty damned important), probably a foreign language (not only useful for communicating with other programmers in our new globally connected online world, but a good foundation for understanding issues of internationalization and Unicode), and surely a linguistics course or two.  Now, you may look at this list and think it doesn’t have that much to do with programming.  Well, when I investigated what it would take to get a CS degree, I was looking at 3 semesters of calculus, 2 semesters of electrical engineering, and 3 semesters of statistics, none of which I’ve ever needed in 25 years of professional programming.7  Whereas the stuff I’ve listed I’ve used over and over again.

And some of the best programmers I’ve known were liberal arts majors: I had an absolutely fantastic sys admin once who was a Music major, and one of the smartest guys I’ve had the pleasure to work with was a Philosophy major.8  Wouldn’t it have been easier for some of those folks if they could have picked up a BA in CS with just a few more courses?  Although they didn’t really need it, obviously; I’m thinking more of some of the kids in school today who might be getting turned off of programming by the idea that they “need” all that extra math stuff.  Seems a shame.  That’s all I’m saying.

See, I think the future is going to trend more and more to where “programming” is just you having a conversation with your computer.  Sort of like on Star Trek.  Except hopefully the computer is brighter than that.  Think about it: First we had machine language, and we were “programming” by flipping switches on hardware.  That wasn’t anything like human language.  Then we had assembly, which is only like English insomuch as they both use letters (mostly).  Then we had things like C and C++, which were very language-like ... sort of English-adjacent.  Perl is a natural progression, to me.  It draws us even closer to natural langauge.  Whereas a language like Python seems to be taking us further away.9  I’m not going to sit here and tell you that I’m never going to switch away from Perl.  That would be short-sighted of me, and, if there’s one thing this personal history lesson has taught me, it’s that I always switch when a better language comes along.  But it has to be better.  The reason I usually say with some confidence that I doubt I’ll ever stop using Perl is simply that there doesn’t seem to be anything else out there that has evolved beyond where Perl is.  I’m looking for a language with even more context sensitivity, even more kitchen-sinkitude, even more linguistical structure.  The only thing right now that I see beating Perl is Perl ... Perl 6, that is.  But, remember, I write programs for myself a lot.  My primary goal is Getting Shit Done—that’s why I switched to Perl in the first place.  When Perl 6 gets to the point where it looks like I can Get Shit Done, I’ll probably leap over there so fast I’ll just be a blur in your retinas.  But right now a lot of the Perl 6 code I see is more academic, solving algorithmic problems and that sort of thing.  And there ain’t no DBI yet.  So I stick with Perl 5.

Besides, it’s hard as hell to evolve beyond Perl, because Perl keeps evolving.  And that’s where I’d like to go next week.


1 I mentioned way back in Part 1, in the comments, that there was another big reason I never got into hacking the Perl core despite my C background; well, there it is.


2 I qualify this specifically to avoid ridicule from any of my old friends who might be reading this, who would no doubt wish to remind me just how many cars I crashed in my misspent youth.


3 Well, technically it was lex and bison.  But you know what I mean.


4 Outside of “domo arigato,” which is less linguistics and more Styx.


5 Different friends with the Lisp and the Russian, obviously.


6 As opposed to a concentration in Literature, which is what most English degree programs are.  My school was one of the few who offered the choice.


7 Okay, maybe the statistics stuff would have come in handy a couple of times, but I’ve managed to survive without it.  So far.  Knocking on wood.


8 For that matter, I’ve known quite a few excellent coders who never even finished college, and one dead brilliant one who never bothered to finish high school.


9 I’m picking on Python a little, although after that sidebar we dissected last week, they probably deserve it.  But plenty of other langugages, like Java, could be substituted there.


4 Comments

An apt analogy. I'm no CS major either, and a lot of stuffs being posted here (like Marpa and theory of parsing series) went over my head. Nevertheless, I can still write parsers :)

That still isn't a reason to not work on the Perl core.

My first patch was to convert

while( readdir($dh) ){...}

into

while( defined( $_ = readdir($dh) ) ){...}

I don't even (really) know how to program in C.
I didn't even go to college, let alone take a class in compiler design.

I did take a (Visual Basic) programming class in high school, though I was already beyond what they were teaching in that class; having taught myself to program in VBA ( Visual Basic for Applications ) before then. ( At one point I also programmed in VBScript )

The mechanic vs. driver analogy is a good one. Being surrounded by mechanics in London.pm can intimidate when all I want to do is make stuff (or drive to the Cotswolds).

Thanks for the reminder :)

Leave a comment

About Buddy Burden

user-pic 14 years in California, 25 years in Perl, 34 years in computers, 55 years in bare feet.