No matter where Perl may be today, it would be difficult to overstate its importance in the late 1990s. Back then, coders weren’t merely excited -- they were absolutely ecstatic about the Perl programming language. It was the interpreted language of our dreams, and damn near everything was written in it: big Web apps like Movable Type, big sites like IMDB, and untold billions of lines of internal code for businesses large and small.
Perl could (and still can) handily undergird both a 10-line script for a sys admin or a million-line business intelligence app. Part of the reason is that Perl has always adhered to the concept of TIMTOWTDI: There’s more than one way to do it.
However, today Perl is largely on the sidelines. While existing Perl apps are being maintained, the prevailing sense in most parts of the computing world is that the wind has left Perl’s sails. In most cases, Perl is being marginalized by a collection of languages, not a single successor. But chief among these might be Python, which has taken the place long filled by Perl for raw interpreted scripting. That change is not simply about syntax, design, or scalability, but may also be due to the fact that Python eschews the very essence of Perl and adheres to a different mantra: There should be only one obvious way to do it.
One of the most significant drawbacks in any sufficiently large Perl project is code readability. Because there are so many ways to perform the same, simple function in Perl, projects with many collaborators can produce functional code that looks like Frankenstein’s monster, which reduces readability for even seasoned developers. Python, in contrast, is designed around readability, almost to a fault. While Python’s readability assists in the future management of the code, it also forces conventions that seem wasteful to developers steeped in Perl or even C.
This is why we have multiple options in computer languages. If there were a perfect language, we’d all be using it, right? (Please note tongue firmly planted in cheek.) Sometimes we need the flexibility, though at this stage of the game we are almost always able to get where we need to be in nearly any language. The question is how painful the journey is likely to be.
This is a core tenet of all things IT, not only development. We’ve all seen Excel spreadsheets that appear to violate the laws of physics and/or thermodynamics in their complexity because Excel was the only tool someone had in their arsenal to complete the task. We’ve seen system and service configurations that are horrendously, needlessly complex, yet still function properly. We see a developer in one language write a function in 1,000 lines that a developer in another (or even the same) language writes in 100.
You see, the concept of TIMTOWTDI extends beyond singular computer languages or operating systems. It encompasses IT itself.
We don’t have zoning laws and building codes. We don’t have inspectors (other than perhaps within ourselves) that vet and approve software and IT infrastructure design plans. We may issue pull requests on GitHub, but there’s no official standards body or documentation that can be referenced as an immutable authority on the code we’ve written. It’s all subjective, and any idiot with a computer can start to build things -- which sometimes leads to great things.
Historically, we’ve needed that freedom because we’ve created all kinds of items that never existed before. We’ve learned from our mistakes (coupled with the wonderful ability to fix problems with new versions and patches -- a luxury note enjoyed with physical construction projects). After all, you may need to color outside the lines to create a wholly new object.
That said, not everyone is developing code or building computing infrastructures that ride the ragged edge of computing. Most of us are either duplicating an item that already exists, such as building an enterprise server infrastructure, or altering known and accepted practices to fit a new need, such as writing an API for a unique mobile app.
If you find yourself struggling with a seemingly insurmountable problem, the best idea is to stop and figure out whether you’re looking for a new answer, or if you should be asking a different question altogether. Perhaps your issue isn’t with how to make your plan work, but rather with the plan itself -- there may be more than one way to do it.
We don’t need to reinvent the wheel most of the time, but we need to recognize when we do and know that we can.