@lanodan for me, it's a second language after compiled into native code.

It's easy to prototype in it, write code. You actually don't need dependencies that much, everything is possible with bloated yet powerful standard library.

Probably a community of low qualified programmers made it worse, but you can say the same about any popular programming language, to be honest.
@a1ba if it would be just community code that would be bearable.

Python basically threw out having a consistent build system and test framework.
And there is the typical mess of python breaking API at each new major.minor version, meaning that you *need* testsuites.

Meanwhile Perl isn't a language that I like, it's syntax is quite a mess and I wish it would come with a REPL but at least I can rely on it and packaging+maintaining perl things is fine.

@lanodan That's because Perl 6 never saw wide adoption and Perl 5 was dormant for what, 15 years already?
I think most modern distros and OSes still come with it because everyone is lazy to rewrite the perl parts. If Git itself wasn't disgusting I'd find it disgusting that it uses Perl 😅
Python on the other hand is finding more and more uses. That is why it's so fscked up. I like some changes e.g. they've made async part of the language, but yeah, a lot of stuff that gets added is cursed.
@a1ba

@m0xee @a1ba Perl5 isn't dead, there is still changes in it, specially in the included libraries, it's just that most people forget them because there is barely ever any breakages, which are often caught early because testers can send their results to CPAN.

For example this is what 5.36.0 (newest branch) got: https://perldoc.perl.org/perl5360delta

It's like if you would say that C89 is the same thing as C11 and the incoming C2x.

Meanwhile Python just breaks every 6 months.

t. packager of numerous things (C, perl, python, ruby, Go, …)
@lanodan @a1ba @m0xee what sort of drugs do python devs take to justify breaking things every minor version
@meeper @a1ba @m0xee They should at least try to nicely deprecate things, this way you have a buffer of at least one version to update your code.

@lanodan @a1ba @meeper They do it. If you take a look at std library reference you'll find a lot of deprecation notes. They are just not too prudent at it I suppose 🤷🏿‍♀️

@m0xee @a1ba @meeper I meant with tagging the APIs so it creates things like warnings, expecting to check the documentation is a mess, specially as I tend to refer to the old one if I'm developing for an ~old system (say debian stable) while my machine tends to run more current versions (and so would trigger a warning).
Follow

@lanodan @a1ba @meeper
>creates things like warnings, expecting to check the documentation is a mess
Yes, this would definitely be better. Not that long ago I was updating a script written for 3.5 to 3.7 or something like that. Most changes were so minor that you could fix it with a few sed runs, but I'd appreciate if they had a standard tool to facilitate that. They've had 2to3 after all, why not for different 3.x versions.

Sign in to participate in the conversation
Librem Social

Librem Social is an opt-in public network. Messages are shared under Creative Commons BY-SA 4.0 license terms. Policy.

Stay safe. Please abide by our code of conduct.

(Source code)

image/svg+xml Librem Chat image/svg+xml