http://qs321.pair.com?node_id=916370


in reply to Re^13: Processing Two XML Files in Parallel
in thread Processing Two XML Files in Parallel

This node falls below the community's threshold of quality. You may see it by logging in.

Replies are listed 'Best First'.
Re^15: Processing Two XML Files in Parallel
by dreadpiratepeter (Priest) on Jul 24, 2011 at 12:58 UTC

    That is a horribly poor comparison. You simplify for an 8-year old because he is probably unable to comprehend the real answer. A beginning Perl programmer is presumably and adult and shouldn't need the simplification. They will benefit more from being shown the right way to do things from the start.

    Plus, your solution was not a simplification, but the wrong way to solve the problem. See the hundreds of posts detailing why you shouldn't use regular expressions to parse XML.

    I would much rather the beginner have to work a little harder to learn the right way, than to be stuck six months down the line when everything blows up because someone added an attribute to the XML. or even a newline

    And actually, I would not even call ikegami's solution harder to understand. Sure, it requires you to actually read a PerlDoc to understand it,but how lazy (the bad kind, not Perl Lazy) do you have to be for that to be the issue? And there is no reason why the user couldn't learn by replying with follow up questions about the code and the idioms used; thereby learning more and creating robust code.

    With your method, the beginner gets a fragile one-off that reinforces a bad methodology. With ikegami's he learns a valuable tool that can help him solve more complex problems safely and easily

    Your comment elswehere in the thread is telling:

    Why oh why, do you need all that complexity to do a simple task? WHY???? I refuse to learn how to write code which has to be that verbose, without some sort of damn good reason! ... What ever happened to keep it simple?

    your good reason is robustness and reliability. Keep it simple is secondary to do it right.



    -pete
    "Worry is like a rocking chair. It gives you something to do, but it doesn't get you anywhere."
[reply]
      robustness and reliability

      Good point!

      I'd give you the double plus if I wasn't 3 floors underneath the dungeon level!

      I did ask if there was a 1-to-1 line concurrency, so you can infer from that that I was aware that the solution would not work if there was any mismatch in the line concurrency. Also adding .*? inside the left tag would catch any randomly added attributes, but yes, I can see why regex's are not the way to go if your less than 100% sure about the quality and consistency of the input data.

      So that leaves me wondering just exactly how XML::libXML recognises the structure of a tag, what is the black magic therein? And also, how does libXML work on the file without loading it all into memory (the guy said they were extremely large.)

[reply]
[d/l]
Re^15: Processing Two XML Files in Parallel
by ikegami (Patriarch) on Jul 24, 2011 at 19:29 UTC

    What stumped me about your solution was that I found no mention at all of the function data_transform

    Holy revisionist history batman! That's not what you said at all. You said "You solution is highly cryptic and you have to consult documents to find out what the various functions your calling on actually do". Were you lying, or did you need to look up parse_file?

    You've also repeatedly claimed that my solution is over-engineered, but now you're saying it's under-engineered because I used 

    $node->textContent() x shift(@counts)

    [download]
    instead of 
    data_transform($node->textContent(), shift(@counts))

    [download]

    Wow! Do you realise you have no credibility?

[reply]
[d/l]
[select]
      Pope vs troll. What a waste.
[reply]

        Pope vs troll. What a waste.

        There in lies the secret to becoming pope -- sometimes you have to be a troll.

[reply]

In Section Seekers of Perl Wisdom