Quote Originally Posted by Sitten Spynne View Post
Agreed, I can't even find the original problem easily. A 20 page thread is no place for code golf. I altered the problem because it seemed like that's what was currently trendy: framing the problem in a way so that the "wrong" person's approach would have issues.



The thing I don't like about dueling patterns, as fun an opportunity to show off as it is, is it perpetuates the myth that there's a "right" answer. It's particularly bad when you pit two different languages against each other, because the APIs and patterns and idioms that work well in one might not be so elegant in the other. For example, writing my post with an early version of C# that lacked delegates would mean losing a lot of my cooler tricks.

So I got sucked in. I was bored, and having a beer with a lot of time to kill.

I feel like this is where we sit in the discussion:

"Here's my solution in VB6, it uses patterns A and B and I plan to extend it this way."
"I kind of like solving it this way in VB .NET, I can use patterns C and D to do the same thing."
"Ugh, no, you don't NEED OO code for this, I did it just fine with A and B."
"Whatever, patterns C and D are well-known and get the job done. Patterns A and B are known to have these problems, it's in plenty of texts."
"No, patterns A and B are perfect, it's C and D that have the problems. Please explain how you'd solve <intentionally bad C&D scenario> with C and D."

This is kind of the point where person 2 ought to roll their eyes and move on. VB6 has some weak spots and there will be problems it just can't solve in an elegant manner. VB .NET also has weak spots, and there will be tasks it fails at that VB6 can tackle elegantly. There's no really good general-purpose language that exceeds at all tasks, the best we can get is one that's great at some things and good at most. It is very possible that both people are right, are using perfectly fine approaches to the problem in their language, and would be up the unsanitary tributary if they tried that approach in the other person's language.

We mustn't get insulted when someone thinks another approach is better. If they're technically wrong, you can comment on that, but it doesn't need to be a "won" argument. Later, someone reading the thread can see a proposal->rebuttal->counterargument discussion and decide for themselves what is best for their solution. Heck, for almost every problem we've discussed I can come up with a scenario where the "good" advice is totally wrong. We need to know all solutions, with all their upsides and downsides, to make the best decisions based on our information, schedule, and budget.
Yeah, that's why I tried to stay out of it for... I think my last reply prior to this was somewhere north of page 10... it turned into dueling posts... as much fun as the Duck Pattern debate was, it degraded pretty fast... and no one seemed to want to back down. Olaf has his way of doing things that works for him great, more power to him. It doesn't work for me. But that doesn't mean he's wrong, nor does it mean I'm wrong. I'm not sure I'd follow DDay's pattern either (I think I attributed that right, I can't go back to the other page at the moment to look it up - if I get is wrong... mea culpa) doesn't make him any more wrong than Olaf either... I'll be the first to admit - I'm a bit jaded when it comes to VB6... I spent far too many years battling it, and yes, it was likely due to bad design on the system on our part... I won't fully throw VB6 under the bus, maybe just under the front wheels. And maybe if we had been willing to redesign our Duck, I'd have a more positive memory of VB6... but it left a bad taste in my mouth towards the end. I moved on to .NET (by choice) and never looked back. I'm happy where I am. I can understand some people willing/wanting to hang onto VB6 for as long as they can. It's a fine language, and there is a lot it can do. But to be honest, between the framework and the IDE, I'm far more productive in .NET than I ever was in VB6. Lambdas and LINQ alone are the two greatest things I use everyday that I don't want to think about having to solve in VB6. I'm not saying it would be impossible, it just would require a few more hoops for me to jump through.

That said, while I think it's perfectly fine for people to want to try to hold on to VB6 for as long as they can, I think they are doing themselves (and possibly others) a huge disservice by not expanding their skill set. It doesn't have to include .NET or JS... but they should be more than a one trick pony. That's where the real value comes in with any language. Olaf seems pretty knowledgeable on the inner workings of VB and the APIs and such .. and I suspect he has more in his toolbox than just VB6, and that's going to work out just fine for him... But I sometimes worry that his pro-VB6 advocacy, while respectable, is going to lead others to think that all they need to know is his vbRichClient and that it's going to work forever... but unless others have the same or similar understanding of the inner workings, it's going to fall apart when he gets hit by the proverbial beer truck (sorry Olaf).

Dang... I was going somewhere with this now I've lost it. It seemed like a good point though.

Oh well.

-tg