develooper Front page | perl.perl5.porters | Postings from November 2021

Re: =?utf-8?B?Q29yZeKAmXM=?= purpose

From:
Nicholas Clark
Date:
November 27, 2021 10:39
Subject:
Re: =?utf-8?B?Q29yZeKAmXM=?= purpose
Message ID:
YaIK5NY0OufRuV6t@etla.org
On Sat, Nov 27, 2021 at 02:09:37PM +0400, Elvin Aslanov wrote:
> If it's a standard way to access databases with Perl it should be in Core,
> I think, no matter how complicated.

Requesting something "no matter how complicated" is creating work for
other people.

In the general case "One Standard" in the core is "One Standard Frozen
Forever" because it stifles innovation and uptake on better approaches.

DBI seems to have got things correct enough that it hasn't been overtaken,
but had (say) Class::DBI gone into core, likely DBIx::Class would have had
a hard time improving on it.

Whilst this is true:

On Fri, Nov 26, 2021 at 01:48:20PM +0000, Neil Bowers wrote:

> As you say, where we want Perl to be considered "a great language for doing X", then you should be able to "do X" out of the box.

you can't do this for all X.

You have to be very choosy about which X this applies to, else you're
basically attempting to bundle all of CPAN.


For example, in the past decade or so, I've had exactly *one* project
involving CSV files (for which Text::CSV_XS was great). But a bunch more
things involving image processing, so a lot of use of Imager (and Imager
subclasses). Which no-one has mentioned (yet). And I'm really not
suggesting we bundle.


It's easy (enough) to add modules. But it's kind of a promise that "they
will be included forever", at which point people start to rely on them.
Meaning that it's harder to get rid of them again, if you make mistakes.

(Hey, maybe Soundex doesn't matter any more because we're not trying to
be conformant with a FIPS tickybox requirement. Times changed)

"Batteries included" isn't a sure fire winning strategy:

http://radar.oreilly.com/2013/10/dead-batteries-included.html
https://pyfound.blogspot.com/2019/05/amber-brown-batteries-included-but.html


You also have this problem that a chunk of the userbase can install
*modules* easily, but not upgrade their perl binary. Sure, in theory having
all the bundled things be "dual life" *should* make this "not a problem",
but most Linux distributions *don't* unbundle dual-life modules into
separate packages, meaning that they don't upgrade their packaged versions
(short of an OS upgrade) for dual life modules. Whereas unbundled modules
might well be upgraded.

This might make some sense. If they are shipping a package that declares
itself to be perl 5.28.1, some users might expect it to be *exactly* the
package versions shipped in our tarball for
https://github.com/Perl/perl5/releases/tag/v5.28.1

(with only portability and bug fixes)

Meaning that an unintended consequence of bundling modules into the core
might mean that it's actually *harder* for part of the userbase to get
current versions, or just update the modules they rely on.

Nicholas Clark



nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About