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
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...
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.
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.
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.
... 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.
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.
this is seriously one of the funniest things I've read on slashdot in the last week. For the canonical car analogy, it's like saying sheet metal has no place in modern automobiles.
there is no need to sign your posts. this isn't usenet. your username is right there above your post. stop it.
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'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.
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.
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.
Change that last sentence to...
"Every language does have it's place, but there are perceptions tha can raise and lower a language's value ON YOUR RESUME"
The perception itself does not raise or lower the actual value
Story:
Way back when, in the DARK days of DOS programming, and when most if not all of Microsoft's support was done on CompuServe, one of the forums was called "MSLANGS" - In there, among others, were the C form, and the PDS form (read that as Pro Compiled BASIC). Both generated OBJ files, for the identical linker (MASM used the same linker) - and in fact, if you wrote code that did NOT involve stings, and used the equivilent control structures, you got identical OBJ files. The big differences were pointers in C, and BSTRS in Basic. Now, as a LOT of business code then, as now, was string related, the string functions that were in basic allowed you to develop certain classes of application a LOT faster than the C guys. They would slag on us for "BASIC", and we'd smile, underbid them, and produce the work in less time. Yeah, the perceved value for a "BASIC" programmer was lower - but often the client didn't care what it was written in - only what the application did, how it performed, and how it was going to be maintained. So, which tool was more valuable? If I can underbid you by 10%, but do the job in 25% less time.... (hence, get more contracts...)
Languages are tools - pick the tool for the job.
Of course, sometimes part of the "Job" is your OWN personal development - then perceptions count for a lot
Back then, it was HARD for a BASIC programmer to get a job - VERY hard. It was niche - BIG time (IEEE-488 aka GPIB aka HPIB instrament control was one - the one I was in). Even if you had a CS degree, folks looked down at you. Then one day, Microsoft came out with VB 1.0. I ordered my copy that day. The world changed. Withing a year, the folks who KNEW BASIC (the old DOS stuff) were in demand, as we actually had a clue. I've never looked back. I've done some C, some light C++, enough MASM to have shipped a bunch of old DOS drivers to clients, and now C# and others.
My advise to anyone reading? Don't be a lanuage snob, but also, don't forget, there are language snobs out there, perceptions DO matter, and don't let yourself get boxed into a corner. Evolve or die
-- 73 de KG2V For the Children - RKBA! "You are what you do when it counts" - the Masso