Perl is Dead. Python is the New Java.
I like to use Perl to quickly carve out prototypes.
In order to solve a problem well, I believe that you first have to attempt to solve the problem. You never fully understand the issues involved with solving a particular problem until you attempt that first solution…at which point you will be well prepared to start from scratch and actually develop a good solution.
In other words, your first solution is probably not the solution, but the effort involved with attempting to solve the problem will give you valuable insights into how to actually solve the problem.
So, I like to use Perl to develop that first software solution if I can.
I can guess what you’re thinking…
Perl is ugly. Perl is hard to read. Perl is a dead. Everyone hates Perl. Why use Perl when you could use Python?
Haters gonna hate.
I keep Perl in my back pocket as my own secret weapon.
To address that question about Python:
Execution Profilers and Debuggers
I write scripts quickly, from the command line. I never assume that I will have access to a desktop environment. I don’t want to have to go and download something like PyCharm — which requires a desktop environment — just so that I can get a good, robust debugger and a good profiler. Sometimes it’s simply not possible to put a desktop environment on the target system where I’m running my code.
To quote Steve McConnell, from Code Complete: A Practical Handbook of Software Construction, Second Edition:
An execution profiler watches your code while it runs and tells you how many times each statement is executed or how much time the program spends on each statement or execution path. Profiling your code while it’s running is like having a doctor press a stethoscope to your chest and tell you to cough. It gives you insight into how your program works, where the hotspots are, and where you should focus your code-tuning efforts.
Many programming languages — Python included — sorely lack a high quality, free, and open source execution profiler like the incredible Devel::NYTProf. Python’s execution profiler looks like a toy compared to Devel::NYTProf.
For a demo of Devel::NYTProf, check out Tim Bunce’s talk: Performance Profiling with Devel::NYTProf.
Note that Devel::NYTProf doesn’t need a desktop environment to collect great metadata about the performance of a Perl script, but you do need one to review Devel::NYTProf’s output. I’m fine with that kind of trade-off.
To be fair, Perl does not come with an execution profiler built into the core language, the way Python does. It may be more fair to compare Devel::NYTProf to Kunal Bhalla’s Panopticon, although Panopticon seems to be almost completely brand new — with its first commit to github occurring on May 3, 2020. I haven’t had an opportunity to try Panopticon yet, but it does seem to have the potential to finally be the answer to this particular criticism that I’ve had of the python ecosystem.
In Hacking: The Art of Exploitation, Jon Erickson wrote:
A programmer who has never used a debugger to look at the inner workings of a program is like a seventeenth-century doctor who has never used a microscope. Similar to a microscope, a debugger allows a hacker to observe the microscopic world of machine code — but a debugger is far more powerful than this metaphor allows. Unlike a microscope, a debugger can view the execution from all angles, pause it, and change anything along the way.
perl -d to be more robust than
pdb , though I know that’s a matter of preference and taste.
Python Mitigates Business Risk
I am comfortable reading and writing Python code — and would gladly do lots of that, if it helped me pay my bills — but…
Python is officially the new Java. It’s the premiere language for corporate software development.
To its credit, Python has attributes that force lazy or inexperienced programmers to be more disciplined as they develop their code. It does abstraction well enough, which means that in many cases it’s easier for junior programmers to wield powerful automation without earning the knowledge for themselves about how it actually works. And, of course, Python has a massive community of developers, which means lots of new ideas get implemented in Python today.
Some time ago I had a flat tyre and called the road patrol to help me out. The mechanic asked about my living and when I used the word “software” in my answer, he smiled and started talking very enthousiastically about his own passion: programming in Python. From that moment on, I knew Python would become ubiquitous — Paul Jansen CEO TIOBE Software
Those attributes are assets if you manage a software development project. They make it possible for you to build a team of less skilled, less experienced, and less expensive programmers. The pool of Python programmers is much larger, compared to the pool of programmers of almost any other language, except for maybe Java. You can get the job done for less money and less risk, if you choose Python over a different programming language, because your people become more interchangeable and disposable.
A big reason why Python is so popular is because of how well it mitigates business risk.
Python is a Blub Language
I tend to think of Python as a Blub programming language, as described by Paul Graham in his essay “Beating the Averages”:
Programmers get very attached to their favorite languages, and I don’t want to hurt anyone’s feelings, so to explain this point I’m going to use a hypothetical language called Blub. Blub falls right in the middle of the abstractness continuum. It is not the most powerful language, but it is more powerful than Cobol or machine language.
And in fact, our hypothetical Blub programmer wouldn’t use either of them. Of course he wouldn’t program in machine language. That’s what compilers are for. And as for Cobol, he doesn’t know how anyone can get anything done with it. It doesn’t even have x (Blub feature of your choice).
As long as our hypothetical Blub programmer is looking down the power continuum, he knows he’s looking down. Languages less powerful than Blub are obviously less powerful, because they’re missing some feature he’s used to. But when our hypothetical Blub programmer looks in the other direction, up the power continuum, he doesn’t realize he’s looking up. What he sees are merely weird languages. He probably considers them about equivalent in power to Blub, but with all this other hairy stuff thrown in as well. Blub is good enough for him, because he thinks in Blub.
When we switch to the point of view of a programmer using any of the languages higher up the power continuum, however, we find that he in turn looks down upon Blub. How can you get anything done in Blub? It doesn’t even have y.
Blub programming languages help pay the bills, and mitigate business risk. But they don’t help you improve past a certain point as problem solver and a critical thinker.
What has been, for me, the most mind-expanding programming language? LISP.
To quote Eric Steven Raymond from his manifesto “How To Become A Hacker”:
LISP is worth learning for a different reason — the profound enlightenment experience you will have when you finally get it. That experience will make you a better programmer for the rest of your days, even if you never actually use LISP itself a lot.
He’s not wrong! I’ve had that exact type of experience with LISP.
I’ve found LISP to be a lot like Linux — there are many different kinds of implementations of LISP in the same way that there are many kinds of Linux distributions.
Which implementation of LISP is my favorite, so far? Clojure. But that’s a topic for another post.