Follow Slashdot stories on Twitter

 


Forgot your password?
Close
typodupeerror
×
Programming

Journal FortKnox's Journal: VB'ers vs. C++'ers/Java'ers 26

Journal by FortKnox
Being a C++/Java programmer for a while, us "OO" types loved to turn our nose at those VB-types. They programmed with a simple language with no regard to quality software practices like OO programming (yeah, its a total stereotype, sue me).
But now, .NET is incorporating OO practices into VB! I have VB guys that can almost explain polymorphism to me! Now what shall us "OO" types fall back on to show our superiority?
The only thing I can think of is Patterns. Its something that is complex and hard enough that most OO programmers need to study it well before understanding when and where to use specific patterns. Any other ideas out there??
This discussion has been archived. No new comments can be posted.

VB'ers vs. C++'ers/Java'ers More

VB'ers vs. C++'ers/Java'ers

Comments Filter:
  • C++ and Java exist on platforms other than M$FT. BillG has to realize that his little empire of IA32 is not the kingdom to own anymore. We are going to have x86-64 desktop machines by Christmas. Unix and its progeny hold large portions of the research and scientific computing world that are completely out of his reach at this point. Java runs on just about any platform and GCC has been ported to an ungodly number of systems. I don't like java personally, but it has done a lot to forward OOP, which is a good thing. C++ had a lot of emotional baggage based on its heritage, smalltalk and the other OO langs were viewed as research toys. Java was somehow able to convince the world of the advantage of OOP, for which we can be thankful.
    • C++ and Java exist on platforms other than Microsoft(sic).

      Does it matter? If 90% of the users in the world run Microsoft operating systems on IA32, then naturally many of the developers (if they like getting a paycheck) will move to that platform.
  • I've coded in Java, but primarily use C# and VB.NET, depending on the project. VB.NET is really quite an improvement over VB6. I always cringed when I had to use VB6 simply because it was so inferior. I blame a lot of the quality problems with VB on late binding and liberal use of variant arrays (aka loosely typed system). VB.NET still allows late binding, but it's almost *tough* to do. Quality still can be a problem but all .NET languages are equally strongly typed and it is *relatively* more difficult to write bad code now, espcially in .NET.

    Dare I say it, but VB.NET programmers are no longer "second class citizens", and a lot of them are starting to realize it, after they learn what OO is (which is no small thing for a typical VB'er).

    Ever since VB6, it was possible to write large and somewhat decent programs. Granted, the quality wasn't necessarily there especially with unexperienced dev shops. However, now performance and VB is not a misnomer. Unmanaged code written in C# or C++ will still have a chance of beating VB.NET out in terms of speed, but the extra work required will not typically benefit the amount of increase in perforamance of using managed code and the GC.

    Of course, no .NET language supports multiple inheritance, but neither does Java. So I guess there won't be too much to put VB'rs back down until some new features come in :)

    C#, Managed C++, and VB.NET, (and a dozen other CLI compliant languages) all compile down to the same byte code (aka MSIL). Since that is the case, at least on the MS platform, there isn't much difference in what language one uses.
  • I can't even envision the types of improvements that have been described as part of VB.NET. Quite frankly, I have my doubts that VB will ever be useful for my purposes because of my experiences with VB6.

    Put plainly, there will almost certainly be too much VB in VB.NET for me to ever think that it will be useful aside from quick projects on the Win32 platform. For anything larger, there's always C/C++. There's a reason it's still the application language to code in, and I don't see that changing anytime soon.

    It is nice to see VB get the new features, and Interfaces is a much needed addition, but no matter how many features you add on to it, you still have the original plumbing. I don't see VB.Net fixing any of my major problems with the language, just adding on more candy features for people to play with while still making things deceptively easy to code on the Win32 platform (just like Visual C++ makes it overly complex!).

    I remember trying to code a dialog based app with ActiveX controls back in 1999. It was a pain in the ass. Part of the problem was that the ActiveX control didn't mate too well with VB in places (the object model it used was horrid, but then again...so was VB6's), and the other problem was making VB try to do things with dialogs that Microsoft didn't have the foresight to think of in the first place (so you had to resort to doing the GDI stuff, yourself).

    I think VB6 has forever soured me on any future potential that Visual Basic has. But for those of you out there who do use it and like it, I hope the new version has made, at least somethings, a lot easier.

    • It's funny (and not) that Cliff's experience with VB is normally what I hear from C++ or Java consultants that had to do something quickly in VB for a client. VB has this negative image as a toy language that serious programmers wouldn't touch. No matter what they do to VB, it will always be this way.

      I see the grand scheme from Microsoft not behind VB but on C#. C# was written from the ground up to mimic Java, yet correct some issues that developers were facing with Java. Microsoft wins when people move away from C++/VB and towards C#. To encourage this move, VB.Net becomes more like C#, in terms of programming concepts. VB.Net is the slow upgrade path VB developers can follow if they don't want to jump right into C#. VB.Net has a place, for now. Just don't expect it to be the next language of the future.
      • I believe in the opposite of what you are saying (although you do make very valid points).

        I think C# has been made to lure Java folks over. Then they try VB.NET for a quick project and realize its flexability and built in OO. Soon, C# is no longer needed, because, as glh has pointed out, almost everything you can do in C#, you can do in VB.NET and save yourself a lot of lines of code.
    • I don't see VB.Net fixing any of my major problems with the language, just adding on more candy features for people to play with while still making things deceptively easy to code on the Win32 platform (just like Visual C++ makes it overly complex!).

      Aye, there's the rub. You weren't coding to Win32 in the first place. VB's core principal was to hide the complexities of the Win[16|32] API. As VB became more popular, that principal went from help to hinderance, as you no doubt discovered when you had to make direct GDI calls. You also saw that, in VB6's eyes, some ActiveX controls were more equal than others. VB6 was only about 90% compatible with COM, either by design or bug. In the end, it was all 4GL bindings for a small cross-section of an API born and bred for C. Outside that cross-section, there be dragons.

      With VB.net, however, there's no more abstraction between the language and the underlying API. You are no longer writing to Win32, but to .net. You don't have the original plumbing, except on a superficial level. Now, instead of wrestling with hDCs and figuring out which GDI functions you need to Declare, you just import System.Drawing, handle the Paint event, and start calling methods on the Graphics object passed to the event handler. There are still esoteric bits of Win32 still not implemented in the .net Framework, but I wouldn't argue with the assertion that anything left out is probably best left behind.

      • With VB.net, however, there's no more abstraction between the language and the underlying API. You are no longer writing to Win32, but to .net. You don't have the original plumbing, except on a superficial level.
        I understood this would happen when I first started reading the descriptions of .NET, waaay back when. Now here's a question (and one asked in a recent Ask Slashdot that didn't make the grade):

        What if I don't want to write to .NET and (for some strange and insane reason) do want to write to the Win32 API? Is (or has) Microsoft planning (or already planned) to obsolete Visual C/C++ for C#? It would make sense, in a weird, monopolistic way. Think about it for a second: why use a standard language to develop for? Why not move all development on the Win32 platform to languages and APIs that you control, completely? Of course, I can see inertia making this a different proposition to implement, but if Microsoft does make this move, surely most of the developers will follow...hurting themselves in the process if they do.

        The whole prospect of developing on the Win32 platform sours me. I've spent endless hours during my first stint as a Windows C/C++ coder, only to move to VB and find myself frustrated by the "best-of-breed" development environments and for that platform (no, the Visual Studio series did not impress me, overall...some nice features there, particularly for debugging, but most of it I can do without and still be effective). Mostly I didn't like Visual Studio's idea of a build environment (why project data is stored in binary form I do not know) and Source Safe was particularly useless.

        • What if I don't want to write to .NET and (for some strange and insane reason) do want to write to the Win32 API? Is (or has) Microsoft planning (or already planned) to obsolete Visual C/C++ for C#?

          Microsoft may shoot themselves in their collective foot with alarming regularity, but ending support for the Win32 API would be shooting themselves in the head. There's far too much legacy code to simply abandon at a whim. You won't see it anytime in the next 5 years, at least. Linus would sooner translate the kernel to FORTRAN. :-)

          • Microsoft may shoot themselves in their collective foot with alarming regularity, but ending support for the Win32 API would be shooting themselves in the head. There's far too much legacy code to simply abandon at a whim. You won't see it anytime in the next 5 years, at least. Linus would sooner translate the kernel to FORTRAN.
            Well, not having a copy of Visual Studio .NET, I can't go and look for myself what the language that is best supported by the environment is. In Visual Studio 5, it was Visual C++, In VS6 it was Visual Basic, I hear in VS.NET it is C#. You don't have to remove support from a language to effectively kill it, just moving the focus of the IDE in favor of another language is enough.

            Mind you, this wouldn't stop anyone from developing more apps using the language or debugging old ones.

  • Err (Score:1)

    by Com2Kid ( 142006 )
    How about that VB is fucknuttity in a large variety of ways? Though vb.net isn't /quite/ so stupid, VB as a whole. . . . **shudders**

    Err, oh yah, and the fact that VB started out as a teaching language doesn't help matters any, no wait it wasn't even that, it is a simplified form of a teaching language. VB is like BASCI for Dummies. . . . though a lot of more 'advanced' features have been kludged on after the fact.

    OO is a tool, a way to think about things. OO is there because the human species is too stupid to comprehend as much information as is in todays bloatware^H^H^H^H^H^H^H^H^Hsourcecode, and so a simple way of breaking all of that information down into nice bite sized pieces is necessary.

    Quite frankly a programmer who was capable of just thinking out near infinite complexity of code in ASM/Machine code could kick every bodies ass and single handedly put at least 1/2 of the software industry out of business. . . . (the remaining sector being needed to port shtuff and make cross platform software. :-D )
  • The only thing I have ever used VB for is a quick and dirty CGI for an IIS intranet server. Anything more serious and I use Java. CGI is EXTREMELY easy in VB, and then you can copy most of your file handling code over and make a little data file viewer for what your CGI is writing. But for anything I'm going to spend more than a few hours on, I'm going to use something OO.
  • Its not natural. (my fear or the language)

    Any programming language in which an (java/tcl) app takes 20-30 seconds to load into a command prompt is just wrong. WRONG. okay, thats websphere, but it's written in java and it's WRONG. My servers (which are configured correctly, thank you) jump 2 points on the load average when i even THINK about loading java. I tell you, its just not natural.

    okay, so its the greatest thing since sliced bread for some businesses. and it's from sun. But that doesn't make it right. Sometimes, even sun does the unforgivable. For instance, adopting linux to partially fill the "void" left by Solaris x86 (Which may be revived).

    I feel like my new websphere server should have been shipped with a Pastor, Priest, and Rabbi. :)

    Sorry, im just a fan of compiled apps. The bottom line is i can start a 60K compiled app immediately, and i have to wait a number of seconds for java to load the vm, parse the java code.. Im not a programmer and don't know much, but, from a my 10,000 ft view, it just -seems- slow.. Someone please tell me otherwise?

Slashdot Top Deals

Lots of folks confuse bad management with destiny. -- Frank Hubbard

Close