I came across this comment in a the newsgroups today ...
I personally recommend against modules, which are a pre-OO [object Oriented] feature. Instead,
go ahead and create a Public class with Public Shared subs and/or Functions.
... and thought it would be a good time to clear up this popular misconception. Modules in VB.NET are indeed object-oriented. The VB.NET compiles a module as a class with a private constructor and sets all of the methods and fields to be shared. There's about as much sense in avoiding Modules in VB (for the sake that they don't seem OO) as there is in avoiding members of the Microsoft.VisualBasic namespace (because they're not in the System namespace). And I can assure you that there is not a whole lot of sense in that.
As a Visual Basic programmer, if you refuse to use Modules, Left(), Right(), etc. because you feel they are too BASIC-ish, then senslessly not utilizing the full power of VB. The namespace is not there just for backwards compatability reasons - it's part of the whole Basic philosophy that simple, common operations should be as easy and straightforward as possible. Left(myString,4) is a bit easier to read and use than If myString.Length > 4 Then myString.SubString(0,4) Else myString. And of course, the builtin function does the exact same thing in the exact same time (minus the function calling, which is pretty insignificant anyway).