Software Development optimize

Is VB.Net a dead end language?


For a change, let's leave out all the debate as to whether VB.Net is a quality language. What I do know is that, while Microsoft pays a lot of lip service to the idea that VB.Net is a good "glue" language, yet it does not seem to provide it with the same sparkle as C#. Over the last umpteen years, Microsoft has introduced precisely zero new languages to the market at a mass level. I actually find this rather surprising, as Microsoft does a ton of research into languages. Sure, Microsoft puts a lot of support behind VB.Net, but they just are not jazzed about it.

Let's look at the facts. Number 1: Open a copy of any Microsoft funding magazine, and you probably will not see any examples using VB.Net; they will all be C# unless the article is VB.Net specific, and they do not seem to publish many of those. Fact number 2: Have you heard of technologies like LINQ associated with VB.Net? Neither have I. Strike number 3: C# is on version 3; if VB.Net is version 3, no one seems to care. And so on.

But there is more to it than that. The serious development community is not too big on VB.Net. Sure, there are tons of VB.Net code samples and VB.Net programmers out there, but most really cool pieces seem to be in C# and not VB.Net. As many readers are probably aware, I have been interviewing a lot of potential hires lately. The ones that strike me as really "senior" mostly trend towards C# and not VB.Net. Sure, it could be a coincidence, but it might not be.

Speaking of "cool," I read a lot of the stuff that comes out of Microsoft Research. Frankly, it is pretty good stuff. Sure, I don't understand a lot of it, but my level of comprehension is rising. I cannot remember seeing any work from Microsoft Research being done in VB.Net. In fact, I have seen more items discussing F# (then again, it is a Microsoft Research project) than VB.Net. Microsoft's own researchers shun VB.Net. As an example, I looked at a cool set of libraries of thread safe components that do not use locks for ultra high speed performance -- they were written in C#.

When C# first came out, it felt like (and most likely was) Microsoft's strategy was to have a Java knock off to help Java programmers easily transition to the .Net platform. Fair enough. VB.Net is close enough to classic VB for that to be an easy jump for them, .Net already supports C++, so really the only big language left would be Java. My assumption was always that Microsoft would lure the Java folks onto .Net with C# and then not really care. Instead, I see a lot of resources being poured into making C# be not just a Java knock off in syntax, but rather a very exciting language in terms of feature set. C# is no longer simply competing with Java -- it is doing a fairly good job at luring programmers for whom VB.Net just does not cut it.

Now, a moment of brutal honesty: I have never really worked with C# for the following reasons:

  • I have always found myself writing code that VB.Net folks will be maintaining.
  • VB.Net has always met my needs, kicking and screaming the whole way.
  • VB.Net is great for code samples because the syntax is so insanely verbose that no one needs to actually know it to understand what the code does.

That being said, I have read plenty of C#, and I understand it just fine. I am sure that after a few hours of working with it, enough Java memories (there I go again with the "Java knock off" stereotype!) will flood back; plus, my solid understanding of C-style syntax will kick in, and I will feel right at home. I just have little motivation at the moment.

For the time being, VB.Net is my .Net language of choice; F# is winning some of my mindshare; and I need to investigate IronPython for business reasons (I suspect that we will need a dynamic language in the very near future). I am promising myself that I will give C# a shot for the next small project (1 day or less) that I have to work on. I feel that VB.Net, while it will never be EOLed, will not be taken much further than it is now. As my days of my gluing libraries together fade into the sunset and what time I spend coding is spent on R&D of techniques and such, I need a language that is forward looking.

VB was an easy way to hook into the COM components that the C++ folks wrote, just as VB.Net is an easy way to tap into the .Net Framework (and, by extension, the Windows APIs in general). F# is cool, but the commercial support is not there yet. IronPython (last time I checked) does not hook into Visual Studio, which is a major ding in my book. So, C# it is. Am I thrilled? Not really. I like what they are doing with C# but not C# itself. But I feel like I have hit the limits of VB.Net.

J.Ja

About

Justin James is the Lead Architect for Conigent.

96 comments
LenGoodman
LenGoodman

