Front page | perl.perl5.porters |
Postings from June 2011
Perl with batteries included?
Thread Next
From:
David Golden
Date:
June 13, 2011 14:16
Subject:
Perl with batteries included?
Message ID:
BANLkTi=o9WZ0Tu_2R=bGxZ7-qvYeYhxgaw@mail.gmail.com
(This email is inspired by the debate on __SUB__, but I want to open a
more general discussion.)
I'm periodically taken aback by the intense reluctance I sense from
some about innovating within Perl 5 and I think the crux of it is a
lack of a common vision (or even an imposed vision from an authority
figure) for how Perl should evolve and a corresponding set of
principles for how to make design decisions. Without a formal design
proposal and review process like other languages have, Perl 5's
evolution is a sort of random walk that occurs when the right
combination of inspiration and implementor are sufficient to overcome
inertia from a sort of cultural resistance.
The question I have is whether that inertia is too high (or too low, I
suppose) first in general and then in more specific cases, and on what
basis we could use to guide decisions. (I note that this is
apparently an issue even for documentation changes, not just code.)
perlhack cites these general considerations for good patches:
* Fast simple and useful
* Orthogonal features and concepts
* No arbitrary limits (platforms, data sizes, cultures)
* Open and exciting to use/advocate Perl
* Assimilate or bridge to new technologies
These questions are posed:
* Breaks backwards compatibility? (noted as "a cardinal sin")
* Could it be a module? (there is a suggestion prototype in CPAN
before considering for core)
* Generic enough?
* Does it preclude other features?
The other considerations I'll summarize as mostly "is it well engineered?"
In particular, the guidance of "could it be a module" suggests CPAN is
a prototype for the core, not a replacement for implementation in
core, which I don't think actually helps address the question of what
should or shouldn't be CPAN or not.
As I thought exercise, I thought of two extreme variations of the Perl
5 interpreter:
(a) core interpreter has only enough syntax to load modules, all
other syntax provided by modules
(b) core interpreter implements in syntax of every great CPAN moduleg
Neither is realistic, but on what basis do we find a middle ground?
Option (a) has the downside of "cluttering" every program with a host
of library load calls (or a meta-loader like Modern::Perl). I would
find that to be a sad throwback to my days of doing C and needing
"#include <stdio.h>" just to print. Option (b) could have a high
maintenance burden.
So here are some of my initial thoughts on criteria:
(1) Is the addition likely to be a commonly used feature by the
"average" programmer? If so, more appropriate for core.
(2) Is the addition something for which there is only one correct
answer or one way to do it? if so, more appropriate for core. To me,
that means that anything with more than one or two arguments/operands
or that could return different things depending on context could have
some debate over the right API and is less appropriate for core.
File::Slurp and read_file is a great example. I'd love a core "slurp"
but File::Slurp shows the many variations (for good reason) that make
it tricky to know the right defaults.
(3) Is it necessary for correctly implementing some algorithm or
technique? If so, more appropriate. E.g. Scalar::Util and weaken()
come to mind
(4) Does it simplify some frequently misused technique or make a
common bug less likely? If so, more appropriate. E.g. Try::Tiny or
Scalar::Util::blessed() come to mind, as does the new s///r syntax.
What do people think of those? What other criteria would you consider?
-- David
Thread Next
-
Perl with batteries included?
by David Golden