6 ms·
As both a long time Perl and long time Python user who has seen both used in production, here are some of my thoughts: Perl - Was an easy jump from bash to Pe
by alexpotato 1y ago
As both a long time Perl and long time Python user who has seen both used in production, here are some of my thoughts:
Perl
- Was an easy jump from bash to Perl
- Perl never felt like it "got in the way"
- was WAY too easy to write "write only code"
- that being said, I learned Java first and most people found MY Perl code to be very legible
- regexes as first class citizen were amazing
- backwards compatible is GREAT for older systems still running Perl (looking at you banks and some hedge funds)
Python
- Forced indentation made it MUCH easier to read other people's code
- everything is an object from day one was much better than "bless" in Perl
- no standard way of setting up an environment for MANY years hurt
- sklearn and being taught in universities were real game changers
- j45 1y agoArticles that poopoo on one language kind of have a dated all/nothing perspective. Most languages have a decent enough framework or two that the differences between using them for different use cases may be closer than many folks realize vs whatever we hear about as the new hotness through the grapevine. A mess can be made in a lot of languages, and a long time ago, it was even easier, except some of that code worked and it didn't get touched for a long time.
- burnt-resistor 1y agoToolbox vs. religious zealotry. Sometimes, one has to maintain .bat files, Tcl, F77, or COBOL. Professionals don't whine or wince, but do the job.
- j45 1y agoAbsolutely. Bytecode doesn't care what compiled it to bytecode. Customers also do not really care what something is or isn't built in, except if the product is made for developers. The vast majority of products are made for non-developers.
- shermantanktop 1y ago> no standard way of setting up an environment for MANY years hurt Serious question: is that solved? I still see a forest of options, some of which depend on each other, and at last count my laptop has 38 python binaries. What's the standard way?
- makeworld 1y agouv. https://docs.astral.sh/uv/ https://docs.astral.sh/uv/
- hsbauauvhabzb 1y agoIt’s hard to call that standard, it’s just the latest hn rust craze idolisation.
- sgarland 1y agoSure, but it’s demonstrably better than Poetry, which was the best until uv. If uv isn’t a standard, it’s because not enough people have tried it. It is obscenely good at its job.
- cozzyd 1y agostandard You keep using that word, I don't think it means what you think it means.
- bigiain 1y ago"Prepare to die."
- nurettin 1y agoFalse dichotomy. Been using pipenv for 8 years. At first it was a bit too slow, but at this moment it gets the job done.
- slightwinder 1y ago
- m463 1y ago> - no standard way of setting up an environment for MANY years hurt I will say coming from years of perl that python had a refreshing amount of "batteries included" via the standard library. It was only rarely that my code needed "outside help", usually something like requests or numpy. I suspect this is because I used python in the same environment as perl, automating unixy kinds of things. I suspect "setting up an environment" is because python has been so successful, becoming an enormously broad general language.
- bigiain 1y agoAwww, come on. cgi-lib.pl was all you really needed! <smirk>
- jjgreen 1y agoPerl was my first scripting language, I occasionally need to run some of those old scripts (15-20 years old), they always run. Python scripts last 6-12 months.
- bell-cot 1y agoSo if job security was a high priority for you, ...
- zelphirkalt 1y ago> Python scripts last 6-12 months. Not, if you know what you are doing.
- alexpotato 1y ago"You're holding it wrong" ;-)
- zelphirkalt 1y agoI mean, if you are not able to make a reproducible virtual environment, by using one of the popular package managers, like Poetry or uv, then yes, you are holding it wrong. If you are relying on requirements.txt merely pinning versions and not transitive dependencies, then yes, you are holding it wrong. In that case it would be a skill issue.
- zahlman 1y ago> If you are relying on requirements.txt merely pinning versions and not transitive dependencies, then yes, you are holding it wrong. Even then, if you have the original environment, you may very well not need to re-create it. If you do need to re-create an equivalent for a newer Python version (EOL versions of Python don't just spontaneously vanish, but maybe you upgraded your system or something, or better yet maybe you're planning in advance for that) then you generally can easily create the needed requirements.txt (or, for that matter, a PEP 751 lockfile) from the old environment.
- somat 1y agoI never did much perl, what is the standard way to setup a perl environment? CPAN?