If it is a deadend then so am I. I am a newbe and picked VB because I thought it was a good way to get my feet wet with coding. It appears the only reason for the language to begin with is Microsoft didn't want to correct anything wrong with VB6 and simply had to have something to stuff down the throats of VB6 programmers that was related. From a novice view (I won't pretend to know anything), it looks like Microsoft plans to eventually stop supporting VB in any form. Is that possible?

CodeRay
CodeRay

I know this is an old thread, but regarding the statement: "Over the last umpteen years, Microsoft has introduced precisely zero new languages to the market at a mass level. I actually find this rather surprising, as Microsoft does a ton of research into languages." I'm not sure how anyone could say that... C# was Microsoft throwing their hat into the new programming langugages arena.. and in a huge way! http://en.wikipedia.org/wiki/C_Sharp_(programming_language) That said, I like VB.NET myself. My company uses VFP, so VB.NET is an easy transition. I also like C#.NET, too. Really, once you get past a few idiosyncracies of each language (mainly of C#), there seems to be almost nothing that can be done in C# that can't in VB.NET, or vice versa for that matter. Most of the learning curve is the insanely large/useful .NET framework, which works pretty much the same from any supported language. Moreover, most of the exam certification books that are put out by MS are easily 25-30% thicker than they need to be because MS provides all the code samples in both VB.NET and C#.NET. MS does like to bill VB.NET as an entry level language, and C++ as a power user language, and C#.NET as a good middle ground. I still feel I can do just about anything I want in either VB or C# .NET; so, as long as they keep making and improving Visual Studio, and I can keep affording it, I'll use both... (insert coin flip here).

mail
mail

VB.NET will be supported by Microsoft for years into the future, but it will not be emphasized as much as C# and other new languages coming from Microsoft. Microsoft 'had' to support classic VB developers with VB.NET, otherwise they would jump ship to other platforms. My feeling is that VB.NET is fine if you have a VB background, C# is the way to go if you're new to programming languages. I too have heard from Microsoft guys that most internal work is done in C#. So if Microsoft prefers C# then why not the general market? Perhaps it is a dead-end language, maybe in 7-10 years, but still dead-end.

vbb1964
vbb1964

Visual Basic is the future. It is integrated in everything Microsoft does. It will be around and will become Microsoft's universal language. It will likely evolve quite a bit by then but the name sake will remain. The differences between languages is syntax. They can perform the same basic functions. I wrote my free terminal emulator that you can download at rampart-ssh.com in Visual Basic. It will smoke any other emulator out there while offering more features than most of them.

cameron.duffy
cameron.duffy

The interesting point is that languages evolve and become components in higher order representations. Intelligence and language are intimately bound for without language there would be no intelligent expression. As the humble equivalent of a single cell in this post modern cybernetic mycelium, I can safely say the language is essentially quite irrelevant, at least I have very little trouble in forgetting them since they all seem to do pretty much the same thing, which is to turn electricity into heat. See ya, i'm off to drop some spores.

D0M1N8R
D0M1N8R

This is coming from a teacher of mine but basically VB.NET is a good language to toss together something quick but gives you little control. Those seasoned programmers are going to want to lean towards more control which in turn they can create code that is more efficient. I've only done some entry level stuff on VB.NET and no experience with anything else. Just repeating what the teacher had told me. VB.NET was used for my programming fundamentals class.

uwe.packer
uwe.packer

VB.net is great for kids who wish to quickly drag and drop something together without the need to understand the code. And this is where the value of VB is. I would NEVER use VB to teach anyone programming as it is far too unstructured. Finally someone who thinks like a programmer and not a hacker! Great to see.

Mark Miller
Mark Miller

