Slashdot Mirror
Making an Argument Against Using Visual-Basic?
ethan_clark asks: "I work for a small company (< 10 employees) as a software engineer. The company got its start with a software product written by the owner in VisualBasic. He hired me to assist in rewriting the software – only catch is, he's stuck on having it re-written in VisualBasic. This scares me, but I honestly can't make a good argument against VB because I'm not familiar enough with it.
So my question is twofold: I am looking for some confirmation to my suspicion that VB isn't the greatest language for large projects; and If VB isn't good, arguments against using it. If it is good, what arguments would you use to argue for it (for my sake)?" If you are going to argue against a language, it is best if you do so after you become familiar with it so that you can argue fairly on its merits and deficiencies. VisualBasic, like just about every other language, has its place. For the sake of discussion however, what tasks would VisualBasic not be suited for?
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?
.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.
Do the
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".
Murray Todd Williams
VB = 6 is unadulterated crap. VB.NET isn't half bad, although I much prefer C#.
"...always new atoms but always doing the same dance, remembering what the dance was yesterday." -Richard Feynman
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.
HIV Crosses Species Barrier... into Muppets
VisualBasic, like just about every other language, has its place.
And it's called hell.
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.
MOUNT TAPE U1439 ON B3, NO RING
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.
John
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...
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.
using namespace slashdot;
troll::post();
You were hired to rewrite some VB software, but you're not familiar with VB? The problem isn't VB, it's you.
Do you even lift?
These aren't the 'roids you're looking for.
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.
<xml><I><am><so><damn>Web 2.0</damn></so></am></I></xml>
Joel Spolsky explained why CityDesk, written by a shop populated entirely by highly qualified C++ coders, is 95% VB. 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.)
.sig: file not found
Visual Basic (especially VB6) have no place in the enterprise.
... End If" rather than "if (foo) {...}" has no place in my brain.
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
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.
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++.
:) I say that partly in jest, they complement each other very well.
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 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.
I used to think so, too.
Try this.
Who's your buddy now? :-)
John
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).
First company I worked for produced a series of ActiveX controls written in VB, shipped and sold with the source. It supported 3 full time devs, 2 support/sales people, one HR person, and an intern (me).
.COM world and got absorbed by ZDNet, but their components are still for sale on Programmer's Paradise, last I checked.
:) ) without peer. As to the inavailability of new APIs: a) Pretty much anything in COM can be used -- although some trickery may be necessary for custom structures. b) Anything done in a "straight" Win32 API can be directly invoked -- akin to P/Invoke in the managed world. For database work, VB was unparalleled. The ease of data connections has now come in some degree to the managed code word, but in unmanaged code only VBA comes close. C++ just can't compete. VB is no longer entirely late-bound -- if a dual interface is available, and the code is written to expect that type rather than just Object, VB6 operates as an early bound client. VB6 is also capable of being used in a late-bound fashion with almost identical code to the early bound scenarios.
They vanished after they tried to compete in the
I got an internship with Microsoft after spending most of my interview defending VB as a language choice -- this was pre-C#/.Net.
Some "facts" from above annoyed me, so I'm responding:
1) VB is only interpreted.
VB6 can be compiled to P-code, and will run interpreted. However, by default it's compiled to executable code. The only "penalty" for using VB6 when it comes to speed is really the memory footprint of the VB6 runtime DLLs.
2) VB6 is not suited to large products.
I'm aware of at least one company that based an entire website off VB6 apps. I'm sure they would be ASP.Net now, but at the time (VB4), that wasn't yet an option. So the web engine was actually a series of VB apps that were invoked to process the web request as ReadLine and Print commands.
3) VB6 -> VB.Net
(The person in question did only propose this as an idea.)
I would argue against this. There are certain elements only possible in VB6, and the switch to managed code is unfortunately not as seamless as MS would have liked. Hence the uproar when MS EOL'd VB6. VB.Net is great for managed code, and even has some features that C# lacks. I personally prefer C#, but I come from enough of a mixed background that I can handle what VB.Net code comes my way. While rewriting the application in VB.Net may be the proper thing to do, it certainly does not provide much in the line of benefits above and beyond rewriting the application in C#.
VB does have certain benefits to use. As a RAD environment, it is (or was
While I can't know why your manager wants to use VB, it's not such a terrible order.
If your manager only wants to preserve the look-and-feel of previous versions, the previous proposal of writing COM components in C++ for the high-performance portions and using VB for the front-end is certainly a very viable option, and one that I've used previously. In this manner, the weaknesses of VB6 can be circumvented while still leveraging existing components and possibly even code. At the far end of the advancement spectrum, even managed components can be exposed to COM clients -- Adam Nathan's wonderful ".Net and COM: The Complete Interoperability Guide" is probably the most complete book on the subject. If appropriate, you can write new code in C#, and expose it back to VB6.
If your manager wants to preserve the code base in VB6, you might want to determine why he wants to rewrite the application -- it's possible a better solution is just to rewrite portions of the code, depending on the scope of the changes he desires. The right tool for the right job -- VB is the right tool for some jobs, but shouldn't be presupposed to be the right tool for every job.
That being said, there are few things you can't do in VB -- although some of the solutions are probably not as simple as they may be in other languages. Keep in mind, however, that it is even possible to get assembly code linked into a VB6 application, if necessary. It just takes a little bit of creativity.
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.
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.
.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.
.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.
.NET language.
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
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
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
Have fun!
Bryan
==
No, you pussy. Real Men(TM) use small magnets directly on platters. ;)
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.
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.
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.
Whenever I hear the word 'Innovation', I reach for my pistol.
Why do people keep dismissing C++? Its free, open source, works on all platforms, and will arguably be able to hang around longer than just about any other language out there. Sure, if you do decide to move platforms you may have to do some porting, but compare that to the constant upgrades ($$$) of an Microsoft technology, and C++ will most likely come out ahead.
So they're identical - but VB.Net programmers can't learn the new (identical) language? Presumably you're not familiar with one or the other of these languages. VB6 developers that transferred to VB.Net had to learn the majority of their chosen language again. C# is more like Java/C++ than VB - the language and syntax is entirely different to VB.NET. The reason VB developers wouldn't learn C# is probably a productivity issue, rather than not being able to learn the language. Why waste time learning a new language, and rewriting (rather than converting) your existing projects when all that does it puts you in jeopardy of missing deadlines (you know deadlines don't you - that's what real programmers have). But heck - perhaps I'm missing the point - perhaps you are talking from personal experience.
dnuof eruc rof aixelsid
... and the bozos that like VB.
.Net isn't much more open), but that VB6 has been end-of-lifed. Obviously, it's not wise to make a significant investment in new development using an unsupported tool chain. Still ... at least it's no longer a moving target, and in spite of your rhetoric to the contrary there's still a large base of established VB coding talent. Much of it is migrating to .Net or Java, true, but there's a shitload of VB6 code out there and plenty of companies willing to shell out good money to maintain and develop with it. Purists such as yourself may not care for that, but there it is.
Not everyone needs to work on the bleeding edge, and not everyone that doesn't is an idiot.
In other words, you're a Java bigot that looks down upon those that don't agree with your choice of tools. It used to be C bigots that irritated me the most (the "if you can't do it in C it isn't worth doing" mindset), but now it seems that most of them have moved to C# and have finally realized the benefits of a decent GUI development system. A friend of mine once put it this way: "Welcome to VB you pompous assholes." VB6 and VB.Net have their place, and calling people that use them bozos won't win you any points (although you'll probably garner some karma from like-minded mods.) But the biggest argument to me isn't that VB6 is a black box (from an empirical standpoint it's about as thoroughly understood as it's possible for a black box to be, and
The higher the technology, the sharper that two-edged sword.
I taught myself C in college and made loads of money making small programs. I got to learn C++ and VB simulatneously when working on medical imaging projects. There are three main points i would make for extending a perhaps "legacy system" thats built using a language, any language
.Net (pref. C#). so if the boss dosent see the point right now, he will in a few days
... hopefully :)
1) If it aint broken dont fix it.
I guess you are quite a whiz at OOPS and C++ but what you really need to do is bring in the DELIVERABLES. So dont bother asking the question... if its built in VB (i would guess vb6) and it isnt a lot of pain (some say VB is a walk in the park, really?), dont mess with it.
2) Make sure you are familiar with it without prejudice!
Oh yeah, i heard a lot of people cursing, blaming and even trying to bring on a ban of sorts for VB6 but seriously its been a favorite RAD tool for many many people. And i suspect some people who do all the above may even use it when they need a quickie UI built! But seriously, i dont see any point burining VB6 at the stake and i dont see any point in installing in on a pedestal in the RAD Hall of fame... its a language, its used (quite extensively for "front ends") so get familiar and then form an opinion.
3) If all the above dosent work, the boss will realise himself
I agree to this -> VB can be a hell at times. I personally like coding in C++ and the
In my limited experience with VB6 at my work, I've found:
.net, or Java myself.
Cons:
- Doesn't really support multiple threads. I think there is a way you can do it via ActiveX controls, but it's not really built into the language like it is in Java.
- It's not really Object Oriented. It sorta has objects, but it doesn't even support inheritance.
- Your pretty much tied to using Visual Studio as the editor, and it shows it's age
- Your stuck with Windows for the rest of the applications existence
- VBs horrible syntax
- The whole language will give you a "half-assed" feeling
Pros:
- Stupid easy to build a GUI
- RS-232 interface is also very easy in VB6, but strangely, it's a PITA in VB.net
I honestly don't think there is much of anything I would recommend it to be used for. Maybe to learn basic programming skills, or a REALLY quickly thrown together GUI, but nothing big. I would look at C++ or C# for
Why do people keep dismissing C++?
Because it sucks .
It is a language designed so that a genius can write libraries designed for the merely smart to use. How many geniuses do you have in your workgroup? Me, I'm lucky. But I'd really rather they work on real design than trying to remember how copy constructors interact with template instantiation.
I don't know C++, and I know that I don't know it. Somewhere around here I have a list of interview questions for people who put C++ on their resume. They're mostly from me reading C++ code and going "what the heck does that imply?"
Unsurprisingly, most candidates fail that section of the interview. And they fail even trivial stuff like "what's a virtual pointer all about?" They may be aces at writing O(n^3) algorithms with CString, but they have no clue what's going on under the surface.
To be fair, I do know some true C++ experts. Most of them would rather be writing Haskell.
VB has taken a lot of slack, because it's a language which gives a lot of slack. You are free to write really bad code, and VB won't complain about compiling or running it. ActiveX provides a really useable interface for components (libraries and widgets) which makes deployment quite easy, and coding in parts easily attainable. That being said, it comes at a performance cost, which I wouldn't want to incur if I didn't have to (for instance, using the ActiveX ADO controls penalises you by as much as 1500%, over writing code that talks to the ADO libraries directly).
.NET has a lot to offer -- and I don't think you will lose on the performance side, because, as someone earlier forgot to mention, although .NET is compiled to an intermediatary language which is interpreted, so, to an extent, is VB. Which is why the IDE provides such an easy-to-use debugger with relative ease. Trust me, the VB6 ide beats the Delphi6 one hands down, especially with respect to real-time debugging (you can actually change your code and carry on debugging without a recompile, for example).
.NET isn't minor, as someone else would suggest. For one thing, .NET kind of forces you to go OO, where VB hid that from you if you didn't want to know about it. VB.NET isn't a simple hop from VB6 -- yes, the syntax is nearly exactly the same, but you have to learn the underlying libraries and code structure as well. There is a curve there, but it may well be worth it because of the compile-once-run-anywhere concept of .NET.
.NET). I originally met with postivity, and showed a migration route, even taking the time to put together and lecture notes on what one needed to know to migrate from ASP to PHP. I even built a mechanism for sharing the session between ASP and PHP pages with relative ease, so that a hybrid environment could exist. And after some time, because my boss didn't take it on, my fellow workers didn't bother. I know that today, they are even looking at re-writing a system I wrote in ASP, now that they have more clearly defined the requirements of the system, and realised that I built something far too complex for them. The point is, they weren't willing to move because it was too new and foreign, and they didn't have a driving force (ie. a boss with determination) to enforce the change.
VB6 is, and, in my opinion, for a long time will be, a very good platform for building database-driven applications for the win32 environment. Also, WINE has no problems with VB6 stuff, so a deployment method for "alternate" clients is the WINE route, though I don't personally offer that as an enterprise solution -- it's a work-around. But there are a lot of software houses that are quite happy providing solutions only for the win32 environment.
The move from VB6 to
All of this doesn't really make that much difference when I don't know your exact target. But I'm assuming that it's not a 3D fps, since that would be just nasty to code in VB (: . If it's database-driven, then VB isn't really your enemy -- but it would be worth the "free cross-platform power" to learn the VB.NET route. I think your boss probably wants to keep in on the action, and moving to a totally foreign language and library base may be a very diffcult move. I faced something similar at a pervious job, where I tried to show the merits of PHP versus regular old ASP (not
Whatever you run with, you have to get your boss to take it on first. Selling it to your team mates may be a waste of time. I would also urge you to choose something cross-platform, just because the way of the world is tending more towards open platforms. I could push any of the seven languages that I use on a (fairly) regular basis, but I don't think this is the place to start a sales pitch. If you would like to discuss this further, feel free to contact me. I think I've seen a lot of what you're talking about before, and I may be able to give you a more objective approach.
Disclaimer: I code in VB, Java and Python.
:: Its VB section is the most active section and enen this month if you see its hall of Fame., the winner is an NT master class., where one can control most of the Aspects of an NT based computer (2000/2k3).., which clearly defines the Fact that mnay things can be achieved EASILY in VB.
.NET apps need .NET framework and python app needs its python Interpreter. [ even files compiled with MS VC++ need MSVCRT.dll ;) ]
.NET.., also I'd like to say about the poor multithreading performance in Python.., not very effecient. Though VB6 natively doesnt supoprt Muthithreading., using VB5 one can achieve multithreading or some thrid party COM servers will help.
.NET..,
VB is one language., from where many ppl. AFAIK started out their programming career.
Many "Others" argue that VB is suitable for only desktop database applications and and mid-level applications and cannot be used to make Enterprise Apps., but with proper planning and knowledge of VB's known bugs one can make a decently performing Enterprise Apps that runs for say atleast 3 years. (I have seen no application perform correctly for more than 3 years)
"Others" argue., VB is not well defined in many aspects right from Socket Programming, GDI etc.., I'd like to say.., if tahts the case., try using alternatives., I remember I have used created an Prformance Effiecient Server handling about multiple connections suing "CSocket" in VB..,
I dunno if you ppl. are aware of PlanetSourceCode.com
If anyone speaks about dependcies.., a clearly well written Vb app has at the most its VM MSVBVM60.dll and its COM servers if reqd [where MSVBVM60.dll is included right from win2000]., perhaps to be reminded
If anyone says VB is an interpreted., so is python and
This I conclude Each Programming language has its own PROs and CONs and nothing in this world is PERFECT.., VB is no exception and so are other langauges.., and I finally say., M$ killed VB6 for their
And if you really have to stick with VB, you have to impose strict coding rules, like requiring "OPTION EXPLICIT" on ALL code, be strict about variable naming and so on.
Better be so strict about the rules that you actually end up with C#.
If builders built buildings the way programmers wrote programs, then the first woodpecker would destroy civilization.
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.
Because C++ sucks when you put it in the hands of the VB crowd. It not only gives you enough rope to hang yourself with, it then proceeds to give you another mile. The language allows programming in about twenty different paradigms, the base support of which are usually per-project custom-implemented (own framework) or crappy (MFC), and because of this and the lack of a large standard library (I mean, one that the VB crowd can grasp), abilities that you gained on one C++ project do _not_ transfer well to other C++ projects.
Now don't get me wrong, I work with C++ every day and I love it because of the sheer power it gives me. You can basically abstract away any management chores using smart pointers and other objects. And you can write the most obscenely decoupled functionality using traits classes and such. But put this same stuff in the hands of a VB coder, and you'll get C++ code using VB idiom. And that's NOT GOOD. VB coding idiom is not exception safe AND does not deal with memory management, so you'll have memory leaks all over the place, and even if they bother to put in the deletes in the proper places, you're one exception away from leaking a whole bunch of stuff. Teach them to use smart pointers to fix this? In an average C++ project "done right", you'll have to write a lot of smart pointers/auto objects yourself, and people who are used to VB are _not_ capable of writing proper smart pointers in C++. That requires reading and understanding all of Scott Meyers' books, and they won't do that. They'll think they grasp the language when they have their first MFC-generated dialog on-screen. It'll only get worse from there.
I'm the owner of a 14 yr old software co. whose first products were written in Visual Basic and HyperCard. I grew up with BASIC in the 60's, had a Timex-Sinclair with built-in BASIC, ate up MS-BASIC, and thought VB and HyperCard (though not ToolBook or SuperCard) were the bomb.
/. community at large, is whether da boss is fluent in something other than BASIC? If not, there's the answer to your question. Perhaps he needs to continue using VB to justify his existence. Just a thought...
Then my product's needs and the market's expectations outgrew what VB or HyperCard could reasonably deliver. But I was too busy running a company to learn C/C++. So I had to hire engineering talent. Talent that needed to write in something *other* than a BASIC dialect. From that point on, my code writing days were over.
Perhaps the background question you need to answer, for yourself and the
Good arguments against C++
manual memory management, obfuscated syntax, to many ways to shoot yourself in the foot.
Good arguments against Java
performance is bad, requires a JRE to be installed to run, which can be a pain. Can be hard to do simple things (eg all primitives are signed)
Good arguments for C++
good performance, as good as you can get. Many platforms have compilers for it. Open and well known. Lots of preexisting libraries for it.
Good arguments for Java I'm going totake some liberty and assume by java you meant he language and the JVM together. (no c++ equivlent)
Compile once, run anyway (via shell scripts or similiar mechanisms) compile on windows, run on z/OS.. cannot say that about much (anything? else). Vast library, no memory management, very clean language that's simple to understand and adapt. Easy to plug 3rd party libraries in and use.
How good is each one in terms of:
* Purely Object Oriented
Java very good, almost pure OO language.
C++ not pure at all
* Multi-threaded
java this is as simple as i've seen
C++ a pain and somewhat platform dependant
* Dynamic
I'm not sure what you mean by this really.
* Portablity
Java wins in that you compile once, run many places
C++ wins in that the same code can be compiled virtually anywhere
* Robust
Java provides mechanisms that make the code much more robust
C++ wins in that it's more deterministic, no relying on wierd VM things
* Secure
I don't think i'm experienced enough to really comment on this one
* High Performance
I'm no thte biggest of fans of the idea that java is slow because it runs on a VM. For most apps, this difference is trivial. For some apps, such as games, this difference is critical.
Overall, I'm a big fan of java and the idea of byte code that runs on a VM, as opposed to native code that runs directly. That said, there are areas where you ahve to use native code (eg: making system calls) or it's better to use native code (games). I think C and java will outlast C++ though.
... to lock itself into Microsoft :-)
.net code and there might be hope that you could get it to run on Linux using Mono but I'm sure that hope will shatter on the cliffs that a lot of Microsoft specific APIs and facilities will not (ever) be implemented on Linux.
Hi,
First off, whatever you're going to code with VB will only run on Windows. There might be a way to generate
Essentially you're once again committing to use "Microsoft Technologies". These so-called 'Technologies' (mostly rehashes and adaptations of what's been out there shrink-wrapped, repackaged and rehyped by Microsoft ActiveMarketing+ )... these so-called 'Technologies' are not open source. IF you are wondering how Microsoft implemented something (because you can't get it to work) you will be stuck going to their "Knowledgebase" on the Microsoft Developer Network site where they might tell you, or again not. Calls to Microsoft support, your only dependable source of support cost $$$ but I think there are subscription plans for this, you might want to check them out. It's not that support for other software is free. It's just that with the "Technologies" they're the only ones qualified to give support.
You will also find and that's aonther angle of the support issue, that people using Microsoft are a pretty much locked in community. I'm sure a lot of people reading here will likely object over this but I'm not talking about you. Slashdot isn't exactly one of the core sites most Microsoft people go to. In general these people lack the scope to look beyond the rims of their plate to see what other ways are out there to tackle a problem which thinking this further is probably why you came here in the first place.
I don't know if I told you anything new but that's my take on the subject. I wish you the best of luck that you and your employer can avoid this particular piece of fly paper.
Isn't this one of those bad ideas? Joel Spolsky seems to think so, and while he isn't an oracle, his opinion is worth something.
Suggest not rewriting the software and simply going through and improving where needed.
I work providing MIS technical assistance in microfinance (used to be an open source consultant). I've seen a lot of Visual Basic applications in service of microfinance institutions and I've seen the consequences.
What I've seen has been mainly Access being used as a RAD to develop portfolio management systems, with VBA constituting the language the logic is developed in. Some observations:
1. Such applications when used over the medium to long run invariably become unmaintainable. The business changes, loan products change, organizational structure changes, new needs arise, servers are upgraded, etc. This we all know; there is no such thing as finished software. A VB application has the advantage of getting up and running fast, but as the code changes accumulate over the years, the code becomes unmaintainable; a change here b0rks fifteen things elsewhere and the developer (often one person) eventually gets to the stage where he just says "no, we can't do this". IF you're lucky, he tells you that it's because he needs to reqrite the app. If you're not, he attributes the limitation to the abstract god of technology.
2. The Access/VB development environment is indeed a VRAD (very RAD). You can go from zero to information system in almost no time with almost no resources (the typical scenario of one developer mentioned previously). TH downside is that when you have this few people working on the system, it can be underdocumented. Which means that when your magical one-man development team jets, it's going to be easier to rewrite the application from scratch (and when that crisis comes, it's often rewritten in Access/VBA again, since a system is needed, FAST). Oh my aching bones...
3. Mentioned elsewhere, but these MS products are EOL'ed periodically. No support. No bug fixes. No security fixes. One often overlooked consequence of this is that MS drives the techie labor market towards its current offerings; what this means is that you are not going to expect a VB-based product to last, since a few years down the road the Microsoft marketing machine has changed the paradigm and driven developers towards other technologies, limiting the availability of engineers to feed your monster.
4. When you're developing a system for business usage, you're going to want to have several things which more proefessional toolchains make more readily expose; things which, more likely than not you can accomplish nominally in VB albeit with a lot of workaounds and in many cases not very reliably and sub-optimally. Audit trails, transaction atomicity, multi-user functionality, etc.
I'll post more if I canthink of them. Good to have a reference of VB drawbacks, especially since I see it so often.
Blearf. Blearf, I say.
1) VB doesn't work well with source code control - it has unnecessary binary files (*.frx, *.ctx) and it's text files create bad diffs because the IDE flips lines around and changes case of identifiers
2) COM components in VB don't keep the same GUID from time to time (depending on what changes you're making). This causes build problems because when the component's GUIDs change, you have to change all the other projects that reference them. This can be a huge timesink in development.
3) VB6 is unsupported and is a black box, which means no one else can support it either
stay frosty and alert
> This scares me, but I honestly can't make a good argument
;-)
.Net at moment has only two versions - 1.x and 2.0 - and all components of next "XXX-Hell" are there: M$ doesn't do excplicit versioning of libraries nor APIs.
> against VB because I'm not familiar enough with it.
I, as system programmer, for three years did ported number of VB applications to C/C++. Funny job for system programmer, don't you think?
The list of problems of my employer was:
1. Run-time libraries conflicts. VB applications affected worse of all by "DLL-Hell" probles of Windows: lots of functionality resides in ActiveX components developped by third parties. People usually quote ActiveX support as VB first advantage, but from POV of deployment and support it is hell.
2. Run-time libraries dependencies. Since VB is all into ActiveX, you might start using some component you haven't explicitely installed. Then when you ship the application to your customers you might find yourself in silly situation: half of them report everything is Ok, half - scream that nothing is working. Apparently, first half have the similar set of applications installed - and VB application finds the library missing from its own installation.
3. Internationalization. That was huge problem for my employer. We have had quite number of customers in Japan. M$ did internationalizion of VB in straight way: it didn't. In other words, VB as we have it in Europe/US and VB in Asia are two different VBs. Absolutely different. Since Japanese love VB, most of our customers had it installed. The situation looked so: if customer installs our application - other and her/his own applications stop working; if s/he reinstalls VB anew - our application stop working. Interpreter is the same, but run time libraries are very very different.
4. Upgradability. VB applications are one hell to maintain. We have had lots of reports that installation of our application made with VB4 was breaking VB5/VB6 installations. According to M$, the cure was to upgrade everyone to VB6. But VB6 introduced some problems so our custormers were split - half used VB5 and other half VB6.
To conclude. One can write good application in VB. But M$ doesn't make that very easy. The whole ActiveX thing is one hell to deploy and maintain.
All hope abandon ye who enter here.
I've written/maintained large programs (.5 megalines) in Java. At some time I had to write a simple program in VB.NET 1.1 (with about 10, 15 k lines). The things I noticed:
..., keep yourself busy-coding)
-to me, the syntax is OK
-the API, compared to Java, is really bad (no jdbc, no generics,
-the GUI is easy
-writing maintainable code is difficult. VB(.NET) is hard to style because of its IDE. Eclipse is magnitudes better.
Good Points about VB:
Bad Points of VB
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
First, VB.NET is everybit the language that C# and/or Java are (that is there is NOTHING that can be done in those languages that can not be done in VB.NET (Regular Expressions, Hashtables etc. and much more is available to programmers in VB.NET)
Second, if the original application was done in VB (6 or earlier) then there is no reason to believe that the language is no longer suited to the task, the only real question is "is the programmer up to the task?" Since VB and C# compile to MSIL (if both the VB code and the C# Code are "well written" then they will compile to the SAME MSIL (or near enough as to not matter...) the ONLY argument for one over the other is comfort/skill level of the programmer. This is not a trivial matter. I am far more productive in VB.NET because that is where I am comfortable, not because it is a better or worse language I can read/write VB much as I can [in my native language of] english. Where as I can read/write C# or Java about like my French, in which I am reasonably fluent, but I have to concentrate more on the translation. And thus we reach the ONLY real argument for you to make against VB, will you be more productive (and therefore cost your employer less) if you work in another language? If you believe this to be so, then you should already be able to quantify this.
Admittedly, There are far more "less skilled" programmers in the VB world than there are in the C#/Java realm. This is simply because people can learn to do "useful things" in VB (or VB.NET) far more easily than they can in C-based languages. The "entry threshold" to "being a VB 'programmer'" is lower. Still the high end abilities of the language are there, even if a number of programmers don't know how to use them, or use them correctly.
Anybody out there proclaiming that any language (other than C or assembler) is "better" then VB.NET is simply demonstrating their own ignorance of VB.
That's actually some sort of bytecode. I've been hacking x86 assembly for 10 years now, and there's no way x86 has a "ldxb" instruction.
Error: password can't contain reverse spelling of ancient Chinese emperor
Mythical like the man month, dude.
emt 377 emt 4
I totally agree with that.
.NET, the end result will be just like C# .NET.
I work with Perl, Java, C# regularly. A crappy coder can use C, C++, JAVA or whatever , he will still produce crappy code. I use these languages because I'm more familiar with C related languages.
Assuming that the guy is working on VB
Instead of wasting your time on syntax matter, better to focus on the application architecture.
I'm sure that half of the negative comment came from the simple reason that VB means virtual "BASIC". Most of them still remember their early experiences on their 80's microcomputers and consider this family of languages as toys.
Concerning the original question:
- His boss knows VB
- He knows VB
An application has been already released and if the boss was able to hire him, it means also that this application has already convinced several customers.
Problems: using VB isn't "cool". The guy doesn't want to tell to his friend that he uses VB at work.
If you choose another language:
- Make sure your boss (the other coder I guess) knows it.
- Find new friends (IE less stupid).
- Find another job.
A quality program must be coded defensively, in other words it must assume that anything can fail at any time and that it must sensically deal with it. It must not make assumptions about external inputs. Unfortunately, few programs are coded to this level of quality, but they are the ones that you won't see security advisories about. Programs that are not coded defensively will, upon hitting a problem, exit with an error message that does not help you find out what that problem is, or continue doing something where it does not make sense to continue. Troubleshooting and maintaining defensively coded applications is simple - whereas with other applications a developer often just leaves the bug for eternity.
There is extremely little example code for VB that is coded defensively. If you disagree, please post a link to an example where code to open a file has a code path that is run specifically when the file can't be opened. In the meantime, google has 748000 hits for "80004005".
However, for your particular situation, this is largely moot. If you're already working with a specific developer, they will either code defensively or they won't, regardless of language.
If you're using VB.NET then I highly recommend Rocky Lhotka's Expert VB 2005 Business Objects and the CSLA framework that the book describes. It has plenty of useful information even if you don't use the framework. There is an equivalent C# book.
.NET 2 and Visual Studio 2005 stuff is pretty cool. Databinding was a bit of a joke in previous versions that no "real programmer" would use but now it really works and can save you a lot of time. Separate your UI and business layers properly and you'll be able to use the same business code from both Windows and ASP.NET if it ever needs to be web enabled.
IMHO, the new
Your question is a bit meaningless without saying if its VB6 or VB.NET. Although I've written lots of VB6 stuff in the past, I'd be reluctant to start something new with it. I jumped from VB6 to C# just because I knew C from long ago and prefer the { } syntax but, as others have said, the difference between VB.NET and C# is pretty much just syntax.
I have one customer that specs VB.NET for all their apps. After getting comfortable with it there's just no reason for some of the comments here. VB isn't "easier" than C#, just different. If you're a bad VB programmer, switching to C# isn't going to make you a better one.
My opinion is that a lot of bias against VB stretches back to the day when it was not considered a "real" programming language. But it's grown up and turned into a capable language and if that's what the customer wants, there's no need to try to sell them on C#.
That's our life, the big wheel of shit. - The Fat Man, Blue Tango Salvage
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.
Cut that out, or I will ship you to Norilsk in a box.
And my X2 4400+ with 2GB of RAM cares why?
Because it's not handheld. A lot of people demand client programs for PDAs or "open market" smartphones.
Or, if it's on a server, because it's limited in the number of clients it can serve. More efficient code can serve more clients per second on your "X2 4400+ with 2GB of RAM".
You were hired to rewrite some VB software, but you're not familiar with VB? The problem isn't VB, it's you.
Actually, the problem is whoever hires people who are qualified for task A to do task B.
This is a perfect example of the difference between a university-educated computer scientist, and a graduate of a 6-month "tech college" program. The community college drone has only been taught how to use one or two tools to perform common tasks, whereas the computer scientist is taught to truly understand the tools, as well as the thinking that went into them, how to use them to solve multiple abstract classes of problems (instead of just a few common, specific problems), and how to apply that knowledge to use tools they haven't seen yet.
A real computer scientist doesn't care what language they work in. A good employer should know that when they hire the 6-month grad at $18/hr, they're getting a code monkey that can do only what is explictly listed on their resume. They know that when they spend the extra money for a computer scientist with an actual degree, they expect that programmer to be much more capable, flexible, and adaptable. The fact that they've never programmed in VB before is nothing more than a minor roadblock. Send them to Borders/Indigo/Chapters with $50, tell them to pick up an O'Reilly or Knox book on VB, leave them alone for a couple days, and they should then be able to apply all their learning in the new language.
Like woodworking? Build your own picture frames.
>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 if you were hired to do this job, wasn't it made plain up front that it was to be done in VB? If this scares you now, didn't it scare you then? Why did you take the job? If you're not very familiar with VB, why would someone hire you to re-write a program using VB?
Steve
A work that expires before its copyright never enters the public domain and thus enjoys eternal copyright protection.
Or, to be more accurate:
VB, as a language, is the worst language I have used in the last 20 years.
VB as a development platform is the most productive system I have used in the last 20 years.
Hate the language, love the system. You will too.
Wow, that's impressive. I've never seen so many people on slashdot admit they program in VB, at one time. Might as well add my name to the list. I'm not embarrassed - it's fed my kids quite nicely.
Sure I'm paranoid, but am I paranoid enough?
1)VB is dead, use VB.net
.net language. So the language doesn't matter in .net.
2) VB is no good for low level work
3) It is good at getting the job done
4) Why the hell does a programming language scare you? the day a language scares me is the day I look for a new line of work.
5) It is easier to maintain. This assumes that the programmer who wrote it wasn't a complete idiot...but that applies to any language.
6) VB.net compiles to byte code. Just like any
7) VB handles the memory for you. For business applications that need to be done, this is a good thing.
The Kruger Dunning explains most post on
For the boss dude, the company and its product is his life and he is stuck with what happens to it. He hired you because, well, you could be off doing your own business and your own software package in whatever language you desire, but you decided to work for The Man, and for all you know and all the boss dude knows, you could be a life-long partner in the business or you could be here today and have taken off for greener pastures tomorrow. He is the captain of that submarine (small boat, small crew, great level of autonomy from Navy HQ), and for all I know you are the XO, but that boat has to have only one captain. So folks to start calling this guy Captain Queeg is a little premature.
Another side of the coin is the software engineering version of the Hippocratic oath of do no harm -- the engineering version is first get a lay of the land, how the customer operates, what the system is supposed to do before you go rip-roaring making changes. The customer could be an accounting department using an app developed by you in information systems -- you first see how the accountants are used to doing their work and what the automated system is supposed to replace. The customer in your case is the boss dude.
The story you are telling about the micro-managing boss and the reluctant employee could be the overbearing professor and the meek graduate student. One professor asked that the project be done using unStallman-worthy Java/Swing for the data graphics front end with a JNI link to C++ to do the heavy numeric lifting. The student goes off and codes stuff in C++/Qt. Another professor has the graphical front end done in Java/Swing but with a hand-coded GUI and a student comes along insisting that the thing be redone in the NetBeans GUI designer and sets the project back an entire semester while he is dinking around with the thing.
The point is not to debate the merits of Swing vs SWT, pure FOSS vs Java, VB vs everything else. The point is that the boss dude is ultimately responsible while you are the hired hand, and if the boss dude wasn't overbearing for insisting on VB, he would be overbearing for insisting on Swing, or overbearing for insisting on anything.
"Unsurprisingly, most candidates fail that section of the interview. And they fail even trivial stuff like 'what's a virtual pointer all about?' They may be aces at writing O(n^3) algorithms with CString, but they have no clue what's going on under the surface."
Of course they fail that portion of your interview questions - 'virtual pointers' don't exist. Virtual methods exist, pure virtual methods exist, pointers to virtual methods exist, but there's no such thing as a 'virtual pointer'.
'CString' is a Windows library. It's not part of the C++ standard. Standard C++ is pretty well self-contained. Don't confuse additional libraries with the language itself.
Not knowing the language is the first reason you shouldn't be interviewing candidates. That last thing I need is a new "C++" programmer who wants to write output to System.err. Maybe you should refer C++ interviewees to someone who actually knows something about the language?