Quote Originally Posted by Carlos Rocha View Post
Well, the problem has changed a bit, didn't it?
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.

Quote Originally Posted by techgnome View Post
Huh... I noticed the conversation has moved away from VB6-v-VB.NET to a more broader subject of Battle of the Design Patterns. Perhaps that's really the crux of the issue, not one of actual languages but the patterns and habits we use.

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