No I don't think VB.Net is dying. In the .Net world it has been a bit of a "stepchild", but not as much as C++. VB.Net was kind of a disaster when it first came out, because it didn't provide a nice migration path for VB 6 developers. The version with .Net 2.0 is more along the lines of what VB 6 developers liked about the language in the first place. One of the things it has that C# doesn't is the whole "My" namespace, so you can get to common functions easily. C# has gone beyond it once again, I hear from others in this forum, because it has anonymous functions, for example. Not that it does C# a lot of good. It's my understanding that no API functions use them. That's the thing about having a unified API. It has to appeal to the lowest common denominator between C# and VB.Net. There has been some talk I've heard before about C# and VB.Net becoming more divergent in language features as time passes. Maybe they'll pull that off somehow without forking the .Net API. From the beginning VB.Net had some built-in functions and language features that C# didn't have, and still doesn't. My guess is they're doing it by having some supplemental library that only works with VB. Anonymous functions will be added to VB.Net in Orcas. Linq uses anonymous functions to support lambda expressions. If you really want to talk about dead-end languages on .Net look no further than Managed C++, Javascript, and J#. I don't know if Javascript is even in VS 2005. It was in VS 2002/2003. The Javascript support was not for web pages, but for compiled modules/code-behinds. Couldn't tell you why. Maybe they were trying to attract people who had worked with server side Javascript. Native C++ is still used in VS. When VS.Net first came out it was really the only usable C++ on it. You could write .Net apps. in Managed C++, but you had no designer support. That's been fixed in VS 2005, and the language has been improved. The old Managed C++ syntax was verbose and kind of confusing. If you look at the job listings though, even RoR beats it, I bet. Native C++ and VB.Net are still very much needed. Microsoft is not going to dump C++, though it's legacy at this point. MFC hasn't been improved much since VC++ 6. Most of Microsofts apps are still written in C++. IMO VB.Net isn't going to go away for a long while because of COM. It has unique language features that are better at handling it than C#.

dale.wilbanks
dale.wilbanks

"VB.Net has always met my needs, kicking and screaming the whole way." - That sums up the problem in a nutshell. I've never kicked or screamed with C#. In C#, we elevate and dominate.

blair0011
blair0011

Before you write off VB.NET go look at SilverLight. It only supports VB not C# as a dynamic language, i.e. you can inject it into an already running SilverLight app to do different things.

jefferyp2100
jefferyp2100

Not dead, but it should be. Any language that turns off type checking and does not require a variable to be declared before being used should be dropped immediately. Yes, those features can be turned on (Option Strict, Option Explicit) but the default has both those turned off. The biggest problem with VB.Net is it allows programmers to continue to write VB6 code. Most VB.Net code is simply VB6 code that runs under .Net.

BillT174
BillT174

Seems to me that MS pushing C# is more to do with getting folks to abandon java on windows then anything else$$$. I don't think their plan is to get rid of vb.net, it's getting more developers to use it's products. They are a marketing company first and foremost.

jpdecesare
jpdecesare

Short and sweet: the only argument that C# is the way to go is always opinion, that "it's cool" and "vb.net doesn't cut it" and "vb.net doesn't have alluring power". Pete's sake, folks, it's a language. Both C# and VB can do most things we need... it's simply a Ford and Chevy argument, folks. Few minor advantages to each side, although VB seems a bit easier (no case sensitivity and a great My namespace), and with the workloads, who doesn't want easy? Also helps the MILLIONS of VB folks transition into .Net. And, C# has it's advantages, one being a great way for Java folks to transition. I don't program in C#, but I know there must be other great advantages, or it too would be bashed in every blog on the planet. Bottom line: it's not the arrow, it's the Indian. You can program up a storm, and both languages get you there. VB has helped me feed my family well for years. I think it's time we end the philosophical whirlwind, and get back to work... most of us have a deadline right around the corner. ;-)

jasocher
jasocher

Maybe I'm missing something, but I don't really see why MS would kill VB.NET. It's a great language for new programmers to cut their teeth on. If something can draw more users into MS's bubble then it's beneficial as far as MS is concerned. Plus VB.NET can do pretty much anything that C# can do. So what it really boils down to is preference and background. I personally like programming with VB.NET more than C# but that's because I came up w/the BASIC language.

DanLM
DanLM

