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?

Comments

Which version of VB is it?

[blincoln]

VB = 6 is unadulterated crap. VB.NET isn't half bad, although I much prefer C#.

Re:Which version of VB is it?

[km790816]

Mod the parent up.

This is the *huge* issue, that will make or break your decision.

If it's VB6, run for the hills. It's end-of-lifed.

VB.NET is a great place.
You'll be able to leverage all of the .NET platform pieces (ASP.NET, SQL integration, WinForms, Avalon, etc).
You'll be able to mix-n-match C# code.
There is continuing investment in the language and tools. There's already a page dedicated to VB9 with some awesome features I wish were going to be in C#.

If you're betting on a Windows environment, VB.NET is a great place to be.

Your first choice should be "Are we going to bet on .NET?".

If the answer is yes, VB.NET vs. C# vs. Managed C++ is a secondary call.

Re:Which version of VB is it?

[hey!]

If it's VB6, run for the hills. It's end-of-lifed.

This is a critical point, and bears on the way the boss is making the decision. Professional programmers don't like VB because, as a language, it is not very good. But that doesn't mean the boss is being stupid. No. He's actually making the decision using a fairly reliable algorithm: repeat what has worked in the past.

The problem with this algorithm is that it can fail when the future is sufficiently different from the past. As in the platform being not supported anymore.

VB is not so much a bad language as an obsolete (and mediocre) one. But it isn't just a language -- it's an IDE and an operating environment with widgets and libraries and so forth. And in the other aspects that VB is relatively strong for some kinds of tasks. Visual Basic is Visual -- it really encourages you to think and work in terms of concrete visual objects. For a professional programmer, this is higly limiting, because a lot of problems you deal with aren't visual. Limiting isn't necessarily bad if the problem you're working on falls squarely in the middle of them.

You just don't do complex programming in VB. It's perfectly adequate for simple form based clients to a client/server style database backed applications that lack demanding scalability or support requirements. Most VB programs consist mostly of short event handler scripts around form components. The tight coupling of business logic to UI code is anethema to systems programmers. Clearly it is bad architecture, but the purpose of architecture is to reduce the cost of development and maintenance. In these kinds of applications, being able to get the application working quick enough outweighs any architectural drawbacks.

I think the sweet spot for you would be C# and Visual Studio. The way you lay out forms and such is the same as in VB 6, and these days learning how the bits is the real work on the learning curve, not the language. Forms in C# hava a Java/Swingish kind of MVC pattern, but it's really only one new design pattern you need to deal with. Once he's got the hang of it the boss can pretty much see a one to one correspondence between bits in the old VB app and a new C# app. You could go with VB.NET, but really for the kind of cmdbtn_click scripts of a typical VB app, there is no reason a VB6 programmer couldn't look at, understand, and maintain the same script in C# without having to swallow the whole C# enchilada.

And C# is a modern, well designed language. This means that if you have a piece of work that is sufficiently complex to worry about reuse, maintainability, scalability or other advanced requirements, you can address them properly. Many of the best practices and frameworks from Java have their counterparts in C#, such as O-R mapping, unit testing and so forth.

IN any case, you're in for tough sledding Dealing with a guy who has built a business where he does everything is difficult. These guys seldom can make the leap to creating a company that is bigger than they can handle personally. Even if they understand change is necessary, and that they can't do it themselves; even if they hire people to create change, they usually end up fighting change tooth and nail. Often they undermine the efforts of anybody to do anthing independently, such as book keeping or filing. Everybody is running a three legged race with the boss, and since he only has two legs, there's a lot of waiting around for him to catch up so he can toss all your recent work into the crapper.

Underneath this behavior is fear and beneath fear is insecurity and ego protection. Probably against all expectations, this guy has made a reasonable success so far; he has customers who send him enough money that there's more work than he can do himself. And since he didn't get where he is by saying no, he hired more people. But he'd probably be happier if it was just him. He may not know how to supervise people or even run a bu

Couldn't agree more!

[pilot1]

VisualBasic, like just about every other language, has its place.

And it's called hell.

Rethink your approach, perhaps

[plover]

