Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 



Forgot your password?
typodupeerror
×

Making an Argument Against Using Visual-Basic? 690

ethan_clark asks: "I work for a small company (< 10 employees) as a software engineer. The company got its start with a software product written by the owner in VisualBasic. He hired me to assist in rewriting the software – only catch is, he's stuck on having it re-written in VisualBasic. This scares me, but I honestly can't make a good argument against VB because I'm not familiar enough with it. So my question is twofold: I am looking for some confirmation to my suspicion that VB isn't the greatest language for large projects; and If VB isn't good, arguments against using it. If it is good, what arguments would you use to argue for it (for my sake)?" If you are going to argue against a language, it is best if you do so after you become familiar with it so that you can argue fairly on its merits and deficiencies. VisualBasic, like just about every other language, has its place. For the sake of discussion however, what tasks would VisualBasic not be suited for?
This discussion has been archived. No new comments can be posted.

Making an Argument Against Using Visual-Basic?

Comments Filter:
  • by MurrayTodd ( 92102 ) * on Wednesday May 31, 2006 @11:22PM (#15441593) Homepage
    Forgive my overall ignorance--I'm a Mac and Linux and Java person, although I've written a bit of VB in a job years ago--but does anyone know if moving to VB.Net allows a phased-in approach to introducing at least some C# programming down the road?

    Do the .Net languages allow a decent functional "Mix 'n Match" capability? If so, I'd make sure the VB rewrite was in VB.Net (or are there VB.Net idiosyncrasies that would justify sticking with the old VB6?) and then I'd learn C# really well. At some point in the project some component might fall under the "this will really suck under VB, and we can tackle it much better by writing this piece in C#" which will let you get a toe-hold on the idea of using a better language.

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

    As for the tasks VB are not suited for (again, I only know VB6, not VB.Net) the biggest glaring omission in my experience was the lack of decent Regular Expressions, or Hash Tables / "Dictionaries"--unless you link to the VBScript/IE6 library like everyone used to. On the other hand, there are IMOHO problems with languages like Perl that make them bad for a number of solutions, but that hasn't stopped nutty fanatics from treating them like "golden hammers".

    While I'm writing disclaimers, there are a number of commercial applications out there written entirely in VB. In all cases I've observed, they "evolved" out of a simple and useful app and fell into being examples of the most counter-intuitive user interfaces and over all "kludginess".
  • by blincoln ( 592401 ) on Wednesday May 31, 2006 @11:22PM (#15441594) Homepage Journal
    VB = 6 is unadulterated crap. VB.NET isn't half bad, although I much prefer C#.
  • by plover ( 150551 ) * on Wednesday May 31, 2006 @11:27PM (#15441617) Homepage Journal
    A fair argument against VB6 is that it's at end-of-life. Microsoft has dropped support. You find a bug in it and it's all yours. But honestly, there just aren't that many bugs left in VB6 that aren't already known.

    There's a different point of view you need to seriously consider: who's signing your paycheck? It's not Microsoft, is it? I thought not.

    Consider meeting your boss in the middle. It's possible your boss is set on VB6 because he can read it fluently. Perhaps you could convince him to port it to VB.net. VB.net might not be so different that it would scare him. The GUI isn't all that different. And the .net framework would allow you to gradually expose him to other languages (C# or C++/CLI.) And it would allow you the opportunity to use a language with better libraries than VB6.

    Have you dug a bit to find out why he's so pro-VB6? Maybe he's biased against .net because it's an interpreted language (like Java)? Perhaps half of his client base is all still running Windows 95 on 90 MHz pentiums, and .net is not an option for them. Maybe he'd be OK with C or C++ compiled to native executables, as long as there are no .net requirements. Microsoft's latest version of C/C++ has a strong push towards safer coding with bounds-checked versions of all the standard library functions. That might be good enough for him.

    Or maybe he just has only two or three long-term clients that are stuck on Windows 3.1, but they've been with him for 25 years so he feels he has to support them into the far future. Consider buying them a few cheapo PCs to run your software: $400 each for a few bottom-feeder Dells would go a long way with customer goodwill, and would allow the rest of you to move into the 21st century of tools. And a $1200 hardware investment is much less money than your time spent struggling with old tools.

    If he built a successful business around a piece of software, the chances are good he's smart enough to listen to rational arguments. So don't be irrational by kicking in your heels and saying "no! no! no!" unless you really enjoy job hunting.

  • by Telastyn ( 206146 ) on Wednesday May 31, 2006 @11:29PM (#15441625)
    Modern VB (VB.NET) is pretty full featured and un-crappy. It, like other .NET languages compiles down to MSIL so should behave identically to anything else. The only real arguement is based around that; if say... VB.NET and C# perform identically, why not use C#? It (arguably) has more of a following, (arguably) has a cleaner syntax, and (arguably) has a more java/C-like syntax incase you happen across people with that background. Not terribly compelling in the face of momentum...
  • what? (Score:5, Insightful)

    by larry bagina ( 561269 ) on Wednesday May 31, 2006 @11:31PM (#15441637) Journal
    You were hired to rewrite some VB software, but you're not familiar with VB? The problem isn't VB, it's you.
  • Wha? (Score:3, Insightful)

    by 19thNervousBreakdown ( 768619 ) * <davec-slashdot&lepertheory,net> on Wednesday May 31, 2006 @11:34PM (#15441657) Homepage

    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.

  • by cryfreedomlove ( 929828 ) on Wednesday May 31, 2006 @11:35PM (#15441666)
    1. VB is not portable. You'll be supporting windows based servers forever if you increase your investment in VB. The company I work for switched from VB to Java and we've been able to move our java server app to 3 different OS/HW architectures with zero code changes. 2. You cannot get insight into what VB is doing. Where is the server spending time? Can you see a thread dump? How much time is lost to collecting garbage. VB is a black box. That's death for debugging a large server system. 3. You cannot attract great new engineers to work on a VB application. Great engineers will avoid working on VB apps and you'll be stuck hiring low grade talent. That will perpetuate a downward spiral where any good people will leave to avoid VB and the bozos that like VB.
  • by plover ( 150551 ) * on Wednesday May 31, 2006 @11:41PM (#15441707) Homepage Journal
    Any app can devolve into kludginess unless there's a strong approach to coding shared by every single one of the maintainers. VB6 isn't magic that attracts crud any more than C++ or Java (other than increasing the number of potential idiots who think they know how to program in VB.)

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

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

  • Cross Platform? (Score:5, Insightful)

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

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

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

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

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

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

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

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

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

  • by Otter ( 3800 ) on Thursday June 01, 2006 @12:04AM (#15441853) Journal
    If he built a successful business around a piece of software, the chances are good he's smart enough to listen to rational arguments.

    Better yet, given that he's built a succesful business by writing version 1 in VB and that you don't actually have any rational arguments, why not defer to his judgment? The worst that can happen is that the next time this question comes up, you'll have a useful opinion instead of just vague concern that VB isn't 1337 enough.

  • Re:what? (Score:2, Insightful)

    by Anonymous Coward on Thursday June 01, 2006 @12:38AM (#15442011)
    Yep, I agree, even if you do manage to convince your boss to switch languages, ***any*** problem you have (and with any development of course you will have problems), it will come back to, "well you're the one who wanted it in language X instead of VB".

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

    Get another job.
  • by km790816 ( 78280 ) <wqhq3gx02 AT sneakemail DOT com> on Thursday June 01, 2006 @01:00AM (#15442104)
    Mod the parent up.

    This is the *huge* issue, that will make or break your decision.

    If it's VB6, run for the hills. It's end-of-lifed.

    VB.NET is a great place.
    You'll be able to leverage all of the .NET platform pieces (ASP.NET, SQL integration, WinForms, Avalon, etc).
    You'll be able to mix-n-match C# code.
    There is continuing investment in the language and tools. There's already a page dedicated to VB9 [microsoft.com] with some awesome features I wish were going to be in C#.

    If you're betting on a Windows environment, VB.NET is a great place to be.

    Your first choice should be "Are we going to bet on .NET?".

    If the answer is yes, VB.NET vs. C# vs. Managed C++ is a secondary call.
  • by stephanruby ( 542433 ) on Thursday June 01, 2006 @01:02AM (#15442114)
    This original poster scares me. He wants arguments against VB, but doesn't explain the scope of his project, nor does he say what language he wishes to replace VB with. Most likely, he doesn't have much experience in the working world and would just prefer to use a language he's already used to from school.

    The crucial ingredient in any project is the people you end up working with, not the language. I'm not a fan of VB, but if this kid doesn't have the experience of successfully completing a project in the real world, he should consider following the owner's experience -- and only worry about changing the underlying language once he has a couple of releases under his belt.
  • by Nataku564 ( 668188 ) on Thursday June 01, 2006 @01:24AM (#15442200)
    Why do people keep dismissing C++? Its free, open source, works on all platforms, and will arguably be able to hang around longer than just about any other language out there. Sure, if you do decide to move platforms you may have to do some porting, but compare that to the constant upgrades ($$$) of an Microsoft technology, and C++ will most likely come out ahead.
  • by pookemon ( 909195 ) on Thursday June 01, 2006 @01:34AM (#15442242) Homepage
    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.
  • by ScrewMaster ( 602015 ) on Thursday June 01, 2006 @01:39AM (#15442264)
    ... and the bozos that like VB.

    In other words, you're a Java bigot that looks down upon those that don't agree with your choice of tools. It used to be C bigots that irritated me the most (the "if you can't do it in C it isn't worth doing" mindset), but now it seems that most of them have moved to C# and have finally realized the benefits of a decent GUI development system. A friend of mine once put it this way: "Welcome to VB you pompous assholes." VB6 and VB.Net have their place, and calling people that use them bozos won't win you any points (although you'll probably garner some karma from like-minded mods.) But the biggest argument to me isn't that VB6 is a black box (from an empirical standpoint it's about as thoroughly understood as it's possible for a black box to be, and .Net isn't much more open), but that VB6 has been end-of-lifed. Obviously, it's not wise to make a significant investment in new development using an unsupported tool chain. Still ... at least it's no longer a moving target, and in spite of your rhetoric to the contrary there's still a large base of established VB coding talent. Much of it is migrating to .Net or Java, true, but there's a shitload of VB6 code out there and plenty of companies willing to shell out good money to maintain and develop with it. Purists such as yourself may not care for that, but there it is. Not everyone needs to work on the bleeding edge, and not everyone that doesn't is an idiot.
  • by Jay Carlson ( 28733 ) on Thursday June 01, 2006 @01:59AM (#15442356) Homepage
    Why do people keep dismissing C++?

    Because it sucks .

    It is a language designed so that a genius can write libraries designed for the merely smart to use. How many geniuses do you have in your workgroup? Me, I'm lucky. But I'd really rather they work on real design than trying to remember how copy constructors interact with template instantiation.

    I don't know C++, and I know that I don't know it. Somewhere around here I have a list of interview questions for people who put C++ on their resume. They're mostly from me reading C++ code and going "what the heck does that imply?"

    Unsurprisingly, most candidates fail that section of the interview. And they fail even trivial stuff like "what's a virtual pointer all about?" They may be aces at writing O(n^3) algorithms with CString, but they have no clue what's going on under the surface.

    To be fair, I do know some true C++ experts. Most of them would rather be writing Haskell.
  • by Karma Farmer ( 595141 ) on Thursday June 01, 2006 @02:03AM (#15442375)
    VB6 developers that transferred to VB.Net had to learn the majority of their chosen language again.

    Yes, and my experience is that it takes them a long time learn, and they're not very good with it when they're done.

    The reason VB developers wouldn't learn C# is probably a productivity issue, rather than not being able to learn the language

    No, the reason VB programmers wouldn't learn C# is that they're generally not very good developers, and it takes them a long time to learn new languages.

    C# is more like Java/C++ than VB - the language and syntax is entirely different to VB.NET.

    The syntax is absolutely the most trivial part of any language. A Java developer should be able to learn the VB.Net or C# syntax in literally a few hours. The difficult part of any language is learning the libraries and runtime. A good developer can learn the basics of the .NET runtime in a few days, but might take months or even years to learn it well.

    The library and runtime for VB.Net and C# are (basically) identical, and the two languages can be mechanically translated. They really are the same language in nearly every way that matters to a developer.

    Frankly, the only significant differences in the languages are seen by a hiring manager.
  • by bunions ( 970377 ) on Thursday June 01, 2006 @02:07AM (#15442392)
    Visual Basic (especially VB6) have no place in the enterprise.

    this is seriously one of the funniest things I've read on slashdot in the last week. For the canonical car analogy, it's like saying sheet metal has no place in modern automobiles.

  • Disclaimer: I code in VB, Java and Python.

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

    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 .NET apps need .NET framework and python app needs its python Interpreter. [ even files compiled with MS VC++ need MSVCRT.dll ;) ]

    If anyone says VB is an interpreted., so is python and .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.

    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 .NET..,
  • by Z00L00K ( 682162 ) on Thursday June 01, 2006 @02:25AM (#15442471) Homepage Journal
    since VB isn't type-safe. It may be easy to write in VB, but you lack a lot of the safety offered by C# or Java.

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

  • by Anonymous Coward on Thursday June 01, 2006 @02:49AM (#15442584)
    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
  • by Handyman ( 97520 ) on Thursday June 01, 2006 @02:51AM (#15442592) Homepage Journal
    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.
  • by pookemon ( 909195 ) on Thursday June 01, 2006 @02:56AM (#15442609) Homepage
    So you aren't actually talking about the languages at all - you are talking about the .NET Runtime - which isn't actually anything to do with the languages. It's like saying VB and C# are identical because both can call the Windows API. It's simply not true.

    And you are saying it takes VB developers time to learn VB.NET because they're bad developers. Nevermind the fact that VB has been around for years, that people have been developing in VB for years and that many of the core VB functions and objects have been moved out of VB and into the .NET framework. Of course it takes time to learn these things.

    A Java developer should be able to learn the VB.Net or C# syntax in literally a few hours

    Of course - because they are familiar with the use of Packages - which the Framework is built on. They'll learn C# faster because the Syntax is very similar to Java. They'll learn VB quickly because it BASIC (you are aware of what the B stands for I presume).

    The language is not what makes a bad programmer - it's their education and experience. The BEST programmers I have worked with were VB programmers (back in the VB3 days). They were great programmers because (a) They were methodical, (b) They worked to proven and widely published standards and (c) They knew how to write REAL windows applications. They were great using VB and extremely good when we shifted to writing C. The language had absolutely nothing to do with their skill.

    And your claim that they are essentially the same language is pure nonesense. Sure they compile to the same bytecode, sure they use the same framework but beyond having the same types virtually everything about the language (not the Framework) is different.

    The operators are different, the functions are different, the syntax is different. Variable declaration is different, operator precedence is different and the initialization of arrays is different.

    and the two languages can be mechanically translated

    Big deal. I worked with some guys a few years back that could "Mechanically Translate" Advanced Revelation (ARev) to Visual Basic. There's virtually nothing similar in those languages yet they could do it - simply because they took the time to write the tool to do so.

    Of course all this aside - you still say that VB makes bad programmers - and then you claim (incorrectly) that VB and C# are virtually identical - yet VB programmers don't learn the new language because they can't. Can you contradict yourself further?
  • Re:C++ and Java (Score:2, Insightful)

    by gangien ( 151940 ) on Thursday June 01, 2006 @03:03AM (#15442640) Homepage
    Good arguments against C++

    manual memory management, obfuscated syntax, to many ways to shoot yourself in the foot.

    Good arguments against Java

    performance is bad, requires a JRE to be installed to run, which can be a pain. Can be hard to do simple things (eg all primitives are signed)

    Good arguments for C++
    good performance, as good as you can get. Many platforms have compilers for it. Open and well known. Lots of preexisting libraries for it.

    Good arguments for Java I'm going totake some liberty and assume by java you meant he language and the JVM together. (no c++ equivlent)
    Compile once, run anyway (via shell scripts or similiar mechanisms) compile on windows, run on z/OS.. cannot say that about much (anything? else). Vast library, no memory management, very clean language that's simple to understand and adapt. Easy to plug 3rd party libraries in and use.

    How good is each one in terms of:
    * Purely Object Oriented

    Java very good, almost pure OO language.
    C++ not pure at all

    * Multi-threaded
    java this is as simple as i've seen
    C++ a pain and somewhat platform dependant

    * Dynamic
    I'm not sure what you mean by this really.

    * Portablity
    Java wins in that you compile once, run many places
    C++ wins in that the same code can be compiled virtually anywhere

    * Robust
    Java provides mechanisms that make the code much more robust
    C++ wins in that it's more deterministic, no relying on wierd VM things

    * Secure
    I don't think i'm experienced enough to really comment on this one

    * High Performance
    I'm no thte biggest of fans of the idea that java is slow because it runs on a VM. For most apps, this difference is trivial. For some apps, such as games, this difference is critical.

    Overall, I'm a big fan of java and the idea of byte code that runs on a VM, as opposed to native code that runs directly. That said, there are areas where you ahve to use native code (eg: making system calls) or it's better to use native code (games). I think C and java will outlast C++ though.
  • by Efrat Regev ( 935278 ) on Thursday June 01, 2006 @03:57AM (#15442821)

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

  • by Anonymous Coward on Thursday June 01, 2006 @04:15AM (#15442877)
    You obviously have no real experience at all from abstract machines and compilation to native code. The difference between stack based and register based abstract machines is marginal, and there is no clear-cut advantage to either variant.
  • problems with VB (Score:4, Insightful)

    by Anonymous Coward on Thursday June 01, 2006 @04:16AM (#15442880)
    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:

    -to me, the syntax is OK
    -the API, compared to Java, is really bad (no jdbc, no generics, ..., keep yourself busy-coding)
    -the GUI is easy
    -writing maintainable code is difficult. VB(.NET) is hard to style because of its IDE. Eclipse is magnitudes better.
  • by shutdown -p now ( 807394 ) on Thursday June 01, 2006 @05:29AM (#15443067) Journal
    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.
    Er... Delphi?
  • by oliderid ( 710055 ) on Thursday June 01, 2006 @05:59AM (#15443130) Journal
    I totally agree with that.

    I work with Perl, Java, C# regularly. A crappy coder can use C, C++, JAVA or whatever , he will still produce crappy code. I use these languages because I'm more familiar with C related languages.

    Assuming that the guy is working on VB .NET, the end result will be just like C# .NET.

    Instead of wasting your time on syntax matter, better to focus on the application architecture.

    I'm sure that half of the negative comment came from the simple reason that VB means virtual "BASIC". Most of them still remember their early experiences on their 80's microcomputers and consider this family of languages as toys.

    Concerning the original question:
    - His boss knows VB
    - He knows VB

    An application has been already released and if the boss was able to hire him, it means also that this application has already convinced several customers.
    Problems: using VB isn't "cool". The guy doesn't want to tell to his friend that he uses VB at work.

    If you choose another language:
    - Make sure your boss (the other coder I guess) knows it.
    - Find new friends (IE less stupid).
    - Find another job.

  • by KDan ( 90353 ) on Thursday June 01, 2006 @06:15AM (#15443173) Homepage
    You'll be able to mix-n-match C# code.

    That has to be somewhere in the manual of permanent employment as one of the tricks of the trade... "introduce technology that no one else understands so that you're the only person who can maintain it". If the original poster's boss has any brain cells, he'll refuse to have any C# lying about unless he has more than 1 programmer capable of working with it.

    Daniel
  • Coding defensively (Score:3, Insightful)

    by rcw-home ( 122017 ) on Thursday June 01, 2006 @07:00AM (#15443280)
    This isn't a critique of VB per se, but more of the culture that surrounds it.

    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.

  • by nogginthenog ( 582552 ) on Thursday June 01, 2006 @07:11AM (#15443315)
    I have been programming in VB since Version 2, and right up to Version 6

    Yet you don't know that VB *is* compiled by default?
  • by jonadab ( 583620 ) on Thursday June 01, 2006 @07:12AM (#15443319) Homepage Journal
    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.
  • by Anonymous Coward on Thursday June 01, 2006 @07:16AM (#15443334)
    And right here is the biggest reason for not developing product in any Microsoft environment:

    If it's VB6, run for the hills. It's end-of-lifed.

    VB.NET is a great place.


    Lessee, VB6 is end-of-lifed so use VB.NET. But what happens when Microsoft decides that VB.NET is end-of-lifed? Well, you can start all over again!

    I have participated in several development projects (not products, just internal software utilities) that started in one version of VB, were rewritten for the next version of VB and then rwritten yet again for the next version! Microsoft has a vested interest in making sure that users must buy the newest version of any of their IDE software development platforms. They enforce it by using their operating system. Even if you want to stick with an older version of the software to prevent having to entirely rewrite stuff, you quickly (like the next version of Windows) find that code produced with the old IDE no longer runs on the latest version of Windows. Due to their constant tinkering with the API's, one version of VB was decidedly not compatible with the next.

    The reason VB.NET is the rage now is because it was supposed to be the underpinning for the new Vista OS. It is also rumored to be a large part of the reason Vista is late. You really wanna hook your wagon to that star?
  • by hey! ( 33014 ) on Thursday June 01, 2006 @07:20AM (#15443347) Homepage Journal
    If it's VB6, run for the hills. It's end-of-lifed.

    This is a critical point, and bears on the way the boss is making the decision. Professional programmers don't like VB because, as a language, it is not very good. But that doesn't mean the boss is being stupid. No. He's actually making the decision using a fairly reliable algorithm: repeat what has worked in the past.

    The problem with this algorithm is that it can fail when the future is sufficiently different from the past. As in the platform being not supported anymore.

    VB is not so much a bad language as an obsolete (and mediocre) one. But it isn't just a language -- it's an IDE and an operating environment with widgets and libraries and so forth. And in the other aspects that VB is relatively strong for some kinds of tasks. Visual Basic is Visual -- it really encourages you to think and work in terms of concrete visual objects. For a professional programmer, this is higly limiting, because a lot of problems you deal with aren't visual. Limiting isn't necessarily bad if the problem you're working on falls squarely in the middle of them.

    You just don't do complex programming in VB. It's perfectly adequate for simple form based clients to a client/server style database backed applications that lack demanding scalability or support requirements. Most VB programs consist mostly of short event handler scripts around form components. The tight coupling of business logic to UI code is anethema to systems programmers. Clearly it is bad architecture, but the purpose of architecture is to reduce the cost of development and maintenance. In these kinds of applications, being able to get the application working quick enough outweighs any architectural drawbacks.

    I think the sweet spot for you would be C# and Visual Studio. The way you lay out forms and such is the same as in VB 6, and these days learning how the bits is the real work on the learning curve, not the language. Forms in C# hava a Java/Swingish kind of MVC pattern, but it's really only one new design pattern you need to deal with. Once he's got the hang of it the boss can pretty much see a one to one correspondence between bits in the old VB app and a new C# app. You could go with VB.NET, but really for the kind of cmdbtn_click scripts of a typical VB app, there is no reason a VB6 programmer couldn't look at, understand, and maintain the same script in C# without having to swallow the whole C# enchilada.

    And C# is a modern, well designed language. This means that if you have a piece of work that is sufficiently complex to worry about reuse, maintainability, scalability or other advanced requirements, you can address them properly. Many of the best practices and frameworks from Java have their counterparts in C#, such as O-R mapping, unit testing and so forth.

    IN any case, you're in for tough sledding Dealing with a guy who has built a business where he does everything is difficult. These guys seldom can make the leap to creating a company that is bigger than they can handle personally. Even if they understand change is necessary, and that they can't do it themselves; even if they hire people to create change, they usually end up fighting change tooth and nail. Often they undermine the efforts of anybody to do anthing independently, such as book keeping or filing. Everybody is running a three legged race with the boss, and since he only has two legs, there's a lot of waiting around for him to catch up so he can toss all your recent work into the crapper.

    Underneath this behavior is fear and beneath fear is insecurity and ego protection. Probably against all expectations, this guy has made a reasonable success so far; he has customers who send him enough money that there's more work than he can do himself. And since he didn't get where he is by saying no, he hired more people. But he'd probably be happier if it was just him. He may not know how to supervise people or even run a bu
  • by trezor ( 555230 ) on Thursday June 01, 2006 @07:57AM (#15443481) Homepage

    In all fairness, this differs from the old VB runtime just how?

    Currently there are 3 versions of the .NET Framework. v1.0, 1.1 and 2.0. I would assume any newer Windows installation at least comes with v1.1 by default, which most current .NET-applications depend on. Oh noes! I have to click "Windows update" and wait 30 seconds! My, oh my.

    As for "refusing to install it". How zelous can you get? Do you refuse to install Sun's JVM as well? Yes, I see you think java ain't a real platform as well. Do you refuse to install perl or php when you write web-applications as well?

    Now let me tell you about the real world: If an application does useful stuff, and uses a framework that cut development time to a tenth, that is not just a real application, but anyone remotely interested in costs will find that framework great. So will probably most realworld developers who care about getting stuff done without wasting their time on rewriting the same generic code 50 times per project.

    Since it sounds like this is a product that will be used outside of a controlled environment (ie withing a specific company, you know what you are running the app on), then you are asking for a technical support nightmare.

    "Install the .NET Framework version 2.0 available at Windows Update or download it from this link [microsoft.com].". Yeah, that was, like, you know, the worst of technical support nightmares.

    I know this is slashdot, but I can't believe this zealous rubbish got mod'ed "Insightful" and not "Troll".

  • by DrXym ( 126579 ) on Thursday June 01, 2006 @08:02AM (#15443509)
    If the answer is yes, VB.NET vs. C# vs. Managed C++ is a secondary call.

    Stay the hell away from managed C++ if you can avoid it. There is precious little reason to use C++ unless you intend to do something unsafe such as call Win32 or other unmanaged code so managed C++ is something of a misnomer. The only reason to use it in my opinion is if you have some legacy C++ that you need to abstract behind an object and expose into .NET land.

    It's also worth pointing out that if ever the day arrives where Mono is interchangeable with .NET that C# is a future proof option. Managed C++ is unlikely to happen on Linux for a host of reasons, and I suspect that MS only support it since it's a great way to muddy the waters for Mono and cross-platform development in general - just like the ease with which they allow you to use COM interop or PInvoke.

  • by hitmark ( 640295 ) on Thursday June 01, 2006 @08:11AM (#15443559) Journal
    and thats the attitude that leads us to having a future windows version that wants a 3D card for basic desktop operations, and eat 15GiB of storage space...
  • Handheld devices? (Score:2, Insightful)

    by tepples ( 727027 ) <tepples.gmail@com> on Thursday June 01, 2006 @08:15AM (#15443578) Homepage Journal

    And my X2 4400+ with 2GB of RAM cares why?

    Because it's not handheld. A lot of people demand client programs for PDAs or "open market" smartphones.

    Or, if it's on a server, because it's limited in the number of clients it can serve. More efficient code can serve more clients per second on your "X2 4400+ with 2GB of RAM".

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

    Actually, the problem is whoever hires people who are qualified for task A to do task B.


    This is a perfect example of the difference between a university-educated computer scientist, and a graduate of a 6-month "tech college" program. The community college drone has only been taught how to use one or two tools to perform common tasks, whereas the computer scientist is taught to truly understand the tools, as well as the thinking that went into them, how to use them to solve multiple abstract classes of problems (instead of just a few common, specific problems), and how to apply that knowledge to use tools they haven't seen yet.

    A real computer scientist doesn't care what language they work in. A good employer should know that when they hire the 6-month grad at $18/hr, they're getting a code monkey that can do only what is explictly listed on their resume. They know that when they spend the extra money for a computer scientist with an actual degree, they expect that programmer to be much more capable, flexible, and adaptable. The fact that they've never programmed in VB before is nothing more than a minor roadblock. Send them to Borders/Indigo/Chapters with $50, tell them to pick up an O'Reilly or Knox book on VB, leave them alone for a couple days, and they should then be able to apply all their learning in the new language.
  • by maillemaker ( 924053 ) on Thursday June 01, 2006 @08:36AM (#15443686)
    >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
  • by fean ( 212516 ) on Thursday June 01, 2006 @10:02AM (#15444357) Homepage
    B) Who doesn't have a 3d card in their computer now?
    90% of laptop owners
    80% of windows users

    Even current integrated graphics won't cut it with Vista... And really, how many computers will have been purchased between now and Vista? I'm guessing that the amount of computers purchased that have adequate Video Cards to run Aero will be less than half, so this does little to really change the ratios.

    You're right, computers without amazing video cards will be able to run Vista, but the whole point of this thread is that the parent suggested the "Fuck the low-end users, write inefficient code that requires a half-gig framework to be installed to run the 5 meg program" approach... (Net 1.1, Net 2.0, and the new XAML/Sparkle based frameworks will total well over 400 megs...)

    Just because you can make a program doesn't make you a programmer... Write a program, write it well, don't use a framework unless it actually benefits the program, not just because it's there. (Because who says it'll be on the client computer?)
  • by KevMar ( 471257 ) on Thursday June 01, 2006 @10:05AM (#15444380) Homepage Journal
    Just because you can have several languages does not mean that you should.

    Where the true advantage of the .net is the common library of functions. syntax is just that, syntax. If you can code it in C#, than you can code it in VB.Net.

    Im a C# programmer at heart, but the existing codebase here is VB. I migrate it to vb.net as needed and all new stuf is coded that way.

    vb.net is not the same old vb6 that you grew up with. It now has all the advantages of C#, but with the VB syntax. When your employer is clueless about .Net, just explain to him its VB7 and that VB6 is loosing support.
  • by CortoMaltese ( 828267 ) on Thursday June 01, 2006 @10:08AM (#15444406)
    The language is irrelevant to comp scientists... A real computer scientist doesn't care what language they work in... The fact that they've never programmed in VB before is nothing more than a minor roadblock.
    I agree that a "real" computer scientist could easily learn a new language and it really might be just a minor roadblock. However, the language is certainly not irrelevant, and we really do care what language we work in. A craftsman needs the right tools. I wouldn't want to code in a language that does not fit the purpose. I like to think that a real computer scientist would recommend a language that best fits the purpose rather than just do what the pointy-haired boss wants.

    If my opinions prevent me from being considered a "real" computer scientist, I'd prefer surreal or unreal. With an actual degree, nonetheless.

  • by jbplou ( 732414 ) on Thursday June 01, 2006 @10:09AM (#15444415)
    How can you say C# is better than VB.NET? If you set your compile options correctly they compile the same in most cases. What matters more is the quality of the programmer and you will get better code. If I could get a good VB.NET programmer I would take him over 4 bad C# programmers and vice versa. The languages are basically the same.

    I've written in both, the main advantage C# has is that it is less verbose but that doesn't make it better, it probably makes it more difficult for inexpierenced programmers to read.
  • by CharlieG ( 34950 ) on Thursday June 01, 2006 @10:27AM (#15444600) Homepage
    Change that last sentence to...
    "Every language does have it's place, but there are perceptions tha can raise and lower a language's value ON YOUR RESUME"

    The perception itself does not raise or lower the actual value

    Story:
    Way back when, in the DARK days of DOS programming, and when most if not all of Microsoft's support was done on CompuServe, one of the forums was called "MSLANGS" - In there, among others, were the C form, and the PDS form (read that as Pro Compiled BASIC). Both generated OBJ files, for the identical linker (MASM used the same linker) - and in fact, if you wrote code that did NOT involve stings, and used the equivilent control structures, you got identical OBJ files. The big differences were pointers in C, and BSTRS in Basic. Now, as a LOT of business code then, as now, was string related, the string functions that were in basic allowed you to develop certain classes of application a LOT faster than the C guys. They would slag on us for "BASIC", and we'd smile, underbid them, and produce the work in less time. Yeah, the perceved value for a "BASIC" programmer was lower - but often the client didn't care what it was written in - only what the application did, how it performed, and how it was going to be maintained. So, which tool was more valuable? If I can underbid you by 10%, but do the job in 25% less time.... (hence, get more contracts...)

    Languages are tools - pick the tool for the job.

    Of course, sometimes part of the "Job" is your OWN personal development - then perceptions count for a lot

    Back then, it was HARD for a BASIC programmer to get a job - VERY hard. It was niche - BIG time (IEEE-488 aka GPIB aka HPIB instrament control was one - the one I was in). Even if you had a CS degree, folks looked down at you. Then one day, Microsoft came out with VB 1.0. I ordered my copy that day. The world changed. Withing a year, the folks who KNEW BASIC (the old DOS stuff) were in demand, as we actually had a clue. I've never looked back. I've done some C, some light C++, enough MASM to have shipped a bunch of old DOS drivers to clients, and now C# and others.

    My advise to anyone reading? Don't be a lanuage snob, but also, don't forget, there are language snobs out there, perceptions DO matter, and don't let yourself get boxed into a corner. Evolve or die
  • by MighMoS ( 701808 ) on Thursday June 01, 2006 @10:36AM (#15444700) Homepage
    That's just ignorant. And I'll tell you why you should care. Because no matter how fast your processor is, I'm guessing your hard drive still only spins at 7200 RPMs. Meaning that those binaries that are getting larger and larger will take longer and longer to load because your hard drive still has to read all that (now larger) data. Also, internet connections aren't getting terribly faster, so downloads now take longer. Oh, and I like to multi-task. I'll the kind of guy who likes to leave programs open (for continuity) while gaming. And the less resources everything else is taking means the more FPS I get out of my FPS's.
  • by tepples ( 727027 ) <tepples.gmail@com> on Thursday June 01, 2006 @11:32AM (#15445385) Homepage Journal

    Both [a PC and a PDA] have their purpose but you need to identify the purpose of each one and develop the application for each with that in mind.

    Correct. And a lot of people misidentify the purpose because they refuse to think out of the desktop box. If an application is capable of running acceptably fast on a 100 MHz machine, that's no excuse to code it inefficiently, as you could expand your market by porting it to PDAs.

  • by Latent Heat ( 558884 ) on Thursday June 01, 2006 @06:39PM (#15449330)
    I have issues with the idea that the boss dude is a stick-in-the-mud and needs educatin' on how to run his business.

    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.

  • by BattleTroll ( 561035 ) <battletroll2002@yahoo.com> on Monday June 05, 2006 @12:48PM (#15473308)
    "Unsurprisingly, most candidates fail that section of the interview. And they fail even trivial stuff like 'what's a virtual pointer all about?' They may be aces at writing O(n^3) algorithms with CString, but they have no clue what's going on under the surface."

    Of course they fail that portion of your interview questions - 'virtual pointers' don't exist. Virtual methods exist, pure virtual methods exist, pointers to virtual methods exist, but there's no such thing as a 'virtual pointer'.

    'CString' is a Windows library. It's not part of the C++ standard. Standard C++ is pretty well self-contained. Don't confuse additional libraries with the language itself.

    Not knowing the language is the first reason you shouldn't be interviewing candidates. That last thing I need is a new "C++" programmer who wants to write output to System.err. Maybe you should refer C++ interviewees to someone who actually knows something about the language?

Kleeneness is next to Godelness.

Working...