Microsoft is offering the express edition of various coding languages for free. Their stated purpose in this is to make it easier to bring new coders online. One of the languages that is offered in express is vb.net. Why would Microsoft want to capture a new market of specific type coders by enticing them with a free ide unless they planned on continual support of this language. Ok, that was my official response. ;o) Bloody eh, I'm trying to learn vb.net right now. And you all are telling me it's a dead language. Ah well, I picked up perl late. And that's still around no matter how many people tell me it's dead. I still read that new COBOL is being developed, which was dead my 10th year in working with it. And now vb.... Looks like I'm always behind the curve, but none of the languages have disappeared yet. So, I think I'll just keep going with my behind the curve learning experience using past history as my example. Dan

Tony Hopkinson
Tony Hopkinson

isn't that big a cost. The .net bit is common, so basically all they have to do is parse your vb into IL. Given you are getting through VB.net flipping to C# isn't that much of problem. Trust me if you had to go back to VB6 you'd be pulling your heair out in short order,

mail
mail

The future? Microsoft's 'universal' language? It has too much baggage to become universal.

Tony Hopkinson
Tony Hopkinson

Even after Orcas, it won't do lambda expresssions. Beised it's more about what it can do that it shouldn't, such as allow skipping declaring variables.... Languages are not just syntax, there's semantics and an implicit level of granularity.

metilley
metilley

IMO, VB.Net is still with us because many do not want to learn C# or C++. VB is an easy language to learn and kind of fun too. I think in upcoming versions of Microsoft's Visual Studio, Silverlight, Ruby, and Python, may be offered but in the near future, VB.Net will remain. Microsoft is embracing APL (finally!) but I don't think it will be the same using it in a .Net environment. IMO, APL2 on an IBM mainframe still rocks. Programming on PC's and such, blows. I have yet to see anything (so far) that excites me the way APL2 does.

Tony Hopkinson
Tony Hopkinson

VB.net is much better than that, what it does have to a appeal to new coders is a way of relaxing certain constraints. Unfortunately that can promote some very very bad habits. I find the managed environment a thorny issue on that front. That came about becuase there were too many people messing about with pointers who didn't have a clue, five years on managed execution and there will be less.....

Tony Hopkinson
Tony Hopkinson

into the Dynamic side, to go with IronPython and IronRuby.

Tony Hopkinson
Tony Hopkinson

It was true that you could only execute .net code in Silverlight from VBScript / Javascript, but that's being fixed. What language you used to generate the .NET code didn't matter.

alaniane
alaniane

The problem is that you are not going to write a foolproof language. The argument for doing away with pointers in Java and other languages was that they were easily abused. However, the problem lies not with the language, but with the programmer. You are always going to have programmers who write sloppy code regardless of the language.

MadestroITSolutions
MadestroITSolutions

While I agree with you that type checking and variable declaration are problems, I think this is a result of Microsoft's legacy support policy. Any serious developer will have these two on (or at least I hope) for all projects. I believe they were going to correct this for VS 2005 so you can have them default to ON for all projects but I am not sure... Although you can port your code with relative ease, I don't think you can just drop it in there and have it run.

Tony Hopkinson
Tony Hopkinson

Approachability, it's not that you can't right professional code in it, it's that it's quite happy to encourage you not to.

Justin James
Justin James

None of those were things I brought up, I think. Indeed, I tried to stay away from technical merits, because as you've mentioned, both VB.Net and C# have advantages and disadvantages. My point is really that Microsoft seems to be dumping a lot more work into C#, and I wonder if this signals that VB.Net will fail to get a lot of good features in the future. Microsoft definitely seems to prefer C# in their publications and research, and new features are now hitting C# first, by many many months. That's really my concern. I aqgree with another commenter, VB is the COBOL of this generation, it will linger well after its visibility fades, and it will probably stick around forever. But I have a feeling that in terms of gaining new functionality, it may be headed into the sunset in the future, in favor of C#. J.Ja

darthvader
darthvader

Microsoft are not trying to kill VB, they do realise the benefit of drawing more users in. However a lot of old VB programmers, myself included, prefer C# to the new VB. I have been working professionally with VB since 1996, and having become so proficient, I didn't want to relearn a language all over again, as easy as everyone says it is. It made much more sense to learn C#, which has been quite easy with this new point and click style of programming. VB will still be around for all the noobs.

