Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Making an Argument Against Using Visual-Basic?

Cliff posted more than 8 years ago | from the is-it-the-right-tool dept.

690

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?

cancel ×

690 comments

Sorry! There are no comments related to the filter you selected.

Umm (-1, Redundant)

Vokbain (657712) | more than 8 years ago | (#15441592)

It's a lot harder to port Visual Basic apps to a real operating system?

Re:Umm (2)

homeobocks (744469) | more than 8 years ago | (#15441609)

The latest VB apps (VB.Net) aren't executed an operating system, they run on the .NET runtime, which is largely cross-platform through projects like Mono.

Re:Umm (0)

Anonymous Coward | more than 8 years ago | (#15441647)

Cross platform is a huge myth when it comes to .net. Your extremely lucky if you can get any non trivial app to work on both .net and mono. VB.net does also not compile to the same code, some on the mono list are considering dropping any claims about suporting vb at all.

Re:Umm (0)

Anonymous Coward | more than 8 years ago | (#15441703)

Obviously you have no idea what an O/S is.

There are several downfalls of programming with Visual Basic. You really have no idea what exactly it is doing and there is quite a bit of overhead that is not necessary. Not to mention that it is seems to use extremely bloated and awkward syntax if you need a smaller, faster, more reliable application I would steer clear. In my opinion, VB is great for demos, quick and dirty apps, and utilities.

Re:Umm (0)

Anonymous Coward | more than 8 years ago | (#15441851)

High speed prototyping at best. Wasted harddrive space at worst.

Can .Net Provide a Vehicle for alternatives? (4, Insightful)

MurrayTodd (92102) | more than 8 years ago | (#15441593)

Forgive my overall ignorance--I'm a Mac and Linux and Java person, although I've written a bit of VB in a job years ago--but does anyone know if moving to VB.Net allows a phased-in approach to introducing at least some C# programming down the road?

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.

That's the way I helped a Fortune 500 company start adopting Linux back in 1998... the friendly and subversive way!

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

While I'm writing disclaimers, there are a number of commercial applications out there written entirely in VB. In all cases I've observed, they "evolved" out of a simple and useful app and fell into being examples of the most counter-intuitive user interfaces and over all "kludginess".

Re:Can .Net Provide a Vehicle for alternatives? (-1, Troll)

Karma Farmer (595141) | more than 8 years ago | (#15441643)

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.

VB.Net and C# are essentially identical.

The only difference in the real world is that VB.Net programmers are usually the low-skilled guys who can't learn a new language in a couple of days.

Re:Can .Net Provide a Vehicle for alternatives? (4, Informative)

Edward Teach (11577) | more than 8 years ago | (#15441650)

The good thing about the .NET languages is that they compile to the same "bytecode". In Microsoft's case, this is the MSIL that runs on the CLR. You can mix and match all you want. Just create a library of C# classes and you can use them in any of the .NET languages. The reverse is true, that you can write code in VB.NET and use that library in any of the other .NET languages.

.NET simply provides the programmer with the ability to program in the language they either know better or in a language that seems better suited to the job, without taking a performance hit, since they all compile to the same intermediate language.

.NET 2.0 takes this to even more extremes, in that, more toolbox items are available and virtually all of the components are data aware. Also, Visual Studio 2005 Pro includes a development IIS instance and SQL Server 2005 Express is included.

Check out the Visual Studio Website [microsoft.com] for more information.

Re:Can .Net Provide a Vehicle for alternatives? (5, Informative)

Osty (16825) | more than 8 years ago | (#15441704)

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 [msmvps.com] (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# [microsoft.com] (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.)

Re:Can .Net Provide a Vehicle for alternatives? (0)

Anonymous Coward | more than 8 years ago | (#15441705)

You can't mix and match code within a project, although you can use vb/net libraries fine within c# programs and vice versa.

They also do not compile to the same code (despite what MS say), vb programs use a different runtime, which is why mono has somewhat good c# support and hardly any VB support.

Re:Can .Net Provide a Vehicle for alternatives? (1)

Osty (16825) | more than 8 years ago | (#15441983)

You can't mix and match code within a project, although you can use vb/net libraries fine within c# programs and vice versa.

Said more correctly, you can't mix and match code within an assembly (generic term for "a compiled chunk of code", which could be a library (dll), an executable (exe), or even a separate sandbox within another assembly (.NET's XML serializer generates an assembly on the fly to serialize or deserialize XML, for example)). A "project" in Visual Studio compiles to a single assembly, either dll or exe, while a "solution" (which most people would think of as a "project") encompasses one or more "projects". Each "project" in your solution can be written in whichever language you like (MC++^WC++/CLI, C#, VB.NET, J#, F#, JScript.NET, IronPython, etc [dotnetpowered.com] ). The caveat is that your code must conform to the Common Language Specification (CLS) [msdn.com] which is essentially a subset of language features that all .NET languages must implement. Languages are allowed to implement more features than those defined by CLS, but should not implement less. This does provide for some pretty arbitrary restrictions (no unsigned types [msdn.com] ), and some inclusions that may mean extensions to a language (like method overloading, which didn't exist in VB6). You can usually do what you want without worrying about CLS compliance, but every now and then you will get caught up in an issue where what you want to do in one language won't be accessible by another.

Re:Can .Net Provide a Vehicle for alternatives? (1)

NutscrapeSucks (446616) | more than 8 years ago | (#15442079)

> Said more correctly, you can't mix and match code within an assembly

Actually, it's possible, but Visual Studio won't let you do it.
http://blogs.msdn.com/junfeng/archive/2005/02/12/3 71683.aspx [msdn.com]
http://www.abstractvb.com/code.asp?A=1055 [abstractvb.com]

Re:Can .Net Provide a Vehicle for alternatives? (2, Insightful)

plover (150551) | more than 8 years ago | (#15441707)

Any app can devolve into kludginess unless there's a strong approach to coding shared by every single one of the maintainers. VB6 isn't magic that attracts crud any more than C++ or Java (other than increasing the number of potential idiots who think they know how to program in VB.)

Any user interface, regardless of language, should be usability tested at every major release. A lot of developers are horrible at adding interface widgets because they're too wrapped up in the solution rather than the problem. How often have you heard someone do something like this: "I just solved the corrupt index problem by adding a StackWalkAndRebuildAllIndexes() routine. I stuck this big ol' "WALK THE STACK" button right on the front screen so JohnsonCo. will quit calling me at 5:00 on Friday afternoons." And the product ships with a stupid WALK THE STACK button right on the front screen.

Strong design is the best cure. Failing that, rigid and annoying development processes will at least delay the implementation of the cruft, along with your valuable modifications. :-)

Which version of VB is it? (5, Insightful)

blincoln (592401) | more than 8 years ago | (#15441594)

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

Re:Which version of VB is it? (5, Insightful)

km790816 (78280) | more than 8 years ago | (#15442104)

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 [microsoft.com] 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.

support (0)

Anonymous Coward | more than 8 years ago | (#15441596)

Start with there is no future support for it.

End with the extreme restrictions to platform.

Give us a bone! (4, Informative)

morcheeba (260908) | more than 8 years ago | (#15441599)

What kind of project are you working on? The only description you provided is "Large". That could mean 3D FPS, relational database, mission-critical embedded vision system for an interstellar satellite, a cross-platform OS... all very different projects, and probably not suitable for VB.

Picking the right tool really requires a better understanding of your project.

Beyond the general problem, what are your expectations for reliability/testability, schedule, maintainability, expandability, performance?

If the owner is the only one qualified to improve the product, Visual Basic might be a good choice.

I once worked for a company that had an extremely accurate satellite propagation program. The problem was it was written in GWBASIC and did not run in a text-only mode (EGA graphics required!). For fun, I tried to convert it to C, but gave up - pure spaghetti code. The author became the head of a 200-person engineering department -- best leave it in GWBASIC and let him support it.

Re:Give us a bone! (4, Funny)

Stormwatch (703920) | more than 8 years ago | (#15441719)

What kind of project are you working on? The only description you provided is "Large". That could mean 3D FPS, relational database, mission-critical embedded vision system for an interstellar satellite, a cross-platform OS...
Or Duke Nukem Forever. Who knows...

Re:Give us a bone! (3, Funny)

PygmySurfer (442860) | more than 8 years ago | (#15441753)

Nah, it sounds like their project is much farther along than DNF.

Couldn't agree more! (5, Funny)

pilot1 (610480) | more than 8 years ago | (#15441604)

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

And it's called hell.

Re:Couldn't agree more! (3, Funny)

twitter (104583) | more than 8 years ago | (#15442096)

VisualBasic ... has its place. And it's called hell.

You can tell the difference?

Rethink your approach, perhaps (5, Insightful)

plover (150551) | more than 8 years ago | (#15441617)

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 (2, Informative)

owlman17 (871857) | more than 8 years ago | (#15441791)

I'd mod the parent up if I had any points. I couldn't agree more. The most compelling reason to gradually (if not immediately) move away is that VB6 has reached end-of-life. Your boss would do well to listen to you that you ought to at least _begin_ to move away.

Just ignore most of the ad hominem remarks against VB6 here. I hate Microsoft as much as the next /.er but I made a living off VB6 for several years. Sure, VB6 won't make Doom 4 or Linux kernel 2.8, but it did and still has its merits. Its just that its on its way to being another Visual Foxpro.

Re:Rethink your approach, perhaps (5, Insightful)

Otter (3800) | more than 8 years ago | (#15441853)

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.

Not rational, look for another job. (0, Troll)

twitter (104583) | more than 8 years ago | (#15442131)

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.

They guy is a nutcase. He's hiring people to rewrite everything and falling into the same trap. Obviously, he's wasting his time and money.

Avoid his NDA, and keep looking for the next job. This one won't last long anyway.

No argument really. (4, Insightful)

Telastyn (206146) | more than 8 years ago | (#15441625)

Modern VB (VB.NET) is pretty full featured and un-crappy. It, like other .NET languages compiles down to MSIL so should behave identically to anything else. The only real arguement is based around that; if say... VB.NET and C# perform identically, why not use C#? It (arguably) has more of a following, (arguably) has a cleaner syntax, and (arguably) has a more java/C-like syntax incase you happen across people with that background. Not terribly compelling in the face of momentum...

Depends on a lot of factors (2, Informative)

JanusFury (452699) | more than 8 years ago | (#15441634)

VB6, with all its flaws, is still hard to compete with when you want a native Win32 app that has a lot of UI and doesn't take a long time to build. If you use it properly, it'll usually do what you want without having any major issues.

On the other hand, it has trouble coping with large complex projects (One of my larger projects regularly crashes the VB IDE when I load it, for no particular reason, and sometimes the VB compiler spits out mysterious build failure errors for no particular reason), and it lacks a lot of important features you get out of better languages and tools. If performance is a concern, you'll also find that it has trouble scaling there (though it's at least tolerable, and if you're careful you can get pretty efficient code out of it). There are also some data models and algorithms that simply don't work well in VB due to the overhead and inefficiency of using COM IDispatch and reference counting for every object.

If you need to make a transition from VB, you might be able to manage to convert it over to VB.net, but I've never been able to do that successfully. I personally use C# for any project these days that I would have used VB6 for in the past. And if you don't really need to do much in the way of UI, C++ is a pretty solid option for almost anything else, even if it's tough for some VB coders to grasp.

One middle-ground option would be to rewrite chunks of the application using C++ or C# and wrap them in COM so that you can drop them into the existing VB application. I had pretty good success doing this with performance-critical parts of a few of my larger VB applications and didn't lose any of the benefits of doing my UI in VB in the process.

what? (5, Insightful)

larry bagina (561269) | more than 8 years ago | (#15441637)

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

Re:what? (2, Insightful)

Anonymous Coward | more than 8 years ago | (#15442011)

Yep, I agree, even if you do manage to convince your boss to switch languages, ***any*** problem you have (and with any development of course you will have problems), it will come back to, "well you're the one who wanted it in language X instead of VB".

People need to make descisions like it should be done in a marriage, you make it together and both take responsibility for it (no blame game). Unfortunately, unless your boss has well above average character, you'll just hate choosing another language.

Get another job.

My biggest gripe... (1)

jginspace (678908) | more than 8 years ago | (#15441641)

... the scroll wheel won't work in the IDE.

Re:My biggest gripe... (4, Informative)

plover (150551) | more than 8 years ago | (#15441762)

... the scroll wheel won't work in the IDE.

I used to think so, too.

Try this. [microsoft.com]

Who's your buddy now? :-)

Re:My biggest gripe... (1)

jginspace (678908) | more than 8 years ago | (#15441822)

"Who's your buddy now? :-)

If I could mod you up or transfer all my karma points to you I would. Thanks.

Wha? (2, Insightful)

19thNervousBreakdown (768619) | more than 8 years ago | (#15441657)

OK, just to get this out of the way, the owner of the company hired you to re-write his program in Visual Basic, and you don't know Visual Basic? I mean, it's not like he hired you to simply re-write it in any language, he wanted you to re-write it in VB. And he obviously knows VB since he wrote the software in the first place. So, uh, WTF?

First, I have to assume you mean VB 6, since VB.net bears more resemblance to C# than anything else. If you're talking VB.net, don't worry about it. The syntax might be annoying, but it's a decent language. Anyway, as for the merits of VB, well, it's appearantly good enough for a large project, since you're looking at one right now that was good enough to start a company that can support 5-9 people. This company's appearantly been around a while; I hope nobody's writing new stuff in VB. So don't worry about whether it's good enough or not, it is.

The issue I would have with it is, it's being killed by Microsoft. There's nothing you can do about it. It may not work on new versions of Windows. Old versions of Windows won't be supported anymore. You'll run into security holes that won't be fixed, or try to interoperate with software that needs a newer version of Windows. Basically, you're going to get screwed, it's just a question of when. If your company has the time and money to do a rewrite, do it in a language that's going to be around for a while.

Normally of course, I'd call you nuts for doing a complete rewrite unless it's a pile of crap that's falling apart at the seams and the basic architecture is shit, but it's written in VB. Which has its merits, and maybe I'm wrong here, but I consider it more of a prototyping language than anything else. Just don't rewrite it in VB 6. Seriously, quit first, it won't do shit for your resume to have VB 6 on there, and it'll just cost the company a crapload of money for no good reason.

Re:Wha? (0)

Anonymous Coward | more than 8 years ago | (#15441966)

Whoopdie-freekin'-doo. We hired a Java developer to write an application in C#. In other news, Satanists have begun performing exorcisms...

Basically. . . (1)

NetRAVEN5000 (905777) | more than 8 years ago | (#15441659)

Basically, if it's a huge app, you don't want to use VB for the sake of speed and stability. VB is slower than many languages since it's interpreted - which may not matter for small apps but for big ones it often does. And it seems to me that it hogs more resources too.

Re:Basically. . . (1)

plover (150551) | more than 8 years ago | (#15441799)

Untrue. VB6 compiles into native x86 executables by default. The option is there to compile to P-code (the old VB4 stuff) but that hasn't been a requirement for at least eight years and probably more. And it's not on unless you explicitly choose to use it. I have never found a reason to do so.

Re:Basically. . . (1)

NetRAVEN5000 (905777) | more than 8 years ago | (#15441946)

Nope. True, VB produces an .exe file, but you can't run it without the VB interpreter.

Re:Basically. . . (1)

plover (150551) | more than 8 years ago | (#15442072)

Nope. True, VB produces an .exe file, but you can't run it without the VB interpreter.

That's sort-of technically correct, but not right. You don't need the interpreter, but you do need the VB6 runtime libraries. And they're both located in the same dynamically loaded module, msvbvm60.dll. While it still contains the "Visual Basic Virtual Machine" required to run the p-code, if you natively compile the program it simply is used as a container of the resources VB programs require. The p-code executor is not used.

The knowledge base has this article [microsoft.com] which doesn't describe it very well, but kind of hints at how it works.

Re:Basically. . . (1)

dtfinch (661405) | more than 8 years ago | (#15441831)

VB6 does real compilation, producing executables that are probably 1/3 as fast as C++, which isn't bad.

On the other hand, VB6 seems to get sluggish when you have more than 100,000 or so strings in memory. Nearing that boundary, I've gotten performance increases by storing strings in a file and just remembering their addresses, even when there's plenty of free ram, which is crazy.

Re:Basically. . . (1)

NetRAVEN5000 (905777) | more than 8 years ago | (#15441929)

VB doesn't do real compilation. It may seem that way, but that's not what it's doing. It simply has all the instructions for the interpreter in the .exe file. Without the interpreter .dll you can't run the program.

Re:Basically. . . (1)

CharlesEGrant (465919) | more than 8 years ago | (#15442021)

This was true for the older versions of VB 4 and earlier, but VB 5 can generate native code. Yes, you still need the run time library, just as most applications writen in C need a runtime library like libgc or msvcrt. The fly in the ointment is that Microsoft doesn't provide a static version of the VB runtime library.

Re:Basically. . . (1)

dtfinch (661405) | more than 8 years ago | (#15442101)

Starting with VB5, VB performed real native compilation, but still required a runtime.

Why the hell did he hire you? (1)

SlappyBastard (961143) | more than 8 years ago | (#15441665)

I'm not saying that I've never taken a job just because the job was there. I have.

But, in fairness, if you have serious doubts about the platform the owner insists upon using, then this isn't the place for you to be working.

You're either onboard, or you owe it to your boss to leave the company.

Re:Why the hell did he hire you? (1)

WindBourne (631190) | more than 8 years ago | (#15442152)

You're either onboard, or you owe it to your boss to leave the company.

Or to simply educate the office. Quite honestly, a lot of small companies get started by someboyd with an idea but no real idea of how to do things. They slowly build it up, but have no clue as to what else there is outside of their little world. This engineer can actually help them move it from a small office with a small product to a growing thriving product that can be enhanced easily (bigger market share, faster changes with lower costs).

BTW, I have worked at plenty of places where one person can with the correct argument can move a company forward. For example, back in the 80's, I did PL/1 on a mainframe. But nobody there did pointers, so many of our apps were slow. One person came in and spotted one app that could be changed easily and with a slight tweak, he changed it from running in an hour, to under 5 minutes. After that, we used pointers (sparingly, but still used).

One good way to convince the owner is to undertake converting one of the most difficult parts and showing the improvements. Of course, that will involve som education if they do not know the language (I am assuming a step up to either java, C++, or a scripting language).

3 reasons from personal experience (1, Insightful)

cryfreedomlove (929828) | more than 8 years ago | (#15441666)

1. VB is not portable. You'll be supporting windows based servers forever if you increase your investment in VB. The company I work for switched from VB to Java and we've been able to move our java server app to 3 different OS/HW architectures with zero code changes. 2. You cannot get insight into what VB is doing. Where is the server spending time? Can you see a thread dump? How much time is lost to collecting garbage. VB is a black box. That's death for debugging a large server system. 3. You cannot attract great new engineers to work on a VB application. Great engineers will avoid working on VB apps and you'll be stuck hiring low grade talent. That will perpetuate a downward spiral where any good people will leave to avoid VB and the bozos that like VB.

Re:3 reasons from personal experience (1)

Tablizer (95088) | more than 8 years ago | (#15441919)

VB is not portable. You'll be supporting windows based servers forever if you increase your investment in VB. The company I work for switched from VB to Java and we've been able to move our java server app to 3 different OS/HW architectures with zero code changes.

Yes, but server OS is a relatively minor issue. You are essentially chosing to be married to Sun instead of MS. If you really want to be free, go with Php or Ruby or something.
       

Re:3 reasons from personal experience (1)

epee1221 (873140) | more than 8 years ago | (#15442126)

You're trying to draw attention away from the portability issue, which what the OP brought up in the first place. If I write code in Java, I can run it on a non-Solaris box. If I write code in VB, I can't run it on a non-Windows box.

Re:3 reasons from personal experience (0)

Anonymous Coward | more than 8 years ago | (#15442135)

"If you really want to be free, go with Php or Ruby or something."

With these you are choosing to be married to whether or not the core developers for these languages stay committed and there isn't political fallout that causes the platform to stagnate or fork.

Basically, the overall long-term risk is about the same with MS, or Sun, or PHP/Ruby. Of course, PHP/Ruby are already open source, so as long as you keep a system that will compile it (right version of Linux/GCC/etc.) it'll work as-is for as long as your hardware stays going. Of course, the same is true for a given installation of Java or .NET.

Granted, there are a number of other good compelling reasons to go with open source.

Re:3 reasons from personal experience (1)

Tablizer (95088) | more than 8 years ago | (#15442148)

I don't fully agree. Having the source code available gives you more legacy-handling options than having just the binary.

Re:3 reasons from personal experience (0)

Anonymous Coward | more than 8 years ago | (#15442117)

The company I work for switched from VB to Java and we've been able to move our java server app to 3 different OS/HW architectures with zero code changes.

What does the client software have to do with the server side? You could easily have a VB client talking to a webapp sending it XML requests. That gives you the best of both worlds: java on the server side and a nice (or quick to program) GUI on the client.

Re:3 reasons from personal experience (3, Informative)

NutscrapeSucks (446616) | more than 8 years ago | (#15442138)

1. VB is not portable.

That's actually the main feature of Classic VB -- that it's really just a user-friendly wrapper around Windows COM. If you want MS Office automation or anything that ties in closely with other Windows apps, VB6 is still a very good choice.

Although I agree strongly with your assessment of VB server apps.

Well... (0)

Anonymous Coward | more than 8 years ago | (#15441669)

For the sake of discussion however, what tasks would VisualBasic not be suited for?

Nuclear power stations.

One of the best assessments I've seen (4, Informative)

petard (117521) | more than 8 years ago | (#15441682)

Joel Spolsky explained why CityDesk, written by a shop populated entirely by highly qualified C++ coders, is 95% VB [joelonsoftware.com] . He has a frank discussion of VB's pros and cons as a development tool, and you may find that many points he discusses will resonate with you as you develop your reasoning. Even if you don't come to the same conclusion he does, it's an excellent discussion of just the topic you propose.

Really, reading his argument in the context of having a bunch of C++ coders build a nice Windows app in 2006, I think I'd probably conclude that C# was the way to go, as opposed to VB. But keep in mind that C#.NET and VB.NET are more alike than they are different. For most apps, the arguments for managed code (VB or other) are very potent.

My take: If you and every single developer on your team can't instantly see and explain the differences between the 4 arguments to this function:

void foo(std::string a, std::string * b, std::string & c, std::string *& d)

stop now and use managed code of some kind.

If you all can, think really hard about why you want to spend your talent managing memory instead of doing things that'll really make your application shine. (There are reasons. They don't apply to most apps.)

Re:One of the best assessments I've seen (1)

QuantumG (50515) | more than 8 years ago | (#15441895)

Using C# is a far call from using VB, even if it is VB.NET.

Re:One of the best assessments I've seen (1)

petard (117521) | more than 8 years ago | (#15441954)


Using C# is a far call from using VB, even if it is VB.NET.


I'll give you that it's a far call from VB 6. But what makes it a far call from VB.NET in your opinion? I like C# much better because the syntax is much more familiar to me, but the appropriate uses for each as well as the capabilities of each seem largely similar to me. Performance is identical. So what does C# buy someone whose mind hasn't been molded by 15 years of C/C++, apart from mono's c# implementation being more mature than its VB.NET implementation (a consideration if cross-platform concerns are important)?

That's a very funny assesment. (0, Troll)

twitter (104583) | more than 8 years ago | (#15442161)

I like the argument where he says VB is good because MFC sucks. Ha, ha! That sold me. I've never seen a VB interface that looked, "professional" because Windows itself no longer looks that way.

VisualBasic = the devil (4, Funny)

Naikrovek (667) | more than 8 years ago | (#15441683)

Visual Basic (especially VB6) have no place in the enterprise.

C# and VB.NET are very similar, and C# has a much more standardized syntax style. It will take little time to teach someone C# that is familiar with Java or even C++, but it could take some time to acclimate that same programmer to VB's retarded syntax style. Any language with constructs like "If Not foo Is Nothing Then ... End If" rather than "if (foo) {...}" has no place in my brain.

JavaScript, C, C++, C#, Java, and even Perl have the same curly-brace blocks, statements end with a semicolon syntax style.

If your boss gives you the often used "anyone can learn visual basic in a day" line, give him the "anyone can learn Java or C# in a day also, and the talent pool for those languages is much larger" response.

Re:VisualBasic = the devil (1)

LoztInSpace (593234) | more than 8 years ago | (#15441864)

Visual Basic (especially VB6) have no place in the enterprise.

Loads of enterprises are run on VB apps. I would go so far as to claim most, although I can't be bothered to find out.
Loads of enterprises also run on Excel and Word documents so what does that tell you?

Re:VisualBasic = the devil (1)

Tablizer (95088) | more than 8 years ago | (#15441977)

Syntax is a personal preference. I won't dictate to you what you like.

However, one thing I find nice about END X type of blocks is that it is easier for the compiler to find the problem if you misplace a block ender. This is because all "}" are the same. If you have end-if mixed with end-while and end-func, then the compiler will detect the missing block ender closer to the problem because it can't try to pair While with End-if etc. Plus, it is more self-documenting than braces.
       

normally... (1)

Beuno (740018) | more than 8 years ago | (#15441693)

As far as I know, common sense is to use VB for small and medium non-critical apps that need speed of development over anything else.
I'm not sure what type of app you're aiming at, but C++ and Java come to mind as solid choices.

Easy answer (1)

Guppy06 (410832) | more than 8 years ago | (#15441712)

Tell them that Real Men (TM) don't use VB, but instead write Perl scripts in ed.

Re:Easy answer (1)

hazem (472289) | more than 8 years ago | (#15442024)

I thought Real Men(TM) wrote the assembly codes directly into memory using debug?!

Re:Easy answer (4, Funny)

geminidomino (614729) | more than 8 years ago | (#15442070)

No, you pussy. Real Men(TM) use small magnets directly on platters. ;)

Re:Easy answer (1)

spir0 (319821) | more than 8 years ago | (#15442115)

don't you want some a bit more lowbrow like edlin?

Cross Platform? (4, Insightful)

spirality (188417) | more than 8 years ago | (#15441733)

I would argue not using VB on the basis that it is not cross platform. Yes, Microsoft is not going anywhere, but there is some possibility that OS X or Linux could be big enough markets to consider. Especially if you are writing from scratch, why not consider a cross platform solution? It's a little more work, but it pays off in several ways. Larger audience, but more importantly different OSes catch different bugs. You wouldn't even have to target multiple platforms at the get go, but it would make porting it a hell of a lot easier down the road. However, it is VERY easy to write unportable code, especially with a compiled language, for example C++.

To that end: Python and C++ are generally good choices. They each have their place. I really like my C++, but rapid development is somewhat of a joke. It takes years and years to master and even after using it for close to 8 years on a daily basis I'm still amazed at what I don't know sometimes. However, you can do anything with C++. If you can think of something, there is already probably a library out there to do it. I don't recommend it to novices or people who want rapid development, however if you want a rock solid well performing system it really can't be beat.

If you're doing GUI stuff, you would have to take a VERY serious look at the combination of Python and Qt. Qt is the de facto cross platform toolkit. It has everything from GUI libraries to network libraries to regular expressions, xml parsers, you name it. It's very good. It's also very good with C++.

I don't know much about C#, but with Mono you at least have the possibility of it being cross platform. I'm not a big Java fan. After being a C++ guy for so many years it just seems like crap. It lacks the good things from C++ with all of the syntax overhead, and it lacks the flexibility of Python.

If you didn't guess I write almost everything it Python or C++. They are my dual golden hammers. :) I say that partly in jest, they complement each other very well.

I do a lot of Scheme too, but I'd be an idiot to recommend that to you!

Perl is glorified shell. I wouldn't touch it except for the smallest most throw away programs, if even for that anymore. Still I know people who swear by it, mostly sysadmin types.

I've played with Ruby a bit. It has some definite strengths, but the library support, or lack thereof is a big minus. Syntactically it reeks of Perl and IMHO lacks the elegance of Python. Still it's got some really cool unique stuff.

Overall I would recommend Python, but like another post mentioned, what are you trying to accomplish? You should fit the tool to the task not the task to the tool.

Re:Cross Platform? (1)

Bones3D_mac (324952) | more than 8 years ago | (#15441829)

Back before it turned into a steaming turd, RealSoftware's RealBasic Professional [realsoftware.com] would have been an ideal solution to the cross-platform authoring problem that VisualBasic presents. (It supports Mac OS, Windows and Linux.) In fact, they even went so far as to provide tools needed to port VB projects to RB.

However, the folks at RealSoftware got greedy and let the quality of their past products go to their heads. All current versions of the software are written and compiled using RB itself... a move that has caused the brand to suffer horribly compared to the 5.x and earlier versions.

VB isn't _that_ bad (1)

dtfinch (661405) | more than 8 years ago | (#15441743)

basicNES [att.net] is written in VB5/6. I helped a lot with the optimization to make it run at full speed on as little as 350mhz with no frame skipping.

VB.Net is fine too. The biggest problem is that simple languages attract simple people.

Re:VB isn't _that_ bad (2, Funny)

bigbadbuccidaddy (160676) | more than 8 years ago | (#15442045)

You just made the exact opposite point you were trying. It took a team of developers 7 years, at least 195.53 times the CPU performance, and your optimizations to emulate an 8-bit game machine. VB sucks for video game emulation in addition to all the other things it sucks at.

Not too bad overall.... (1)

meburke (736645) | more than 8 years ago | (#15441749)

Visual Basic is not too bad for creating a large project. The trick is to be a decent Windows programmer. You would get almost all the knowledge you need to create good programs in Visual Basic by reading and applying the stuff in the Deitel books (Pick one according to your level of skill)
http://www.amazon.com/gp/product/0130293636/104-33 75871-4590326?v=glance&n=283155 [amazon.com]
and then learning the essential stuff from Charles Petzold http://www.amazon.com/gp/product/0735617996/104-33 75871-4590326?v=glance&n=283155 [amazon.com]

However, understanding the applications may be more important than the code. In a large project, after familiarizing myself with VB (using the books mentioned), I would suggest using a tool such as Rational Rose, Embarcadero or even Visio to get a UML documentation of the project, revise the model to reflect my current needs, generate the revised code from the modeling tool, then optimize the code to get the project revised in the shortest period of time. If you think you'd rather use a different language, most of the modeling tools will also generate other languages from the same model.

I hope this helps,

Mike

Not enough info (1)

Alien Being (18488) | more than 8 years ago | (#15441780)

I'm sure there are plenty of good reasons to move away from VB, but IMO, it's an elegant way of leveraging the MS API's. Kinda like wearing fancy gloves while driving a diesel Audi.

reasons not to use VB (5, Funny)

rifftide (679288) | more than 8 years ago | (#15441815)

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

...what...does...it...do? (1)

solitas (916005) | more than 8 years ago | (#15441835)

The company got its start with a software product written by the owner in VisualBasic. ... For the sake of discussion however, what tasks would VisualBasic not be suited for?

Um, maybe I've overlooked it, but what does this app DO? I see many discussing various programming environments but I don't think I've seen anyone try to 'relate function to method' ('end justifying means'?).

A particular environment isn't the be-all-and-end-all for EVERY application or discipline...

What is better? (1)

9mm Censor (705379) | more than 8 years ago | (#15441863)

Dont tell someone whats wrong with VB. Tell them what is BETTER. VB is the best language, until there is something better for your project.

For one thing... (1)

countach (534280) | more than 8 years ago | (#15441923)

For one thing, Basic is on the way out in favour of C#. It won't disappear soon, but in a few years it might be harder to find people who want to work on it.

In my opinion, if you are re-writing, I would say do it in Java - then it will work on Mac and Linux and everything. But if you are determined to be Gates' whipping boy, at least do it in C#.

Have you considered this.. (1)

Jettamann (25050) | more than 8 years ago | (#15441945)

... Have you considered using an automation tool to convert almost all of the existing VB6 (prototype?) code to C++/MFC.

I have done extensive research into the limited set of tools on the market that can do the job and this is the best one i have found. And it has the best price too.

http://vbto.net/ [vbto.net]

Don't judge this software by the web-site...download the limited demo and give it a whirl.. the latest 2.x version of the software is very very good.

Joel seems to think it's okay. (1)

SirShadowlord (32925) | more than 8 years ago | (#15441978)

To quote Joel:

"What I wondered was, what happens if you take top-notch C++ programmers who dream in pointers, and let them code in VB. What I discovered at Fog Creek was that they become super-efficient coding machines. The code looks pretty good, it's object-oriented and robust, but you don't waste time using tools that are at a level lower than you need."

Check this link:
      http://www.joelonsoftware.com/articles/fog00000000 06.html [joelonsoftware.com]

VB.NET and C# are great tools! (0)

Anonymous Coward | more than 8 years ago | (#15441996)

Using .NET (VB or C#) you can now program quality 3D games using Managed DirectX which cuts develop time by a third! If you can program a 3D game in C# then it is sufficient for business tools.

Here is a 3D Real Time Strategy commercial game written entirely in C#:

http://www.exdream.com/games_aw.html [exdream.com]

Here is a great thread on C# games...C# will start to dominate in indie development:

http://channel9.msdn.com/ShowPost.aspx?PostID=2085 0 [msdn.com]

Go with C# 2.0 (1)

TheFairElf (669537) | more than 8 years ago | (#15442012)

I'd been predominantly programming in C#/Java until I was called upon to do a project in VB.Net. I was very skeptical initially but as the project progressed I realized that it was pretty much same as C#. It had all the features (plus some more) that C# had. A major reason why I actually started liking VB.Net was that the IDE (Visual Studio) for it was a lot better than the one for C#. This was in version 1.1 of the framework and Visual Studio 2003. The case insensitivity of the language just added to the ease of programming.

Having said that, the new version, 2.0 and Visual Studio 2005 makes up a lot of ground for C# to catch up with VB. The IDE is almost up to par with the VB IDE. In my opinion VB.Net 2005 actually went a step back when it introduced "Default Instances" - a concept where you can call non-static members without instantiating the object.

My recommendation would be to use C# if you're on the 2.0 version of the framework and VB if you're on 1.1. C# is a pleasure to program with in VS2005 due to the improved IDE features and also the code snippet feature.

VB not for enterprise wide solutions (0)

Anonymous Coward | more than 8 years ago | (#15442022)

unless it involves merely lots of small programs.

VB isn't inherently bad. What really causes the problems with it is that Microsoft redesigns the bloody language on EVERY FREAKING RELEASE.

If you had a VB 3.0 app, and you wanted to change it but have since installed 4.0 or later, you'd have to reinstall 3.0 and all the controls you used when you wrote the 3.0 app. Either that, or you would need to basically recreate the program for 4.0. Any controls you've purchased for 3.0 will not work for 4.0, and good luck on finding a 4.0 version with exactly the same functionality and calls. You are guaranteed on major rewriting of your code to merely compile in a new version of the compiler.

This is true for 4.0, 5.0, and undoubtedly will be for dot net.

The problem with Microsoft and VB is that they don't expect people to write long lasting applications. Sure, make code relatively easy to write, but they totally ignore maintainance or enhancements of the resulting code later.

Sure, with C/C++, chances are you might have a few tweaking to make, perhaps, assuming the original coder didn't use standards. However VB coders often are less standardized. Their generally only nod to standarization is by what the IDE lets them do, or builds for them. This isn't nearly the case with C or C++.

If the project is expected to be long lived and to grow, don't limit it to vb. Sure, vb is easy to pick up, but even dot net has huge drawbacks with vb in terms of limitations.

I won't even go into how big vb executables tend to get either.

"It's VISUAL BASIC!!" (0)

ThinkTiM (532164) | more than 8 years ago | (#15442037)

That's about it really.

Re:"It's VISUAL BASIC!!" (0)

Anonymous Coward | more than 8 years ago | (#15442142)

Yeah, that was helpful.

VB6 has its place... (5, Informative)

Nevyn522 (309931) | more than 8 years ago | (#15442042)

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.

Wrong Question (1)

mochan_s (536939) | more than 8 years ago | (#15442052)

Did you just get scared of the word VB?

  • There is good old VB which was used for RAD for windows.
  • There is VBScript which is a general purpose scripting language. It can be used for browers to Office to any app scripting. Basically gives access to all the sytem's objects.
  • And, there is VB.NET which is basically as full of features as C#, C++ and other code that fits into the Microsoft.NET platform.

If only Microsoft had the imagination to name products like Open Source Software does, then all the confusion would be avoided. VB, .NET, ActiveX mean so so many things it's ridiculous.

Depends! (4, Informative)

bryanporter (847667) | more than 8 years ago | (#15442059)

I've done a great deal of VB programming over the years, and I've seen all manner of projects written in VB that never should have been. Now, the poster did not specify if they were talking about VB ala VB 6, or VB.NET - the two are completely different in so many respects an argument for/against one doesn't translate very well to the other.

Here's my two-cents, by language/environment:

VB6
---
If you're writing business applications, VB6 will get you through. Manipulating very large datasets can be a bit of a challenge, and you're always going to have problems with user experience (due in large part to a complete lack of multithreading). Applications can be made that are *functional*, although your resultant UI will always seem dated.

VB.NET
------
This is an entirely different beast. You've got a much more powerful langauge on your hands, with as much power and expressivity as Java - it is quite straightforward to produce a modern, performant application with little muss or fuss.

My suggestion, if VB is an absolute must, would be to insist (as best you can) on VB.NET. Now, that being said, VB is not a magic bullet - VB/VB.NET/C#/Java, they are all languages designed to allow a programmer to express their thoughts, and it's quite easy to produce unworkable software with any of them. Do not allow yourself to fall into the 'C# is better than VB.NET' arguments, simply because they are completely non-sensical; the power of any .NET language lies in the .NET Framework, and the language chosen should be the one you are most syntactically comfortable with. That being said, I abhor the syntax of VB.NET; C# is more my cup of tea, but in the end they are (with minor exceptions) functionally equivalent. It takes about the same amount of work to do one thing in either.

I've worked professionally in VB, VB.NET, Java, Perl (alot of Perl, in fact), C#, and C/C++, and I must say IMO the most expressive langauge is C++, hands down. I love Perl, and you can do an amazing amount of things with it, but the power and flexibility of C++ is unmatched in the list above. VB.NET/C#, however, can be excellent choices for presentation-centric applications (Windows Forms applications or Web Forms). In the past, I've worked on projects that combined the two; a C# GUI that interfaced with a C++ server component. It worked great.

Any .NET language can interoperate with libraries written in any other .NET language (assuming the library conforms to the CTS), but the same goes for VB applications; in VB, you're dealing strictly with COM, a technology designed to allow components written in disparate languages to interoperate.

Short Story: If you're writing a business-focused application with limited or no multithreading needs, VB works; If you need a modern GUI with all the latest bells and whistled VB.NET/C# should be examined; If you need high-performance, minimal runtime requirements, and low-level system interaction, look somewhere else. Real-time equipment monitoring, for instance, is a task best left to C++. The rest can be done in VB or a .NET language.

Have fun!

Bryan
==

SWT Is Your Friend (1)

saden1 (581102) | more than 8 years ago | (#15442071)

Like many in here have said, I would simply argue that VB6 is on it's death bed and that is a good enough reason 90% of the time.
If I were starting a new desktop application I would seriously lean towards SWT [eclipse.org] and Eclipse Rich Client Platform [eclipse.org] . Hell, there are a number of visual [eclipse.org] editors [cloudgarden.com] for it.

News for turds. Stuff that splatters (0, Troll)

SurturZ (54334) | more than 8 years ago | (#15442089)

What kind of troll article is this anyway? Some guy gets a job in a VB software house, to re-write a VB app in VB and then complains because he doesn't know VB? And starts heaping on it, even though he's never used it much? How is this newsworthy?

Increasing cost of support (1)

bitflip (49188) | more than 8 years ago | (#15442093)

As was mentioned above, VB6 is end-of-life, so MS won't support it. That, in and of itself, may not be a big deal to your employer right now.

However, it does mean a lot to the potential labor pool he'll need to hire from in order to maintain this app into the future. Developers tend to upgrade their skills along with the technology. Sure, they may know VB6, but that doesn't mean they'll use it, or take a job requiring it. It sets back their career.

I mean, c'mon, he's hired someone who doesn't know VB to code in VB. He's obviously getting a bit desperate already (no offense intended).

However, if you're talking about VB.NET, then you've got little to complain about. It looks syntactically weird to me, so I don't like it, but it is quite full-featured and modern. Every so often I have to work with it, and it works just fine.

Myriad of problems (2, Informative)

jasonditz (597385) | more than 8 years ago | (#15442095)

Without knowing what the nature of the app is, it's really hard to make a serious case for or against VB.

Some good things to point out though:

VB is not an open standard,

VB is platform specific

VB is generally quite time consuming to maintain for large apps

VB is much slower than C++ for certain CPU intensive apps.

Possibly: The people expected to maintain the code are less well-versed in VB

If this is a small-enough, simple-enough, Windows-centric enough application, there's probably no good reason to do a total rewrite in a different language.

If, on the other hand, this app might have a customer base on a non-Windows platform, and if the program is likely to dramatically increase in size in the future, it might be worthwhile to think about changing it to a different language.

REALbasic might be a good option (1)

jessimko (139100) | more than 8 years ago | (#15442100)

I'm not sure how to best articulate VB's deficiencies, but I've had a lot of luck with REALbasic. RB will look very familiar to VB users, and it compiles for Windows, OSX, and Linux, and its apps don't require a virtual machine. Now that Microsoft has abandoned VB, REAL Software has been marketing their product as its successor, so you might want to check it out.

This original poster scares me (5, Insightful)

stephanruby (542433) | more than 8 years ago | (#15442114)

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.

The Best Language is the one you know how to use! (1)

NerdENerd (660369) | more than 8 years ago | (#15442121)

The best language is always the one you are familiar with. A language you are not familiar with is always difficult to use. If you are not a VB programmer then leaning it on a big project is a big mistake. Do not start any new project in VB 6. VB 6 had its place years ago for forms based apps but since VB.NET it should never be used to start a new project. VB.NET fixed most of the major problems with VB. With the .NET framework you can really write equivalent apps in any of the supported languages no matter what kind of project you are working on.

FORTRAN Follies (1)

CyberGarp (242942) | more than 8 years ago | (#15442124)

I worked at a place and the founder wrote the core piece of code in FORTRAN. A 300 person company sprang up around it. 99% of the software for the company was written in C around the core piece in FORTRAN. If you so much as mentioned rewriting that last piece, it was a quick ticket to the unemployment line. If I were you, I'd stick with VB or work on your resume. Strange part about the magic FORTRAN code-- it was a discrete Fourier transform. Business acumen beats good code when it comes to making money.

Don't Argue Religion with Your Boss (1)

edward.virtually@pob (6854) | more than 8 years ago | (#15442125)

Religious arguments aside, all modern programming languages are about the same. My advice would be to learn VB and do the best job you can. Fighting with the boss over which language to use will be at least unproductive and could get you fired.

VB What? (1)

dcam (615646) | more than 8 years ago | (#15442130)

Do you mean VB.Net, VB6, VB5 or what?

If it is anything other than VB.Net, you might want to mention the fact that Microsoft's support for VB5/6 has basically ended. There is also no upgrade path to newer laguages (you cannot upsize VB6 to VB.Net).

More upcoming arguments..... (1)

zymurgy_cat (627260) | more than 8 years ago | (#15442137)

Making an argument against eating arsenic.
Making an argument against sticking a wet finger in an electrical outlet.
Making an argument to end the vi/emacs debate once and for all.

VB6, and why its not as cool as you think (1)

IheatMyAptWithCPUs (978410) | more than 8 years ago | (#15442139)

In the past, I've had three serious issues with VB. 1: When distributing a VB6 application, you have to distribute the VB6 runtimes, which aren't particularly small and can make distributing your neat little app over the web a royal pain. 2: VB6, without its use of block seperators ( {} ), make for the ugliest and least intelligible code in the world. Maintenance is a nightmare. 3: There's a lot of VB6 coders out there. There's just not a lot of good VB6 coders. Anyone, and I mean anyone, can code in VB6. When people are having a hard time learning to program simple apps in a real language, like C or Java, they learn VB. Then they go into the workforce. People who honestly have no purpose coding are now writing your major applications. Don't let this happen. Stop using VB, before joe-schmo uses it to make the next windows.

Just say 'NO'. (1)

chris_sawtell (10326) | more than 8 years ago | (#15442147)

Just say no!, if you wish to preserve your mind's v^Hsanity.

A friend of mine had to produce a similarly large - dozens of screens, menus, and a WWW interface - VB project as a team leader. He came within a whisker of being admitted to the emergency psych. ward.

Get another job if you possibly can.

Key Elements Missing (1)

tmortn (630092) | more than 8 years ago | (#15442154)

If you are talking VB6 then run far run fast in terms of a large scale application. But then... what is large scale here ? Not that VB6 isn't perfectly capable in some areas. But it is fading fast and you could run into serious deployment issues in the near future with Vista looming and VB6 at EOL from M$.

VB.net is ok. By that I mean it will do anything the other languages will in the .NET architecture but it does not always do so as easily or as elegantly. Additionally the lack of a more structured syntax (lack of semi colon's etc) gets really fricken annoying if you ever switch back and forth much.

My personal experience with it has been that for more in depth options you tend to continuously dip into the common library interface accessible to all the .NET languages and it makes for very jarring transitions at times with huge swaths of 'black box' code that is sometimes hard to expose when trouble shooting. Basically this is how they 'welded on' all the real functionality of a 'real' programming language. Thus VB.net is pretty much on par with anything. But getting serious with it is not its design goal. It is optomised for the RAD concept more than any of the other languages.

For varied reasons I got sucked into a VB.net project. At the onset we were told it was our only option and thus we reluctantly picked it up as we went along only to discover later we could have chosen any of the MSIL languages. If I had a do over I would have gone with C# (if I had to be stuck in .NET at all that is.) My biggest objection has less to do with the languages/environment themselves than it does with M$ licensing/support and portability. Though mono is progressing pretty nicely.
Load More Comments
Slashdot Login

Need an Account?

Forgot your password?

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>