A fair argument against VB6 is that it's at end-of-life. Microsoft has dropped support. You find a bug in it and it's all yours. But honestly, there just aren't that many bugs left in VB6 that aren't already known.

There's a different point of view you need to seriously consider: who's signing your paycheck? It's not Microsoft, is it? I thought not.

Consider meeting your boss in the middle. It's possible your boss is set on VB6 because he can read it fluently. Perhaps you could convince him to port it to VB.net. VB.net might not be so different that it would scare him. The GUI isn't all that different. And the .net framework would allow you to gradually expose him to other languages (C# or C++/CLI.) And it would allow you the opportunity to use a language with better libraries than VB6.

Have you dug a bit to find out why he's so pro-VB6? Maybe he's biased against .net because it's an interpreted language (like Java)? Perhaps half of his client base is all still running Windows 95 on 90 MHz pentiums, and .net is not an option for them. Maybe he'd be OK with C or C++ compiled to native executables, as long as there are no .net requirements. Microsoft's latest version of C/C++ has a strong push towards safer coding with bounds-checked versions of all the standard library functions. That might be good enough for him.

Or maybe he just has only two or three long-term clients that are stuck on Windows 3.1, but they've been with him for 25 years so he feels he has to support them into the far future. Consider buying them a few cheapo PCs to run your software: $400 each for a few bottom-feeder Dells would go a long way with customer goodwill, and would allow the rest of you to move into the 21st century of tools. And a $1200 hardware investment is much less money than your time spent struggling with old tools.

If he built a successful business around a piece of software, the chances are good he's smart enough to listen to rational arguments. So don't be irrational by kicking in your heels and saying "no! no! no!" unless you really enjoy job hunting.

Re:Rethink your approach, perhaps

[Otter]

If he built a successful business around a piece of software, the chances are good he's smart enough to listen to rational arguments.

Better yet, given that he's built a succesful business by writing version 1 in VB and that you don't actually have any rational arguments, why not defer to his judgment? The worst that can happen is that the next time this question comes up, you'll have a useful opinion instead of just vague concern that VB isn't 1337 enough.

Re:Rethink your approach, perhaps

[something_wicked_thi]

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.

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

what?

[larry bagina]

You were hired to rewrite some VB software, but you're not familiar with VB? The problem isn't VB, it's you.

Re:Can .Net Provide a Vehicle for alternatives?

[Osty]

Do the .Net languages allow a decent functional "Mix 'n Match" capability? If so, I'd make sure the VB rewrite was in VB.Net (or are there VB.Net idiosyncrasies that would justify sticking with the old VB6?) and then I'd learn C# really well. At some point in the project some component might fall under the "this will really suck under VB, and we can tackle it much better by writing this piece in C#" which will let you get a toe-hold on the idea of using a better language.

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

As for the tasks VB are not suited for (again, I only know VB6, not VB.Net) the biggest glaring omission in my experience was the lack of decent Regular Expressions, or Hash Tables / "Dictionaries"--unless you link to the VBScript/IE6 library like everyone used to. On the other hand, there are IMOHO problems with languages like Perl that make them bad for a number of solutions, but that hasn't stopped nutty fanatics from treating them like "golden hammers".

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

reasons not to use VB

[rifftide]

1. Chicks won't be impressed because it's so nerdy

2. Geeks won't be impressed because it's so VB

3. Microsofties will explain how your language is "deprecated" unless it's VB.NET. Trust me, it's bad to be deprecated on.

4. Enterprise programmers will explain how C# (or Java) is better than VB.NET, has more constructs, etc.

5. (An elaboration of point #2.) To a programmer, "dim employees() as integer" just looks goofy.

6. You and your company will be a one-man profit center for Microsoft (their tools are priced so that they don't come cheap when you need to do real work). Here it's not so much big bad Microsoft that's a problem, but I hate being someone else's one-man profit center.

7. If it's Visual Basic 6, try to get a hold of Ted Pattison's (out of print) book on how to use Visual Basic with DCOM. It's a great book, but my takeaway was that it's easier and wiser just to say no. (I suspect this may have been Pattison's POV too).

VB6 has its place...

[Nevyn522]

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

They vanished after they tried to compete in the .COM world and got absorbed by ZDNet, but their components are still for sale on Programmer's Paradise, last I checked.

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 :) ) 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.

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.

This original poster scares me

[stephanruby]

This original poster scares me. He wants arguments against VB, but doesn't explain the scope of his project, nor does he say what language he wishes to replace VB with. Most likely, he doesn't have much experience in the working world and would just prefer to use a language he's already used to from school.

The crucial ingredient in any project is the people you end up working with, not the language. I'm not a fan of VB, but if this kid doesn't have the experience of successfully completing a project in the real world, he should consider following the owner's experience -- and only worry about changing the underlying language once he has a couple of releases under his belt.

It does have it's place too

[Sycraft-fu]

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.

Good and Bad Sides of VB

[TheLogster]

I couldn't resist :)

Good Points about VB:

1. It's a fast development environment. You can get a decent sized program from idea to final build in hours and not days
2. It's an easy language to master. It is based on BASIC after all.
3. It has a large number of extra controls that can be used to do things like display webpages, upload/download from FTP sites, talk over IP, etc
4. It understands COM, so you use automation objects with it.
5. Now that PCs are so fast the execution time of the interpret is not an issue any more. However, VB is a slow language
6. It's Database objects are easy to use, and supports Access, SQL server, ODBC...

Bad Points of VB

1. It's BASIC, so the language has its limitations
2. It's OOP implementation is backwards. Parent class members cannot be called directly by their child descendants
3. It's UI design elements haven't really changed that much, so building a nice looking interface takes some time
4. The Right Way, The Wrong Way, and The VB Way
5. It is interpreted and not compiled, so you can have difficulty giving an exe from VB to a customer and get it to run. The easiest way to get a program onto a customer's machine is to create an installer. The installation system that comes with VB hasn't changed since VB3 and doesn't look processional at all. Use Visual Installer instead.
6. You have to declare your User Defined Types in an ActiveX DLL with a class that is never used, in order to use your UDTs as parameters to your classes in your main project

Overall Thoughts

I have been programming in VB since Version 2, and right up to Version 6. I cut my teeth on programming Windows Applications using VB, and I have to admit it is one of my favorite development systems. I also program in C++. I use VB to prototype an application, the other guys and customers can comment of the look and feel of the software, and modifications are easy to make. Once everyone is happy with the App, it is then ported to C++.

VB.NET is not VB (google for Visual Fred) VB.Net is a completely different language to VB and it is not code compatible. Time will have to be taken to rewrite the parts of a VB app that don't work under VB.Net

VB is a fine system and well suited to RAD projects, DB projects, and client/server projects. However, if you are looking for a system that creates faster code, is more secure, and easier to maintain, then you'll need to start working with things like C/C++/Java/etc

VB's not that bad

[HangingChad]

At some point in the project some component might fall under the "this will really suck under VB, and we can tackle it much better by writing this piece in C#" which will let you get a toe-hold on the idea of using a better language.

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

Wait, let me get this straight...

[jonadab]

He hired you to rewrite this thing in VB, even though you aren't familiar enough with VB to effectively argue (one way or the other) its merits? So he's smart enough to have written the software that got the company started, but he's not smart enough to realize he should hire somebody who *knows* the language he wants them to work in? Does he seriously think it's a good idea to have somebody who's new to the language writing production code in that language?

I don't.

If you're going to be working on rewriting it, it needs to be rewritten in a language you have significant experience writing in. Period. For instance, if *I* were going to be rewriting it, the logical languages to choose would be Perl or maybe lisp, because those are the languages I know well enough to write good code. If he wanted it rewritten in VB, he needed to hire someone with VB experience.

VB *is* reasonably good for certain things (mostly, pure GUI work, e.g., an application that facilitates data entry), but only if the programmer doing the work is familiar with VB. I've seen applications written in VB by someone who didn't know the language well, and they were universally terrible in every respect (_including_ the UI). This is true in any language. When somebody is just learning the language, they aren't going to be comfortable with the language's features or conventions, and so they're going to write execrable code for several months until they learn those things. During that time, you don't want them writing something mission-critical in that language. It's bad juju.