Front page | perl.perl5.porters |
Postings from October 2012
[Caveat -- I have not read the thread. I'm just replying to the initial post because I respect Peter as having thoughtful -- if forceful -- points of view.] On Fri, Oct 26, 2012 at 10:41 AM, Peter Rabbitson <rabbit-p5p@rabbit.us> wrote: > I will start with the TL;DR - I can not fathom why given Perl's > *exceptional* modularization track record, the general tendency on p5p > still is "MOAR CORE FEATURES!!!". I also do not understand how does this > sentiment continue to survive given an overwhelming mass of core devs > opposing such experiments (I do substantiate this claim - keep reading). Speaking for myself only, I don't particularly want a Perl where I have to read the documentation for half a dozen pragmas to understand the dialect of any given Perl code file. While I don't want to become Python, I favor whatever that "but consistency is not a bad thing either" expression in counterbalance to TIMTOWTDI. Providing one (or a preferred) way to do things means core. There are a lot of ugly things still in Perl. I favor trying to fix them. The "prototype on CPAN and bring into core" approach has pretty much failed to fix some of these nastiest problems. Are there good examples of when it's happened? > So, now the longer version. What continuously keeps bugging me is that > the brilliant strategy championed by Obra (Jesse Vincent) almost 4 years > ago turned out to be nothing more than a couple of well executed > presentations (not his fault). It's not his fault, and yet it is in a way. He laid out a vision and then retired as pumpking. IMO, it was with the best of intentions, but faced huge technical challenges for which a sufficient cadre of do-ers never signed on. It's no surprise to me that it hasn't gone very far. Moreover, I never saw the vision as being for a "smaller" Perl -- but rather that by making *legacy* pieces more modular (e.g. getpweng), those could eventually be moved out to modules/CPAN and back-compatibility could become easier to achieve. > Let's focus on sub signatures for a bit. I've read every thread about > them. Peter Martin's work kicks ass. The speedups are tangible which is > even more awesome. Yet the whole proposal seems to be set up “It either > happens in core or it doesn't happen at all”. Why? There are many things I could write, but I will sum up by quoting: "the perfect is the enemy of the good". Perl evolves based on the willingness of people to work on it. Proposing that something could be done better only accomplishes something if someone is willing and able to make it happen. If that doesn't happen, then I would rather have something good than nothing at all. The alternative is near-total stagnation. I don't want that. Many others don't want that. Those that *do* really want either stagnation or perfection have two options: (1) Stop upgrading Perl and STFU complaining about things other people want implemented (2) Do the work and write the code to deliver perfection That's not to say people can't say "I don't like your idea and think it should be done this other way", but if that doesn't happen, I hope they would have the decency to let it go rather than fight endless email wars until those doing the work say "fuck it, I don't have time for this" and drop it. Victory for the complainers, defeat for Perl. David -- David Golden <xdg@xdg.me> Take back your inbox! → http://www.bunchmail.com/ Twitter/IRC: @xdgThread Previous | Thread Next