In My Own Way, I Am Core
Is the DBI any less essential because Tim Bunce maintains it outside of the Perl core? It's the official database interface for Perl 5. It's well-maintained. It's comprehensive. It's stable. It has copious documentation, including at least one book. It's code no one's crazy enough to compete with.
It's not a core module, and no one cares that it's not a core module. It's still the way to access databases from Perl, regardless of any official or blessed or core status. It's just great code -- stable code -- that's been around for a while and does what it does very, very well.
It's still not a core module. If you use it, you've installed it yourself, your operating system vendor has included it, or the Perl distribution you've installed has included it.
Good. Bad. I'm the Guy with the Core.
A persistent difficulty of language designers is that we can't predict what users will want to do. We want to give them power and flexibility, but we also want to make languages that will fit in their heads and get out of the way when they don't need all of the features we've invented. The balancing act between "small is beautiful" and "complexity has to go somewhere" is difficult. So is finding the right balance between "Let's make it easy for the users!" and "Someone has to implement this beast!"
One rule I've tried to express here recently is "Someone has to maintain this beast!" For "beast", read "the core language", "the core libraries", or "the dependencies of my application." Here trouble begins.
If nothing ever changed in your application besides the changes you had to make, life would be peachy keen. Bacon would fall from the sky, and you'd get thinner and your cholesterol would improve when you ate it. You would not need to worry about operating system upgrades, or security patches, or new versions of dependencies, or what users had installed versus what you have installed. You would work a very comfortable 35 hour week and go home and sleep the sleep of the just.
You'd ride a magic pony to and from work, too. They eat bacon, but their breath is sweet. The world doesn't work that way.
Change is not the enemy though. Poorly managed change is the enemy.
The Book Awoke Something Dark in the Core. Something Evil.
Larry Wall and the rest of the Perl 6 design team like to talk about the Waterbed Theory of Complexity. You can take the Lisp or Forth approach of defining a very simple, easily understood core and building everything else in terms of that. "It's simple!" people say, until they start building real applications in that. One of the deepest lessons of computer science in The Little Schemer is that you can implement multiplication recursively with guard clauses and subtraction. One of the best lessons of software development is don't do that. Scheme is simple. Lisp is simple. Forth is simple. The SK calculus is simple. All of these are simple in theory, but doing practical programs may not be simple. There is an essential complexity in certain tasks that you cannot sweep under a rug. It will come out messy.
Put another way, Larry says that the Perl language can be messy because the problems it tries to solve are messy.
I suspect there's a similar theory of change. You can try to hide change, but mostly you just move it around. That's certainly true in the Perl core.
I'm Afraid I'm Gonna Have to Ask You to Leave the Core
The discussion I started with Sacrificing the Future on the Past's Golden Altar spread to p5p the other day. The question of replacing or enhancing File::Find came up, and someone raised the idea of adding an alternative to File::Find to the core.
I replied that that would make the problem worse, not better.
If I had my way, the Perl 5 core would contain the language itself and only those libraries absolutely necessary to download and install other libraries from the CPAN. That's it. There is no more. There's no Switch, or Class::Struct, or Search::Dict, or File::DosGlob, or File::Find in that core.
There'd be no ExtUtils::MakeMaker either, but that's aesthetics, not function or flourish.
I'll Swallow Your Core!
Clearly the core zeitgeist has gone in another direction. You don't swallow the core. It swallows you. There's no better explanation than Nicholas Clark's description of why people want modules to enter the core:
The Perl core is already installed. But they can't get approval to install other modules from CPAN.
[Bad programmer. You're trying to burden someone else with a long term technical problem because you've failed to address your local political problems]
They perceive modules in core as being "blessed" - if it's there it must be better than all the competitors on CPAN]
[Bad programmer. Historically things have only ever been added to the core. Reasons for its addition at the time may not be as clear cut as you infer, and there may now be a better solution. You're trying to burden someone else with a long term technical problem because you're falsely lazy, excessively inpatient and insufficiently hubristic to devise your own criteria for selecting the right module for the job]
They perceive modules in core as being "supported" - if it's there, it will be looked after for ever.
[Bad programmer. You appear to think that the mere mortals volunteering to maintain the core are of a difference species than the mere mortals volunteering their code to CPAN]
In other words, "please maintain my dependencies for me!"
I agree that change can be painful, and that arbitrary changes are unpleasant and not useful. No one's arguing for those (at least no one who isn't a violent time-traveling sociopath with a chainsaw for a hand).
However.
We Are But Sixty Men
This is not your rug, and you are not welcome to sweep your change management problems under it.
The core developers can provide you with a great language -- a modern language -- designed to help you solve problems that no one can forsee now. They can provide you with mechanisms to extend the language in reusable and shareable ways. They can encourage experimentation with new features and ideas with the intent of pulling those ideas into the core in future versions if they prove useful. They can even maintain well-defined backwards compatibility and keep promises not to break thing arbitrarily.
They cannot do so and take on an ever-increasing maintenence load. Coordinating the release cycles of the core language and dual-lived modules and version numbers and multiple authors with their own time schedules and multiple queues and venues for bug reports and feature requests and patches... well, that's madness.
The DarkPAN is and shall remain impenetrable. That's fine -- but that means the DarkPAN has to take responsibility for its own code. It's just not possible for the core to do so any longer.
