Too many people these days learn programming by way of languages where all of the datastructure work is done for them, so they really just become users of tools instead of people that can think for themselves...

I agree with you that people need to learn the basics too, but I disagree that being a "user of tools" is a bad thing. I think if you look at all of mankinds great acheivements (especially in the modern era), you will find that many (if not all of them) would not have been possible if people did not stand on the shoulders of others to get there. It is the sharing of knowledge and tools which got us to where we are today as a species (I will make no judgements as to whether that is a good place or a bad place).

This probably involves having some objects behave as Nodes, which is where we need mixins (subclassing Node is wrong!)

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).

I also abhor the design pattern FAD so I avoid things such as VisitorFactories, as I get this silly image of a factory with Tourists popping out of the loading dock -- that's not what OO is supposed to be about.

I don't agree that it is a FAD, and all that being a "FAD" implies. But that is your perogative.

I think you've got a Forrest::Complex there instead of a Tree::Simple

Maybe if you take into account all the other Tree::Simple::* classes, but that is all optional. And while I am not really 100% happy with the ::Simple name, and have many times regreted calling it that, it is too late to change now as I have a number of users of the module already, that that is not fair to them.

No reason to rant against Tree::DAG_Node about line count (line count wars are always petty) in your POD

I just re-read that, and I realize I am not being clear. My problem with Tree::DAG_Node is that it only has one test, and that is to test if the module loads without errors. It is pretty well known and accepted that the number of bugs increases alongside the number of lines of code. So to me having 1500+ lines of virtually untested code is not acceptable, I am (badly) contrasting this with the 250+ lines of code in Tree::Simple, which comes with approx. 400+ tests and has 97% code coverage.

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.

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