First VB gets the axe. What's next COBOL?

First VB gets the axe. What's next COBOL?

Summary: Perhaps the moral of this story is that you can't teach a dog new tricks. Particularly these old dogs, who, like my old dog, bite back if you don't handle them just right.

Perhaps the moral of this story is that you can't teach a dog new tricks. Particularly these old dogs, who, like my old dog, bite back if you don't handle them just right. After all, you can't read Matthew Broersma's report about how more than 100 Microsoft Most Valuable Professional (MVP) developers are asking the Redmond-based company to reconsider its plans to end support for the pre-.Net form of Visual Basic without concluding that going from the old VB to the new VB is, for all intents and purposes, a new trick.

How much of the older generation VB is out there in numbers of lines of source code is unknown. But according to the report, 45 percent of all North American developers (including yours truly) continue to use the non-.Net versions of VB. The footnote is that 34 percent have used the .Net version. But that says nothing of how many lines of code either group is responsible for. So putting our fingers on just how much of that legacy code out there can't cross the gap to VB.Net isn't clear. But the "experts" seem to think it's significant.

According to Evans Data analyst Albion Butters, "One of the main issues keeping VB6 and earlier developers from making the migration to VB.Net is the steepness of the learning curve....The difficulty in moving existing VB6 apps to VB.Net is, in some cases, insurmountable."

Broersma's report quotes developer and author Rich Levin as saying "The .Net version of Visual Basic is Visual Basic in name only....Any organization with an investment in Visual Basic code--consultants, ISVs, IT departments, businesses, schools, governments--are forced to freeze development of their existing VB code base, or reinvest virtually all the time, effort, intellectual property, and expense to rewrite their applications from scratch."

Cries from the MVPs haven't gone unnoticed. Paul Vick, Microsoft's technical lead for Visual Basic .Net wrote an empassioned response in his blog, offering details of how the two architectures are so different, that it's technically impossible to keep the old VB going without maintaining an entirely separate (from Visual Studio .Net) development solution. In addition, the company is throwing its weight behind managed code solutions like Visual Studio .Net versus the unmanaged nature of the older VB.

In their petition, the MVPs asked that, in the same fashion that Microsoft continues to support C++ while also evolving C# as a part of the .Net family, that the same should be done for VB and VB.Net. Wrote Vick in his blog, "... the architectures are totally different and, in many ways, incompatible. Heck, we spent four years getting VB .NET integrated into the Visual Studio shell and we were writing it from scratch (and therefore could design a compatible architecture)!" After talking about how any extension of the old VB's life is just inviting a more painful conversion down the line, Vick

Topic: Software Development

Kick off your day with ZDNet's daily email newsletter. It's the freshest tech news and opinion, served hot. Get it.


