Beefy Boxes and Bandwidth Generously Provided by pair Networks
Syntactic Confectionery Delight
 
PerlMonks  

Re^3: How do "you" make a tree in perl

by SpanishInquisition (Pilgrim)
on Sep 29, 2004 at 17:47 UTC ( [id://395073]=note: print w/replies, xml ) Need Help??


in reply to Re^2: How do "you" make a tree in perl
in thread How do "you" make a tree in perl

You may be confusing lack of an integrated Test::More with a lack of testing. While automated testing in a CPAN module is awesome, the omission does not mean the author did not test it. In fact, to assume only automated testing is sufficient is an equivalent evil.

I like mix-ins too, but I am not sure they are always better than subclassing (which is what I think your implying here, but I may be wrong).

You are indeed. I am referring to the common falacy of subclassing Car as a Node just because you need a Tree of Cars. I'm not sure having Car as a data element in a Tree is exactly right either, though it is more passable.

As for design patterns not being a FAD, you have to think about when they started to come into acceptance and whether such technology existed "pre design patterns" and if there is software today that is sufficiently more advanced because of them. My answer to these questions are no -- the design patterns are not bad because they are not useful, they are bad because they are BLATANTLY OBVIOUS way of restarting what computer scientists have done for a long time.

Eric and the GoF are guilty of blatant plagarism -- and all those that worship them are doing millions of programmers a great disservice. We do not need to buy a specific book that gives us legos to build software from -- I'm a HUGE advocate of solid design and planning, but I also believe in sensible breakdown of components without a lot of sludge gumming up the gears. And, as you say, "that is my perogative".

Why do I say this? Why do I shun design patterns? Because I love software design. People that really love software design can see what they are doing is just dumbing down Software design into a bunch of duplo blocks. Don't implement a "Facade pattern" because you read it was good in a book. I am not a simple user of someone else's duplo blocks -- this is the rapidly disappearing line between computer science -- this is the commodization of programming -- (or to the same: this is the reason all of our jobs will go to India as soon as we all think alike and exactly the same -- safe programming languages whether COBOL or Java, coupled with politically correct design patterns, signal the doom of the world).

Implement an interface because you know what an interface is and because it is needed. Call an abstraction layer and abstraction layer. No need to claim that only PhD's can write books on good software and only lofty " architects" can design good software ... this just hurts us all. Why make a quasi-religion out of common sense? And why make simple things too complicated? Part of good software design is knowing when to stop. I chose not to build on to these ivory towers (castles?) and keep things simple where I can. Others may chose not to. That's fine. But they should not profess that this is the only way or that the design pattern people are somehow "smarter" than the rest of us because they retranslated common sense into lofty holier-than-thou textbooks that are politically incorrect to disagree with.

Replies are listed 'Best First'.
Re^4: How do "you" make a tree in perl
by stvn (Monsignor) on Sep 29, 2004 at 18:03 UTC
    You may be confusing lack of an integrated Test::More with a lack of testing. While automated testing in a CPAN module is awesome, the omission does not mean the author did not test it. In fact, to assume only automated testing is sufficient is an equivalent evil.

    If you spent so much time testing it, and your tests are well written, then why would you not include them in the distro?

    I agree that Test::More and make test are the not the only ways to test, but the author seems to have taken the time to include a very basic test.pl script, which from all indications is auto generated in some way, but not taken the time to do anything further. Including tests with a module is just good practice, it lets those of us who are control freaks (you and I) know that you have tested your code. Not including them makes paranoid control freaks (me) very very uncomfortable. And its not just about my mental well being, I have paying clients, who expect me to create reliable and well tested software. To use a module whose tests I cannot see, and have no way to verify is not fair to my clients and frankly unethical IMO.

    And yes, you are correct, that testing is no guarantee. However, it is an excellent tool, and one whose benefits should not be dismissed. I would rather have/use the most effective tool available, even if it is only 50% effective, than nothing at all. Basically, 50% is better than 0%.

    You are indeed. I am referring to the common falacy of subclassing Car as a Node just because you need a Tree of Cars. I'm not sure having Car as a data element in a Tree is exactly right either, though it is more passable

    I thought so, I agree with your point, however I disagree that mixins are the way to solve that. Surely a Car is not a Node, but I don't see a Car as needing to be mix-ed-in with a Node either (meaning the Car now has the properties of a Node as well as that of a Car). I see a Tree of Cars needing Nodes which contain Cars (has-a/delegation however you want to look at it).

    Regarging your opinions on Design Patterns, I agree on some points, however, I think this topic deserves its own meditation. Which I would happy to participate to contribute too.

    -stvn
      This slide from Dominus is more succinct than I am: http://perl.plover.com/yak/design/samples/slide012b.html
      * The pattern language does not tell you how to design anything * It helps you decide what should be designed * You get to make up whatever patterns you think will lead to good designs * The Gang-of-Four idea is to discover existing patterns of software development o Then program people to implement them habitually o Not the same thing at all o Much less profound o Also much less human
      Yep, it would make a good meditation. Let me uncloud my general theme (dominus comes close), get back to work, and maybe i'll post something (more well phrased) tonight. edit: on second thought, check SuperSearch. This has been done before, it's been played out.

Log In?
Username:
Password:

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

How do I use this?Last hourOther CB clients
Other Users?
Others chilling in the Monastery: (3)
As of 2024-04-25 17:21 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found