Idle Core Thoughts

chromatic on 2004-09-26T21:09:40

Once a module goes into the core of Perl 5, it stays there forever, for good or evil. Having written tests for a chunk of core modules, some of that code isn't very good. (In 2004, we know a lot more about good Perl 5 programming than anyone did in 1995, so please don't read into that sentence more than I intend.) Some of the interfaces are terrible.

Will those modules ever go away? Unlikely. Backwards compatibility is important. Will those modules ever have interface-compatible replacements? Maybe someday, but how will you convince people to use them?

I wonder, idly, if every core module became dual-lived, distributed in the core and on the CPAN, if someone could write Bundle::CoreModules, keep it up to date, and the core could grow smaller.

Yes, there's still a problem with those people who compile Perl themselves apart from vendor packages, but I'd be surprised if those people don't have the technical saavy to download and install such a bundle somehow.

That leaves shops who refuse to install anything not distributed with the core. It's too bad that business stupidity isn't more lethal (to businesses).

There may be drawbacks I don't see right now, but the idle thought has a lot of appeal at the moment.


Business Stupidity

Ovid on 2004-09-26T21:26:23

It's too bad that business stupidity isn't more lethal (to businesses).

I frequently hear programmers talk longingly about how their competitor's products are so much more professional and must be better written. However, I've sometimes had a chance to see the competition's code or talk to their developers and their developers have the exact same thoughts. Somehow everyone knows that the grass really isn't greener except when it applies to their own situation.

The reason that businesses don't do a better job, though it's not always apparent from the outside, is the problem of satisficing behavior. This is the "minimum necessary to survive" behavior. If your project is far removed from the core business, this is OK. However, if it is the core business, this is abysmal. This behavior isn't lethal to companies because so many other companies engage in satisficing behavior rather than optimal behavior that it lowers the bar for everyone. As a result, businesses are more loathe to take risks unless they are forced to -- when it's often too late -- but anything "new" automatically gets perceived as a risk because it's unknown, despite the fact that even cursory research can reveal how illusory that risk actually is.

When one contrasts that to Paul Graham and Robert Morris' success with Lisp and the software that eventually became Yahoo! Store, one sees that there's actually tons of potential out there. Now to convince people to exploit that potential.

Perhaps seperate out into Core and Standard lib

TeeJay on 2004-09-27T11:01:11

Perhaps it would be worth seperating Core from Standard Libraries. Core is now so large that it might benefit from some hierarchal organisation into core (builtin and essential), standard and common.

Looking at what is included in things like NMS and or required by commonly used modules like DBI would help categorise which modules should be organised where.

It would also be nicer if openssl, etc were integrated into the core so that users had things like SSL, mysql, etc working 'out-of-the-box'.