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
Start with there is no future support for it.
End with the extreme restrictions to platform.
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.
... the scroll wheel won't work in the IDE.
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.
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>
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.
www.linuxpenguin.net
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.
I scream. You scream. I assume that means we're both acquainted with the problem. We proceed.
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.
For the sake of discussion however, what tasks would VisualBasic not be suited for?
Nuclear power stations.
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.
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.
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.
Tell them that Real Men (TM) don't use VB, but instead write Perl scripts in ed.
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.
basicNES 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.
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)3 75871-4590326?v=glance&n=2831553 75871-4590326?v=glance&n=283155
http://www.amazon.com/gp/product/0130293636/104-3
and then learning the essential stuff from Charles Petzold http://www.amazon.com/gp/product/0735617996/104-3
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
"The mind works quicker than you think!"
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.
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).
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...
"It's time to take life by the cans." ~ Bender ("Bendin' in the Wind", ep. 3-13)
High speed prototyping at best. Wasted harddrive space at worst.
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, 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 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/
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.
- No Sig for you!
To quote Joel:
0 06.html
"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/fog0000000
- Any Day above Ground is a good Day (Michael Rich, 1997)
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.
5 0
Here is a 3D Real Time Strategy commercial game written entirely in C#:
http://www.exdream.com/games_aw.html
Here is a great thread on C# games...C# will start to dominate in indie development:
http://channel9.msdn.com/ShowPost.aspx?PostID=208
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.
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.
What do you mean by Visual Basic exactly? VB6? VB.NET? 2003 or 2005? VBScript?
1 08690845702685296
One of my pet peeves is when people don't specify which VB they mean.
http://www.schnapple.com/2004_06_06_archive.html#
Schnapple
That's about it really.
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.
Did you just get scared of the word VB?
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.
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
==
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 and Eclipse Rich Client Platform. Hell, there are a number of visual editors for it.
-----
One is born into aristocracy, but mediocrity can only be achieved through hard work.
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?
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.
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.
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. 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 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.
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.
I used to wonder what was so holy about a silent night, now I have a child.
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.
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).
meh
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.
Friends don't help friends install M$ junk.
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.
-- Fugacity: Confusing chemists since 1908
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.
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.
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$.
.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.
.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.
.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.
VB.net is ok. By that I mean it will do anything the other languages will in the
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
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
I don't ask you to be me. I only ask you not expect me to be you.
Friends don't help friends install M$ junk.
I have spent the last 10 years coding the constition of the USA on a disk using large magnets and now it is good to use small magnets? Man, how times have changed.
I prefer the "u" in honour as it seems to be missing these days.
VB is very productive for creating simpler UI. Problems starts cropping up when you try to build complex UI. Thats when you will have to start using all these (commercial and free) addins and things get hairy.
Realbasic is also nicely object oriented. And a basic license is $99.
you might also want to check on the debugging and maintenance aspects of VB.
see if all the functionalities and underlying tasks for your target application are available with actively supported libraries/groups.
* lon3st4r *
If you want to be able to use your software on different servers, clients, or embedded systems. A portable language would be best.
VB is not a standard language at all let alone portable to other OS's or platforms.
I would suggest C/C++ and wxWidgets. wxWidgets is like MFC, only portable to many platforms and free.
One of the most important rules of software development is to not rewrite unless you've got a massive budget. Most companies fail when they do that. Look how long Microsoft had to stick at their rewrite of their OS before it (NT) finally became good enough. Existing code has already been debugged, so find some way to evolve it and leverage what you already have. New code in the same language always introduces new bugs. Completely new dev environments open up an even bigger can of worms. So get down off your high horse and lose the anti-VB attitude. You took the job knowing it involved VB, now make it work otherwise you're not doing yourself a favour, nor the 9 or fewer people who depend on you.
"Any language with constructs like "If Not foo Is Nothing Then ... End If" rather than "if (foo) {...}" has no place in my brain."
Then you'll hate Cobol.
JetBrains ReSharper doesn't work with VB.NET. Resharper gives you the tools to refactor easily and fast. Not the crappy, slow Visual Studio way. Apart from that, there is very little difference in what you can do in either language, the problem with VB is that the language itself sucks. Which looks better
If (Not MyVar is Nothing AndAlso MyVar.IsOK) Then
Or
if (myVar!=null&&myVar.IsOK)
?
-- Make America hate again!
I read slashdot too Ethan. Expect a pink slip tomorrow morning.
In 2001.
Forget thrust, drag, lift and weight. Airplanes fly because of money.
It would help to know which version of VB you're talking about, but let me try and help you out.
...well it's object oriented (unlike vbscript with the notable exception of things like ADO and calling activeX com components). VB.net is not going to provide any more comfort to the VB6 or asp.net programmer than any other language. Might as well start out with c#, get the benefits there and also have a very similar syntax as java, javascript (typeless though it is), or c++. If you love the curly brace, you'll love c#.
.net code to make it cross platform so vb.net or c# ARE cross platform to a degree. Ultimately it depends on what your boss is trying to get out of the application and what platform he/she is pushing on you.
If he's talking about VBscript (asp or script com type stuff), it's a useful, but deprecated technology. ASP can be very powerful, but unless you want to by Chilisoft, it's hard to go cross platform on it. That means buying/leasing a windows server. The upside is that it has a great connection to SQL server (ADODB) and easily instantiates com objects on a windows server. PHP is a viable alternative that's cross platform and easily connects to the same database servers as ASP. It's free and that's always good. It's just not as forgiving. As a side note, avoid client side vbscript. It's fine for internal intranet environments where you're guaranteed all IE browsers, but if you have to LEARN that or javascript, go with javascript. It's going to be easier to use in the long run, more powerful and vbscript (on the client) is not crossbrowser in the least.
If he's talking about VB 6, you'll have the same problems with cross platform environments as asp, but moreso unless you can get an exe or dll to run on whatever platform you want to port to. The upside is that it's easy to make com objects, the downside is that it's apartment threaded so you might end up with some scaling problems down the line. You can do a lot of the same things with java as you can with com, but I think there are still negative performance impacts, especially in a windows environment.
If he's talking about VB.net and is sold on the windows platform, I'd steer him toward c#. Though the object models are very similar, C# has a far superior garbage collection module in "using". VB.net has "with", but it doesn't clean up after itself like using. VB.net is also pretty useless if you're trying to re-use your prior vb or vbscript knowledge. Because of the way the object model was changed to make it more strongly typed (option explicit is always on) and
Java is also a viable choice in this market, though once again, it's going to suffer if you're using a windows server.
As mentioned before, you can use mono on your
Hope this helps.
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
I tend to question your immediate distrust of VB. Sure, I have heard all the opinions on how VB is crap from several sources. However, their criticisms are usually very specific and to be honest, quite nitpicky.
I have VB.net experience. It is a good language for quick and easy programs, for a small company. Don't set out to convince your boss it is no good, unless you have a valid reason.
That being said, if for whatever reason you still don't want to use VB, you will need to come up with good "business" reasons. Telling your boss something along the lines of "it does not right adjust the data variable in arrays, which can lead to inverse tachyon pulses in the flux capacitor" is just going to get you know where. You have have to come up with the type of reason that one user suggested when they mentioned that VB isn't cross platform. Or that it is EOL. Even thoughs are quite flaky if the boss has no intentions of upgrading the computers any time soon and doesn't really care about the 10% of the population who use something other than Windows.
He is a business man. As long as it works and "looks right" he isn't going to care diddly-squat about changing the language.
My advice, is to just ask if he is dead set on going with VB. If he says yes, leave it alone. If he says, "Why, you want to do it in something else?" then I would give him your opinion. However, right now it just sounds like you want to change something that already works for no apparent reason. (I assuming that the owner just wants the code updated and maybe some features included. Otherwise, the program itself fine.)
Why would he hire you to rewrite the software in Visual Basic if you're not familiar with Visual Basic? Moreover, if that were to happen, why would you take the job?
There is a very important point you are overlooking.
The code was created by the owner of the company. He understands VB.
And so, there is a very important business reason for the keep to continue on VB: if you leave, the owner can maintain it.
From your post it seems it is a fairly small company, at least from the IT point of view. I get the feeling you are the only programer there.
If you leave, there is no one to take care of the code until someone else is hired, and that can take some time. Who will manage it during that period ?
I don't like VB _at_all_, but it make a lot of sense to keep using it for the reasons I pointed above.
morcego
LOL... I also can't figure out an argument against making buildings on lego blocks.
It's quick to deploy, and easy! My grandma can build a house too!
Since the owner is so comfortable with VB, he is likely comfortable in the possibility that any arcane bugs will be relatively easy for him to fix or identify for the team. He probably has a good idea of what to look for before the software is released. Although tests are great, they never catch everything and he probably is counting on his tribal knowledge of the program and VB as insurance. Besides, if he has trouble with a team member, he probably thinks that he can jump right in without loosing any time.
Porting a program to a new language introduces more bugs than a rewrite because some things don't port directly, though they may come close (even VB to VB.Net). There are also bugs in any language and chances are that the owner is familiar with a good percentage of the VB bugs.
Also, he may be one of those that thinks "I can do it all and have done it all" and has the attitude that he only needs people because he doesn't have the time to do it all by himself. If he is like that then nothing you do will be appreciated.
All of them?
Help stamp out iliturcy.
which language are you going to offer as an alternative? you know which one is the best for a large project? - the one you've got large project experience in. sounds like you'll be carving your boss out as a possible contributor to the project - if you switch languages you'll be responsible for the choice. you can hang yourself in any whizbang language. what matters is experience...
What about C++ and Java?
In which areas is each one good in?
In which areas is each one bad in?
Good arguments against C++
Good arguments against Java
Good arguments for C++
Good arguments for Java
How good is each one in terms of:
* Purely Object Oriented
* Multi-threaded
* Dynamic
* Portablity
* Robust
* Secure
* High Performance
I am sure lot of us would like to know what other people think about the same. So, more comments, the better....
RealBasic is quite portable and surprisingly stable. I've used it for a couple months and have VERY few complaints. Python on the other hand...
Often wrong but never in doubt.
I am Jack9.
Everyone knows me.
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
He hired me to assist in rewriting the software - only catch is, he's stuck on having it re-written in VisualBasic.
That's his perogative.
This scares me, but I honestly can't make a good argument against VB because I'm not familiar enough with it.
Then you're obviously not the man for the job, and you are fucked.
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
I always thought that VB was just leet speak for AOL ProG CoDERz.
Get used to different types of files can only do certain things:
Consider the following:
Remember that this is your boss's pet language. Say three nice things about it before you trash it. The best way to do this is a comparison table with columns like:
.NET, with Win64 coming).
* upgrade path
* portability
* availability of trained staff
* error rate
* development speed
* performance
* etc, etc, etc.
The "best" language will depend, as other have said, on what the exact application is.
Given that your current environment is VB6(?), I would suggest that you consider:
* VB.NET
* C# - because VB.NET is much closer to C# than the original VB, so you might as well bite the bullet.
* Delphi - although unloved by IT types, it is a very good RAD environment suited to a medium-sized shop, and offers portability that puts M$ products to shame (Win16 projects can be opened, built and run for Win32 and
* Lazarus / Free Pascal - an open-source Delphi clone that is a bit clunky, but covers a very large number of platforms.
* RealBasic - a VB "clone" that is very cross-platform.
First of all, you really should consider the project's needs and your customer's needs. For example, I'm developping and supporting some small point-of-sale application for over a year now, and I chose to write it in VB6. The project called for something that would be ready in about 3 days, and work on old machines, so neither C++ nor .NET were a possibility.
.NET app on Win98SE? Yeah right). However, there are a few companies I heard of that offer VB6 language clones that are supposed to be good, and even better than VB6. Google...
For small (Or even medium) apps that are not speed-critical, and just handle files, user input, and database data, VB6 is great. There's also a huge supportive community around it, that adores Copy & Paste, and I say that as a good thing - When you see a code snippet on some site, chances are you can use it without modifications. It will be "packaged" as an independent function or module. And people do great (and crazy) things with VB6 - You can find almost anything on the web..
The major problem with VB6 is that Microsoft killed it off, and left people like me without a replacement (Support a
All in all, I'll continue using VB6, unless I stumble upon a really big disadvantage.
VB and VB.NET are effective, productive programming languages; on technical grounds, you have very little grounds to argue against them. In fact, for most applications, they are probably better languages to use than C++.
Performance used to be an issue with VB, but is not with VB.NET anymore; even in VB, a good strategy was to write performance critical code in C (as little as possible) and the rest of the application in VB. And the VB language (but not VB.NET) had grown organically, so that, as a language, it was a bit crufty, but I don't think that mattered much.
Of course, VB code frequently has problems, but that has causes outside the language, foremost that the IDE enables people with little experience to write applications, and the way the IDE handles GUI design (also a problem with VC++). Another big problem with VB is that it's proprietary, so you are stuck on the Windows platform; however, there is a VB.NET implementation being created for Linux.
So, overall, I don't think you have much of an argument, in particular if the discussion is about VB.NET
I would argue not using VB on the basis that it is not cross platform. ...
I second that, if you become successful with your product sooner or later you'll be confronted with this question. As soon as you want to sell your product to governments or city administrations you'll be faced with this question.
Yet VB definitely has no long time future and you have to switch anytime. If you surely know you always stay in the Windows environment you might choose C# but I wouldn't advice that. You can equally well choose to switch to C++/MFC (as somebody else advised) and still have the road open to anything. From C++/MFC it's quite easy to switch to C++/wxWidgets which you should target in any case in the long run. With wxWidgets your code almost instantly becomes cross-platform without much extra work. All you have to do is keep an eye on wyoGuide (http://wyoguide.sf.net/), it advises you how to code so your product becomes cross-platform even if you never actually try it out.
So before you switch design your development strategy first. Since development always needs time, sometimes years, and you have to support your product even longer. So IMO moving slowly towards C++/wxWidgets pays off in any case. Any good developer knows C++ and wxWidgets is quite a full featured framework.
There are more ways to develop good products but I simply can't advise them. Java with all its addins isn't easier to code than C++ anymore, faster development time has become a joke and Java applications are easily spotted by the users and definitely not liked. The QT framework is another alternative but there seems to be no free cross-platform applications and when you look how long it takes to port GoogleEarth to Linux I'm loosing fait. Yet the GTK+ framework, forgive me if I say it so blunt, might be useful for free SW but in no case for commercial development.
O. Wyss
See http://wyoguide.sf.net/papers/Cross-platform.html
http://www.geocities.com/SiliconValley/2060/freewh eel.html
.Net has never been interpreted. I doubt it ever will.. Code is compiled to byte code. When executed, the JIT steps in and compiles it, then runs it. The IDE and debugger run against compiled code. You can step through at source level, IL level, or ASM level. There is no interpreter, anywhere.
There was a 16 bit version of VB4, but not many people used it.. Most used the 32 bit version of VB4. VB5 and up were all 32 bit, and COM based.
Other than that, your other points are very pragmatic.
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.
Slashdot: WHADDAYOU WANT?
VB: Well, Well, I was told outside that...
Slashdot: DON'T GIVE ME THAT, YOU SNOTTY-FACED HEAP OF MALIGNED SYNTAX!
VB: What?
Slashdot: SHUT YOUR FESTERING GOB, YOU TIT! YOUR TYPE MAKES ME
PUKE! YOU STRUCTURELESS STUFFY-VARIABLED MALDELIMITED CODE!!!
VB: Yes, but I came here for an argument!!
Slashdot: OH! Oh! I'm sorry! This is slashdot!
If you're not familir with VB, how do you know you should argue against it?
Dialectician. Archology.
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.
In computer science courses, the best language is the one that teaches you the most with the least distracton: Scheme for recursion, Java for OOP, assembler for how computers really work, C for OS-level software, C++/Java for "software development" and because a lot of jobs will expect that you know them.
/could/ do it the hard way, why would you?
In business, programming languages are tools. Good CS languages are bad industry languages almost by definition. Coding in VB/Perl/Python is so easy that you don't need a course on it. (How would you feel if you were paying $40,000 a year, and you had to watch your professor position a button on an interface?) But when you just need to make something work, even if you
If I was going to write a program just because I wanted to, I would use Ruby/GTK, or maybe Gtk-Perl when Perl6 (and bindings) come out. (Python is a great language, but after spending some time coding in Scheme, Python's syntax annoys me. Like the whitespace thing.) But I use Linux. If you're talking about a Windows program, VB very well might be the best choice. Compared to something like Visual C++, anything bad about VB is negated by the fact that you don't have to manage memory. Compared to something like Perl or Python (or even Java), anything bad about VB is negated by the fact that making the GUI is painless.
Yeah, I had the EXACT same experience last summer (are you working for Astech?) and found out that VB is great if you are integrating your software into a MS Office application, like for instance excel. It's easy to learn, I picked up all my know-how from that paperclip helper guy and the MSDN online database, and it's easy to do fairly complicated things with. The major downside is that it's really slow, and doing complex calculations makes it really really slow. It's not bad though, I would give it a try. Besides you are a software engineer and you should act like one, you were taught to adapt and that's just what you should do!
Har?
I think the remarks others have made about cross-platform issues are good ones, but I would add to that one other important comment: Don't make a big fuss about why not to use VB unless you're prepared to offer a substitute. If you do have a substitute, focus on its good qualities rather than on VB's bad ones. Show what additional things you could do if only you had that other choice. Sounds more positive that way.
Common Lisp is industrial strength, scales well to large applications, and works cross-platform. For example, LispWorks offers a Common API (CAPI) that allows writing portable code for deploy on Mac/Windows/Linux.
Kent M Pitman
Philosopher, Technologist, Writer
Well, "large" in the sense of "lots of lines of code" is one thing. 250,000 or 2.5M lines servicing 10 people is a much different thing than 25,000 lines of code serving 10,000 people. Maintaining the former in any language is easier than maintaining the latter in any language.
The main strength of VB is it's relative accessibility. It is suited for small projects and by small I mean small distribution, not small in terms of the size of your codebase. The main problem you should be addressing is your development methodology. If you have 47 branches of the same product that you're trying to maintain simultaneously, it doesn't matter what language it's written in and it would seem the temptation is there far more often with VB projects than with other languages precisely because it is so "accessible." Ergo, its greatest strength is also its greatest weakness.
Other languages, almost entirely because they are somewhat inaccessible to the layman, frankly make it harder to fuck up the development cycle and that is more of a problem than the choice of language.
There used to be several good reasons not to choose Java. They disappeared a long time ago. If you want to be able to say to your customers "Yes" to (almost) every can I deploy on/with/or against then Java is the logic choice. Everything else is an also-ran.
We are selling bucket loads of java applications and deploy anywhere, anytime with (almost) no code rewrites. Even on windows (which is a rare choice).
Stu
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.
Oh it wouldn't be a discussion on /. about programming languages without the obligatory bust on PERL! I think we need Wall's law to compliment Goodwin's Law.
Atleast you arent being forced to switch to tcl/tk
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
Visual Basic is not good for writing for the fuel injection computer in your car. For everything else it's perfect.
i really don't hear any compelling arguments agaisnt vb. the market obviously needed it, and ppl do enjoy writing it. it all depends on what kind of software system you need and pick the right tool for the job, and other considerations in business.
it is me
For those that don't actually know (what kind of nerds are you!), BASIC is an acronym for Beginners All-purpose Symbolic Instruction Code. Do you really want to be writing in a programming language that is made for beginners? Granted Microsoft has brought it a long way, but it's still a beginners language. My personal experience is VB is buggy at best. If you want to do it better, write it in Visual C++.
--
Luck is just skill you didn't know you had.
I had almost exactly this situation a few years ago. My then boss had test suites written for him in VB, and when we were designing the test software for the newest of products, he insisted it be in VB (for the Windows part, at least).
There were many problems with that, not least that the test suite had to test a number of different systems, and was distributed by nature. The test client could in fact be anything (the target system was running LynxOS). My argument was that the existing (VB5 transitioning to VB6) implementations did not give me proper access to sockets and IPC functionality, so we compromised.
The client had a VB front end, which called DLLs written in C (I wrote those for the back end access) which then did the heavy lifting of communicating with the target and invoking the tests. The VB front end dealt with data display and user interface.
From my experience, that's the best place for VB, and it also meant I could port the client to anything I wanted (I simply had to invoke tests and get results across sockets).
He was happy (he could see how the overall logic of the system worked) and I was happier because I could do the back end in a far more portable (and writeable, to me) manner.
Pete
So this is what I did. I said to my boss that I thought it might be a good idea, but that we should bring people up to speed with Visual Basic. And I would do that: I would design a self-teaching course on building applications with Visual Basic. So I created a course in which the students would build a small application, which basically was a simplified version of the Telebanking system for which my boss wanted to use VB. About 20 of my colleagues did the course, and after that we sat down with my boss, and I just let my co-workers thrash VB. They all said that at the start it seemed to be fun to work in VB, but when you had to get down to do some serious work, it was absolutely terrible. In the end, my boss had no choice to drop VB, and I could bring in my preferred Delphi.
Problem solved.
... 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.
I know, I know.
.NET. But, just go for it. Why?
.NET, you can share respectably generic containers
/hard/. Got that? /HARD/ to produce. And,
You don't want to speak
Well... at least with
and other constructs across languages. That's a big deal.
That includes C++/CLI (or whatever they call it now). Yay!
Think of it: You get to learn modern C++. And if during that process
you gain insight into your VB or C# or whatever the language-du-jour
happens to be, you can integrate it into a difficult but ultimately
rewarding multipardaigm approach. Pretty nice.
But, really, don't worry about all of that for now: focus on good
object-oriented programming, while taking advantage of hard-won
lessons from Lisp and ML. That's part of what you get from studying
generic programming.
You'll get the most benefit, ultimately, from being able to work with
all kinds of programming (I know, a number of important approaches are
still left out here, but bear with me): structured, object-oriented,
functional, and generic programming.
C++/CLI is looking awfully good. It's not a perfect or pure representation of
any of those things, but it's a platform that can allow very many of the
good things of each to make sense.
If you swallow the VB.NET pill... well, medicore designs will always be
medicore. Excellent designs are
their benefits are nearly always underappreciated.
If you produce an API that makes sense today, look at it and ask: will it
also make sense tommorow?
I know. We live, and do our work, in a deranged view: Get it out the door!
This isn't the right way to do it-- almost never is-- but, that's bread and butter.
I once left a job over the adoption of Java. If I'd been more clever and subversive,
I would have just said "sure" and waited.
Makes sense? Sure it does.
So don't worry: It sucks that the platform you want isn't what the people-- managers
especially, but also the team that's already acclimated to it-- want to use, but
let them do it. Just try to bend it in directions which make real sense.
When your day comes, you can shine (especially if you also are ready to adopt what
are ultimately more professional and frankly more expressive tools, wherever they
come from), even though it's ultimately probably going to be the case that this
is not noticed.
My two bits.
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.
By yet another "I'm a great programmer and I recommend Python" type zealot.
Don't believe the hype, VB is a great tool for most real environments, the alledged superiority and flexibility that Python brings you is mythical.
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.
If you can do it in Visual Basick then go for it. The best programming language is the one that you know the most. each language is designet for a praticular tasks...thats why we have so many programming languages. but if you know the language you can do allmost anything. as an example lets say that you know basic C and strong VB .. if you have to do a program what language you will pick ? if you pick VB is this mean that C sucks ? no ! it mean that you know VB better and you can make your work with VB.
afcourse if you are a super ninja mo fo on programming languages you will know that there is some BIG diferences between VB and C. And in general between compilator languages ( C ) and interpretators ( VB ) .
but as i previos state it depend of the taks.
So .. to finalize with one word .. go for the language that you know most.
p.s.
sorry for my bad english
sorry for my lack of brain ... too much Jack Daniel's & beer
DrFrancky
--
Breadh Acetone - thousands of GNU/Linux users can't be wrong !
but I honestly can't make a good argument against VB because I'm not familiar enough with it.
There's your argument right there. If you're not familiar with it, then either you're the wrong guy for the job, or the tool is bad. It's up to you to prove that a different tool would be better.
Ask him for a chance. Take a small, standalone part if it exists and rewrite only that in your favourite language as a proof-of-concept.
Assorted stuff I do sometimes: Lemuria.org
If we're talking about VB.NET (VB 7.0), it's the same arguments as you would use against Java. Because .NET is very close to being a clone of Java.
Of course the keywords are different, VB still has "End If" instead of "}" and so on, but to base your argument on that you basically have to be a PHB (our boss actually used that arugment *for* VB. "Those curly parantheses are way too hard for people to keep track of". Even though 90% of the programmers were taught on Java - but of course the boss himself and three other people were old Cobol programmers).
For example, in VB: If (a = b (c)) Then ...
1. Is the "=" an assigmnent or comparison?
2. Is b a function or an array?
The syntax of VB is absolutely shocking and has caught me out many times. Luckily, the guy I used to write it for has now got the horn for C#, which is a lot better.
Stay away from VB6 if your project will require extensions and modifications in the future. VB6 is object-based, not object-oriented. You can not make good object-oriented apps with it that follow the Model-View-Controller pattern. VB6 also has other inconsistencies (like null and empty, set and assignment etc).
VB7 is a proper object-oriented basic; there are minor differencies with C#, aside from syntax.
I think I speak for everyone here when I say...
HOLY BAD ENGLISH, BATMAN!
Anyhoo; VB may well be the language that many people start their programming careers with, but it shouldn't be. VB is a poorly conceived language in terms of syntax structure and consistency, not to mention that it lacks a vast number of functions which you would expect to be native to the language, not to have to load DLLs to access them.
Also, it's Windows-only and proprietary, and you have absolutely no idea what VB is doing at any given time.
Goten Xiao
Looking at comments, the main criticisms of the language seem to be:
1. It's made by MS, and MS are inherently evil
2. We like open standards that work cross platform. VB isn't one.
3. We're C programmers (or Java programmers or whatever) and don't know it therefore it must be bad.
4. Early versions of VB were buggy and inconsistent. People believe this to be true of the later version too.
5. experience with lots of bad code written in VB.
6. Technical, well researched reasons that seem minor but actually make the language less practical than other candidates.
Of course, #6 is always legitimate. #2 can be legitimate, but some software doesn't need to switch platform. If it will run on a low power PC running an old version of Windows, and typically there will be a single machine dedicated to running the application, then there's no need to port to a different platform. The others are just FUD and hysteria.
It seems that the previous replies discuss the pros and cons of VB per se. In a more general sense, they're discussing whether one programming language is better than another.
Does the choice of the programming language really matter that much? From my humble experience, I've noticed that programmers' output depends on other things entirely, such as their development methodology, and correct use of design patterns (not going too far in either direction).
I've actually seen different programmers write projects in different languages, and it seemed their output was relatively uniform (the good ones did well in each language, and produced code that had a 1-1 correspondence with what they would have done in a different language). Stuff like test-driven design (and other XP methodology), for example, has a more dramatic impact than the debugger of the IDE of the language that your using (which I avoid anyway). You can encapsulate stuff (to some degree) in any language, as is the same for abstracting things that may vary.
In some rare cases, some things can't be done in some languages (and I'm not talking about Turing completeness): there are deffinitely programs that you _cannot_ write to execute as efficiently in Python as in C. Given that you already have a prior version in VB, is this really your case?
So overall, I think that if your project is large, then amortized over time, you will produce the same results anyway (because getting used to the language will be averaged over time), and if the project is small, what's the difference anyway?
BTW, mod me down to your heart's content, but I'd appreciate some reply with content if you disagree (perhaps I'm wrong, who knows?).
Maybe I'm getting old and cranky, but I just can't take development language holy wars anymore. Ninety-nine times out of one hundred, unless you are present at the start of a business, the language choice has already been made for you. No matter how appealing it may be to you as a programmer to start from scratch, it rarely makes sense from a business perspective. The lure of the complete rewrite has killed more otherwise successful software products than just about anything else, Netscape being one of the more recent and spectacular examples. And at the end of the day, as an employee you are paid to make money for the company, not to advance your biases about language aesthetics at the expense of the company.
As far as VB goes, it's not the best language around, IMHO, but it does make rapid development of user interfaces pretty quick and easy, and if performance becomes an issue, you can always call out to DLLs written in C or C++. It wouldn't be my first (or second or third) choice if I was starting from scratch, but if you already have an extensive existing codebase, you need to have some damn good reasons to abandon it, and language choice is seldom a good reason for much of anything.
Proud member of the Weirdo-American community.
I can't remember, but I think this version doesn't work properly across horizontally split code windows ; I've got a patched version lurking around somewhere (I got the sourcecode and patched it).
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.
It is Just-In-Time compiled to native code.
Despite all technical argument, the main argument against using VB is that it is end-of-life; no more support. Old VB would be a stupid choice right now as any bugs in the language will never be fixed and any future features you might want to use, will never be implemented. VB.NET will have a longer life-span, but will inevitably be a dead-end too as it's upgraded to VB.BuzzWord, though the life-span might be long enough to survive the life-span of your application (although applications usually life much, much longer than expected, as Y2K demonstrated). Personally I'd atleast choose to use a language with a better life expectancy.
Slashdot social media options: AIM, ICQ, Yahoo, Jabber and Mobile Text. Why no MySpace?
Pfff! Real Men will the binary onto the disk with only their minds.
"Proudly Posting Without Reading The Article"
Firstly, there are different versions of visual basic. Although VB.Net and VB6 are supposedly versions of visual basic, they are really very different. From language perspective, VB.Net is VB6 structured in the C# structure. So if your boss is an expert in VB6, there is still a learning curve for him when migrating to VB.Net. According to internet sources, VB6 is more popular than VB.Net. From implementation perspective, there are options so that VB6 programs can be compiled to native code. VB.Net programs on the other hand requires the .Net framework. That means the computers must be of
certain calibre so that the .Net framework requirements can be met. If you are migrating the new programs on existing computers, there is a high chance that these computers will need upgrades/replacements.
Whether visual basic (VB6 or VB.Net) is suitable for a project is actually dependent on the nature of the project and the client. Below are some of the characteristics of visual basic I can think of. I have also put in pointers for Java as it is currently one of the most popular language.
(1) VB is good for prototyping. Screen changes can be made within minutes.
There are IDEs for Java to support GUI design but not as seamless as VB.
(2) VB is good for both non-programmers and programmers.
The syntax is fairly simple to understand and there is no need struggle with OO concepts.
Err...well VB.Net is actually OO. Hence VB.Net is harder to learn than VB6.
Java programmers need to know OO concepts just like C programmers need to know pointers.
(3) VB is not so good when high performance is required (games/encryption...etc).
It's not designed for that.
(4) VB is not so good when very fine control is required.
(eg. programming of window components, COM objects, communication objects...etc)
(5) VB is only usable on Microsoft platform. VB.Net is only usable on Microsoft .Net platform.
It is possible to use Mono for linux platform but it is not a safe bet. .Net framework is not native in WinXP and need to be installed separately.
This is just like downloading Java runtime and installing it to run the Java program.
(6) VB programs can do automation (eg. invoke an Excel spreadsheet from your program...etc)
on the Microsoft platform.
(7) VB6 is coming to the end of life. VB.Net is less matured compared with VB6.
Compared to VB6, VB.Net is much lacking in both content and accuracy in the documentation.
Java is a matured product compared to VB.Net and has more in both content and accuracy
in the documentation.
(8) If VB.Net is used, please avoid SOAP calls. They degrade performance.
For big projects, the overhead will be significant.
(9) If the older application uses Window DNA, it is likely to be easier to migrate to VB.Net.
Otherwise, the team may want to explore alternatives and weigh pros and cons.
Afterall, VB is not the only choice on the Wintel computers.
Hope these information will be useful.
Visual basic allows *very* ugly code to run; the problem with VB isn't necessarily the language or the API; but the fact that it allows *TOO MUCH* freedom, resulting in ugly code, ugly hacks being used; hence my amazement that VisualBasic is actually used as a language to teach other languages (this was back in 2000 btw), before visual basic was introduced, Pascal was the learning tool of choice.
Now, it sounded all very nice, but the reality hit when C++ is taught, basically you have to dump everything you ever learned about Visual Basic, and learn the correct way.
I think in the end, what makes a bad VB programme and source code, isn't necessarily the language itself, but the programmer who fails to discipline him or herself to sticking to the basic programming principles; now sure, Microsoft could go in there, have *very* strict rules for how code should be laid out, resulting in the most crapiest of programmes to be rejected, and thus require reviewing, but at the same time, this is also Visual Basic's strengths, the ability to write very dirty and very quick code, and push it out to the users with in a space of a few hours - then sort the niceities of the software out later on.
I'd have to point out most Aussies recognise VB as Victorian Bitter, ie beer. Is that a problem?
-- All your bass are below two Hz
Consider VB.net.
.Net framework under the hood. Syntax familiar to old VB6 coders. You can mix C# or C++/cli later.
.net runtime download.
Pro: As powerful as C#. Full
Cons: 20MB+
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
I am on a similar situation, anyone would like to explicit que reasons NOT to use Access + VBA for a medium to large development?
missing "end if" leads to a runtime error. 'Nough said. Oh yeah, also the IDE is hellspawm.
___
No power in the 'verse can stop me
VB (.net I presume) is a pretty feature-complete language. Cons: it has a legacy and .net features have been retrofitted onto the language. Pros: it really is quite powerful, rapid and reliable in ways that Perl, PHP etc fail to achieve. The debugging environment is streets ahead of anything else I've seen and really saves you time. Just to note, I've developed commercially with all of the lanugages I'm citing.
.net framework, C# was built specifically for that purpose and provides a more elegant syntax than VB.
I do believe however, if programming for the
If your boss is hooked on VB5/6 - forget it. The languages were meant to be simple, but through bugs in the libraries and the convoluted methods you had to use to access system calls it generally wound up being more time-consuming than just coding in C++.
HTH.
A friend of mine works for an engineering firm that churns out software tools for their kit in all sorts of languages, none of which I'd classify as cutting edge, neat or elegant. While I rib him about it, there's no denying that it all works and their customers nevver complain. The boss has no problem attracting good people since that all view software as a means to an end, and if it ain't broke...
So I am guessing that the boss:
- doesn't care about portability
- figures the VB black box is small enough to grok
- figures he has had no problem retaining good staff
Xix.
P.S. conversely, I have spent the afternoon wading through La Brea tarpits of undocumented MFC spaghetti and decided to replace it with half a page of PHP socket calls.
"Everything is adjustable, provided you have the right tools"
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
I believe I have never heard the term before. Yet so fitting, so...insulting.
My new sig:
I hate Microsofties.
VB6 or previous, your asking for trouble, Try pushing for VB.NET, as at least it's a .NET language.
Personally, I would push that little bit harder, for C#, as it got all the advantages of VB, and none of the disadvantages...
V I S U A L B A S I C
22 9 19 21 1 12 2 1 19 9 3 - as numbers
4 9 1 3 1 3 2 1 1 9 3 - digits added
\_____/ \_____/ \_____/ \_____/ \_________/
4 4 4 3 4 - digits added
Thus, "Visual Basic" is 44434.
Add 2971 to it - this is the year guillotine was first used, written backwards - you will get 47405.
Add 4091 to it - this is the year Oppenheimer, the man who created the atomic bomb, was born, written backwards - you will get 51496.
Add 8591 to it - this is the year Nabokov's "Lolita" got published, written backwards - you will get 60087.
Turn the number backwards, subtract 1686 - the year Newton published wildly misunderstood "Principia". The number is now 76320.
Turn the number backwards, subtract 1929 - the year Bingo was invented, taking many lives in years to come. The number is now 438.
This, written in octal, is 666, the number of the Beast.
It speaks for itself. QED.
Copyright (C) Michal Zalewski http://lcamtuf.coredump.cx
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.
Reason Number 1 not to use VB:
Tell your boss no one on Slashdork thinks it's cool to use VB and I'm sure he'll change his mind right away.
This is not surprising since VB is basically glue. Programmers spend much of their time pointing and clicking, and calling components without understanding what they are doing or the rationale for the way things work they way they do.
Attempting to rewrite any code in VB is sheer stupidity. Even if it was VB to begin with.
Porting to VB.NET is an option but even there I would be extremely wary of using it. VB.NET might be easier for VB coders to pick up, but as I mentioned before, such people tend to be lousy programmers and will consequently turn out rotten code. It would be far better to code in C# and hire C#, C++ or Java programmers who tend to have a clue about what they are doing. Be aware that .NET framework is a large runtime and doesn't work on older versions of Windows.
Another alternative is to port to Java. This isn't without pain of its own but it at least allows you to produce something that runs anywhere.
I worked on several similar projects a few years ago where the orginal applications were written in VB6 and I had to re-right/fix them. While I will agree with many other posters that the UI portions were very easy to write/integrate/change and use, the backend code was a different beast. (it you are using VB.Net then many this doesn't apply?) VB6 wants to use a lot of variants.. big slow memory structures for a lot of variables that it passed between functions. For one example I had an array of numbers stored as text in a file that I had to change to integers, flip the array, and save. While my 10 lines VB code were crunching away, I wrote the same code in C, ran it, and was written and done before the VB app finished processing one file. Of course I likely could have optimized my VB code but my point is that simple data munipulation can end up being extremly slow if you are not careful, more so than in any other language I've used. If all your VB code does is UI stuff and very little backend or data processing then it's probably fine given that your client usings VB now and doesn't seem to have any cross platform problems. I would however suggest that you interface with as much non VB code as possible for doing any sort of heavy processing.
1. I was hired to do Visual Basic programming 2. I don't know VB 3. I need to move them to a language I know to save my job 4. Thus, I need to find problems with VB, instead of determining what is the best tool for the job (the existing code base in VB would tend it give it a head start, but see #2 above).
My software solution is often thrown out of a company when a new manager comes on who knows our competitor, and not our software. Or software still does the job they bought it for, better than the competitors, but the new manager will sandbag us to management instead of learning a new piece of software, thus burdening his new employer with costs for new software, conversion costs and lost productivity as everyone stops what they are doing, is retrained, and comes up to speed on the new product.
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".
A fair argument against VB6 is that it's at end-of-life.
.NET, and as their flagship programming product, I'd be very surprised if they were planning on dropping it. After all, more people program in VB than any other language. Why would Microsoft turn their backs on their biggest customer base?
Got a link to back that up? VB support has already extended into
Like woodworking? Build your own picture frames.
It isn't a large project if you're writing it yourself. Large projects require teams of developers. You by yourself does not a team make. ;)
VB 6 would be OK for this kind of project although it's a bit dated now. If your boss is stuck on VB you could try recommending VB.NET (which also sucks but)...
I went from being a big VB fan (in the early 1990s) to being completely disgusted with it (early 2000s). The reasons why are irrelevant to this discussion.
My suggestion to the original poster is to do what your boss wants. VB will either prove itself useful for this particular project, or prove itself useless for that particular project. If the latter, then you will have all the ammunition you need.
Despite my disgust with VB, rewriting large applications that are already based on it in another language will be even less productive than continuing to maintain the VB versions. The tactic I have taken, however, to rid myself of all my old legacy VB programs is to write all my new applications in a better, more future-proof framework. My bosses eventually came around to see my point of view, and the old applications are being allowed to lapse and die as new applications evolve to replace them.
That approach allows us to continuing functioning under the old applications while giving us all the time we need to develop reliable replacements. This takes all the pressure off of us and allows us to continue working towards the future rather than spending all our time running in place rewriting what we already have.
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.
First VB6 and VB.net are different . Then you have the major itterations of VB.NET. I personally like VB.NET 2005 and I really like upcomming technologies like Linq (DLinq, XLinq). I will tell you that no matter what language your using, you better prepare to scale. Not everyone will have a grid, but you need similar code to make good use of quad and eight way cores that Intel and AMD will certainly have out in the application's lifetime. .Net embraces web services and will help you scale and move into other OS's in the future. But you have to know your companies tolerance for Linux.
Remember your writing the solutions your client (boss) will embrace. Not just cool stuff for yourself.
Check out channel9.msdn.com and look up "server core" and "Linq". You will see that microsoft is taking higher order programming very seriously and taking the simplicity of non GUI servers seriously.
Hey, sounds like I could have worked for the same company. If the re-write is in .net, then chances are really good haha. But I felt the same way, I hadn't really used VB, but I had heard that it was really only good for beginners, and wannabe developers. I found this to be untrue however, especially with .NET. With .NET comes the ability to do the same things in all .net languages, in fact the .net compiler turns it all into the same meta-language for the CLR, no matter what it's written in. So don't sweat it, just learn the VB and use the VB, leave the issues with that to your boss to deal with, and try to learn a little about optimizing the code while you re-write it, because you can take your skills anywhere with you.....as long as you have some to take.
What problems are there with the existing code? Performance, reliability, scalability, maintainability, major new functionality, portability, or something else? Or some combination? The reasons will have a strong bearing on whether VB is appropriate.
I don't know VB myself (other than hearing constant comments about its bugginess, lack of scalability, the way it encourages quick hacks and bad design, platform dependence...). But it might be that the reasons for the rewrite (e.g. portability or scalability) pretty much rule it out. Alternatively, if the system performs and scales well and is maintainable and reliable enough, and is likely to remain so for the long term, then perhaps VB might not be such a bad idea after all.
Other folks have already pointed out that the decision also depends strongly on the nature of the system. But I think the reasons for the rewrite are also vital.
Ceterum censeo subscriptionem esse delendam.
One of keys to managing large projects is being able to break the project down into its component parts. VB.NET (or even VB6) allows you to do this easily by supporting multiple assemblies linked together. However to be fair this is a feature of the .NET environment so most .NET langauges (C# C++.NET) can make assemblies.
Other langauges can certainly create and use libraries but being able to do this is one of the explicit design goals of the .NET environment. In addition you will find the managed memory making you far more productive then environment like C++ where you have to manage memory yourself. Again to be fair Java certainly has memory management so this is not unique to the .NET environment.
Visual BASIC is verbose where C# is terse, I find this easier to read over the long term but to a experienced programmer it is a minor difference. There is virtually little difference between .NET assemblies and apps written in VB.NET and C#.
However if your app is meant to run in a constricted or resource limited environment like embedded applications then using VB.NET (or even VB6) will not be your best choise. You need to use C, C++, or even assembly. A langauge that will allow you control over every aspect over what resources your program uses.
Problems you will run into with .NET will be with the framework install and maintaining it in face of future Microsoft updates. I strongly recommend that you minimize reliance on 3rd party add-ons if this application is to be maintained over the long-haul. (Short-term or one-off projects are a different story).
Avoid storing assemblies in the global cache unless you have too as that force you into strict versioning rules. This was the bane of large projects in VB6 with the rules for COM DLL versioning. Plus using the global cache force you to register the assembly where otherwise it is a drag and drop situation with local assemblies.
Be aware of how much memory you are using. I have noticed with .NET application they tend to glup memory down like it is nothing. I learned this with VB6 (and later VB.NET) that despite the fact you have managed memory you don't create huge memory structures just because you can. Make sure you need that amount before designing it in.
As for my own personal experience I written a maintained a large CAD/CAM application that creates and runs parts for a metal cutting machine. I maintained this program through its original HP Workstation origin through DOS through VB6 and finally to VB.NET. It is has several hundred thousand lines of code organized using the model view presenter structure (http://www.martinfowler.com/eaaDev/ModelViewPrese nter.html) Also I maintain an open source simulation of the Program Mercury and Gemini capsule and rocket written in C++. So I had experience in both worlds. VB.NET (and VB6) was certainly up to the job of creating and maintain a large application.
Finally get Design Patterns and Refactoring Software these two books (and the othere they refer too) will help make the most out of .NET ability. (Plus the benifit of these applying to other langauge like Java)
http://www.amazon.com/gp/product/0201633612/sr=8-1 /qid=1149165698/ref=pd_bbs_1/002-2543787-3204834?_ encoding=UTF8
http://www.amazon.com/gp/product/0201485672/qid=11 49165751/sr=2-1/ref=pd_bbs_b_2_1/002-2543787-32048 34?s=books&v=glance&n=283155
I assume you're talking about the .NET VB, and hence comparing it to something like C#.NET. Personally, I think in the .NET world it really just comes down to preference. The syntax between VB.NET and C#.NET seem very similar. I started off on VB (in much the same fashion - my old work's custom app was written in VB6), and now at my new job develop in C#. I prefer C#, but mostly because I feel it makes me a better programmer. VB is very loose in it's structure; I feel like C# forces me to lose some of the bad habits I had from VB, and makes me have better looking and structured code. But from using both, they both can be easily used to accomplish the same things. I also think VB has some better handling of "business logic" type things like date manipulation and the like.
Good luck!
Well, I'm not going to argue against VB and I wouldn't have you do that either, but depending on what type of program it is, you might point out VB's weakness on lack of portability. You might think I'm about to jump on the Java bandwagon here, but I'm not. Assuming your superior knows C/C++ you might encourage him to check out wx-Devcpp. It as an interface simular to VisualBasic (and C# for that matter)but gives you the ability to take the code and move it to Linux and other OSes that use the GCC compiler.
Well, I've worked with VB and VB.net for over five years commercially now. I learned VBA and then moved to VB6 as my first programming language. Since then I have learnt and worked with Java C/C++ Python and Ruby. I personally prefer C++ and Ruby but then I like working with KDE. I still work with VB.net as that's what I'm employed to do. I believe the products I work with would suit C# better to make full use of the .Net framework and the OO abilities that it provides. But hey we've all got to earn a £/$.
The main issue I have with VB is that it's Microsoft (who I'm not bashing!!) and therefore, you are always tied to them. I like Mono (which no one else seems to have mentioned!) I realize that mono is mainly C# but they do have a VB compiler and vibe support is increasing. At least using mono would allow the product being developed to be run on multi OS's. Also Gambas is the open source version of VB6 designed to run on Linux.
VB6 is DEAD though and I think any application that is being re-written or started now needs to be based on .NET. A discussion should probably be held with the clients to see what plans they have for their own software. If they are going for vista or to Linux or OSX then that will impact the language of choice as well.
As much as we would all like to change the tools/software etc we commercially work with as we have our own opinions of what is best it's surely the employers decision at the end of the day.
Oh, uh, good question. Now technically speaking, uhh, let's say, put me down as a... 'Whatever'?
I suggest you quit and let him hire someone who can and will actually do his job. You know, someone who actually wants a job programming enough to program in the language the boss wants. Someone who has some experience in programming VB or wants to program in VB. Someone who knows their place as an employee and will not let their anti-MS/anti-VB bias effect their job performance.
If you don't know enough about the language to make an argument for or against it, you should quit and let him hire someone who actually does know the language.
Of course the fact that you don't know the language well begs the question, "Why do you think you are qualified to make the decision of which language to use when you can't even make an argument against the language your BOSS has decided to use?"
Of course, you could actually LEARN about the language and what it can do. Then, you will either be able to make a reasonable argument or be able to do the JOB YOU WERE HIRED TO DO.
There is no "-1 offended" or "-1 you don't agree with me" mod options for a reason.
VB (and .NET) is not cross-platform.
Even if there is a compiler available for other platforms, it is not the same thing.
Microsoft will always include some hooks to make you use Windows, Office, etc. Your product will have this "Microsoft tax", which you cannot negotiate, eating your margins.
Then, you have all the problems with vendor-lock in:
In economics, vendor lock-in is a situation in which a customer is so dependent on a vendor for products and services that he or she cannot move to another vendor without substantial switching costs, real and/or perceived.
These costs to the customer create a situation which favors the vendor at the expense of the consumer. Monopolies tend to result when lock-in costs create a market barrier to entry, which may result in antitrust actions from the relevant authorities (the FTC in the US).
Vendor lock-in is often used in the computer industry to describe the effects of a lack of compatibility between different systems.
Different companies, or a single company, may create different versions of the same system architecture that cannot interoperate. Manufacturers may design their products so that replacement parts or add-on enhancements must be purchased from the same manufacturer, rather than from a third party (connector conspiracy). The purpose is to make it difficult for users to switch to competing systems.
How to avoid vendor lock-in? Embrace open standards.
Having worked in both, I prefer C# due to its cleaner syntax and ability to use XML comments in the code. VB does have a few minor advantages, like the ability to use default parameters. Either one can get the job done, and a decision on which one to use is genrally made based on what the developers have the most experience with/are the most comfortable with.
If you are not familiar enough with the product to argue against it, as it states in the summary, should the owner really have hired you to help with the re-write ?
Interesting how it sounds if substitute PHP/Perl/Java/etc. for VB?
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 PHP/Java/Perl. He hired me to assist in rewriting the software - only catch is, he's stuck on having it re-written in PHP/Java/Perl. This scares me, but I honestly can't make a good argument against PHP/Java/Perl because I'm not familiar enough with it. So my question is twofold: I am looking for some confirmation to my suspicion that PHP/Java/Perl isn't the greatest language for large projects; and If PHP/Java/Perl 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. PHP/Java/Perl, like just about every other language, has its place. For the sake of discussion however, what tasks would PHP/Java/Perl not be suited for.
Here's a reason: MS Dev Studio 6.0 doesn't even install cleanly on Windows XP with SP2, but I've heard there're workarounds. The .NET editions are surely much better, but...
I'll consider VB when someone shows me its context-free grammar.
I can attest that VB can be used in situations that may not be the best fit for it (trading systems, large spreadsheet-based forecasting applications), but as others have said, it's a great tool for "one off" or prototype apps where it's important to get the gist of it going.
.net.
That said, what a lot of people don't realize is that Apple has their own VB-like environment with XCode, Cocoa and Objective C. I have been able to prototype and write apps in XCode pretty much the way I did in VB, but I have C as the language, C++ if I want it, and the full API of the system, instead of being limited to what's available in a VBX/OCX or using unnatural syntax to make Win32 calls. Yes, it's Mac only, but that's not a hinderance...the bulk of the application (model and controller) are more easily ported (if necessary) than anything
Also, you typically come to depend upon a whole ecosystem of third-party vendors whose OCX'es may not keep pace with changing versions of Windows.
Slashdot entertains. Windows pays the mortgage.
Yes, that 1995 interface is what I'm talking about. Vista will almost bring it up to KDE 2.x standards, but VB has been "depreciated" and probably won't come along for the ride as usual.
Friends don't help friends install M$ junk.
I mean, really.
Asking slashdot for an analysis of why VB might not be ideal is like asking Innocent III for an analysis of Cathar beliefs.
(Or, if you're a Godwin fan, asking Hitler for an analysis of Jewish culture)
Reality has a conservative bias: it conserves mass, energy, momentum...
The single biggest reason you should move from VB to another language is that Visual Basic is no longer supported, or won't be soon. I'm not sure about the exact date. VB.Net is a pleasure the develop with. If cross platform issues are a concern, then I would go with C/C++ or C#.
Other reasons might be:
1. VB error handling is not very robust.
2. OOP is a bit lack luster, and some OOP methodologies can't be applied to Visual Basic applications in a coherent way.
3. You cannot control the IDL and Type Libraries generated by VB, some features of COM interfaces can only be accomplished by cobbling together some IDL and compiling it with the midl tool outside of VB.
There are lot of arguments against any language. It all depends on the environment you are putting it in and what you are trying to accomplish.
As for all of the FUD about Visual Basic being a bloated, slow, toy language, only suited for utilities (toys), and prototyping:
VB applications can be completely free from VB Forms other less flexible aspects, and developed purely with Win32 API. There is virtually nothing you can do with C++ on the Win32 platform that you can't do with VB.
I work for a company that designs a complete suite of software applications that controls and tracks automobile manufactuing assembly lines. If this software were to stop the manufacturer, they would fine the party at fault as much as $15,000 per minute of down time. A supplier can easily go out of business with as little as an hour or two of downtime.
We communicate with every type of device/system you can imagine, control assembly line PLCs, track huge volumes of data about the manufacturing process. Our clients trust us to control and track the process of assembling air bags, anti lock brakes, and other critical systems. We in turn trust Visual Basic to get the job done.
Is Visual Basic perfect? Nope. Is it my language of choice? Nope. Does it get the job done, and do what we tell it to? Yup. Does it ensure that the bolts on the air bags, or ABS are torqued properly? If your car was produced in the US chances are good.
Visual Basic is a scripting language. It has some of the advantages of a modern scripting language, and all of the drawbacks. It's easy to pull in a precompiled piece and use it as a part of your program. That's an advantage. It's got a nice IDE if you're using the right version. (May be an advantage.) It's also going to run much slower than a properly written C program would. That's a disadvantage much of the time.
.Net environment. That's where Microsoft is currently pushing. VB is just a tool there. You can also use C#, Python, or real C routines (compiled) and let the parts use each other. There may be other language options in this mix as well. The Basic, C# and Python parts will all be compiled to byte code anyway for run time. You get to use what you're comfortable with, and the end result is that the thing will (or might) work. You'll end up with a Windows only product (Probably with an XP or Vista only product), but that may not be an issue. if you talk to your boss, you may find that this is what he has in mind anyway.
Treat is like a clumsy Python, and you'll be close to reality.
Try to push for the
VB is a tool, sometimes a nice tool. Remember that doesn't mean it's your only tool. Good luck iimplementing the program.
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.
What are you smoking? It is most certainly not turned into native machine code, at least not in any environment I've ever seen. It is turned into Java's own byte code, which is then-- you guessed it-- interpreted. That is one of the reasons java is so damned slow.
The interpreter is a big "feature" of Java... you can't have garbage collection without something to collect it for you. I can't believe that a post that is flaming incorrect was moderated *up* as "informative". C'mon, slashdot mods... just because you don't understand something doesn't mean it's informative.
I'd suggest that most anybody proffering a dead-on answer to your ill-conceived question is unprofessional, uneducated, inexperienced, and/or limited in their skill set. This is not a question that can be answered without knowing many specifics which you are probably unwilling to supply. To wit:
-You *claim* this is a 'large' project, but would you really know a large project if you saw it? Can a 10-man (person) shop (presumably not all coders) really handle a *large* project? What criteria are you using to define large?
-Do you already HAVE a set of tools/libraries/etc that would be helpful in one platform or another? Is the platform you are contemplating moving TO a non-free one? Because that's more overhead if not.
-Other specifics are needed. Client-side only? Client/server? Web-based? Any specific hardware that needs supported? Who's the end user? Are real-time capabilities needed? Is this a mission-critical system? What's the logical/physical (if applicable) architecture look like?
This is the short list.
Look , I'll be blunt: you obviously don't know enough about what you're doing to actually put forth the info required to deliver you the answers you seek (but, to be fair, you could not possibly do so in a forum such as this (so why try?), even if your employer did approve of postring so much info about your product), so perhaps you should either let someone more capable than you speak up, or put forth some compelling reasons FOR a different platform instead of reasons AGAINST something. That, or listen to the boss who has managed to build a successful business - no easy task.
It really depends on what are you planning to do with VB.
..
I'm hired to do custom,small projects for various companies and simply put I don't need to complex C++ to create a small application.
For example, I create CD presentations, CD autoruns, batch convertors for various documents (from one format/version to another) and many many other similar apps.
Another good example that I could mention is a small application that takes video frames from a video file, checks each frame and tries to block the eyes of the people in the image (sensed motion and ads a black/blurring rectangle over the eyes). It took me about 3 hours to program the whole thing,I'm sure it would have taken at least twice as much to write it in C++.
Conclusion, VB is great for RAD (rapid application development), for custom,small applications, helper applications and so on. It's great to use it for interaction with databases, Active-X controls are painfully easy to create in it
Of course, it has limitations, naturally I wouldn't start writing a system driver in it.
My advice to the person asking, start learning VB, you'll understand it completely in a few days.
".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?
Using natively compiled languages too the programmer can choose the language they know better and interoperate with a bigshit framework either via language bindings or IPC, and they'll get compiled to the very same "intermediate language": assembly!
So, how is this different from going
oh, yes, i know! natively compiled languages perform far better...
I don't feel like it...
Here's the funniest thing I've seen written about VB: Verity Stob's "Thirteen ways to loathe VB".
Slashdot entertains. Windows pays the mortgage.
I've known for years how sensitive can this topic be to many developers. its like discussing religions + politics and who's girlfriend is prettier.
...
Anyway, I still believe that today's programming scenario is much more levelled than 5-10 years ago; everyone is generally dancing the OOP waltz and most available tools offer the same overall features and power. *However* as much as this is true to me, each language has better focus on a particular business segment. If you're attempting to sell a regular store cash management app to earn your daily bread, C++ or Java will be probably be clumsy choices. Perhaps you'll be starved by the time you whip up a decent GUI or fully understand the requirments. That's where VB or Delphi (sniff...already missing her) come into action, offering OOP leverage as well.
In my humble opinion, my brain treats software development as teamwork, so if I was to make a choice between tools I'd prefer one that offers me a friendly, productive IDE and clear, easy to maintain syntax that most people can understand in a glimpse and not a string of Mayan cryptographic symbols:
if ( Box = open ) and ( not IsEmpty ) then..
rather than
if (Box == open && IsEmpty != false;
With all respect to all the skilled Java, C++, C# programmers out there, I can't understand the practical use of weird characters as standard logical operators, case sensitiveness or excessive sintactical complexity tradition in these tools other than being a geeky "macho" thing for self assurance by their creators.
Most problems with software (as with the world itself) come from inside the head of guy that writes the code and not from the language used.
---
If heaven gives you lemons, learn to make lemonade.
The Microsoft .NET platform is rapidly migrating to C# instead of Visual Basic.
And one day, MS will drop VB from their SDKs.
Sample ? The DirecX SDK can't use VB now, it's C# instead.
I have runned projects from web apps, c, c++, python, .net, java, jython, gambas, php, and of course, vb and Delphi. Visual Basic has 2 problems. I mean, it's really good for getting the work done fast, but it's really hard to escape from begin just a proof of concept. is hard to harden. and also, deployment. a lot of vb. apps fail to deploy due to dependencies. Delphi is a very similar approach to programming, it generates really fast code, it's compact and is less prone to having mistery bugs. .net is... to big. i can't imagine a .net app on a P166 32mb ram with win95b . delphi apps we do work fine on a wide range of wardware, including Wine (*nix).
Also if you program vb, catching delphi is a no problem.
Try that.
And... if your boss wanna vb, maybe it's not so bad. you can do marvelous things with vb. just write good code, and you gonna have good apps.
COM is COM... and you could write dll's in VB and call them from C++ - even thru the debugger which is really coo - and vis- versa.
It's easy, if you cannot make a good argument against VB, or preferably, a good argument for your preferate language, then just stick to VB.
After all, he's your boss and he's got the right to decide which language he prefers.
Look at it this way, of course, vb 6.0 (i assume thats the vb you speak of) is not so great, mainly because its not scalable, its single-threaded with a truckload of overheads that kills the performance.
*but* IT IS possible to write something efficient in VB6, its just harder. So you can think of it as a way to test your skills.
Plus, learning a new language, especially for a small company, has a lot of risks involved because the company may not have the backbone to support the financial delays associated to the learning curve of a new language. Moving from VB6 to VB.net isnt that bad (and vb.net is FAR more efficient than vb6) but there's still a learning curve to it, mainly because the programmer really has to start thinking in terms of OOP, which VB6 doesnt support at all (it merely lets you implement interfaces).
lets say there are 5 programmers on the team, all earning 40k per year. and lets say the average programmer will take about 2 months before being comfortable and productive in the new language (vb.net, c#, ruby....whatever you choose) then the financial burden on the company, the risk is :
(40k/12 months) * 2 * (5 programmers) = roughly $33,000
for a small company, $33,000 is a lot of money, so right there you can see why your boss is reticent.
not to mention it may cost more if for some reason the team is forced to go back to VB6 because say.... there's component only compatible with VB6 that needs to be used and you only find out after a month or so.
If you look like your passport photo, you're too ill to travel. - Will Kommen
I think the main arguments against against VB are two things. One is the lack of cross-platform development (as others have mentioned). The other has to do with dependence. Using VB or VB.net locks you into Microsoft's upgrade cycle (or gets you stuck behind it) and makes it difficult to deploy your software widely without insisting that the user has just the right version of Windows, MS Office, etc. Your application my conflict with others that have different requirements.
My experience from the sysadmin point of view is that you don't have too much problem supporting one or two applications written in VB but, once you have more than that, you get into trouble trying to satisfy everyone's requirements. Maybe the particular applications I have delt with were just not well written and such programmers would have come out with crap in any language but this is the impression I have of VB.
OK - you don't tell us what the project is, why VB was chosen in the first place, and why you are re-writing it now so this has to be very generic (and therefore not very useful). And there are some good points here already.
.NET sadly) but in general structuring VB code well is hard and this makes it very, very hard to maintain VB apps (think of it as a write only language).
.NET was quite upsetting as a VB programmer. In one move they made our investment in VB redundant. It is, undeniably, a vastly more sophisticated offering and fixes some big issues (the multi-threading for one).. Essentially you have an early version of Java/JEE with some of the quirky bits of Java ironed out and one or two nice features added in but without the platform independence (a big minus) and with some significant bits missing (for instance Applets, Servlets etc. - basically the older bits of the toolkit). The major issues I had with .NET were: .DLL hell.
But
Until Relatively recently I did pretty much all my development with VB6. Briefly this is a summary of what I liked about it:
1. Its very quick to write: OK so the IDE looks a little dated now but it is really a very, very good environment for working in. The only IDE I prefer is IDEA.
2. It's a lot more powerful than people who don't spend time with it realise. Since it is basically just a wrapper on to COM anything you can do in COM can also be done in VB. What's more it is actually pretty easy to call C++ libraries from VB (so long as you know how to) so if you need to, say, do a memory copy to avoid the deep String copy that VB will do by default this isn't hard to do either.
3. Its pretty stable and pretty bug free (though no longer supported so if you have a problem you are stuck with it).
4. You can get a fairly good looking GUI built in know time at all.
Why VB6 is a pain:
1. COM is deeply integrated into Windows. When something goes wrong (like the wrong version of a COM component is registered with Windows) it is hard to track down to put it mildly.
2. DLL hell. Someone changes a library you didn't even know you were using and suddenly you don't have it any more and your code breaks for no readily apparent reason.
3. VB6 is quite a quirky language - not quite object oriented, not quite procedural, it can take some getting used to, and I'm not sure it really works as a hybrid.
4. Although it isn't impossible to write VB well it is hard - much harder than it should be. The error handling is one major part of this (not much better in
5. Although you can (sort of) multi-thread a VB app is it unfeasibly difficult and generally not worth the bother.
I built some pretty big systems with VB6. The largest was an internet banking system for a major retail bank - and the problems above turned out to be killer. Getting a cluster of half a dozen WIN2K machines built the same, reliably, every time was almost impossible. I don't think we ever got the solution to run at full strength.
1) There isn't explicit versioning of libraries or API's - welcome to son of
2) There is no way to change an API without breaking it (no equivalent of Java's deprecation mechanism that I can see).
3) No checked exceptions.
4) It still ties you to Microsoft. And after what they did to me with VB I don't particularly want to be tied to them again.
I spent about 6 months learning it then decided to have a look at Java. That was in 2003 and I've stuck with Java since. The main problem with Java remains Swing (the GUI foundation classes). They've got a lot better but it still quite difficult to build a nice looking GUI in Java (way harder than it should be). Still it is a pretty sound choice for most Enterprise apps.
VB used to be kind of bad, and it's still sort of verbose. But VB.Net is kind of good, and the next VB (VB9, codnamed Orcas), for which there is a technology preview out now, positively frickin' awesome!
I know, it seems strange that a VB iteration is actually great, and nobody was more surprised than me, but try it out, leave your preconceived notions at the door, and I promise you'll see how cool it really is!
One of my absolute favourite languages so far. Type inference, XML as first class values (including XML syntax!), static typing everywhere it's possible, dynamic typing where it isn't, "strong duck-typing" etc. etc.
As I said, the syntax is still kind of verbose, but I can live with that. VB9 owns C# 3.0.
Download the tech previews here: http://msdn.microsoft.com/netframework/future/
You got things wrong.
.NET; if you use the framework to interact with them you have to use interop, which means that you basically cast everything and make no use of .NET features.
-Visual Basic is not a scripting language; the programs are compiled ("true" EXE since version 5). Two stripped-down version of Visual Basic are available though; VBA (Visual Basic Application), a scripting language designed mostly for Microsoft Office, and VBScript, which is an actual scripting language (for ASP or Windows Scripting Host mostly).
-Most of the Office (and some of the Windows) libraries are still unavailable in
lucm, indeed.
The .Net version of VB is nothing like VB6 it is essentially just Java/C# with a different syntax. The .Net framework is very powerful and VB.Net is a full partner.
Our policy is to write new code in C# but to leave existing code unchanged. This appears to be a valid approach.
We considered using a .Net decompiler to convert the original
code to C#. Unfortunately, this produced too many issues to resolve in the time available. My understanding is that specialized converters can convert about 90% of the code automatically.
Our big issue is not with the language - any programmer worth his/her salt can soon adapt - it is with the Visual Studio 2005 environment. We find VS buggy and unusably slow. We typically exit to Textpad to perform any extensive editing. The VS editor allows you to type half a line before the background parser kicks in and locks the keyboard for 20 seconds or more. Simple operations like Find/Replace are faulty for some replacements. I suspect that VS internally holds the source in some syntax tree and that some replacements are incorrectly structured. Access to Intellisense and the the Help system are unbearably slow. On a 1.8GHz computer with 1GB of ram it takes over a minute for a help page to appear.
If the owner wants to write in VB6, or you're not prepared to drink the Microsoft Kool-Aid and require .NET and a 15MB download, you might want to consider RealBASIC.
It's almost totally compatible with VB6, and compiles to native code on Windows, Macintosh and Linux, so you'd actually have the option of supporting multiple platforms.
http://www.realsoftware.com/
GCHQ Quantum Insert installed. If only our tongues were made of glass, how much more careful we would be when we speak
I've refused to install programs that required me to install or upgrade the .NET framework. Why? Because I don't want another x00 MB of hd/memory taken up by something that Microsoft says is good for me. The machine that the software was going to be installed on had limited RAM and hd space and a relatively slow processor and I wasn't in a position to upgrade it. Throwing the .NET framework at an already overloaded system was out of the question. In fact, I decided to code my own version for this very reason.
.NET framework is the best thing ever, but there are people out here in the real world that actually have reasons for not wanting to install it.
You may think that the
I always wonder what magical "hardware is no object" world a lot of slashdot posts come from. If there's a space-time portal over to your universe, let me know. For now, I have to live with the constraints that my current universe imposes.
Interested in a Flash-based MAME front end? Visit mame.danzbb.com
VB6 and VB.Net are completely different things.
I currently do Visual Basic 6 programming on large machinary. With it we drive customized hardware and require millisecond timing. A basic idea, we have 5 seperate areas of the system that all have to interact with each other. 3 of the sections have 8 stations that are independant of each other and fire every 2 seconds.
.NET. Of course this was all done by my boss who only knows Visual Basic. We are even directly controlling printers outside of the windows printer queue via a class I personally wrote in Visual Basic.
.NET has made such API access more difficult but at the same time .NET has introduced all of the nice things from C++ like overloading functions, virtual classes, class inheritance and instancing, and polymorphism.
We are migrating to Visual Basic
With my 10 years of programming knowledge ranging from low level assembly to C++ game development, I have learned that Visual Basic allows for quick application development for business applications.
However, Visual Basic has progressed over the years from what it use to be. It use to be slow, cumbersome, and a pain. Now between CPU speed increases and Visual Basic actually being mostly compiled, you do not see a difference. The only time I find that VB is unsuitable and unable to perform a task is when you need the last little drop out of the CPU. Most applications do not require this. I can slap a screen together and have new data showing on the screen faster in VB than going thru the complexity of C++.
Combine VB with Windows API's, which you use anyways in C and C++, and you have just as much control. I know
...and THEN jumping to a conclusion?
I am very small, utmostly microscopic.
The level of ignorance exhibited in relation to Java compilation and execution is just bewildering - even for a slashdot crowd. Please educate yourself on how the JVM Hotspot compiler works before making such silly comments in the future. And just to clarify, the JVM HotSpot compiler does compile the byte code into extremely efficient platform targeted machine code.
The Java HotSpot Compiler
Background
The Java programming language is a new one, with its own unique performance characteristics. Most attempts to date to accelerate Java programming language performance have focused on applying compilation techniques developed for traditional languages.
Just-In-Time (JIT) compilers are essentially fast traditional compilers that translate the Java-technology bytecodes into native machine code on-the-fly. A JIT runs on the end-user's machine which actually executes the bytecodes, and compiles each method the first time it is executed.
There are several problems with JIT compilation. First, because the compiler runs on the execution machine in "user time," it is severely constrained in terms of compile speed: if it is not very fast, then the user will perceive a significant delay in the startup of a program or part of a program. This entails a trade-off that makes it far more difficult to perform advanced optimizations, which usually slow down compilation performance significantly.
Secondly, even if a JIT had time to perform full optimization, such optimizations are less effective for the Java programming language than for traditional languages like C and C++. There are a number of reasons for this effect:
The Java programming language is dynamically "safe", meaning that it is ensured that programs do not violate the language semantics, or directly access unstructured memory. This means dynamic type-tests must frequently be performed (when casting, and when storing into object arrays).
The Java programming language allocates all objects on the "heap", whereas in C++ many objects are stack allocated. This means that object allocation rates are much higher for the Java programming language than for C++. In addition, because the Java programming language is garbage-collected, it has very different types of memory allocation overhead (including potentially scavenging and write-barrier overhead) than C++.
In the Java programming language, most method invocations are "virtual" (potentially polymorphic), which are much less frequent in C++. This means not only that method invocation performance is more dominant, but that static compiler optimizations (especially global optimizations like inlining) are much harder to perform for method invocations. Most traditional optimizations are most effective between calls, and the decreased distance between calls in the Java programming language can significantly reduce the effectiveness of such optimizations, since they have smaller sections of code to work with.
Java technology-based programs can change on-the-fly due to the powerful ability to perform dynamic loading of classes. This makes it far more difficult to perform many types of global optimization, since the compiler must not only be able to detect when these optimizations become invalid due to dynamic loading, but also must be able to undo and/or redo those optimizations during program execution, even if they involve active methods on the stack, without compromising or impacting Java technology-based program execution semantics in any way.
As a result, any attempt to achieve fundamental advances in Java programming language performance must provide non-traditional answers to these performance issues, rather than blindly applying traditional compiler techniques.
The Java HotSpot performance engine architecture addresses the Java programming language performance issues described above by using adaptive optimization technology. Adaptive optimization is the fruit of many years of research into object-oriented language implementation performed by the Sel
Forget VB6 or prior. Just run if that's the job.
VB.NET and C# can accomplish almost all of the same things and have access to the exact same framework. Just do not use any of the old VB6 keywords like MsgBox but rather use MessageBox.Show().
C# has some extra freatures that make it better than VB.NET for writing frameworks, although you can still write frameworks in VB.NET just fine. If you're into Visual Studio 2005 (the only way to go) then C# has the following advantages:
- Implicit Conversion Operator Over-riding
- out Parameters (not the same as ref/ByRef as they don't have to be initialized)
- Custom Iterators
- Pointers
C# is also a pain in the butt by forcing you to explicitly cast just about everything - but that is a very good thing as it reduces runtime exceptions. If using VB.NET use "Option Strict On" to accomplish the same.
The other thing is that a lot of C# programmers came out of the C++ and Java community and those communities, because of their nature, have a stronger emphasis on OOP, best practices, design patterns, etc. You'll probably find better advice and tutorials on theoretical things in the C# camp. VB is catching up and there are some really great programmers in that camp but there are still a lot of VB programmers that probably shouldn't be writing code.
But both VB.NET and C# are good options. I was a VB programmer for years and switched to C# because of authoring frameworks, better theoretical help, and I prefer the smaller syntax, but VB.NET is just fine.
I'm a Unix/C/Perl/Python/Smalltalk type of guy. However, a few months back, we needed a small, interactive Windows-based program and the only thing available to me was VB 5 so that's what I used.
My thoughts:
From the documentation and the nature of the IDE, I get the impression that VB is aimed at non-technical users. It's designed to let (mostly-) non-programmers write useful programs. So, for example, although I found a good overview of looping in the manual, I had a hard time finding out the order in which window-close events were processed.
VB is designed for small programs. You design a GUI, then hook activity to it. The GUI design part is dead easy, as is hooking code to the GUI parts. If your program doesn't have any complicated business logic, you're done then.
In my case, it was like that. I just needed to write a GUI that talked to a DLL. It took me maybe half a day to get that up and running. Of course, it turned out that the DLL needed much more glue code than I'd initially thought and it took me something like a week to get that written and debugged.
I found that the IDE was great for quick GUI development and began to fight me when I tried to do anything bigger.
VB is very good at interfacing with Windows components. It has the most seamless method of linking to DLLs that I've seen in a non-C language. It also lets you embed COM objects (which I've never tried or needed, but it's there) in a really simple way.
If your program mostly consists of external DLLs and COM objects, VB is probably for you.
You're stuck with the IDE, which makes GUI development easy but just gets in the way when you do plain coding. (You can edit your sources with your favourite external editor, but you can't rebuild your program from it so I don't think that's a viable option.)
You can't automate your build process, regression tests, etc. You can do conditional compilation but you need to set the conditions in the build dialog, so, say, automatically building both a debug and a production version at the same time is out of the question.
VB isn't standardised and is controlled by a single vendor. Said vendor has already end-of-lifed VB once and left thousands of customers stranded. Who's to say they won't do it again?
VB is Windows-only. You will never be able to move to another platform if you use VB.
In conclusion, I think VB is the Windows equivalent to shell scripting. It's really nice if you're writing small, simple programs that connect more complicated components together but it will fight you the moment you try to do anything more complicated than that.
I'm currently working on the followup to this project and I'm doing it in wxPython with wxGlade and cx_Freeze. That combination has its own problems but it's much better got developing larger, more complicated programs.
Actually, it is compiled. The compiled code is actually highly optimized machine code that is more efficient than what a statically compiled language could ever hope to produce. The technology is called HotSpot compilation. Do your career a favor and educate yourself on it.
OK, this questions definitely has flamebait written all over it. Here are the quick answers.
On a related note, VB is a not really a language, it's a RAD tool. The goal of VB code is to quickly produce a working product. I've worked with a few n-tier VB apps, but the language really peters out at this point (you end up "faking" inheritance just to get things working)
Friendly tips when you move to .NET
And you were hired as a software engineer? One would think a software engineer would know the answers to those questions. Me thinks you might have padded your resume.
"Care about people's opinions and you will be their prisoner." ~~Tao Te Ching~~
I write VB code (and C#, when I can get away with it) for a living. My boss is also adamant about using VB on all large projects, largely because it's the only language he's comfortable (familiar?) with. As someone who started out with BASIC, and moved to better and brighter pastures (like C++), Visual Basic syntax sickens me. It's comparable to pretty much all other haphazard Microsoft project (DOS and Windows, anyone)? As a result, the language is bloated with bad syntax, poor design, and speed that probably only surpasses slow, esoteric languages like Squeak. The average programmer probably will not notice such problems, but I dare anyone to move to a higher-level language and not be sickened by VB's inefficiency and poor syntax. I could write an entire article about how badly the language is designed, but let it just suffice to make a couple of points: a) Unlike any other well-designed language, VB versions .net allowed dilapidated DOS BASIC-type syntax such as
canvas.Line(x1,y1)-(x2,y2),b
Mind you, no one who developed libraries could ever write functions that accepted such input, but some built-in language constructs did.
b) Language is bloated with keywords such as Overridable, Overloadable, Shared, Static, etc... I know programmers who've been working on VB most of their lives and they still don't remember when to 'override' and when to 'overload'
c) Still no operator overloads
And that's just the top of the iceberg.
VB .net is a lot better than its predecessors, but it suffers from most of the same problems - language is bloated, and its syntax is so arbitrary, as to make it near-useless. If your boss is willing, at least try to get them to switch to C#. While it's still a "bytecode" language (pox on Sun from turning that idiotic idea into a trend), it's far more superior to Visual Basic, and its syntax will not make you bang your head against the wall.
It seems that the less-than symbol did not show up in my post. Anyway, the following sentence: "Unlike any other well-designed language, VB versions .net allowed"
should read
"Unlike any other well-designed language, VB versions PRIOR TO .net allowed"
Preface: I work for a company whose primary product is a programming language, so I spend my days thinking about things like language design and what makes one language better than another.
In evaluating a language the first thing I'd look at these days is, how rapidly is it evolving, and what impact does that evolution have on its user base? For example, Java evolves relatively slowly, and tends to remain backwards compatible, so when a new version comes out you just install the new compiler and keep working, mostly. My company's product is evolving very rapidly, there are constant changes, but we include a feature that scans your code and brings 99.9% or so of old code up to date, so there's relatively little pain for the programmer in updates, they just have to learn what's different. VB has relatively infrequent updates, but they tend to be huge and, according to the massive wailing and moaning in the trade press, break compatibility substantially. So, unlike other choices, if your employer proceeds with development in VB, they can expect to have to do a substantial rewrite of the product every few years, with associated costs. I know quite a few people who got hired to translate large apps from VB into Java when Microsoft released their last major revision, because companies were fed up with rewriting their app over and over again just to keep up with Microsoft's changes. I would argue that it's better to develop in a language with a smoother growth path, so the code written today will maintain its value in the long term. That represents a businesss advantage of using a language with a smooth growth path.
The next thing I'd look at is what competitive advantage does using this language offer you? Is it unusually fast to develop in VB, bringing you to market early? No, it's not really faster than, say, Java, and I could argue that my employer's product is much faster to develop in than either, so that's not it. Does VB run unusually fast? Not that I've heard, and Java application servers have been highly optimized for speed. Is VB's cost unusually low? No, you can get plenty of Java development software for free. Is VB code particularly easy to maintain? No, Java offers features like Javadoc which can help you keep the code well organized and documented so it'll be easier to maintain. Do available VB libraries and packages substantially exceed those available for other languages? No, there are vast libraries of code you can use in Java to do practically anything you want. Does VB have an unusually superb IDE? No, while I'm told the MS IDE isn't bad, there are plenty of excellent IDEs for Java as well. So, I would argue that VB offers no competitive advantage, and that Java (for example) offers you at least two competitive advantages: its vast libraries of available code, and maintainability features such as Javadoc.
I'd look at whether the language has special purpose features which make it unusually suitable for your application. For example, Ruby on Rails is designed for rapid development and easy rich ui development. My employer's product is designed for rapid development, easy object/relational mapping, easy AJAX, easy rich UI, and easy web services development. VB and Java seem more general purpose, with no particular specialties, so I'd argue that VB offers no particular advantage in this regard.
Finally, I'd look (as a programmer) at the details of the languages themselves. How are everyday constructs expressed? Is it awkward to write the language, or easy? Is it awkward to read the language, like perl (notorious as a write-only language), or easy? I'll give you a tiny example of what I mean. In, say, Javas****t, if I want to loop through all the objects in array foo, I have to do something like this:
for (var x=0; x
That sort of thing saves me a few moments here and there, and makes the code neater. A particular example I like to look at is string functions: how easy or difficult is it to do complex things to strings, like if I wanted to replace a
Everyone else has given you all the sane, rational arguments for why you may or may not want to use VB. But at the end of the day, there's this:
Tell him that you refuse to work in VB, and that you'll walk out if he insists. And then, do it.
At the end of the day, that's the difference between treating a job like "work" or doing it because you like to do it. Pick the jobs that you want to do. There's always work -- hell, you could be packing boxes, parking cars, or flipping burgers for a living. My guess is, the primary reason you're not is that you like what you do. If you're not careful, you'll lose that, and you'll end up no happier at your job than the burger-flipper.
Of course, I could be entirely wrong. It could be that you just like the money, in which case you should try to get fixed salaries or hourly wages, then shut up and do your job to the best of your ability. If it's having problems because it's VB, politely remind your boss that you didn't think VB was the best choice, but that it really doesn't matter to you whether the project gets done, all you care about is working hard and getting paid.
Don't thank God, thank a doctor!
VisualBasic = the devil
:)
by Naikrovek (667)
Naikrovek is still pissed that the slashdot UID registration lagged for just one second.
With a 3 digit UID, that's quite a long time to hold a grudge!
If you pass a string into a & d, and a pointer to the string into c & d you get the following available inside your function:
a is a copy of the original value,
b is a new pointer to the original value,
c is the original value directly addressed,
d is a copy of the original pointer.
With a you can't modify the original string, only the new copy.
With d you can modify the original pointer.
So there.
And for what it's worth I don't think knowing any particular syntax is ever a good measure of programming aptitude, it can only be a measure of experience in a particular paradigm. Though I agree with the rest of the post, and very much like Joel's articles.
Respect copyright - the GPL relies on it.
I've been doing development for a couple years in VB.net and find it generally to be one of the most cumbersome development tools I've ever had to work in. Exasperation is a daily experience.
I have to develop apps which run on whatever variety of hardware and operating system people in my organisation use, the real pain is when you have Win 98 up to XP scattered in pockets everywhere and some don't have the current drivers, such as the MDAC, to perform simple Access database access.
Cleary this has presented the logistical problem of getting the Framework and all drivers up to snuff on each client. Then there's the matter of differing default behaviour of the machines, some see .MDB extension and others show only the small icon (which no everyone's eyes are up to devining and lots of confusion, hilarity and lost time.)
Probably worst of all is the large steps between releases of Visual Studio. Your VB6 isn't going to convert, period. Your VB7 (VS 2000) will convert to VB7 (VS 2003) but if you've got a lot of code you may be thinking twice about this. Now along comes VS 2005, which to be honest is where the damn product should have been when it first came out. Problem is for me, I have too much vested in VS 2003 and won't be "upgrading" for some time.
Reminds me of the suffering I encountered (never did 100% recover from) when Linux changed libraries. That was a painful episode and I'm in no hurry to revisit it.
A feeling of having made the same mistake before: Deja Foobar
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
Visual Basic was designed for developing desktop software. If that's what you are building, it's suitable. For the most part, the language you choose is a personal preference and it sounds like your boss wants to use VB because that's what he is familiar with. That said, IF your boss is suggesting VB6, you have to consider the fact that it is no longer supported by Microsoft. If he is comfortable with VB.NET, that's another option. However, any .NET application requires the .NET runtime to be installed on the user's machine. If the software product you are creating is something that will go outside your company (perhaps it's a product you sell for example), then you have to consider the extra overhead of having to deal with making sure the user has the proper .NET runtime installed.
Another alternative is REALbasic which is very similar to Visual Basic but is completely object-oriented and is cross-platform (Windows, Macintosh and Linux). It also builds self-contained exes so you don't have to worry about DDL hell or having to make sure a particular framework, runtime or virtual machine is installed.
You can find out more about REALbasic here: http://www.realbasic.com/
It is very simple. Follow what Microsoft is embracing, and all signs are they are going with C#. C# looks like the best bet down the road as MS might anytime pull the plug on VB. Also C# is kinda liked by non MS ppl too.
--gks
Sounds like somebody 'exagerated' there programming knowledge thinking 'anyone can do VB'. Onve they saw you actual had to know something they paniced.
The Kruger Dunning explains most post on
Bein an over critical sod i'd like to know what 'commodity' language is nod as 'failed' as VB.
... for something to write webserver applications and/or the occassional desktop application.
Since i do not use windows, prefer cross-platform to proprietary and don't mind good syntax, clear instructions, non-bloated library's etc. I'm curious, C/C++ are above me but i'm looking
Perl, PHP, Python, Boo ? What should i do ?
Regards,
J.
free dom(inion) - free energy - free your mind - whee!
I wanted to escape Visual Basic even before I decided that I needed to escape from MS.
VB is fine for developing a project quickly. Possibly even for a large one, though I only used it on projects that I built and maintained on my own. And here I should add the disclaimer that though I'm saying VB, I actually mean the VB dialect that was used with MSAccess97/2000. (That's two incompatible dialects. They will NOT work together in harmony despite the ads proclaiming that they would. They will, however, appear to work together for about a month...then I couldn't open the project in Access97. (Solution: duplicate databases synchronized via an ASCII deltas file.)
Despite much frustration, VB was actually very quick to develop in, largely because of the screen painters used for entry and report forms. However, occasionally a routine would break, and the only solution I ever developed was to dump the routine into an ascii file, delete the code, recreate the code by copying in from the dumped copy. (I finally decided that MS was storing the code and the "binary" in the same file, and that occasionally something would invisibly corrupt the binary. This may not be correct, but it was consistent with everything that happened.) The problem was that the corruption could occur in routines that hadn't been edited in months...or, if it happened on a client site, in years. (Those I fixed by sending them a new copy, so the error is speculative.)
The final straw was when I caught VB making arithmetic mistakes in an accounting module I was writing. Not rounding errors, but full fledged mistakes, on the order of 3 instead of 7. It also wasn't consistent with the mistake. After that I started making VERY strenuous attempts to avoid VB. Strenuous that I introduced Linux into the company back in the days of RedHat 5.0. (I actually started at 4.2, but it took me awhile to get good enough to let anyone else know.) Now I don't use MS products at all for any purpose.
Still....if he insists on Basic, have you checked into Gambas? I don't know it's quality, but it is trying to be Visual Basic for Linux. (Yeah, you just want to avoid VB, and I congratulate your instincts. But I've read the MSWind2000 EULA, so I never want to deal with MS ever again.)
I think we've pushed this "anyone can grow up to be president" thing too far.
I have never been so glad that my car was made in Germany.
There is a lot of vb out there drawing on earlier BASIC code which resembles FORTRAN. It must be good for something if people are using it to solve business problems cost effectively. You might want to consider your boss' point of view and rationale. It would be a good opportunity to learn a new language on the job, and display your generic skills in making it absolutely fool-proof.
Chances are that if nobody understands the problems of VB, then they won't find advantages in other languages.
a va-web-apps-in-visual-basic-or-javascript/
If your product is all front-end and database, chances are VB is actually a fine choice--that's what it was designed for.
If your product involves significant design, routines that manipulate the data rather than just display it and/or many interacting pieces implemented by multiple programmers but designed by a smaller team of architects (as you will get in a larger project), VB narrows towards completely unusable.
For one thing, when you are architecting a project, it is much easier to "Think" OO in a more pure OO language (C# / Java). It is also more simple to transfer these designs to paper and to other engineers.
Refactoring, which should be constant and ruthless, is much more difficult in VB--last time I checked, in fact, VB basically encouraged C&P through their lack of dynamic form creation and some of their constructs.
There are also programmer/programmer issues in VB, defining an abstract interface between two areas, intelligently isolating code, etc. There are actually many reasons.
The problem is that if you have a team of VB developers, they are going to be completely capable of designing a VB app in any language. Also, if you have really good, experienced OO programmers and a talented architect, you will be able to create a fine app in VB.
My real recommendation would be to get an architect--someone who can design your product out to be maintainable and expandable in any language, and let them pick the most appropriate language for you.
As an alternative, I guess I'd say don't worry about it. Although I'd never recommend VB, if management is stuck on it and all the programmers know it, it's probably your best choice. As I said, you can write crappy VB code in any language, so you might as well do it in VB.
Besides, VB isn't as dead-end as it used to be:
http://www.sitepoint.com/blogs/2006/05/19/write-j
I disagree; I've done production code a number of times in langauges I haven't even heard of prior to the project, and often recieved complements in return. Once you learn your first 10 or so languages, additional languages tend to be very easy to pick up; last time I listed the languages I'd programmed in at one time or another, there were over 30.
In any case, if you're creating the language for the project, having prior experience would be impossible.
I will note, however, that doing so will add a few days to the project as you learn the language.
Zimbel
My experience has been that bosses could care less as long as the existing system works.
I scream. You scream. I assume that means we're both acquainted with the problem. We proceed.
Not only you answer to the question about platform choice, but also accurately describe a company lifecycle issue and solve it. Very good!
In fact, going from VB6 to VB.NET is like going from MFC with C++ to
"[Regarding the 'cloud,'] ownership was what made America different than Russia." -- Woz
PHP is a great, scalable language for writing cross-platform web applications. As far as cross-platform desktop apps - you got me. With cross-platform desktops you're either looking at a) writing c/c++ apps with gtk, or b) using a 'managed' platform like .net/mono or java.
Can anyone improve on that one?
John 17:20
I would say that VB is to windows what bash/perl/Tk is to UNIX. The things that the two OSes wind up doing the most can be handled by VB or perl respectively.. VB has an excellent form-management editor so it blows away perl/Tk. I didn't realize that VB compiled down to assembly, but I highly doubt that that matters any, as most assembly probably only delegates to VB core libraries. The fact that you can probably optimize a (pseudo code)
.NET might be undesireable because it's interpreted. For the above arguments (that much of VB/perl type languages are nothing more than delegators), that's largerly a moot point. Especially since the interpretedness of java/.NET faclitates a JIT.. You can consolidate all the byte-code of an entire custom-extended core-library (such as Map), and have it become more highly performant than say writing a 'magic' enhancement to the core reg-ex engine of VB or perl, which will never get faster than the sum of it's parts. E.g. extensibilty in VB/perl is a performance penalty, whereas extensibility in java/.NET has as much performance potential as anything else.
for x in 1 to 100
tot *= x
end for
to raw assembly probably does not affect 99% of the code that is generated for a VB app. Perl, on the other hand doesn't have the assembly option.. The closest I ever saw was something that wrote out c-code to render the AST - thereby skipping the parser stage. I was under the impression that VB compilation was merely a tokenizer (similar to python). In perl all variables are advanced objects which can type-cast on the fly (and keep caches of previous type castings in case they flip flop back and forth, say between a string, an int and a double). I recall VB having similar opaqueness (though I also recal that you can designate more stringent data-types). The effect is that the simple 'total = total operator varable' is not going to translate directly into assembly code very nicely.. Especially if the language can support side-effects in variable assignment (perl is notoriuos for this.. They even call it a reference's 'magic' setting).
I've seen people comment that
-Michael
None of those things are applicable to writing business applications.
.Net for the language we also decided to get a machine that supported a highly threadable system. We had to determine where each of the servers for the DB, Cube, Reports, and website went. On the same box or all on separate boxes? In the end we decided to put them on the same 8 core 64bit box but have 3 identical boxes behind a load balancer.
It defines what you refer to as a business app. Nobody in their right mind writes custom accounting apps anymore. But it definately does benefits any development effort to understand operating systems, language theory and hardware archetecture.
Consider the project I am presently working on. It is a business intellegence reporting suite. Sounds about as generic as "business apps" come, right? Yes, except for the fact that we had to select the correct programming language, DB cube technology, DB engine, and hardware archetecture for the system. Because we went with
Now we weren't writing our own OS or designing our own load balancer. But we had to have knowledge about the uses and theories behind each. There would have been many combinations of solutions that would have been ill suited to the task at hand. A complete understanding of the theories and technologies available really benefited my employer ($6 billion company).
None of those things are applicable to writing business applications.
What you probably meant by that is that you would prefer that the term "computer scientist" describe the person who invents those solutions and engineers them from scratch. But in-depth knowledge of "those things" definately IS "applicable" to properly designing and implementing high performance biz apps.
Isn't going to be a good enough reason, Eh?
I used to work for CitiBank, and the client-side software used by their customer service reps to service credit card accounts was thick-client VB software (though the other tiers of the arrangement were not). I don't know if it's still VB based, since the company was still kicking around the idea of moving to a new platform when I left them a couple years ago.
The app was comprised of hundreds of screens dealing with everything from lost/stolen cards to rewards redemption to credit line increases, as well as general service questions. 99% of a customer service rep needed to do for a customer could be done with this software, and in an industry where seconds of lost productivity by customer service reps equates to millions of dollars lost, it performed just fine.
I also used to work for the MHA group, which recently merged with AMN Healthcare, making it one of the largest physician & nurse staffing companies in the country. It's entire business software suite, from invoicing to accounting to payroll to staffing was handled by software written in-house in VB.
I once wrote an EBSDIC to ASCII converter in VB to convert Texas Railroad Commission files to a format we could use, because a contract programmer had written one in C++ that didn't work--it translated text fine, but it didn't account for the EBCDIC Packed Numeric format. The version I wrote in VB was faster, and had GUI such as progress bars, etc. Granted, the C++ program could have been optimized and improved, but the point is ultimately that VB can compete on many levels with other programming languages.
Like martial arts, the ultimate value of a programming language must be judged by what a good programmer can do with it. Unfortunately, VB is so simple, it's easy for bad programmers to fake it just enough to get hired.
Just because it has the word "basic" in the name doesn't make VB unsuitable for applications.
One of the biggest differences I noticed when taking over a project that was written in VB6 and rewriting it and extending it in VB.NET/C# was the error handling. In VB6 the error handling is very kludgy. You can set up an error handler for any function that you want to, but unless you remember to also set up an error handler for every single button, etc. on your forms, your application will constantly be crashing in random places as you accidentally add new bugs with your new features or the user does things in an unexpected way. With VB.NET you could set up some try...catch blocks in a few convenient places and they would even catch exceptions thrown by the interactive portions of forms. My product had very few crashes compared to the other huge product that we still had in VB6 that crashed all over the place. I am also a huge fan of OO design and when I ran into a couple of things that I couldn't do well in VB.NET I wrote them in C# and they worked together seemlessly. Good luck, I hope you win.
Let's go Hurricanes!!! 2006 Stanley Cup Champions!!!
One of the biggest differences I noticed when taking over a project that was written in VB6 and rewriting it and extending it in VB.NET/C# was the error handling. In VB6 the error handling is very kludgy. You can set up an error handler for any function that you want to, but unless you remember to also set up an error handler for every single button, etc. (I guess they run on different threads) on your forms, your application will constantly be crashing in random places as you accidentally add new bugs with your new features or the user does things in an unexpected way. With VB.NET you could set up some try...catch blocks in a few convenient places and they would even catch exceptions thrown by the interactive portions of forms. My product had very few crashes compared to the other huge product that we still had in VB6 that crashed all over the place. I am also a huge fan of OO design and when I ran into a couple of things that I couldn't do well in VB.NET I wrote them in C# and they worked together seemlessly. Good luck, I hope you win.
Let's go Hurricanes!!! 2006 Stanley Cup Champions!!!
I assume you are talking about VB.NET since VB6 has been discontinued. I work for a company that still has a big VB6 product with tonnes of different VB6 DLL plugins that customers can pick and choose as extra features. We have neither the time nor money to rewrite it all in another language. This is a real problem that I suspect many companies are facing. (Don't tell me about interop, we've visited that nightmare)
A few months back I was saying that going with VB6 all those years ago was a massive mistake (due to its discontinuation) and that we should have gone with Delphi instead. Now Borland is selling off the Development tools division, Delphi's longevity is suspect. I now view proprietary languages with a great deal of suspicion. If I had my own company, I would try to avoid proprietary languages as much as possible since they can be a very big risk. You never know when that big company is going to turn around and tell you they are discontinuing it, leaving you completely stuffed. If you really have to use a proprietary language, try to pick one that is as open as possible.
e.g. Java
C# is supposed to be an open standard ( I don't know about VB.NET) but you will most likely find that the open source implementations do not have all the features you are making use of in Visual Studio. They will always be playing catch up with Microsoft. And you never know if and when Microsoft will turn around and start eliminating the open source implementations of C# in the courts.
As for the virtues of VB.NET as a language, it has all the modern features you would expect from an object oriented language. I personally think C# is a better choice to go with since Microsoft seem more interested in it (and are perhaps less likely to dump it), and also because its syntax is similar to lots of other languages such as Java and C++.
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.
Some of the anti-VB replies are kind of funny. Assuming that you're using VB.Net, (as opposed to VB 6, which is obsolete,) it's about as good as C# or Java. Having programed in all 3, I can attest to the fact that they each have various strengths and weaknesses; but in the long run, are all good for similar tasks.
The only real argument against VB (and C#, and Java,) is that they aren't meant for resource-intense computing. Specifically, if you're writing a program that needs to perform an operation on a 200 meg data structure in a matter of seconds, you might want to implement the algorithm in C, and use VB.Net (or C#, or Java) as the GUI.
No, I will not work for your startup
Do you recommend that applications be written in assembly? If you're willing to accept the performance hit of using C instead of assembly, than perhaps you do believe there is an excuse for inefficient code after all.
The difference between choosing C over Java or C# is the degree of balance between performance and productivity. The compromise is different for different languages, but make no mistake, it is a compromise that all languages make.
...as it has a fairly shallow learning curve, the variables' syntax is simple beyond belief, and it was designed from C specifically for web applications. If you want to do desktop, you could do that with php, but as a browser-based app with lots of backticks and system() calls.
#include <disclaimer.h>
#include <beer.h>
I used to love VB and it was for years a great language. Granted, it wasn't the most powerful language in the world, but it was easy to use and stable enough for smaller applications.
.NET came along and Microsoft Changed the language.
The
Now VB isn't compatible with VB.NET and I've lost my faith.
REASONS FOR NOT USING VB/VB.NET
1. It's Microsoft ONLY and your "potential customers" arent.
2. It's a Non-Standard language and therefore not portable.
3. It's a VERSION 1 Product - Yep VB.Net is NOT VB7.
4. Microsoft's history of upgrade compatibility is poor, and you'll need to rewrite whenever they decide to make a change to their systems (which is often).
5. VB is usually tied to ACCESS Databases, which are not platform independent.
I'd recommed throwing these arguements at the boss and asking him to provide a good reason for the choice of language.
Why do people keep dismissing C++? http://artlung.com/smorgasborg/Invention_of_Cplusp lus.shtml
of convincing your boss. If he's already decided that VB is the right tool for everything (apparently he has), nothing will convince him otherwise.
On a more general note, every programming language is suitable for everything, modulo availability of specific libraries. There are languages that are simply superiour, and they are always the better choice, with the possible exception of small throw-away programs and speed sensitive inner loops. VB is not one of them, but you won't convince your boss.
Therefore, write the sodden thing in VB or get a better job. Your boss is an idiot for not letting you use the best tool for the job, but he doesn't know and he doesn't want to be educated about that.
Ethan, many small companies have, and will continue to, develop in VB becauase ALL of the alternatives are more expensive. VB is indeed the greatest language for client/server applications. It's fast and it's cheap. Does it have glitches. Yes. Can they be overcome. Yes. Just like any other language. So this is not about the language. Now are there substantial differences between VB6 and .NET, yes, huge ones.
So the next question is, which version of VB are you talking about? You didn't state which one was used for the original development.
If the boss isn't using .NET, then it's time he did, and got the application converted to objects. Then you can continue this conversation.
as a business owner, i make my decisions based on the skills of the programmers involved, my tolerance for demanding that documentation be done regularly, and whether the 'team' can produce and keep current a modular flowchart-roadmap of what the project 'is' 'does' and what resources it 'uses' and 'connects with'.
in the MS world, their NET language and development tools are really the only way to go.
if you are doing Unix/Linux or web stuff, you can avoid VB/VBNET.
our favorite tools for heavy data work are VB Studio , VB (.NET compatible language), MS Access, and SQL variants.
if we have a real puzzle of a program, it is far better to see if a highly talented person can solve it with the language they know and think in, than forcing a new fit along the way.
Well, not addict so much as captive. My career path went from C++ (pre-windows) to VB to Delphi to finally Java. VB is pure hell in an enterprise environment. Of all the many problems, the biggest is deployment. If you have to deploy a VB app to a large number of non-standardized machines, you might as well just kill yourself now. Once any one microsoft-owned DLLs from the entire twisted conglomeration of DLLs on the target machine gets modified to the wrong version, (like, for example, if some other VB program gets installed) you might as well format the drive and reinstall Windows. Add to that that the actual language structure is infantile, and it takes a genius to use it to write really well structured code (which is paradoxical, because geniuses are too smart to use it).
.Net is Java eaten and puked back up and charged for. GET OFF THE MICROSOFT CRACKPIPE.
Delphi is great for Windows RAD. Deployment is the polar opposite of VB, as it will make a well-optimized standalone self-contained EXE which requires no DLLs at all. It's safer than C, but like C, it lets you use pointers and inline assembly.
IMHO, of the many develpment platform I've had any experience with, Java is by far the best for the enterprise development. The language structure itself makes it natural, if not necessary, to write well-structure object-oriented code. It's designed to be safe. It's easily ported to any OS. For most purposes it runs just as fast or nearly as fast as compiled C++, though if you really need a native implementation of something, you can easily incorporate a DLL. You are no longer dependent on the Windows API, and you don't have to worry if your program will run under the next version of Windows. As opposed to the Windows API, Java implements things like threading in a logical, safe, efficient and object oriented manner. Java and everything you could possibly need for it, are free, and what amazed me the most when I started Java, nearly every common functionality that you would want to add to your project is out there as a free open source java library.
Yeah, I know, I know, it's not fair to say Microsoft sucks because it is Microsoft. But with my years of experience with microsoft, I really can't find any useful advantage of the company. Open source is better and more stable. Only the documentation is better when being a programmer. Solution: buy a book (guide) for 15 dollars, instead of the 50 you pay for a very, very, very, extremely cheap ms system. All you need to know is in it. Plus: it's (in most cases) objective.
...). ah well, I hope you got my point: VB is 100% commercial. Java is going open source, I (!) think that that'll put the development quality to a higher level. And with the latest JIT compilers and stuff, java can be almost as fast as native code. I don't see the javaScript-like language VB do that!
Now, what is bad about VB? It's as slow as javaScript. Plus, you can hardly port it to, for example, unix systems (what other kernel bases are there in fact? microsoft's windows, unix, and...?).
I've tested the speed of microsoft's c++ 2003 toolkit against java. BINARY Java is FASTER, frikkin' FASTER than the COMPILED software, when checking loops. 'Da' hel'!
What should I think of VB?
Now, to the serious part:
I've learned VB.Net (webserver part) and not only is the language inflexible (is that english?), unstable and unlogical (is that english as well?), also: the system is discriminating! Omfg! Certain styles and layouts are just totally NOT sent to the browser, when that browser isn't windhoze internet exlocker! WTF!
I'M SERIOUS!
Yeah, of course you can switch that off (I'd be very mad if you couldn't, it's really discrimination!), but the point is: microsoft keeps its very own monopoly where it is. So the software is 100% commercially made (take a look at vista and you see it again and again) (take a look at msn live and you see it again and again) (take a look at windows media player and you see it again and again) (take a look at
Ah well, my major message:
Of course it's unfair to say something is bad because it's microsoft's, but in this case it's 100% true IMO
I would be scared of classic VB however ...
I second the comments here about the advantages of the new VB.NET. If your app is rewritten in VB.NET there are no worries because VB.NET is just syntactical sugar now and harmless. It's just syntax now that taps into the entire power of the .NET framework like C#, Java, Visual COBOL.NET! syntax etc etc.
The VB.NET syntax is still long and convoluted as classic VB always was, but VB.NET has none of the classic VB hinderences. It's totally different underneath. VB.NET is fully object-oriented.
Programming in VB6? Isn't that a bit like doing maths in roman numerals?
That, actually, is the most insightful comment I've yet seen in this forum.
The higher the technology, the sharper that two-edged sword.
I'd not reccomend VB Dot Net. Dot-Net is completely different to VB6 in methodology. I believe that keeping bits of the old language around will just prolong old habits that do not make sense in the Dot-Net world. Best go for something completely different and break from the old.
VB-Dot-Net also uses new words for concepts that have been in common use for years. You have to learn the new concepts anyway, so you may as well learn them in the words that the C# world and the rest of the object orientated development world are using. Using the VB terms you will have a harder time talking to non-VB object orientated designers and developers.
I must admit that i hava little experience in pure VB but...
without any prior knowledge of VB it's very easy to become productive (nasty code for sure).
You can always have the backend done in anything else (i do on Python)
What is really true is that bad coders are allways bad coders, and that VB does not help any little to create good coding habits.
Good platform, nasty language. You are true.
VB6 and VB.net
The TRUTH is (rather than speculation) that VB.Net and VB6 have a huge overlap.
Probably 80-90% of VB6 is still in VB.Net.
The real probelm with VB.Net (but only from the perspective of OO purists) is that you can still code like you did in VB3: i.e. ignore the majority of the OO constructs and treat it like a scripting language or a 3GL non OO language.
BUT it's still very productive.
As for VB.Net vs C#?
There's not a lot in it. They are very close to being functionally identical and in the end it comes down to syntax. If you are likely to get a lot of programmers working with you who are non-microsoft they will be more familiar with c like syntax and thus going with c# is probably better.
If, on the other hand, most of the programmers you will be working with are VB guys (good, mediocre or whatever) then they will still have SOME KIND of productivity in vb.net where they would be completely unproductive in C#.
As for maintanability: Is VB6/VB.Net inherently any more difficult to maintain than C# or Java? Only if written poorly (lots of global variables, poorly structured code etc etc). But you can do this in C# and Java too, so it comes down to the individual in the end. Personally when going through C# or Java code I find that there is a tendency to make it deliberately hard to follow with multiple layers of abstraction. Call the average VB coder simple if you like but I waste a lot less time trying to figure out how their code works than I do with Java or C#.
Is C# or Java or whatever better than vb.net? I think not.
Is C# or Java or whatever better than vb6? In certain ways yes, in others no.
And that is the bottom line...
Not since the time of GW Basic meets QuickBasic has the language had any real backward compatibility. Syntax and gramattical changes are common in each major version release. It's a relatively safe assumption that your code will be orphaned unless you are prepared to migrate it with each new VB release. The problem with Basic is the complete lack of standards to govern its evolution. As a result, the language has become a repository for every whim Microsoft has ever had.
It's not just Visual Basic that lacks true backward compatibility. Visual C++ will orphan your projects also. In the most recent incarnation, 2005, they don't even offer true C++ generics support (templates). I've worked on porting 1,000's of lines of code between Microsoft compiler revisions. The degree of breakage is unique to MS products.
I never liked how code in Visual Basic disappears behind modules, forms, and buttons. It makes it 10 times worse when you're porting VB 5 to VB 2005.
Three comments:
1) VB.NET offers 'scripting', or 'late-binding' capabilities that allow you to
write one line of VB code, where C# needs 20 or more.
Example: Late binding myths.
2) VB.NET exposes some elements of the underlying CLR (runtime) that C# hides,
e.g. a 'where' clause during catching of an exception. Link
3) Upcoming VB.NET (with DLinq & XLinq) will include native support for XML, whereas
C# has no such plans. Link
Personally, for new projects, I would choose C# over VB.NET.
Good luck!
George
I have to ask, but, why not port to VB.Net? VB.Net isn't inherently evil.
I don't care for it, but in most respects, its not different than using C#. My dislikes of it are lack over overloading support and its 'wordiness.'
So why no just write it in assembler or skip all these interpreters and jmp right to machine code! Oh sure there are problems with machine types and different cards (thats the end users problem) /BGATES heh heh /!BGATES.
yeah I know I'll get blasted for that comment, but I'm feeling real brave today.
FragHARD or don't frag at all