Beefy Boxes and Bandwidth Generously Provided by pair Networks
"be consistent"
 
PerlMonks  

Re^3: (Placeholder) Imagine!

by dave_the_m (Prior)
on Nov 30, 2016 at 23:34 UTC ( #1176999=note: print w/replies, xml ) Need Help??


in reply to Re^2: (Placeholder) Imagine!
in thread (Placeholder) Imagine!

Can it be improved?
Possibly. Possibly not. But that one function does quite nicely demonstrate why perl internals are complex and hard to work with. That "clearly defined" op has to cope with (from a quick perusal of the src):

  • both byte- or utf8-encoded strings - and having to convert between byte and char offsets - with a caching scheme for sometimes O(1) performance on long utf8 strings;
  • delayed lvalue assignment, with sometimes the lvalueness only known at runtime depending on how a :lvalue sub has been called;
  • being called in void, scalar or list context;
  • handling a variable number of args;
  • integer-valued args being either signed or unsigned (both are supported);
  • get and set magic;
  • being passed a reference rather than a string;
  • issuing appropriate warnings;
  • tainting;
  • locales;

Putting all that together makes it really easy to break things, even with an extensive test suite.

Dave.

Replies are listed 'Best First'.
Re^4: (Placeholder) Imagine!
by BrowserUk (Pope) on Dec 01, 2016 at 00:28 UTC
    Putting all that together makes it really easy to break things, even with an extensive test suite.

    Indeed. That's why for it to have any merit at all it would need the indulgence of someone like you.

    Not to do the testing, but to guide us on how best to test. To establish some procedure that would allow us to arrive at a high degree of certainty before we request someone from p5p take a look at what has evolved. If anything.

    Maybe the idea is just too half-baked, but I've seen some extraordinary results produced here ... I was just looking to see if there is a way to tap into that for the benefit of Perl5.


    With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'
    Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
    "Science is about questioning the status quo. Questioning authority". The enemy of (IT) success is complexity.
    In the absence of evidence, opinion is indistinguishable from prejudice.

      It's not half-baked at all. I think it's a great idea, even though I don't know the innards all that well. If there are questions here on PM that I've never faced before, very often I research, test, research more, test, fail, cry a bit from frustration, research, test again and the odd time, I've found that I produced something useful I can post as an answer to someone else's question.

      Compound that with two or more monks going at a problem, bantering and throwing ideas back and forth, and good usually comes from it.

      I really like your idea. I like challenges. There are many other monks here (imho) that also like to work on challenges, and some like the environment where many monks are working on it, and they happen to be able to bridge ideas from multiple separate monks' replies into a great solution that benefits everyone (you said this earlier in this thread). In this case, it has the potential to benefit Perl/perl directly, so count me in, even though it may be a mountain of studying I may have to do (I've reached the summit of many mountains on foot, as well as tech/coding, and am always ready to learn more).

      Doesn't matter what the 'weekly' challenge is... if opcodes don't get much traction, start another challenge, and leave that one in the queue. It can always be looked at later. Perhaps list a known bug once per week that as a collective, we can look at and help the p5p. Perhaps a couple of docs get thrown up once per week... we look through and make sure the doc says what the code actually does, or better, we write patches for the docs where we know tricks that may or may not be bugs (but will never go away due to perlpolicy) that others may not know about because it's not listed, or not listed prominently enough.

        It's not half-baked at all. I think it's a great idea

        Thanks.

        Doesn't matter what the 'weekly' challenge is...

        I think it does ... but I'll come back to that.

        Perhaps list a known bug once per week that as a collective, we can look at and help the p5p.

        I've been down that route in the past; and it is not an easy in. Even when you have a very clearly defined and repeatable bug; a minimal demonstrative testcase; the appropriate tools (debugger etc.) and the knowledge of using them; you still need to know your way around the perl codebase and internals at a pretty intimate level to stand any chance.

        That's a big ask. And even if you get that far, the fact is that finding the source of the bugs is the minor part of the problem; and one that the experienced p5p guys will do so far faster than any of us.

        The big problem is fixing them in a way that is commensurate with the policy; proving that the fix is commensurate; and then championing the fix through the p5p 'process'.

        It is a) very hard; b) not for the faint of heart; c) apt to annoy p5p if you don't know their ways; d) intensely frustrating when all your work is reject for reasons you do not agree with. There is no appeals process!

        Perhaps a couple of docs get thrown up once per week... we look through and make sure the doc says what the code actually does, or better, we write patches for the docs where we know tricks that may or may not be bugs (but will never go away due to perlpolicy) that others may not know about because it's not listed, or not listed prominently enough.

        You (or I) can do that now; but documentation-by-committee is a frustrating and fruitless exercise. If you've been around here long enough to have witnessed one or more of the 'pedant wars' -- try super-searching for "array context" with author ikegami -- then you'll understand one the reasons.

        Another is that critique requires a lot less effort than composition. It is really disheartening to expend the (for me at least) considerable effort required to construct what you consider to be a concise and lucid description of something only to have it picked over and trashed by the 'I've an opinion and I'm gonna express it' crowd.

        Better to write your doc patch in isolation and if it gets incorporated, it then requires an equal expenditure of effort by someone to 'correct' it. If that happens, even if you disagree, the fact that at least one person felt strongly enough to construct and champion that correction; and at least one more agreed sufficiently to apply it; means you can probably accept that.

        Doesn't matter what the 'weekly' challenge is... [Part deux]

        A long time ago, Dominus used to post his Quiz Of The Week, but it is a thankless task.

        After QotW dried up, I've tried posting a few challenges, but in the absence of a real-word problem for inspiration, it's really surprisingly hard to come up with something interesting, challenging. Even harder to find something for which the result has the potential to be useful.

        On the other hand, the opcodes are clearly defined -- even if the definition is complex -- and any result that passed muster, would definitely be useful. And there are plenty of them. They have the potential to provide much entertainment for as many monks that can see past that it was I that proposed this.

        Even if none of them ever produced anything worthy (or accepted) to the p5p process; the challenges would be so much better than watching cat videos or playing sudoku for those of us that would rather expend our downtime programming than watching reality TV or bad drama.

        If 2 or 3 of the major opcodes got significantly improved by the expenditure of Monk's leisure activity that'd be a real bonus.

        And if as a result of their participation in a no-pressure, have-fun, while-away-that-down-time-pleasurably activity, resulted in a couple-or-three Monks acquiring the knowledge, skill and confidence to risk subjecting themselves to p5p scrutiny, who looses?


        With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'
        Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
        "Science is about questioning the status quo. Questioning authority". The enemy of (IT) success is complexity.
        In the absence of evidence, opinion is indistinguishable from prejudice.
      Not to do the testing, but to guide us on how best to test. To establish some procedure that would allow us to arrive at a high degree of certainty before we request someone from p5p take a look at what has evolved. If anything.
      I have not the slightest idea of what such a procedure would look like - it sounds like wishful thinking to me.

      Dave.

        it sounds like wishful thinking to me.

        Fairy snuff. I did choose the thread's title.


        With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'
        Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
        "Science is about questioning the status quo. Questioning authority". The enemy of (IT) success is complexity.
        In the absence of evidence, opinion is indistinguishable from prejudice.

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://1176999]
help
Chatterbox?
and all is quiet...

How do I use this? | Other CB clients
Other Users?
Others studying the Monastery: (6)
As of 2017-11-25 01:08 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?
    In order to be able to say "I know Perl", you must have:













    Results (355 votes). Check out past polls.

    Notices?