Justin James
Justin James

... letting it remain tepid. That's why I am currently thinking of it as a "dead end" and not a "career trap". VB and its varients are a lot like COBOL, there is a massive base of it driving so much, it will probably never die, and will be maintained forever, just won't see much innovation after a certain point. J.Ja

mbrandon
mbrandon

Remember that your .NET framework app really compiles from IL - not whatever language you like to write in. C#, F#, VB.NET, Delphi.NET... even powerscript. Yes, some of the languages have semantic access to functionality that others don't. If you need that functionality, and it's not in your primary language, write the layer/library that uses it in that language. Write everthing else in whatever you are the most comfortable in. That's called productivity.

Justin James
Justin James

Dan - Nothing wrong with VB.Net, and it is still an easy way to get into the .Net ecosphere and OOP if you are not already there! BTW, more lines of COBOL get written every year than any other language, so I have read. I am more willing to beleive that more lines of COBOL are in use than any other language. Both are beleivable. COBOL is hardly dead. Neither is Fortran. Don't beleive everything you hear! :) J.Ja

Justin James
Justin James

You know, I keep meaning to check out APL! I still have the links you sent me about 6 months ago, but my queue is so insanely long at this point... :( J.Ja

Tony Hopkinson
Tony Hopkinson

but support. As soon as you started using untyped pointers or unsafe casts, they were exactly that. The compiler / interpreter cannot help you, you are on your own. The poor side of language was allowing you to do it implicitly.

PJfromOttawa
PJfromOttawa

I thought I just saw that Intel also released both a C++ and Fortran compiler to go with its spanking brand new 80-core CPU. Since it would likely be picked up for use in a science/engineering/modelling shop, and a LOT of that code is Fortran, it ain't dying anytime soon. As for Cobol, it's the Jason/Freddy Krueger/Michael Myers of programming languages. I doubt that "more lines in Cobol" bit, though. When did you read that? I can see that being true from 1998-2001 to handle the Y2K scare but not anymore. But being wrong is how I got so smart.

samuel_ervin
samuel_ervin

VB.NET was just another progression just as C# was for Visual Studio. I have been hearing from some Microsoft Folks that VB.NET is being poised to be the XML language of the future right now. They are making it the easy to use XML language for everyone. I don't think VB will go away, but Microsoft sure wants programmers too eventually.

Wayne M.
Wayne M.

I guess across the years, I've personally come to believe that language selection is one of the least important criteria in determining the success of a project. I will agree that OO languages provide better guidance in partitioning code into modules, but the keys to quality code still lie mostly in the hands of the developer. I would also question the assumption that using a more modern language implies anything about the design of the program. I would contend that the choice to use sessionless HTTP in order to implement session oriented distributed applications has lead to far more design complexity and software failures than any language choice. Personally, I would not consider rewriting a working application into a new language with a newer style database to be new development. I personally find it more compelling to make use of the existing data and code to add new capabilities and expose services to other applications. Developers can write good quality code and poor quality code using whatever tool provided them. Time spent on replacing "legacy" applications is time stolen away from providing new capabilities and the latter is what I find exciting about software development.

Tony Hopkinson
Tony Hopkinson

Yes and No. You could prove beyond doubt the potential cost savings in the future of a port to a more modern set up. Sheesh you prove it for a redesign in the same language at 99.999% of places. What you can't do is mitigate the risks of the change itself to the business' satisfaction, so they'll constrain you from doing changes that don't add obvious value to the user. Try this with some of your mates. One person write a a class with some persistence and a simple Form to do CRUD. You can do an MVC pattern if you want. A week later that same person thinks of three or four obvious enhancements and get three of four people to do them, don't tell them what the others are doing. Do that a few times but never give your self enough time to do it by starting again. Log the number of bugs, log how many changes you had to make that you thought 'you' shouldn't have had to. Log how many times you trampled on each other's code, breaking it. Now get someone who up to now has had no involvement and get them to implement a different persistence layer or in a different language, switch from Win32 to XAML, make it web based... Trust me the entire thing will go sh*t faced on you unless you violate the spirit of the exercise.

alaniane
alaniane

The self documentation in Java requires that the programmer add special remarks to the code otherwise you get just a class/method skeleton. The self-documentation in Cobol is built into the language itself. The programmer is forced to document his code just by programming it.

demonhunterii
demonhunterii

But it is my experience that perhaps some things have had their time, and we need to move on. I understand that COBOL and Fortran play an important role in the history of computing, and that long into my career systems will exist that were programmed using those languages before I was even born. I know well that as the landscape has changed so have they. But I can't help but feel that this is a bad thing, that in doing so we take away the purity of the langauge and start to find other uses for it. And when we start to do thing's that it wasn't designed for then we get into trouble. Fortran originally had no recursion, let alone objects. It's design wasn't influenced by making it easy to work with, or understand, but rather making efficient compilers. It wasn't/isn't type safe, has some massivly odd ways of doing things (arrays of length 7, initial letter determining type), and is generally just not a very nice language to work with (again my experience, so don't hate me for saying it) It's current specification is close to 700 pages long, and getting longer. And if I'm not mistaken no-one has yet produced a compiler that complies fully with the COBOL 2002 standard. Can anyone honestly say that this is a good thing? Tony - I put to you that language design is already a serious academic field, that research into semantics, into typing, into complexity and computability have left us in a stronger position than ever to develop languages that are powerful, flexible, efficient and easy to work with. As for my thoughts on case sensitivity, I don't actually think that with good coding style it should be an issue. I for one am not inclined to write MAXSIZE in one spot and MaXsIzE in another. Reusing variable names generally not one of my methods either. Wayne - 30 years may suggest that an application works, but as you point out it may also suggest that people have been to afraid to change because of the disasters that have occured in the past. I know what maintenance means, but after a point it's just like having a machine that you keep adding bits to because you need to keep up with the times but are afraid to try something new. Sooner or later it'll need to be done, and I guarantee that the new solutions won't be written in COBOL or Fortran. Alaniane - Self documenting features can be found in Java and C# amoung others. Again good coding style means that this shouldn't be an issue. Equally a well designed project in VB should be as stable as one in Pascal or as one in COBOL. And there was me thinking that the whole Y2K thing was a result of COBOL code being potentially instable. Yes? Dan - Sorry, I didn't mean to make it seem like I was simply against them because of their age, I do have genuine reasons for my opinions. Certainly they are often based on academics rather than experience, and may quickly change, but at this stage in my life that's all I got going for me really. But learning a bit more about the real world of IT is why I am here. As for the languages I'm into, I'll work with just about anything, even if it doesn't have a very pretty interface. Which is why I might just go have a look at a little bit of COBOL, see if I can wrap my head around it. Thanks for the thoughts by the way. D.

