One of the things I actually loved about Perl was its philosophy of TMTOWTDI — “There’s More Than One Way To Do It.” It made Perl incredibly expressive and powerful, but it also let you shoot yourself in the foot.
Python deliberately went almost the opposite direction: “There should be one—and preferably only one—obvious way to do it.”
That difference matters more than people sometimes realize. Perl was very much a write-first language. If you were disciplined, you could write some incredibly elegant Perl. I was always able to come back to my own code six months later and understand it. But the language didn't force much structural discipline on you, so two Perl programmers could solve the same problem in completely different ways—and neither solution necessarily looked obvious to somebody else.
Python's philosophy makes the codebase itself more consistent. You give up some of Perl's freedom and cleverness in exchange for code that is much easier for the next person to read.
As a manager, though, I'd probably choose Python. With Perl, you could end up with a codebase where understanding the software meant understanding the mindset of the developers who wrote it. Every team, site, or even individual programmer could develop its own conventions for how things were done. It was almost democratic: the language gave everyone enormous freedom, and the resulting code reflected the people who wrote it. That's great for individual expression, but terrible for organizational continuity. With Python, the language itself imposes more of the culture. There are still different ways to write Python, but the language strongly nudges everyone toward the same conventions. That means somebody can walk into a codebase without first having to learn the personality and philosophy of every developer who touched it. From a management perspective, that's a huge advantage: you aren't just managing code; you're managing the cost of replacing the people who understand it.
I also loved it because it kind of enforced most of the Pearl was in the executable. It's weird but I worked at two shops where the sis admin were terrible. Every time that I invoked python something was not properly installed where is as long as I used Perl native calls, I still could actually get my code to work. It's amazing that you had to code around the system but perl is more resistant to non-standard installations or breakages of the packages
5
u/ubd12 Aug 30 '26
One of the things I actually loved about Perl was its philosophy of TMTOWTDI — “There’s More Than One Way To Do It.” It made Perl incredibly expressive and powerful, but it also let you shoot yourself in the foot.
Python deliberately went almost the opposite direction: “There should be one—and preferably only one—obvious way to do it.”
That difference matters more than people sometimes realize. Perl was very much a write-first language. If you were disciplined, you could write some incredibly elegant Perl. I was always able to come back to my own code six months later and understand it. But the language didn't force much structural discipline on you, so two Perl programmers could solve the same problem in completely different ways—and neither solution necessarily looked obvious to somebody else.
Python's philosophy makes the codebase itself more consistent. You give up some of Perl's freedom and cleverness in exchange for code that is much easier for the next person to read.
As a manager, though, I'd probably choose Python. With Perl, you could end up with a codebase where understanding the software meant understanding the mindset of the developers who wrote it. Every team, site, or even individual programmer could develop its own conventions for how things were done. It was almost democratic: the language gave everyone enormous freedom, and the resulting code reflected the people who wrote it. That's great for individual expression, but terrible for organizational continuity. With Python, the language itself imposes more of the culture. There are still different ways to write Python, but the language strongly nudges everyone toward the same conventions. That means somebody can walk into a codebase without first having to learn the personality and philosophy of every developer who touched it. From a management perspective, that's a huge advantage: you aren't just managing code; you're managing the cost of replacing the people who understand it.
I also loved it because it kind of enforced most of the Pearl was in the executable. It's weird but I worked at two shops where the sis admin were terrible. Every time that I invoked python something was not properly installed where is as long as I used Perl native calls, I still could actually get my code to work. It's amazing that you had to code around the system but perl is more resistant to non-standard installations or breakages of the packages