Apprenticeship Patterns: My First Language

The first language I ever learned well enough to really command was Perl. Before that I coded the occasional short recipe in Basic. I even did a smattering of Visual Basic. I fiddled with Delphi. I made several attempts at Java, but to no avail. At one point I even downloaded and printed a huge stack of Eiffel documentation (read the first couple pages). Back in college I coded in Pascal, and got good grades, but never felt like I was really fluent. I even coded in FORTRAN for a numerical methods math class. It was a blast, but I didn’t own a copy of FORTRAN, and didn’t understand its execution environment. But somehow, when I delved into a Teach Yourself Perl in 21 Days book, it just clicked. Perl was the first programming language that I ever really loved. Whenever possible, I read that book while sitting at a computer. This was so that as soon as I encountered a code snippet, I could immediately type it in and then start tweaking it.

Making Perl My Batch

One reason I loved Perl was that, for me, its operating environment was very easy to understand. You have this executable program, perl.exe. You write scripts in plain text. You run the executable, passing the filename as a parameter. Perl.exe reads the script and does what you intended it to do. Easy. No make files. No linking. No memory management. It let me go straight past all that chip-head junk and just do stuff that I’d actually want to do.

I also think that Perl scratched the itch I had developed through rather extensive writing of DOS batch files (my day job). Perl was simple enough for me to learn quickly, and provided so many of the features I had come to really wish for in DOS batch. I remember how excited I was to be working with real live flow control structures.

Peace Love And Understanding

Furthermore, Perl —or more accurately, the Perl community— was also very non-judgemental. They liked to say “there is more than one way to skin a cat.” Larry Wall, the creator of Perl, said that the language was purposefully designed to be apprehended in different ways and at different levels by the novice, the intermediate and master programmer. I liked that. Rather than worry that my code might not be completely proper, I felt free to just launch in. And as my organic piles of code began to collapse beneath their own weight, I had the opportunity to learn first-hand the basic tenets of clean code cultivation. Eventually I came to be a rather opinionated Perl programmer. But at the beginning, I appreciated working in a language touted as accessible to horrible coders. So what if my code took 15 lines to do what a Perl master could do in one? I still accomplished what I wanted to do. And writing 14 extra lines of code is not the end of the world. Eventually I came to value readable Perl code over hopelessly cool and dense obfuscation, and I’d settle for the five line version. When you have coded cleanly in Perl, you have under-promised and over-delivered.

After reading several chapters of the Teach Yourself book (but before getting to the chapters on Object Oriented Perl), I started working on a real-live application of my own. Back in the days before wikis, I wrote a wiki. Well, kinda. I called it a Document Management System. You logged in, and found yourself on a kind of home/default/landing page. There was a list of titles down the right-hand side. Click one of them, and you could view it. You could also create or edit any of the documents, using plain HTML to nicely format the page. Then I began reading about Object Oriented Perl, and suddenly the DMS just wasn’t good enough anymore. Now I wanted it to be object oriented.

Hacker For Hire

Soon I got a gig, coding CGI scripts for a local web designer. That was fun. It was also harrowing. Welcome to legacy spaghetti in Perl. I learned to gather requirements very carefully, guarding against scope creep and hidden complexity. I also began to learn why some codebases are fun and easy to maintain, while others are positively a nightmare. And I experienced the refactoring pain which ultimately prepared me to embrace TDD. Nonetheless, the first gig was fun, and I started thinking, “you know, my next job is going to be a Perl programming job.”

And so it was. I got a job working for a dot-com, with a small, distributed team of Perl programmers. Up to that point I didn’t actually know any other Perl programmers personally. I learned from books, from the Internet, and by experimenting. In hindsight I think that failing to connect with some other Perl programmers in the early days was a real mistake. So working at the dot-com gave me a chance to learn from some excellent programmers. And I learned to respect and strengthen our team’s coding conventions. Some of the conventions I liked and internalized. Others I didn’t agree with, but I observed them nonetheless. Perl is so permissive that Perl programmers soon learn that if they want to work as a team, they must lay down a few team ground rules for code they maintain together, or soon they will drive each other crazy.

After I left the dot-com (they ran low on money) I went to work as a database developer. Predominantly I wrote SQL queries and stored procedures using TSQL and PL/SQL. But once in a while someone would come to me and say, “Joel, I need to know something about the data which is spread across these 25 files. Can you help me?” And I would write a 12 line Perl program to give them the information they needed. And I began to really love Perl for its power in creating use-once, throw-away programs. Sometimes, when someone came back to me with the same or a similar problem, I’d be able to find the script I wrote before and re-use it. Often I couldn’t find what I was looking for, so I’d just code it all over again. Well-designed, reusable code is best, but fast and dirty throwaway code ain’t bad eiter. Today, as I learn to talk like the cool kids, I tend to call such code a “spike.”

That’s No Perl, That’s A Death Star

Throughout the years that I used Perl, I really learned to savor the culture of the Perl community. They are brilliant folks, and often they seem to have a quirky outlook which I appreciate very much (no wonder my first Ruby book was Why’s Poignant Guide!). The leading masters in the Perl community were miles ahead of me, both in coding skill and in their understanding of elusive, abstract concepts. All the reading and hacking that I did throughout those years helped to stretch my mind, and to remind me that I had a long ways to go.

This experience taught me the value of turning to powerful programming languages to solve problems, mine data for answers and automate tedious tasks. What I feel Perl did not give me was a really solid understanding of Object Oriented design. For that I would finally return to Java, and then soon after, to Ruby. But those are other stories for other days.