Front page | perl.perl5.porters |
Postings from September 2014
Re: Roadmap/plan for Perl 5?
Thread Previous
|
Thread Next
From:
Sawyer X
Date:
September 7, 2014 08:55
Subject:
Re: Roadmap/plan for Perl 5?
Message ID:
CAMvkq_R4fJ9N7XGEFPsUffv5vuNCP3T0zqrS4PztsziQZc+KpQ@mail.gmail.com
-- tl;dr at the bottom --
On Sun, Sep 7, 2014 at 4:26 AM, Ricardo Signes <perl.p5p@rjbs.manxome.org>
wrote:
> * Sawyer X <xsawyerx@gmail.com> [2014-09-06T16:11:57]
> > On Thu, Sep 4, 2014 at 5:55 PM, Ricardo Signes <
> perl.p5p@rjbs.manxome.org>
> > > It's important to have a plan and a vision before you break ground on
> your
> > > massive new skyscraper. After it's inhabited and in heavy use, it is
> not
> > > unreasonable for the vision to be "it remains standing and habitable,
> with
> > > improvements made when the possibility becomes apparent."
> >
> > But Perl 5 isn't a skyscraper. There is no "we're done, we can go home
> now"
> > stage. If we're at the stage of "basically we're done, we just gotta make
> > improvements when the possibility becomes apparent", it's more like just
> > trying to keep the patient alive.
> >
> > The issues you raise (and how you raise them) gives me the impression
> that
> > we really are still building something. The skyscraper analogy gives me
> the
> > impression of a patient.
> >
> > Are we still building something or simply trying to not let it die just
> > yet?
>
> It's not one or the other, but I don't think, at this point, that we
> *need* any
> further plan. That's my point. Of course the boundaries can be grown,
> but if
> we "need" a vision, a vision of "keep it doing what it does with no real
> changes" is not a completely laughable one. On the other hand, if that
> was the
> whole vision for, say, Rust...
>
"Keep it doing what it does with no real changes" is not a laughable one.
It's not much of a vision though, is it?
As I just wrote in a reply to BooK, this means that practically many of the
stuff we changed recently that you discuss in your talks are not just
unnecessary but impeding this Status Quo Vision. I don't understand how any
of these were accepted, if that is how people see the project.
In fact, if this really is the vision, I don't know how many Porters are
still working on it. From what I understand from quite a few, they are
interested in bringing new things to the table, not keeping the current
state of affairs.
So, let me rephrase my question. Instead of "Is there a vision?" I'll ask
"Is the vision to just keep it doing what it does with no real changes?" If
so, may I ask why the heck subroutine signatures came in? Why there are
pluggable keywords? Why do we keep adding features to the regular
expressions engine? Why do we support new versions of Unicode in core? Why
was CGI.pm even removed from core? What's the purpose of overhauling the
testing suite?
I really do hope "keep it doing what it does with no real changes" isn't
the vision you're thinking of. At least, that's not what your emails on
improving and changing things reflect. That's not what I understand from
your talks. That's not what I understand from Porters I talk to.
>
> So needing a vision isn't the same as needing to know what we want to
> change,
> because sometimes "nothing much" is not insane.
>
Agreed. "Nothing much" is not insane, but it would be a dead-end vision, if
it were one.
>
> Of course, though, there's plenty we can imagine wanting to change.
> Faster.
> Less memory usage. More maintainable C API. Better PRNG. Clearer type
> differentiation. Identifier normalization. And so on. The list can go on
> quite a ways.
>
Those actually align with progress, not "keeping it as is with no real
changes". Is it too late to jump off the "no real changes" train, back into
"we're still open to real changes"?
>
> If we actually do make a nearly exhaustive list, categorizing possible
> future
> directions of development, it's not going to make a useful map -- by which
> I
> mean it can't generally and usefully provide any sort of ordering, because
> ordering is mostly dictated by work done.
>
I'm not sure that's correct. Sometimes it's possible to point at a
direction with enough points on the graph. Often times it's possible to
notice dependencies between processes and formalize a clear "this should go
before that", which allows people to know "hey, this is waiting to be done
for all of that to be done".
Core hacker #1 thinks "I would like to implement Feature A, but I'll need
Fix B". She doesn't share it, because it's all part of her personal TODO
list, and that's not something people will easily agree on, so she keeps it
to herself for a future time. Core hacker #2 can work on Fix B, but she
doesn't know about it because Core hacker #1 didn't really share.
Since formalizing an "official planning" seems to be a "no no", everything
is maintained in brilliant peoples' heads, and once in a while surfaces on
the mailing list, unreasonable to expect it to be remembered by the next
time it surfaces.
If there was an exhaustive (or nearly exhaustive) list of all things
Porters want to get done, and those can show relationship between them, and
those can provide dependencies and requirements, and those can provide
described work (maybe work not only core hackers need to do), wouldn't that
constitute as a map?
If there was a vision, other than "keep it alive", priorities could be set.
This won't dictate what someone will work on. It will only dictate what
core hackers see as more important to hack on, if you're open to
suggestions.
>
>
> Within each idea, of course, there can be clear ordering. If you want to
> implement Tokyo cabinet-backed hashes, first you probably want hash
> vtables,
> which means first you want... and so on. I think you suggest that
> yourself,
> and if I read you correctly, then I agree with that. [...]
>
Yes, I do suggest that.
>
> Without workers dedicated to any given project, though, I think that
> trying to
> coordinate multiple projects into a larger-scale dependency tree is
> probably
> not a great investment. There will too many possible conflicts, branching
> paths, and so on. These things are best resolved, I think, when work is
> begun.
>
Except for a few problems:
1. Work will not begin for newbies (or new-comers, or beginners, or random
contributors) if they don't know what the project would like to have.
Telling someone (me included) "just find a scratch to itch" isn't useful
(not that I would file it under "things you told me"). What I would like to
itch I cannot scratch. Alternatively, I have no clear scratches. I care to
*help*, not necessarily *suggest*. Although, if I were able to help, I
might suggest later on.
2. Lacking a direction means that any suggestion is just as justifiably
shot down as any other. This is akin to any policy set in place. If there
no direction, you cannot tell me that this new feature of regular
expression is necessary. You cannot tell me I cannot offend you as much as
I want. I mean, if that wasn't something people thought was true, there
wouldn't be any behavior policy here (or on Rust, or on Python, or on
numerous other mailing lists and language communities). If there is a
direction, there is also some precedence that this should go in. We can now
discuss how more effectively.
3. Since clause 2, many hackers I talk to (not 1, not 2, not 3, not 4)
actively tell me they 1. Do not want to contribute to p5p anymore (I have,
unfortunately, received emails - in plural - telling me this) and 2. Do not
suggest the features/fixes they want to push.
There's more but I think those are important enough to not take into
account.
tl;dr
I just want to know:
1. Is the vision indeed "no real changes"? Is this how you and p5p see it?
If so, I can finish the thread and stop wasting everyone's time.
2. If not, is there a different vision? If so, what is it?
3. If none exists, is there a specific reason why there shouldn't be one?
(assuming it's formed from what Porters actually want and doesn't impede
anyone's complete freedom and ability to do anything else)
And I apologize for any snark or condescension that might have crept into
the email.
Thread Previous
|
Thread Next