Forgot your password?
typodupeerror

Making an Argument Against Using Visual-Basic? 690

Posted by Cliff
from the is-it-the-right-tool dept.
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:
  • Give us a bone! (Score:5, Informative)

    by morcheeba (260908) * on Wednesday May 31, 2006 @11:22PM (#15441599) Journal
    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.
  • by JanusFury (452699) <kevin.gadd@g[ ]l.com ['mai' in gap]> on Wednesday May 31, 2006 @11:30PM (#15441634) Homepage 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. 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.
  • by Edward Teach (11577) on Wednesday May 31, 2006 @11:33PM (#15441650)
    The good thing about the .NET languages is that they compile to the same "bytecode". In Microsoft's case, this is the MSIL that runs on the CLR. You can mix and match all you want. Just create a library of C# classes and you can use them in any of the .NET languages. The reverse is true, that you can write code in VB.NET and use that library in any of the other .NET languages.

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

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

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

  • by petard (117521) * on Wednesday May 31, 2006 @11:38PM (#15441682) Homepage
    Joel Spolsky explained why CityDesk, written by a shop populated entirely by highly qualified C++ coders, is 95% VB [joelonsoftware.com]. He has a frank discussion of VB's pros and cons as a development tool, and you may find that many points he discusses will resonate with you as you develop your reasoning. Even if you don't come to the same conclusion he does, it's an excellent discussion of just the topic you propose.

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

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

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

    stop now and use managed code of some kind.

    If you all can, think really hard about why you want to spend your talent managing memory instead of doing things that'll really make your application shine. (There are reasons. They don't apply to most apps.)
  • by Osty (16825) on Wednesday May 31, 2006 @11:41PM (#15441704)

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

    .NET languages are all pretty much interoperable, so long as you make sure to build your assembly as CLSCompliant [msmvps.com] (which may limit usage of some language features). The main problem is that VB.NET is quite a bit different from VB6. For someone who's only ever done VB code, it's easier to learn VB.NET than C#, but for everybody else you may as well start directly with C#. In the past, I'd have advocated building your UI with VB and calling C++ COM objects for any heavy lifting. Now, I'd recommend you go C# and do everything there.

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

    You get regular expressions and collections with .NET (though not as many different collections as in Java, unless you bring in the J# assemblies for your project). You also get generics, anonymous methods (anonymous delegates, lambda functions, closures, whatever you want to call them), and quite a bit more cool stuff, though I have no idea how well that's exposed through the VB.NET language. Even cooler than that, you could subversively write modules in a functional language like F# [microsoft.com] (a dialect of ML) and nobody'd know the difference from their VB.NET or C# environments. (yeah, you can do that with Java as well.)

  • by plover (150551) * on Wednesday May 31, 2006 @11:50PM (#15441762) Homepage Journal
    ... the scroll wheel won't work in the IDE.

    I used to think so, too.

    Try this. [microsoft.com]

    Who's your buddy now? :-)

  • by owlman17 (871857) on Wednesday May 31, 2006 @11:53PM (#15441791)
    I'd mod the parent up if I had any points. I couldn't agree more. The most compelling reason to gradually (if not immediately) move away is that VB6 has reached end-of-life. Your boss would do well to listen to you that you ought to at least _begin_ to move away.

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

    by Nevyn522 (309931) on Thursday June 01, 2006 @12:46AM (#15442042)
    First company I worked for produced a series of ActiveX controls written in VB, shipped and sold with the source. It supported 3 full time devs, 2 support/sales people, one HR person, and an intern (me).

    They vanished after they tried to compete in the .COM world and got absorbed by ZDNet, but their components are still for sale on Programmer's Paradise, last I checked.

    I got an internship with Microsoft after spending most of my interview defending VB as a language choice -- this was pre-C#/.Net.

    Some "facts" from above annoyed me, so I'm responding:
    1) VB is only interpreted.
    VB6 can be compiled to P-code, and will run interpreted. However, by default it's compiled to executable code. The only "penalty" for using VB6 when it comes to speed is really the memory footprint of the VB6 runtime DLLs.

    2) VB6 is not suited to large products.
    I'm aware of at least one company that based an entire website off VB6 apps. I'm sure they would be ASP.Net now, but at the time (VB4), that wasn't yet an option. So the web engine was actually a series of VB apps that were invoked to process the web request as ReadLine and Print commands.

    3) VB6 -> VB.Net
    (The person in question did only propose this as an idea.)
    I would argue against this. There are certain elements only possible in VB6, and the switch to managed code is unfortunately not as seamless as MS would have liked. Hence the uproar when MS EOL'd VB6. VB.Net is great for managed code, and even has some features that C# lacks. I personally prefer C#, but I come from enough of a mixed background that I can handle what VB.Net code comes my way. While rewriting the application in VB.Net may be the proper thing to do, it certainly does not provide much in the line of benefits above and beyond rewriting the application in C#.

    VB does have certain benefits to use. As a RAD environment, it is (or was :) ) without peer. As to the inavailability of new APIs: a) Pretty much anything in COM can be used -- although some trickery may be necessary for custom structures. b) Anything done in a "straight" Win32 API can be directly invoked -- akin to P/Invoke in the managed world. For database work, VB was unparalleled. The ease of data connections has now come in some degree to the managed code word, but in unmanaged code only VBA comes close. C++ just can't compete. VB is no longer entirely late-bound -- if a dual interface is available, and the code is written to expect that type rather than just Object, VB6 operates as an early bound client. VB6 is also capable of being used in a late-bound fashion with almost identical code to the early bound scenarios.

    While I can't know why your manager wants to use VB, it's not such a terrible order.

    If your manager only wants to preserve the look-and-feel of previous versions, the previous proposal of writing COM components in C++ for the high-performance portions and using VB for the front-end is certainly a very viable option, and one that I've used previously. In this manner, the weaknesses of VB6 can be circumvented while still leveraging existing components and possibly even code. At the far end of the advancement spectrum, even managed components can be exposed to COM clients -- Adam Nathan's wonderful ".Net and COM: The Complete Interoperability Guide" is probably the most complete book on the subject. If appropriate, you can write new code in C#, and expose it back to VB6.

    If your manager wants to preserve the code base in VB6, you might want to determine why he wants to rewrite the application -- it's possible a better solution is just to rewrite portions of the code, depending on the scope of the changes he desires. The right tool for the right job -- VB is the right tool for some jobs, but shouldn't be presupposed to be the right tool for every job.

    That being said, there are few things you can't do in VB -- although some of the solutions are probably not as simple as they may be in other languages. Keep in mind, however, that it is even possible to get assembly code linked into a VB6 application, if necessary. It just takes a little bit of creativity.
  • Depends! (Score:4, Informative)

    by bryanporter (847667) on Thursday June 01, 2006 @12:50AM (#15442059) Homepage
    I've done a great deal of VB programming over the years, and I've seen all manner of projects written in VB that never should have been. Now, the poster did not specify if they were talking about VB ala VB 6, or VB.NET - the two are completely different in so many respects an argument for/against one doesn't translate very well to the other.

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

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

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

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

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

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

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

    Have fun!

    Bryan
    ==
  • Myriad of problems (Score:3, Informative)

    by jasonditz (597385) on Thursday June 01, 2006 @12:59AM (#15442095) Homepage
    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.
  • by NutscrapeSucks (446616) on Thursday June 01, 2006 @01:07AM (#15442138)
    1. VB is not portable.

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

    Although I agree strongly with your assessment of VB server apps.
  • by jma05 (897351) on Thursday June 01, 2006 @01:15AM (#15442168)
    >> You'll be able to mix-n-match C# code.

    Actually you can. The IDE might not support it though.
    http://discuss.fogcreek.com/dotnetquestions/defaul t.asp?cmd=show&ixPost=471 [fogcreek.com]
  • by Anonymous Coward on Thursday June 01, 2006 @01:49AM (#15442304)
    VB.Net and C# are essentially identical.
    The only difference in the real world is that VB.Net programmers are usually the low-skilled guys who can't learn a new language in a couple of days.
    Not at all.

    I consider myself to be a fairly skilled programmer, but I prefer VB.Net over C#, although I code in both, per project team requirements. It's a matter of personal preference over the syntax - some people like to use very verbose languages, similar to English, while some prefer something dense, similar to Klingon. I'd be the happiest person ever if someone made AppleScript.Net :)

    But, as you've said, the languages in question are essentially identical. It's the framework that matters, not the language syntax.

    You can't learn VB.Net and not know C#, and vice versa, as the differences are something you pick up in half an hour. There's an equal number of crap VB.Net and C# programmers out there, and prefering one language over another doesn't make you better or worse at your job. It's a flawed analogy from the very beginning, as the difference between VB.Net and VB6 is *extremely* large. It's a whole other universe, and it's not like all the VB6 programmers just switched to VB.Net one day - that's impossible.
  • Interpreted? (Score:1, Informative)

    by Anonymous Coward on Thursday June 01, 2006 @02:12AM (#15442416)
    .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.

  • by brick_in_the_wall (924014) on Thursday June 01, 2006 @02:13AM (#15442418)
    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).

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

    The move from VB6 to .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.

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

    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.
  • by Anonymous Coward on Thursday June 01, 2006 @02:13AM (#15442421)
    Lots of good points, but also a few corrections...

    Visual Studio doesn't include a dev version of IIS - it's based on cassinni. And not only in the pro edition - the standard and express versions also have it (all of them do).

    And SQL Server Express is toally free, whether it's bundled in whatever edition of VS you're using (BTW, SP1 is out, and there are some new downloads for the express ed - oh, and new Books Online too). There are also free editions of Oracle and DB2 (and PostreSQL is free, and ...)

    Why VB.NET/C#? Indeed MSIL and interoperability (different languages). There are a bunch of others if you ever want (F#, IronPython, etc).

    -Full OO goodness. That's a major plus in my book
    -Not end-of-lifed. Not only you get bugfixes, but also improvements - and a bright future for the dev platform (hence for your apps)
    -No DLL hell (and tons of win32 apis you gotta know and all).
    -A *MAJOR* selling point too is the extra stuff you can get. With VB6, you got VB6 and that's pretty much it as for tools. VB.NET/C# wise, there are metric FUCKTONS of wicked great stuff... From ORM tools (NHibernate, DLinq, LLBLGen, - dozens of them), code generators (MyGeneration, Codesmith, ...), lots of the good stuff we see in the java world (NHibernate, NDoc, NCover, NUnit, NThis, NThat...), great TDD tools (TestDriven.NET, NCover, ...), loads of great libs (like the Enterprise Library and WSE 3.0), AJAX libs like Atlas (if you're suckered into the web 2.0 thingy), many many wicked 3rd party apps (VisualAssist X, Jetbrains Resharper and DotTrace, etc), decent SCMs are available or can be integrated (CVS/SVN/Perforce/VSTS/whatever you like), etc.
    -A half decent IDE that's out of this century (VS6 is teh suck big time)
    -Another GREAT plus in my book is the ability for the code to be ported to either Mono, or to J2EE using tools like Grasshopper (converts into Java bytecode)
    -More niceties avaialble the day Vista ships (like a built-in workflow framework, and a great enhancement to WS/Remoting/MSMQ/WSE namely - oh, and shiny GUI things too I guess)

    That list could be much, much longer if someone had enough time to spend. VB6 is dead in my book. Legacy code to support? Port it or too bad. I *WOULD* turn down a job that was VB6 coding/maintenance (or keep it temporarily to pay bills as a last resort while I find something else).
  • by Anonymous Coward on Thursday June 01, 2006 @02:14AM (#15442425)
    For debugging, I've found VB6 to be without peer. It's mainly due to the intepreted heritage -- when doing debugging, the language is run interpreted, so the integration of edit-and-continue and the immediate window are seamless. E&C in the compiled languages sort-of works in my experience, but there's still nothing to compare to the power of the immediate window. Not only does it allow you to evaluate more complex expressions than are accessible in, say, the VC watch window, but it also allows you to execute arbitrary code, which can be very useful e.g. for doing a test run of a procedure in the context of a running program.

    (This is one of the main reasons I'm sad that MS decided to kill VB.)
  • by Sycraft-fu (314770) on Thursday June 01, 2006 @02:27AM (#15442476)
    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.
  • by Jugalator (259273) on Thursday June 01, 2006 @02:28AM (#15442482) Journal
    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.

    Just FYI about .NET:

    VB.NET directly supports dictionaries, even by using generics.

    It also suports reasonably powerful regular expressions via the System.Text.RegularExpressions namespace.
  • by adrianmonk (890071) on Thursday June 01, 2006 @02:47AM (#15442572)
    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)?

    Aiiighghghghhhhh!!!! Why, why, why do people keep saying this?!

    Java is a compiled language. The Java source you write gets turned into native machine code. It's just that the compilation happens at runtime, unlike with many other languages where it happens earlier. Same process, different time.

    It's not like this is a new concept. For one thing, the documentation describing it has been up on the Java web site for years. For another thing, people on Slashdot have been saying it for years. And for another thing, LISP environments that do incremental compilation to machine code at runtime have been around for at least, what, 15 years? Some quick googling indicates that language environments that compile stuff to native machine code at runtime have been around since 1968.

    And heck, it's not as if it's even all that high tech or complicated in certain ways. You don't need something as esoteric as the internals of a JVM to see machine code being generated at runtime. If you want to see it happen on something simple, go to your nearest Unix or Linux machine and type "tcpdump -d not port 53". Notice that it spits out machine code? Now try some different filter expressions like "not host 127.0.0.1" or "host 127.0.0.1 and tcp and port 25" and watch how the assembly code changes. Yes, that's right -- even tcpdump compiles code at runtime, at least it does so with the packet-matching code, which is where the speed is really needed.

    So hopefully it's not too hard to comprehend now that modern JVMs do the same thing, and as far as I know, so does the .NET virtual machine.

  • by Ravatar (891374) on Thursday June 01, 2006 @03:30AM (#15442724)
    Wrong, you can use COM+ to call .NET com-visible(which you set) assemblies. An example of that can be found here [execpc.com].

    By the way, in terms of speed .NET has been found to run nearly on par with C++ in many cases, and memory use is sometimes better (although usually similar) thanks to automatic garbage collection.
  • Problems with VB6 (Score:5, Informative)

    by Fat Cow (13247) on Thursday June 01, 2006 @04:12AM (#15442866)
    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
  • by ThePhilips (752041) on Thursday June 01, 2006 @04:13AM (#15442871) Homepage Journal
    > This scares me, but I honestly can't make a good argument
    > 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. .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.
  • by something_wicked_thi (918168) on Thursday June 01, 2006 @05:13AM (#15443027)
    Aside from it being at end-of-life, there are plenty of other, more technical, reasons why VB6 is a bad choice for many projects, especially large ones. I say this coming from a long history of writing and maintaining VB6 code, not because I have a bias against the language.

    VB was my second language and VB6 does vastly improve the VB experience, but there are several large problems: it doesn't support inheritance (only polymorphism); it is very difficult to use advanced features of the Windows API, it is very hard to debug and profile, and finally, it can lead to extremely unstable code.

    The VB6 language supports a feature where you can implement an interface, similar to Java or C# interfaces, or C++ pure virtual functions. It does not, however, support a method to inherit methods from another class. Thus, you often find yourself writing reams of code to delegate to another class that has a common implementation of various functions. Furthermore, if an interface changes, all the classes that inherit that interface must also be changed. That can lead to a rather large maintenance headache. Furthermore, changing the interface often plays havoc with the IDE's parser, so it can no longer tell which methods on the class are inherited in the Intellisense functions.

    More advanced features of the Windows API require you to copy and paste large bits of function and constant declarations into your code, and you have to jump through all kinds of hoops just to properly use the registry, system tray, or message handlers. I.e. if you want to catch a certain message sent to a window, you have to use SetWindowLong to override the message procedure of the window (you pass in the address of another procedure, which you acquire by calling "Address Of"). There is also all kinds of problems with passing pointers to structs, since you can't get a pointer in VB6. I.e. often, many window procedures require a struct with a pointer to another struct. There are hacks to get that, such as allocating a new memory buffer (using the LocalAlloc API), using CopyMemory to copy the VB struct into the memory location, then passing the pointer you got from the LocalAlloc call in as a struct member, and then using CopyMemory after the call to put the data into the VB6 struct. There are also undocumented functions to retrieve the address of variables, but there is, of course, no way to dereference a pointer, short of copying the data into a VB struct, or doing some fancy copying to change what an object points to (but that plays havoc with the reference counting).

    Next, you've got the instability issues. Using *any* of these features leads to instability. Under normal circumstances, things work alright, but if you try to run the application in the IDE while you've got a custom message handler set up for a window, then the moment you hit "Stop" to end execution, the whole IDE crashes. The reason for this is that the VB6 IDE runs the app inside the IDE's process, so if your app causes a GPF or similar, the whole IDE goes with it. It also makes it a real pain for debugging, since setting breakpoints inside the window procedure often causes crashes.

    Finally, it's very difficult to debug a VB application. If you've ever looked at the assembly output of the compiler, it's absolutely horrendous. Trying to step through it in WinDebug or something similar is just about impossible. The only way to debug it is with source code and full symbols, but even that is rather difficult sometimes. For example, most of the magic happens within the VB6 runtime (just about every VB statement is implemented as a call to the runtime; even assignment), so it's very difficult to follow what is really going on underneath the hood.

    Those are my main problems with it. I also don't like many other things. For example, VB is really slow. Slower than .NET, in my experience. Every benchmark I've ever run has VB losing by at least an order of magnitude. For example, I wrote an MD5 algorithm in VB (no small feat since VB has no unsign
  • by SigILL (6475) on Thursday June 01, 2006 @05:46AM (#15443100) Homepage
    go to your nearest Unix or Linux machine and type "tcpdump -d not port 53". Notice that it spits out machine code?

    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.
  • by patrixx (30389) on Thursday June 01, 2006 @05:54AM (#15443112)
    "Aiiighghghghhhhh!!!! Why, why, why do people keep saying this?! "

    Because they are right, and you are wrong.

    The definition of an interpreted language is that the code is converted to native machine code at runtime. Java is "compiled" into Java byte code. That is correct. But Java byte code is NOT native machine code. It is code that the Java Virtual machine *interprets* into native machine code *at runtime*. So yes, Java is an interpreted language!

    References:
    http://en.wikipedia.org/wiki/Java_virtual_machine [wikipedia.org]
    http://en.wikipedia.org/wiki/Interpreted_language [wikipedia.org] /Patrix
  • by psmears (629712) on Thursday June 01, 2006 @06:01AM (#15443137)
    Yes, that's right—even tcpdump compiles code at runtime,

    While I agree with most of your post, that's not actually true—tcpdump compiles to bytecode, which it then interprets much like a non-optimised JVM. To see this, run the same commands on the same version of tcpdump on different CPU architectures (I tried SPARC and i386): you’ll see the same instructions being generated (you can even check that the compiled bytes are the same, if you use the -dd option).

  • VB's not that bad (Score:5, Informative)

    by HangingChad (677530) on Thursday June 01, 2006 @07:05AM (#15443299) Homepage
    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.

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

  • by S.O.B. (136083) on Thursday June 01, 2006 @07:42AM (#15443426)
    Because they are right, and you are wrong.

    Actually I would say you're both right and you're both wrong.

    Java is neither 100% compiled or 100% interpreted. Java is compiled in the sense that what is executed is not the original source code. The Java compiler has taken the code and produced a bytecode file that is closer to machine code than the original source and as a result executes far more efficiently than a purely interpreted language. Also, because what is interpreted is not the original source code it is not an interpreted language in the classic sense. Although I agree, it is not truly compiled.

    About 10 years ago I was working closely with the IBM COBOL division on their PC compiler and in those discussions they told me that IBM's compilers, and I assume other vendor's as well, are built as a two phase compile. The first part is specific to each language (COBOL, C++, PL/1, etc) and compiles the code to a common internal format. This intermediate code is then taken the rest of the way to machine code by a common back-end compile used by all languages. This way they write a front-end for each language and a back end for each platform they wanted to produce machine code for.

    What Sun has done is take these two steps and separated them. In a traditional compiler both these steps would happen during the "compile". With Java the first step, generating the intermediate or bytecode, occurs during the compile. The second step, generating the machine code, occurs at runtime on the target platform.

    And because the intermediate code generation is the most costly part of the compile process most of the compiling has been done before execution. This is what allows Java to approach native code speeds.
  • by sbrown123 (229895) on Thursday June 01, 2006 @09:33AM (#15444074) Homepage
    The good thing about the .NET languages is that they compile to the same "bytecode". In Microsoft's case, this is the MSIL that runs on the CLR.

    That is not always true. Unless you put the following line in your AssemblyInfo file your class library, it is likely the resulting byte code can not be used by other .NET languages:

    [assembly: System.CLSCompliant(true)]

    Visual Studio 2005 Pro includes a development IIS instance

    It's actually Cassini. The only real nice thing about this is that Cassini is much lighter than IIS and doesn't run as ASPNET user.

    a development IIS instance and SQL Server 2005 Express is included.

    Oh gawd they can keep that pile of crap.

    more toolbox items are available and virtually all of the components are data aware.

    I don't see a real advantage here except that novice programmers may be able to put together a cheap CRUD app. I have yet to see a client actually want only this bare minimum application though.

    There are also some major issues I have found with VS2005:

    1) It is very slow. I think they wrote the bugger in .NET because you can actually watch the thing redraw itself at times. This from a Pentium 4 with a 1G of memory? I fear the day they upgrade to Vista with this bloated beast in tow.

    2) ADO 2.0 looks promising but there seems to be a huge lack of vendor support. Oracle support is still in beta mode.

    3) The database wizard seems to only support Microsoft database connectors and Oracle. There is no way to add new ones.

    4) Visual Studio hides files from the programmers view. I know they did this to make it "easy on the eyes" for novice programmers but it plays hell when your working as a team with a version control system. And when you delete projects or solutions you will find out that they are actually STILL on the harddrive. Its more of a "remove from view" option than true removal.

    5) No Subversion support. There is a plugin called Ankh that does okay but it is limited. I have no idea of any support for CVS.

    6) Partial classes? What the f***! This wouldn't be so bad if .NET used Java's strict file naming convention but now I find that I am looking for these "other parts" all over the place.

    Mono looks more promising and has a larger selection of languages. It also works on multiple platforms whereas Microsoft's implementation will only work on Windows. There is also rumor on the .NET forums that Microsoft will be releasing new API functions to .NET that will only work on Microsoft Vista. If this is true you can kiss backwards capability goodbye.
  • by fitten (521191) on Thursday June 01, 2006 @09:52AM (#15444254)
    a development IIS instance and SQL Server 2005 Express is included.

    Oh gawd they can keep that pile of crap.


    I don't know much about the IIS instance, but SQLServer2005 Express is decent for its intended purpose... a development environment.

    There are also some major issues I have found with VS2005:

    1) It is very slow. I think they wrote the bugger in .NET because you can actually watch the thing redraw itself at times. This from a Pentium 4 with a 1G of memory? I fear the day they upgrade to Vista with this bloated beast in tow.


    Odd, I haven't had this problem and I have a similar system to what you describe (you have no description of your video card, though, but I've used it on Intel integrated graphics on a laptop with few issues. Plus, redraw effects are very subjective. Some who see the redraw actually see it complete in a second, which may be an issue for some but not for others. Anecdotal evidence is fun!

    2) ADO 2.0 looks promising but there seems to be a huge lack of vendor support. Oracle support is still in beta mode.

    In my experience, Oracle support for Windows development environments has *always* been in beta mode.

    3) The database wizard seems to only support Microsoft database connectors and Oracle. There is no way to add new ones.

    I haven't tried, so what you say may be true.

    4) Visual Studio hides files from the programmers view. I know they did this to make it "easy on the eyes" for novice programmers but it plays hell when your working as a team with a version control system. And when you delete projects or solutions you will find out that they are actually STILL on the harddrive. Its more of a "remove from view" option than true removal.

    This depends on which you use. There's a "remove from project" and there's a "delete". "Remove from project"... removes it from the project (removes the entries from the makefile) and that's it... just like it says. The "delete file" option deletes the file (you can look to see that it was moved to the trash can even, if you want.

    5) No Subversion support. There is a plugin called Ankh that does okay but it is limited. I have no idea of any support for CVS.

    It doesn't support CVS. This isn't necessarily an issue with the product. Perhaps you should talk to the 3rd party suppliers of those products to ask for plugins, instead?

    6) Partial classes? What the f***! This wouldn't be so bad if .NET used Java's strict file naming convention but now I find that I am looking for these "other parts" all over the place.

    Don't use them if you don't want. I personally don't like using them, either, so I don't use them. I personally dislike Java's strict file naming rules/conventions for a number of reasons.

    Mono looks more promising and has a larger selection of languages. It also works on multiple platforms whereas Microsoft's implementation will only work on Windows. There is also rumor on the .NET forums that Microsoft will be releasing new API functions to .NET that will only work on Microsoft Vista. If this is true you can kiss backwards capability goodbye.

    That's "forward compatibility", not backwards. Backwards compatibility means that Vista will run XP applications. Forwards compatibility means that XP will run Vista applications. There are few systems that support forwards compatibility. Did Linux 2.4 support forwards compatibility with all 2.6 APIs, for example?
  • by IngramJames (205147) on Thursday June 01, 2006 @10:48AM (#15444848)
    The only "penalty" for using VB6 when it comes to speed is really the memory footprint of the VB6 runtime DLLs.

    Try this:
        - Write a very simply object in VB with just a few properties that can be set.
        - Write the same object interface in C++.
        - Write a test harness which instantiates and then releases 1 million of each type
        - Compare the results.

    C++ allocates and deallocates COM objects an order of magnitude faster. If you're working with lots of instances of tiny objects, then using C++ will increase your performance dramaticlly.

    But doing a GUI in C++ is like pulling your teeth one by one without pain killers while a large dog mauls your left knee.

    Mix and match the most appropriate tools for the job in hand.
  • by mikaelhg (47691) on Thursday June 01, 2006 @11:02AM (#15445016)
    Project Semplice [sun.com] brings people with Visual Basic skills to Java the cost-effective way.
  • by TrueSpeed (576528) on Thursday June 01, 2006 @11:11AM (#15445112)
    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.

"I have just one word for you, my boy...plastics." - from "The Graduate"

Working...