Log in or register to join the discussion
  • no one wants to use .net

    so ms will try to kill the options, bad move ms
    • W.G.A.S.

      Were you reading a Y2K prediction of COBOL's demise?
    • It's not a matter of liking it

      Would you like MS to continue to support VB-16 as well? Get a life and learn the new model!
    • at least no one that you know

      your statement is a bit of a generalization and probably limited in scope, don't you think?

      I know large groups of people that refuse to use VB, does that mean that you don't exist?
  • Another example

    This is just one more example of the drawbacks of closed source software. If the code were open, no one company could dictate the shelf life of the product. What a shame.
    • RE:Another example

      Exactly! I couldn't agree with you more....
    • wrong

      As the examples stated of C++ and COBOL the problem was that VB was a propriety language, not because it is closed source.

      C++ and COBOL are not open source and are a live and well. Don't get confused by the OSS rhetoric
  • COBOL, and software in general...

    ...will never die as long as there is some purpose to it. We use some Gawd-forsaken DOS program named TValue, but it works, and that is what matters, right?

    My Comp. Sci teacher says the real reason COBOL is still around is because of the way it handles money and financial transctions and whatever, I really didn't pay that much attention becuase after all it was COBOL.

    Also, just becuase something is not fashion of the moment does not mean it isn't as efficient or as good as anything new, or even still better. Didn't one of the recent Apple clusters down in Mississippi or somewhere get built just to handle Fortran calculations for jet fighter engines? Fortran, isn't that carp of a language dead yet?

    I think if they want to drop support for the easiest to learn, quick application building, easy to maintain WHEN DONE RIGHT language; then let them. It could open up one more possibility for the OSS people to take another inroad into the territory of M$. Eclipse should take this as a possible avenue to pushing VS aside, don't they have an aspect project in the works, I think they should target former VB'ers (pre-.Net) to move them over, they don't, as I have "usually" found, have formal training but are very good at making LOB apps.
    • Fundamentally there is nothing wrong with COBOL ...

      If it solves problems, then it has value.

      The real problem is that there are newer languages that require less effort to create and maintain software. If you don't explore them, how will you ever know?
      George Jay
      • Whatever happened to

        the FREE COBOL to C++ converter tool? Really, COBOL is very old - but there are TRILLIONS of lines of code there. Very hard to kick a 30 yo habit - ask my wife about her smoking . . .
        Roger Ramjet
      • Yes and no

        If something does the job, but other things can do a better job with less effort, that does not negate its value. But I'd argue that it's a fundamental flaw if it requires more time and effort than something else.

        Although some COBOL programmers I knew were in love with programming, few were in love with COBOL. There were exceptions. I knew one guy who wrote COBOL programs to deal with bitstream data. Back then, we got data from telephone switches, and the data did not fall on byte boundaries. It was easy in PL/I, and doing it in COBOL was like trying to prove that if you have a table saw, you don't really need a router. (The woodworking kind, that is.)

        If you can do that in COBOL (which does not let you address individual bits) you can probably do just about anything to manipulate data.

        The real reason that most programmers back then did not explore other languages was that COBOL was their job. They did not have the option of installing or using a different compiler, nor did they have a PC. Whatever was on the mainframe is what they used, since it's what their boss told them to use. Sitting down and learning C++ was not an option.
  • I've been on two multi-million dollar VB.Net projects ...

    That have been complete disasters. Why? Because the developers thought they were doing Object-Oriented just because they were successful in developing in .Net.

    In one case the budget was $3 million and when they were done, $9.5 million was spent. In another case, the resulting code base was completely unuseable in subsequent iterations ... aka completely useless.

    You have no choice but to understand OO before you make you .Net transition, otherwise you will rewrite your VB6 to VB.Net applications twice. Once because you wrote your first VB.Net application based on VB6 experience, and a second time to write the VB.Net application correctly according to OO approaches so it can be maintained.

    If your existing resource base has no OO experience. You either train them right to be OO or you chuck them. Sad to say, but most non-OO resources will take years "to see the light". Until then, you're throwing your money away on OO technology like .Net
    George Jay
    • Two sides to it...

      OO has it's advantages, but it has some real negatives too. Code bloat being one, and always having to build work arounds when the object doesn't do quite what you want.
      • No_Ax, no_more, please

        ..OO has it's advantages, but it has some real negatives too. Code bloat being one, and always having to build work arounds when the object doesn't do quite what you want....

        What are you talking about, your personal forays with .Net?
        That doesn't make it true.
        You sound like a Slashsnotter expert on something they nothing about.

        If you're objects don't work right then they weren't designed and/or implemented correctly.

        As far as code bloat, even Bill Gates has moved on from the 640K limit.
        Have you considered assembly?

        • speaking of assembly

          ever look at the assembly code an optimizing compiler generates from OO code? Ever try to find the objects?
          • ... Why Do You Care?

            >> ever look at the assembly code an optimizing compiler generates from OO code? Ever try to find the objects?

            Yes, I have. Last time I looked, I found that MS Visual C++ could generate code nearly as tight as C code. And the last time I looked was over five years ago, so it may have improved.

            More to the point, what kind of work are you doing that makes you care what kind of code got generated? In most of the work I've done, it's more important to optimize the development process than to optimize performance. In Process Control applications maybe not so much.

            John Saunders
    • That's engineering 101

      ...Sad to say, but most non-OO resources will take years "to see the light". Until then, you're throwing your money away on OO technology like .Net...

      Absolutely agree.
      Transitioning to new technology os risk laden and must be thoroughly analyzed.
      It is not for all cases.

      BTW, I was on a project that was collapsing half way through due to every conceivable mis management you could imagine.
      I don't know the exact millions lost but that's why us consultants charge by the hour.

  • VB is commercial, COBOL is ISO.

    Th following are held by international standards bodies (most are 2004 spec):

    [b]Fortran is ISO/IEC 1539-1:2004
    COBOL is JTC1/SC22/WG4
    C is JTC1/SC22/WG14
    C++ is JTC1/SC22/WG21
    C# is ISO/IEC 23270
    CLI is ISO/IEC 23271
    CLI TR is ISO/IEC 23272[/b]

    VB is a commercial product form a single for-profit company, Microsoft. In order to continue revenue growth and push to the "new" platform (.NET was available as an add-on for Windows 2000 and XP) and a new way of developing web applications (Web Services) Microsft came up with VB.NET. This is just progress on something that is held by a commercial entity.

    People should stop making such a big deal out of this. If you want to make your money from keeping legacy applications alive (say VB6 stuff), all the more power to you. If you want to go for more modern applications (say, those using Web Services) then you go with VB.NET (if you do VB). Why is this so had to grasp?
    • Your history lessons SUK and have no place here.

      Who the frell cares about you understanding the history of COBOL? Answer, abosolutely NO ONE. Please, next time you want to give the world a history lesson according to you, DON'T DO IT.

      It's not hard to grasp at all, but what you fail to grasp is that there is an unbeleiable amount of code base out there that must be maintained and updated. You also seem to be oblivious to the problems this causes with VBA add-ins, of which there are millions.

      Let me ask you this. Say you are going to write a VBA add in next week. Do you write it in VBA or in some half baked version of .net? Keep in mind the vast majority of the installed base does NOT have the .net framework installed and you must force your users to make a 20+ meg download and install for it to work, and that is ONLY if the OS allows it.

      Ok, so your answer is .net, fine, as long as your willing to write off say 80% of all installed systems as potentical customers. Oh and before you say it, you can bet your bottom dollar the next version of applications (MS Office) won't support add ins written in VBA, heck it's already happening with Office 2003. (many features can not be accecessed with VBA.)

      I had a client just this week that bought a new mouse. The driver was only about 60K. Guess what? Yup, it required the download and install of the .net framework to make it work. Care to ask me how pleased he was about doing it???
      • It's the difference between commercial and internatinal standards.

        If you don't grasp what it means to be a commercial product v. an international (ISO, ECMA, IEEE, etc.) standard, that is your problem. Since Microsoft completely owns Visual Basic and VB Script, they can do what they want with it (including abandon the older stuff for .NET and managed code or whatever they are calling it this week).

        If you are bothered because you are now just supporting legacy systems, that is also just your problem. I gave the 2004 standards from ISO and ECMA (includes C# and Fortran, Fortran and COBOL have 2004 standards).

        There are many small companies you can go cry to (as you appear to be beyond whining) including: Microsoft, IBM, Oracle, BEA, Ford, Deimler-Christler, Royal Dutch Shell, Generla Electric, etc. It would appear that you are refusing to adapt to change and are only supporting legacy systems now!

        Did you cry when Microsoft changed the BASIC that they dsitributed from 1976 to 2001? If not then why cry now?