Slashdot Mirror
COBOL Comes To Visual Studio 2015
New submitter dmleonard618 writes: Micro Focus isn't writing off COBOL just yet. The company is trying to win developers over with COBOL with the latest release of Visual COBOL for Visual Studio. The new solution aims to bring back the ancient language and make it relevant again. "Visual COBOL for Visual Studio 2015 is the next generation of COBOL development solutions, designed for today's application developer to do just that, in a productive and cost-effective way," said Micro Focus' Ed Airey.
while there are some ancient systems still out there requesting the odd COBOL programmer
Trillions of dollars worth of code is written in COBOL. Every time you make a monetary transaction, it involves a system running COBOL.
do they actually expect COBOL to make a come-back?
Over a billion new lines of code is written in COBOL every year. It's here to stay.
"First they came for the slanderers and i said nothing."
Over a billion new lines of code is written in COBOL every year. It's here to stay.
Of course, that billion lines is enough to add two checks together.
Micro Focus is playing a last man standing strategy. Their company focus is based on keeping companies on the legacy systems for as long as possible. The problem is, most companies have some sort of migration strategy in process, or at least on the pipeline, the cost of operating these legacy environments and handling business changes are started to exceed the cost of maintaining it. As security concerns, changes in business processes, customer expectations of promptness, and connectivity with newer tools become prevalent. Staying on the mainframe, and using old tools or upgraded version of such tools, with a bit of polish to make it appear more modern, is just becoming more of an effort to keep going, the it will be to start over again.
So they are in business because most of their competition changed strategies or went out of business. However dealing with them, I can tell they are feeling the pain, as they are now bossing around their customers, giving them more expensive contracts thinking that they are stuck. (I recently gave them a snub at my current employer, by replacing their tool that they though was vital to the institution, with about 500 lines of python code and 24 work hours, because they were asking too much for license fees). I really don't trust them as a company, they are rather low life.
Now they are the last man standing, in a world where they are needed less and less.
If something is so important that you feel the need to post it on the internet... It probably isn't that important.
Now in plain English and just to the point: .NET languages"
What: Micro Focus offers a plugin for Microsoft Visual Studio 2015 that lets you "to maintain and modernize COBOL systems alongside Microsoft
When: Press Release on 2015-08-20
Who: Micro Focus has recently merged with Attachmate Group, owners of brands like Borland, NetIQ, Attachmate, Novell and SUSE
Why: COBOL is still used in a lot of legacy applications.
An old COBOL programmer that I worked with early in my career described how he got tired of the keypunch operators making mistakes entering his code, so he would do the keypunch himself.
Eventually he said that he just started programming off of the top of his head at the keypunch terminal
He ended up writing most of the programs used at the local department of transportation with little or no documentation
The director allowed it and was stuck with it when he was forced to retire by the local government HR rules
He was back at work a week later as a consultant making three times what he had been at the top of his pay grade
Wherever You Go, There You Are
You're way off. By orders of magnitude. Or maybe you were being sarcastic.
Source. Apologize, anonymous one. I find your lack of faith disturbing.
"First they came for the slanderers and i said nothing."
Visual punchcard
Seek and ye shall find.
Remembering that COBOL was written so your average 60's MBA could write code, there's a decent chance that COBOL will come back. It's terrifying, but it's much more understandable to the finance types than more modern languages.
In recent years about one third of MBAs are scientists or engineers, including many software developers. So there is a pool of traditional (science and engineering) software developers who are financially literate enough to properly implement financial software. The "accountants" don't have to write the code themselves anymore, and neither do the "scientists" and "engineers", as in the 60s. They probably have not had to do so for many decades.
Plus there are (or were as recently as the 80s) "software development" type degree programs that are enterprise focused rather than science or engineering focused. At one university I am familiar with the school of science had a computer science program, the school of engineering a computer engineering program and the school of business a computer information systems program. The former two were pretty much what one might expect. The later was similar to computer science for the first two years, algorithms and data structures for example, but the later two years were focused more on development of large software projects for large enterprise and government. Cobol was still taught and used. My understanding was that it was uncommon for a school of business to have a "software development" type program.
The problem isn't the systems. It's 50 years of business logic embedded in the code that runs those systems. Half of it was never documented, because management needed it Right Now and once it was working they needed the developers on another project they also needed Right Now. Of the half that is documented, most of it has undocumented special cases in it and nobody has a clue whether they're needed anymore or not. And this is where the sticking point is, because you can't configure a canned solution to do the job if you don't know what the job is and there's always parts of it so arcane that the canned solutions just won't handle it (this is usually the final nail in the coffin of SAP projects that actually went long enough to get the basics working).
So the decision's more often whether to spend a million dollars on a new system and keep 100 developers, analysts and the like at $100K/year working for 8-10 years on the new system and keep those 10 COBOL developers working for the same period (because you need the old system working until the new one's at least mostly ready), or just keep the 10 COBOL developers working.