Slashdot Mirror
Making an Argument Against Using Visual-Basic?
ethan_clark asks: "I work for a small company (< 10 employees) as a software engineer. The company got its start with a software product written by the owner in VisualBasic. He hired me to assist in rewriting the software – only catch is, he's stuck on having it re-written in VisualBasic. This scares me, but I honestly can't make a good argument against VB because I'm not familiar enough with it.
So my question is twofold: I am looking for some confirmation to my suspicion that VB isn't the greatest language for large projects; and If VB isn't good, arguments against using it. If it is good, what arguments would you use to argue for it (for my sake)?" If you are going to argue against a language, it is best if you do so after you become familiar with it so that you can argue fairly on its merits and deficiencies. VisualBasic, like just about every other language, has its place. For the sake of discussion however, what tasks would VisualBasic not be suited for?
.NET languages are all pretty much interoperable, so long as you make sure to build your assembly as CLSCompliant (which may limit usage of some language features). The main problem is that VB.NET is quite a bit different from VB6. For someone who's only ever done VB code, it's easier to learn VB.NET than C#, but for everybody else you may as well start directly with C#. In the past, I'd have advocated building your UI with VB and calling C++ COM objects for any heavy lifting. Now, I'd recommend you go C# and do everything there.
You get regular expressions and collections with .NET (though not as many different collections as in Java, unless you bring in the J# assemblies for your project). You also get generics, anonymous methods (anonymous delegates, lambda functions, closures, whatever you want to call them), and quite a bit more cool stuff, though I have no idea how well that's exposed through the VB.NET language. Even cooler than that, you could subversively write modules in a functional language like F# (a dialect of ML) and nobody'd know the difference from their VB.NET or C# environments. (yeah, you can do that with Java as well.)
First company I worked for produced a series of ActiveX controls written in VB, shipped and sold with the source. It supported 3 full time devs, 2 support/sales people, one HR person, and an intern (me).
.COM world and got absorbed by ZDNet, but their components are still for sale on Programmer's Paradise, last I checked.
:) ) without peer. As to the inavailability of new APIs: a) Pretty much anything in COM can be used -- although some trickery may be necessary for custom structures. b) Anything done in a "straight" Win32 API can be directly invoked -- akin to P/Invoke in the managed world. For database work, VB was unparalleled. The ease of data connections has now come in some degree to the managed code word, but in unmanaged code only VBA comes close. C++ just can't compete. VB is no longer entirely late-bound -- if a dual interface is available, and the code is written to expect that type rather than just Object, VB6 operates as an early bound client. VB6 is also capable of being used in a late-bound fashion with almost identical code to the early bound scenarios.
They vanished after they tried to compete in the
I got an internship with Microsoft after spending most of my interview defending VB as a language choice -- this was pre-C#/.Net.
Some "facts" from above annoyed me, so I'm responding:
1) VB is only interpreted.
VB6 can be compiled to P-code, and will run interpreted. However, by default it's compiled to executable code. The only "penalty" for using VB6 when it comes to speed is really the memory footprint of the VB6 runtime DLLs.
2) VB6 is not suited to large products.
I'm aware of at least one company that based an entire website off VB6 apps. I'm sure they would be ASP.Net now, but at the time (VB4), that wasn't yet an option. So the web engine was actually a series of VB apps that were invoked to process the web request as ReadLine and Print commands.
3) VB6 -> VB.Net
(The person in question did only propose this as an idea.)
I would argue against this. There are certain elements only possible in VB6, and the switch to managed code is unfortunately not as seamless as MS would have liked. Hence the uproar when MS EOL'd VB6. VB.Net is great for managed code, and even has some features that C# lacks. I personally prefer C#, but I come from enough of a mixed background that I can handle what VB.Net code comes my way. While rewriting the application in VB.Net may be the proper thing to do, it certainly does not provide much in the line of benefits above and beyond rewriting the application in C#.
VB does have certain benefits to use. As a RAD environment, it is (or was
While I can't know why your manager wants to use VB, it's not such a terrible order.
If your manager only wants to preserve the look-and-feel of previous versions, the previous proposal of writing COM components in C++ for the high-performance portions and using VB for the front-end is certainly a very viable option, and one that I've used previously. In this manner, the weaknesses of VB6 can be circumvented while still leveraging existing components and possibly even code. At the far end of the advancement spectrum, even managed components can be exposed to COM clients -- Adam Nathan's wonderful ".Net and COM: The Complete Interoperability Guide" is probably the most complete book on the subject. If appropriate, you can write new code in C#, and expose it back to VB6.
If your manager wants to preserve the code base in VB6, you might want to determine why he wants to rewrite the application -- it's possible a better solution is just to rewrite portions of the code, depending on the scope of the changes he desires. The right tool for the right job -- VB is the right tool for some jobs, but shouldn't be presupposed to be the right tool for every job.
That being said, there are few things you can't do in VB -- although some of the solutions are probably not as simple as they may be in other languages. Keep in mind, however, that it is even possible to get assembly code linked into a VB6 application, if necessary. It just takes a little bit of creativity.
I remember back in 2000 my roomate had a job with a small firm that was kind of a "coders for hire" place. They didn't have a product, but if you came to them with something you wanted made they made it. Mostly a bunch of CS grads that didn't know anytihng but Java, however a few like my roomate were more diverse. He knew a few languages but PERL was his thing. Guy was a complete PERL badass wrote amazingly fast PERL code. PERL + MySQL development under Linux was his thing. Not at all a fan of MS development environments.
So General Motors, or at least some small division of it, hired their company to do a project and my roomate was assigned to it. He was kinda miffed though, because GM insisted it had to be done in VB. He talked to them and they acceded that the backend could be in PERL, but the client side UI had to be VB. Well he didn't really know anything about VB, he just disdained it as a "toy language"... That all changed on that project. He was amazed by it's flexability in doing Is and speed of development. He said that every time they totally changed the requirements of the client interface he could get a new one done in a couple hours.
In the end, he was certianly no VB-all-the-time convert, but he had a respect for the situations it was useful in.
Not knowing anyting about this project I can't say, but there are projects out there that something like VB is the best answer for.
Aside from it being at end-of-life, there are plenty of other, more technical, reasons why VB6 is a bad choice for many projects, especially large ones. I say this coming from a long history of writing and maintaining VB6 code, not because I have a bias against the language.
.NET, in my experience. Every benchmark I've ever run has VB losing by at least an order of magnitude. For example, I wrote an MD5 algorithm in VB (no small feat since VB has no unsign
VB was my second language and VB6 does vastly improve the VB experience, but there are several large problems: it doesn't support inheritance (only polymorphism); it is very difficult to use advanced features of the Windows API, it is very hard to debug and profile, and finally, it can lead to extremely unstable code.
The VB6 language supports a feature where you can implement an interface, similar to Java or C# interfaces, or C++ pure virtual functions. It does not, however, support a method to inherit methods from another class. Thus, you often find yourself writing reams of code to delegate to another class that has a common implementation of various functions. Furthermore, if an interface changes, all the classes that inherit that interface must also be changed. That can lead to a rather large maintenance headache. Furthermore, changing the interface often plays havoc with the IDE's parser, so it can no longer tell which methods on the class are inherited in the Intellisense functions.
More advanced features of the Windows API require you to copy and paste large bits of function and constant declarations into your code, and you have to jump through all kinds of hoops just to properly use the registry, system tray, or message handlers. I.e. if you want to catch a certain message sent to a window, you have to use SetWindowLong to override the message procedure of the window (you pass in the address of another procedure, which you acquire by calling "Address Of"). There is also all kinds of problems with passing pointers to structs, since you can't get a pointer in VB6. I.e. often, many window procedures require a struct with a pointer to another struct. There are hacks to get that, such as allocating a new memory buffer (using the LocalAlloc API), using CopyMemory to copy the VB struct into the memory location, then passing the pointer you got from the LocalAlloc call in as a struct member, and then using CopyMemory after the call to put the data into the VB6 struct. There are also undocumented functions to retrieve the address of variables, but there is, of course, no way to dereference a pointer, short of copying the data into a VB struct, or doing some fancy copying to change what an object points to (but that plays havoc with the reference counting).
Next, you've got the instability issues. Using *any* of these features leads to instability. Under normal circumstances, things work alright, but if you try to run the application in the IDE while you've got a custom message handler set up for a window, then the moment you hit "Stop" to end execution, the whole IDE crashes. The reason for this is that the VB6 IDE runs the app inside the IDE's process, so if your app causes a GPF or similar, the whole IDE goes with it. It also makes it a real pain for debugging, since setting breakpoints inside the window procedure often causes crashes.
Finally, it's very difficult to debug a VB application. If you've ever looked at the assembly output of the compiler, it's absolutely horrendous. Trying to step through it in WinDebug or something similar is just about impossible. The only way to debug it is with source code and full symbols, but even that is rather difficult sometimes. For example, most of the magic happens within the VB6 runtime (just about every VB statement is implemented as a call to the runtime; even assignment), so it's very difficult to follow what is really going on underneath the hood.
Those are my main problems with it. I also don't like many other things. For example, VB is really slow. Slower than
I have one customer that specs VB.NET for all their apps. After getting comfortable with it there's just no reason for some of the comments here. VB isn't "easier" than C#, just different. If you're a bad VB programmer, switching to C# isn't going to make you a better one.
My opinion is that a lot of bias against VB stretches back to the day when it was not considered a "real" programming language. But it's grown up and turned into a capable language and if that's what the customer wants, there's no need to try to sell them on C#.
That's our life, the big wheel of shit. - The Fat Man, Blue Tango Salvage