Forgive me, I just woke up and won't have time later, so I gotta take a stab at this now <yawn>.
I think it is just legacyitus, I guess the old vb used modules simply to seperate code sections which would be similar to using different files for different types of classes.
I think it's a combination of legacyitus and "convenience" -- it's less work to create a module, you don't have to tell the module it cannot be instantiated (implicit) nor explicity tell each method etc "You are shared" (vb's equiv to static) because that's also implicit. I say "convenience" because if down the road one wanted to port module based code to C# they'd have to rewrite it unless there's some <eeek> VB->C# wizard app <I'll pass>.
Classes in old VB from what I've seen are a more specialised item and are not used near as much as with C#/++ as VB wasn't really OO in its pure sense so modules I guess were the next best thing.
VB was never truly OO, more like OO lite, but I wouldn't say "modules were the next best thing". Speaking of old VB (< ver 7) Modules were where you placed common, non OO code, like what you'd find in static C# (helper) classes. Can't speak for anyone else but having coded in VB since the early 90s I wrote a lot of VB code that was as OO as it would allow (VB has had classes since Version 4 IIRC).
It does seem like MS are trying to swing VB users around to the OO way of thinking and you do see quite a lot more classes in the new .net version. I haven't had a close look but they may enforce full OO it already(?)
It makes sense I guess as it would be a lot easier to compile similar OO code from different languages than it would if you had to compile both OO and non OO app's to IL.
Yep, insert laughter here if you must, but VB is now truly OO, including inheritance, generics ... yada. An aside, it now supports all the unsigned suite of integers ('bout freakin' time), arrays are zero based (yeha) ... yada. In a nutshell it has moved a lot closer to C#.
One thing I'm trying is to code without using the Microsoft.VisualBASIC libraries, instead just using the BCL like a C# coder would be forced to (not C# envy at all, just trying to minimize porting activities down the road).
So instead of (traditional VB via Microsoft.VisualBASIC.Information) --
for i as integer = 0 to ubound(anArray)
...
next iGoing BCL is --
for i as integer = 0 to anArray.GetUpperBound(index)
...
next iEtc. I could write pages noting the differences but I've not the time.
.. AND, to make it more confusing, there is a Module Class, usable by both Vb and C#.
Meh.
I have had a long term hatred of VB/A, the word Dim alone causes a brain freeze < for me >, so thankfully, I wont be prototyping in VB :lol>:
Ahhh, my dilemna too, but the other way 'round. I've taken numerous runs at C#. While I appreciate it academically when it comes to writing any code in it I just get nautious, it just looks aweful to me (I'm not saying VB is pretty, just familiar). Still, I have numerous books on C# (the BCL, The C# language, Forms) to augment my one VB book (that's another story).
... but I do understand your quandry MP
Thank you sir.
<dang out of time>