Front page | perl.perl5.porters |
Postings from September 2014
Re: Roadmap/plan for Perl 5?
Thread Previous
|
Thread Next
From:
Ricardo Signes
Date:
September 7, 2014 02:26
Subject:
Re: Roadmap/plan for Perl 5?
Message ID:
20140907022605.GA14289@cancer.codesimply.com
* 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...
So needing a vision isn't the same as needing to know what we want to change,
because sometimes "nothing much" is not insane.
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.
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.
So we're back, I think, to some sort of "idea clearinghouse." I still think
that's a good notion.
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. If you didn't, I'll
settle for agreeing with myself. In our stockpile of possible projects, it
seems reasonable that there would be within each one some sense of ordered
steps.
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.
--
rjbs
Thread Previous
|
Thread Next