Beefy Boxes and Bandwidth Generously Provided by pair Networks
Think about Loose Coupling
 
PerlMonks  

Re^3: Five Features Perl 5 Needs Now

by xdg (Monsignor)
on Dec 19, 2008 at 21:14 UTC ( #731661=note: print w/ replies, xml ) Need Help??


in reply to Re^2: Five Features Perl 5 Needs Now
in thread Five Features Perl 5 Needs Now

Nicholas Clark is fond of saying "perl development is driven by people who haven an itch". Which basically means "something is only going to be added/changed if someone is motivated enough to do the work".
s/do the work/maintain the work/

Proofs of concept are easy(ish), patches are harder, maintaining features/modules in core is harder yet. There are a lot of great suggestions that seem to stall for lack of volunteer labor. Oh, well, that's life.

I wish these kinds of threads could be more productive than this prototypical exchange:

Tweedledee: X would be a cool feature! Tweedledum: X is hard/incompatible Tweedledee: but if X could be done, it would be great! Tweedledum: if you want X, then write the code Tweedledee: !?!

Sometimes a wish list is just a wish list.

Maybe the original article should have been titled "Five Features I Wish Someone Would Commit to Adding and Maintaining in Perl 5" -- but that doesn't exactly have the same ring. ;-)

-xdg

Code written by xdg and posted on PerlMonks is public domain. It is provided as is with no warranties, express or implied, of any kind. Posted code may not have been tested. Use of posted code is at your own risk.


Comment on Re^3: Five Features Perl 5 Needs Now
Select or Download Code
Sometimes I'd Rather Punch Myself in the Head
by chromatic (Archbishop) on Dec 19, 2008 at 22:05 UTC

    I deliberately chose the smallest, easiest syntax change which represented a useful feature, and the negative responses have been:

    • You can't add syntax to Perl 5. (Fine, now you have to use the feature pragma to enable it.)
    • It might break existing code which defines a class method featured in an indirect call on a bareword which passes a hash reference as its argument. (See the previous point.)
    • I don't understand how it's useful. (Fine, don't use it. I don't understand how the Perl 4-style package separator is still useful fourteen years, two months, and three days after the first release of Perl 5 which used a much better package separator.)
    • It doesn't do enough. (I thought small patches were easier to review, and I'm not interested in wasting my time writing a complete replacement of Perl 5's object system if I can't even get a simple dumb patch like this accepted.)
    • Moose hackers reserve the right to modify syntax and features to explore alternate approaches, and reportedly don't want old code to go stale in the core, if the Perl 5 release policy remains as it is. (Of course, I've only heard this secondhand and probably shouldn't include it in the list, but it is an objection I've heard. Remember though, that my patch represents the Perl 6 syntax which has remained stable for longer than Moose has existed. I helped design the Perl 6 object system.)
    • I prefer the existing syntax. (Then don't use it. It's optional. If you adamantly oppose adding new features to make a language easier to learn and to use, boy do you have the wrong language.)
    • You can already get the same syntax with a source filter, a CPAN module, a minilanguage written by hijacking and copying parts of Perl 5's tokenizer into an XS module. (Clearly this is a problem many people have wanted to solve. What's so bad about solving part of it once and for all for everyone?)

    It's no surprise there's a lack of volunteers lining up to add and maintain features for Perl 5. I'm motivated or stupid or gullible or stubborn enough to have patched Perl 5's parser and lexer twice this year. I don't mind doing hard work, but I'm not motivated or stupid or gullible or stubborn enough to waste my time if there's no chance my work will ever be used.

    Update: Rephrased the Moose comment to reflect reality more clearly.

      The Moose hackers don't want to commit to any syntax, and they don't want their code in the core. (This is the Perl 6 syntax which has remained stable for longer than Moose has existed. I had a hand in the Perl 6 object system, as you know.)

      That's not exactly fair. One you're lumping "the Moose hackers" in together, be specific. I know autarch didn't comment on that thread, nor did Sartak, nor did nothingmuch or stevan. That covers everybody who's made an official release of Moose in the last year or two, and the top 4 Moose committers. As someone who has contributed to Moose, I *support* your patch, I just don't have any skills with C to do more than cheer you on. I know that others (who may have the skills) do as well, including Florian and mst who're responsible for MooseX::Declare.

      Two, Moose people don't want Moose in Core for specific reasons. Most of the people who have released core have said (and sadly not in a public forum) that if Perl were on a stable and frequent enough release schedule that would obliviate the major complain that core == death. I have argued with you elsewhere that I think *core* should be as minimal as possible and things like Moose should live outside. Perhaps I should clarify, "should live outside until the someone decides that they're important enough to be made part of the default language". Your class patch is something that I think should be made part of the default language for roughly the reasons you've expressed elsewhere.

      Before slagging on "The Moose hackers", please actually verify that "The Moose hackers" need slagging and that you're not just reacting to one or two loud and opinionated people.

        One you're lumping "the Moose hackers" in together, be specific.

        You're right; I based that off of a response from Jonathan Rockway and didn't ask anyone else. I'll update my rant accordingly.

        I'd certainly be happy to get some public comment from people who like the idea of the class patch, as well as people who'd like to see more frequent stable releases. Sometimes I feel like Cassandra trying to homestead an undiscovered country (to mix metaphors).

      I like the work you're doing for class. I'd love it to be easier to do OO in core Perl. I hope that someday we'll get to rework Class::MOP to use the keyword.

      Easier OO in core is exactly why I recommended coring Class::Accessor (which you thought was a dumb suggestion). It's certainly not a complete OO system, but it is a start; one that is mature and widely used. Baby steps, just like the class keyword!

      I agree with practically everything you've been saying and doing. I'm sure many others do, but it can be hard to vocalize support other than saying "me too". Please don't be discouraged!

        I should elaborate. There's nothing wrong with Class::Accessor; it's just not in and of itself a replacement for the class keyword.

      In case it wasn't clear, I was referring to responses to the "5 things" article and I was actually agreeing with you (or defending you) that one should be able to get on a bully pulpit and offer up a wish list without being told to get down and write some code.

      FWIW, I'm on the p5p list, liked the class keyword idea you wrote (and re-wrote) -- albeit with feature (see next para) -- and stopped reading the threads in the end after it got too depressing to see endless objections to progress. (We're talking 5.12 for pete's sake, people!)

      Regarding feature -- while it's annoying to stick use 5.NNN at the top of a file (which is what we have boilerplate and macros for), I thought that was the tradeoff so we could add new things and not break old things. That seemed like a perfect solution to the issue.

      All the other objections people raised just seem pointless to me.

      -xdg

      Code written by xdg and posted on PerlMonks is public domain. It is provided as is with no warranties, express or implied, of any kind. Posted code may not have been tested. Use of posted code is at your own risk.

        This is one reason writing code to support a feature is often more useful than writing a wishlist; code is less ambiguous than English.

        I still do think that feature is the wrong approach. I'd rather see the burden of forwards compatibility placed on upgraders. What if we had a module which removed the new features added by default? If you're upgrading a large codebase, you can write use feature limit => 5.006; or something, rather than forcing all potential future code to enable new features explicitly.

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://731661]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others lurking in the Monastery: (4)
As of 2014-09-16 01:48 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    My favorite cookbook is:










    Results (155 votes), past polls