zlacker

> "More than one way to do it" is Perl's motto, because of its audacious experimentation ethos, I'd say.

Perl lets every developer write Perl in their own idiosyncratic way.

And every developer does.

It makes for very un-fun times when I'm having to read a file that's been authored by ten developers over ten years, each of whom with varying opinions and skill levels.

I guess in 2026, it'll be 11 developers writing it over 11 years. My sincere apologies to those who come after me, and my sincere fuck-you to those who came before me. :)

>>pavel_+(OP)
> in 2026, it'll be 11 developers writing it over 11 years.

Perhaps too, a tool that's been around and in active maintenance for 11 years has been wildly successful.

>>pavel_+(OP)
Something I only figured out in the ‘10s is that the main tax of code smells is during debugging. Debugging when taken to the level of art is less about sorting all of the possible causes for a problem by likelihood but by ease of validation.

Things that are cheap to check should be checked first unless they are really unlikely. You change the numbers game from trying to make the biggest cleaving lines possible, to smaller bites that can be done rapidly (and perhaps more importantly, mentally cheaply).

Code smells chum the waters. Because where there is smoke sometimes there is fire, and code smells often hide bugs. You get into Tony Hoare’s Turing award speech; either no bugs are obvious, or there are no obvious bugs.

So I end up making the change easy and then making the easy change because we have more code each week so the existing code needs to be simpler if someone is going to continue to understand the entire thing.

Perl doesn’t seem to have figured this out at all.

>>pavel_+(OP)
Exactly. Perl is about experimenting, trying things your way, and discovering new and good ways to write programs. Which is a wonderful capability for research and discovery, and for art or recreation, but not that great for industrial production.

This is why Perl was quite fit for the job at the dawn, or, rather, the detonation phase of the Internet explosion in late 1980s and early 1990s, along with Lisp and Smalltalk that promote similar DIY wizardry values. But once the industry actually appeared and started to mature, more teamwork-friendly languages like Java, PHP, and Python started to take over.

>>creer+91
I wouldn't say "wildly". I would say that it's critical enough to the company's workings that they devote enough resources to it to keep it going, but not enough resources to consider re-writing it or re-factoring it to be easier to work on.