DanLM
DanLM

You feel it should die? Why, you can now code COBOL in o.o. What do you want? Only languages that support GUI? Wonder how many gui languages call COBOL on the back end to acquire their data? The fact that it is self documenting, by design structured, and has consistantly been updated with new development practices lends itself to longevity. Or should anyways. Because it is 30 years old you feel it should be terminated? Have any reason other then it's age? Damn, I'm 47 and have some 25 years in IT. Should I be retired also because I'm not the prettiest face on the block? Want to put COBOL up against any other language for high volume transaction processing? That's what it's mainly used for now, not some pretty interface that offers the blue screen of death. But back end processing for keeping your pretty interface accurate. It's self documenting, structured design, and continual updating to stay with modern development practices lends itself to stay active long after both you and I retire. And I see you are still a student, so that means for a very long time. Which by the way, I wish you nothing but the best. Dan God, I feel old now that I'm looking at this post. Ok, I agree. It's time I retire and made candles.

alaniane
alaniane

Do not underestimate Cobol. One of the reasons it has been around is that it is self documenting. Also, it logically divides the functionality into different sections. Many of the apps written in Cobol have been stable for decades. It's hard to say the same for other languages.

Wayne M.
Wayne M.

30 years of operation certainly implies that an application fits well with its intended use. Also, some of the biggest project disasters that I have witnessed have been attempts to rewrite legacy applications into "modern" languages and technologies. The current trends in the application of computer programming are concerned far more with the interoperation of computer systems without regard to the individual languages in use. Much of this is driven by the desire to preserve legacy systems that have proven their worth over the years. Finally, let me clarify what is meant by "maintenance" in computer programming. In our profession, maintenance is not trying to keep a system operating as it did originally, but it is the continued evolution of the system to add new and differing capabilities. Yes, legacy systems are in "maintenance," but that means that there is continued new development being done for them.

