William (Bill) Vaughn's Musings

Once the design is done and enough people agree on the intended outcome, the student needs to learn the mechanics of implementing the solution.

• Capture information from a user, other programs or other computers here and elsewhere.
• Process, validate, purify, clarify and codify the information using whatever security schemes and the business rules are defined.
• Save this information where it can be protected and later retrieved.
• Retrieve this information from local or remote computers to permit editing and annotation, produce reports or to perform some task—like selling a product.
• Share this information with others—other people, programs or computers.
• Deal with the stuff that happens along the way.
• Perform all of these operations in a way that your team, company and/or family can share the development tasks.
• Document what has been done so the developer and others can leverage and understand the contribution.
• Manage the development tools themselves. Learn how to code, save your work, backup the source and reconstruct it once parts are lost. Learn how to use the tools to create databases, populate the schemas, build test data and setup rights to the data.
• Debug and test the code in simulated and real environments.

Up to this point, the language you use to interact with the computer and to perform these tasks is irrelevant. Any introductory course in Visual Basic (or any language) would need (IMHO) to do more than worry about the complex details of inheritance, polymorphism and class instantiation. Do you really expect to teach an introductory student about generics? While these concepts are important, an entire industry was once built around a Visual Basic that didn’t expose these concepts to the developers. I expect there are still several million developers still using this tool today and several million more that got their start in programming using it.

Yes, a Visual Basic course should talk about how to write code, but more importantly, it should talk about what is already written. All too often we see amateurs reinventing the wheel—writing code to do things that the language would do for them or built into the Framework, third party controls or addin libraries. At one time Tom Button called Visual Basic “glue”—implying that the language is simply a way to tie together with the trillions of lines of code already in place to do almost everything imaginable—and I expect some things that are unimaginable. Visual Basic was originally intended to hide the complexities of the OS and make the process of leveraging this body of code easy and seamless. Yes, Visual Basic (the COM version) was not that flexible and some developers grew out of it as their requirements and skill evolved—generally because their applications were successful.

Today Visual Basic (Visual Fred) is a very different language as much of the ease of use has passed out of the “language” and into the hands of Visual Studio. It’s Visual Studio that helps build Windows Forms and ASP pages—not the language. It’s Visual Studio that generates code to manage data sources and paint the contents in controls the users don’t have to write. Sure, there is a Visual Basic .NET Express, but it’s really a hobbled Visual Studio. These same development techniques apply almost universally to C#. Is it Visual Studio that implements edit and continue, intellisense (and intellinonsense) and the object parameter popups or is it Visual Basic? Does it matter? Because of this, any introductory course should include several hours of Visual Studio.

So, an introduction to the language itself should be written to show students how to implement the guiding objectives (as described above) in code.
But getting back to the language concepts, I know that many computer languages share the same basic concepts of variables, data types, logic branching and conditionals as well as ways and means to handle events and invoke other code. Any Visual Basic (or any introductory language) course needs to cover these basics. If done correctly, the course would permit students to learn that it does not make a snit of difference which language they use to implement these basic constructs—the results can be about the same—good, bad or disastrous. I wrote a Polish translator in college in COBOL when I (and the rest of the class) tried and failed to get FORTRAN to correctly parse the strings. Yes, there are cases where a language can make a difference, but… let’s not get into the C# and Visual Fred wrangling again.

Ah, I’ve been going on too long. Clearly I’m passionate about Visual Basic and computer science education. I just wish I had the energy to write another book on the subject. If you want to discuss this with me privately, I would be happy to provide whatever insight I can. I provided the same to Paul and Dr. Harvey Deitel.