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

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.

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.

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.

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.