Tony Hopkinson
Tony Hopkinson

enhancements constantly for two years, just over two years ago. What design reasons are now obsolete ? What inherrent bad coding styles ? I'd rather programming language development was a serious practical field. Do you consider case sensitivity a technical step forward for instance?

demonhunterii
demonhunterii

Sure 30 years ought to get rid of the bugs, but it doesn't rectify design decisions. Some languages have been designed for reasons that are now obsolete, and using them is simply prolonging both a language that should have died and the bad coding styles that are inherent with writing in it. I'm sure a lot of code is still written in COBOL and Fortran, but I pray it's simply for maintanence. We've moved beyond them, programming language development is a serious academic field, and these languages should be left to die. Irrelevant to the main part of the thread, but felt it was important to say...

Justin James
Justin James

... a COBOL.Net, from Fujitsu, if I recall. Yes, those proven, exisitng install bases will be so expensive (and risky!) to replace that there is little point. I mean, some of them have *30 years* of maturity, that is a lot of time for every darn bug to have gotten worked out. Cheaper and safer to train people to work on the old system then attempt to replicate it. J.Ja

Justin James
Justin James

I have seen that floated in a few different sources (cannot recall any off of the top of my head), but it may very well be an urban legend. I have heard (and certainly beleive) that 75% of financial transactions pass through COBOL at one point or another, which is more than beleivable. J.Ja

samuel_ervin
samuel_ervin

I know of a few finacial institutions that still use both Fortran and Cobol as there backends. Where I work now we have C code older than I am around here. I know a few places such as the US Post Office have Assembly language programs running. It will never fail if there is old code out there and someone with a manual and money a programmer will probably have to maintain it. I don't look for any major colleges or tech schools to start advertising any classes for Cobol, Fortran, or Assembly as a degree program today.But those programs will probably be around at least for another 10 to 20 years and then they will still probably lurk somewhere out on the web.

Tony Hopkinson
Tony Hopkinson

don't use PCs for their core business. I was back doing Fortran 77 two years ago, got an email hit from a recruiter this week to go back there. There code base has been steadily growing over the last twenty plus years, millions of lines of code in the one place. The business side is cobol on IBM's, control Fortran on DEC. The investment required to replace it is hideous, PCs are simply office automation and glorified dumb terminals. Hmm Dec.Net anyone :p

DanLM
DanLM

This is the numbers I seen on Wikipedia, but I don't like using this as a source. [i]COBOL is the dominant language for business applications. Over 80 percent of the world?s business runs on COBOL (Gartner Group, ?97). Almost every major industry from financial applications to manufacturing real-time system relies on COBOL. The investment in COBOL technologies, staff and hardware, is estimated to be greater than 5 trillion dollars. [u]Over 180 billion lines of COBOL code are in use today, with an estimated 5 billion new lines added per year. COBOL applications include:[/u][/i] http://www.legacyj.com/cobol/FutureOfCobol.pdf Like I said, the last place I seen that figure was in Wikipedia. But, I don't consider that a good source. All though, who is to say this article is anymore valid. Here is the Wikipedia reference to those numbers also. http://en.wikipedia.org/wiki/COBOL dan

alaniane
alaniane

I doubt that Microsoft or anyone else can do away with programmers. Programming is more than just knowing a language. Anyone is suppose to be able to write a macro with Word or Excel; however, I still have people wanting a macro written for them. The average office worker is not going to grasp how to write a program.