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.
Naming things "Visual X" is so last century. Follow my advice, wait until they come out with cobol dot NET 3.1 for workstations and the cloud. All the cool kids are on the cloud these days, don't jump on the bandwagon too early.
"First they came for the slanderers and i said nothing."
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."
I have a bad feeling about this.
Image and virtualize it
“He’s not deformed, he’s just drunk!”
To everybody who is going to be bitching about how dead COBOL is:
http://skeptics.stackexchange....
I'm glad I'm no longer involved with any COBOL code, but my 10+ years of COBOL programming has left me with the impression that it's not going away any time soon.
Slashdot social media options: AIM, ICQ, Yahoo, Jabber and Mobile Text. Why no MySpace?
MicroFocus has been trying to decades to get people to use COBOL off of the mainframe, but haven't had much luck. They must have enough big clients to stay around. In the 90s, they tried to get people to do development on PCs, and it went nowhere. COBOL these days is tightly tied to IBM's stack of stuff like CICS, DB2, etc - by the time you replicate all this on a PC, you're not buy yourself much. And most old-school programmers would rather use the ISPF editor anyway. (Let me guess, there's an ISPF mode for VS2015?) Anyway, we see MicroFocus in the news every year or two with a story like this. They'll keep doing it until they finally fade away for good.
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.
Oh come on. Really?
I had an employee who worked part time 20 hour here and 20 hours for another company leave within the past 2 years to train for a COBOL job. He's making six figures now. I think the idea that COBOL is dead is laughable. We're losing COBOL programmers left and right because they're all retiring or dying off, but COBOL is still here and is commanding a premium salary. While 10 years ago it seemed everybody was trying to jump ship the reality is it was largely an utter failure. Companies who tried largely failed. They'd spend millions of dollars on a new system that ultimately didn't work and I think this was repeated all over the place. These systems have taken 50 years to get here and companies think they can spend 3-5 years replacing them? It's just not happening.
My ex-employee now makes more than I do coding for COBOL as far as a salary goes even if my total net worth might be higher due to owning a very successful company. Usually people in my position try and take a low salary for tax reasons. I'm actually probably not taking that low of a salary relatively speaking, but... in most cases CEO's of smallish companies at least will.
Seriously, Slashdot? How is this news? There have been *multiple* COBOL implementations for Visual Studio since at least 2002. Fujitsu and MicroFocus both have implementations that are not only native but also can compile down to .NET bytecode and integrate completely with the CLR. They even have designer support for visually creating UIs and web pages.
Could you be any less relevant, Slashdot? Olds for Nerds, shit that mattered over a decade ago?
I'd rather write java code with hot needles sticking out of my eyes.
Not if you're over one space too many.
I wouldn't want to start any new projects in COBOL, but if I had millions of lines of legacy stuff on my hands, I'd be pretty excited about the prospect of putting it under the magnifying lens of a modern IDE and interactive debugger.
And a quintillion lines of code is written in each and every other language than COBOL every day.
Puleeze. What a load of ineptitude. "Over a billion new lines of code is written in COBOL every year."
ADD ONE TO INEPTNESS GIVING COBOL-UBER-ALLES
While COBOL is not dead, claims re: the quantity of COBOL being newly written are lies, having been a compiler engineer at Liant (LPI-Cobol && RM-Cobol).
Y2.038K is coming, and as we saw with Y2K, companies will wait until the last minute and then scramble to make sure their code handles the clock overflow properly.
COBOL programmers (if there are any left by mid-2037) will probably make a lot of money for those six months.
Compiled Only Because Of Luck.
In seriousness, I've only heard medicore things about it - is it worth trying to learn it for the rare chance I could land a COBOL position?
So a business decision.
Spend a million dollars for a new system or keep 10 COBOL developers at 100k each for a year?
We are getting to a point where things are crossing over and it is getting cheaper to migrate.
Open Source Database engines, Cheap cloud computing solutions, programmings languages that allow for more rapid design... BPM, CRM, and a whole set of Alphabet soup solutions available canned to replace those custom jobs... It is a different world out there, and they are tradeoffs with some major problems, but changes none the less and expecting to stick on COBOL unless you are planning on retire in a few years is a loosing battle.
If something is so important that you feel the need to post it on the internet... It probably isn't that important.
You're way off. By orders of magnitude. Or maybe you were being sarcastic.
It's just a very very old one.
Fortran - which is still in wide use - and Plankalkül (not so much) are older.
Knowledge is how to play a game, intelligence is how to win, wisdom is knowing what game to play.
c language 43 years old, c++ 32 years old, basic 51 years old, fortran 58 years old, sql language 41 years old, and cobol 56 years old. How can people say cobol is an obsolete language when the primary languages c/c++ which are pretty damn old are still used today.
I remember trying out something like this many years ago with Fujitsu COBOL. It was just like Visual Basic, except when you opened the code editor for the buttonClicked() method for example, you coded a COBOL procedure rather than VB. Weirdest thing I had come across in a long time. Never did end up using it on anything productional.
'The tyrant will always find pretext for his tyranny.' - Aesop's Fables
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.
I guess this article struck a nerve with c language extremist.
Perhaps MS will include Visual MUMPS in the next release of Visual Studio.
Do what thou wilt shall be the whole of the Law - Aleister Crowley
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."
And in Java you would have a billion lines of code show in the stack trace debugger for adding two checks together
http://saveie6.com/
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.
Visual Brainfuck, while we're at it. No but seriously, while there are some ancient systems still out there requesting the odd COBOL programmer, do they actually expect COBOL to make a come-back?
Considering Java nowadays is radioactive as fuck, yes COBOL seems like a good alternative.
Of course it will be anathema to most hipster programmers that change a language every other day.
Maybe Visual Lisp will be next... oh, wait: http://autode.sk/1PsAwTO
I made a shitton of extra money in 1998/99 during college, via y2k/cobol contracts. People would just come to the school and if you knew how to even declare variables, you could make $50 USD/hour.
Thing was, these were run on old unix mainframes that were still justifying their cost. I'm not sure the target audience with this thing though
"When life gives you lemons, don't make lemonade. Make life take the lemons back!" -- Cave Johnson
While we're at it, can you provide a source that says I need a haircut?
Preferably one that doesn't come from a barbers' association.
Confucius say, "Find worm in apple - bad. Find half a worm - worse."
People without hair shouldn't ask for a barber.
People without sources to cite should find some.
"First they came for the slanderers and i said nothing."
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.
IDENTIFICATION DIVISION.
PROGRAM-ID. ADD01.
ENVIRONMENT DIVISION.
DATA DIVISION.
WORKING-STORAGE SECTION.
01 FIRST-NUMBER PICTURE IS 99.
01 SECOND-NUMBER PICTURE IS 99.
01 THE-RESULT PICTURE IS 999.
PROCEDURE DIVISION.
PROGRAM-BEGIN.
DISPLAY "Enter the first number :".
ACCEPT FIRST-NUMBER.
DISPLAY "Enter the second number :".
ACCEPT SECOND-NUMBER.
COMPUTE THE-RESULT = FIRST-NUMBER + SECOND-NUMBER.
DISPLAY "The result is :".
DISPLAY THE-RESULT.
PROGRAM-DONE.
STOP RUN.
Java
import java.util.Scanner;
class AddNumbers
{
public static void main(String args[])
{
int x, y, z;
System.out.println("Enter two integers to calculate their sum ");
Scanner in = new Scanner(System.in);
x = in.nextInt();
y = in.nextInt();
z = x + y;
System.out.println("Sum of entered integers = "+z);
}
}
Both suck, but Cobol is idiotic.
The company I'm currently consulting for handles 10s of millions of credit card transactions using a COBOL-based system. Their "new" system is legacy "C".
Part of my job was to figure out the bit-twidling they were doing to handle the EMV (Europay-Mastercard-Visa) data from chip-based credit cards. It was ugly.
Bear in mind that the vast majority of the COBOL running today is *NOT* Microfocus COBOL, but code written in the compilers made available by IBM, Honeywell-Bull and other mainframe providers back when it was pretty much the only game in town. Microfocus may be offering an implementation of the language, but it doesn't mean they have access to the "Big Iron" applications where the bulk of that legacy code exists.
Observing exchanges between programmers who are discussing which language is best reminds me of Eric Raymond's "Art of Unix Programming" and the rule which says, "There is no 'One True Way'" - his point being that different problems favor different solutions.
Name any of the popular programming languages out there and you will find detractors. The thing is that most if not all of those languages were specifically designed to solve a class of problems. FORTRAN, i.e. "FORmula TRANslation" was designed to help scientists who use computers to solve problems in the worlds of math and theoretical physics. COBOL, the COmmon Business-Oriented Language was designed for, um, wait for it... Business.
What industry sector is driving "Big Data Analytics" these days? Yes: Business.
Our industry moves in cycles - we see techniques come into fashion and then go out again. For example, in the 1980s there was an explosion in (COBOL-based) on-line transaction processing solutions [as machines got powerful and cheap enough to support the load] and solutions like CICS [IBM] and TDS [Honeywell-Bull] became established and popular. Fast-forward to the web and *exactly* the same techniques are being used by PHP and JAVA programmers - many of whom were never exposed to COBOL back in the 1980s because they either weren't working or were't even born then.
We have data. We have code. Code will always be designed to accommodate what we want to do with the data. If our requirements are similar to those that brought COBOL to prominence back in the 1980s, then it will remain a viable solution today. Especially when compute power is cheap and optimising compilers make the code even more efficient than was possible last time around.
Language-based disputes among programmers are often fun to observe, but sadly they seem to be driven by either unaware or ignorant people who can't see beyond their narrow views.
Code follows data. Always has. Always will.
I'm DEAD !! leave me alone.
Isn't Cobol the only language where MOVE really means "copy"?
no, I don't have a sig
That reminds me, time to apt-get a copy of open COBOL. Considering today's P-code and JIT runtimes, COBOL is like a suit and tie compared to C++/Java is a t-shirt and jeans with sneakers. For C# add a hoodie. haha. All the extensions and assemblies will just merge right in and our beloved dinosaur becomes my pet iguana.
Visual Cobol... AKA Microsoft Word.
it's HARD to NOT write a billion lines of COBOL code to do anything...
The entire system at social security is done in COBOL.
Hmm, maybe we should already start a Visual Perl as well.
As I think most of us know, there's a huge amount of legacy COBOL code out there, still grinding away in banks and insurance companies and such. As a percentage of total production code it may be declining dramatically, but as an absolute number the decline is much smaller. It's a lot easier to say you're going to rewrite an undocumented COBOL monstrosity in Java than to actually do it.
If COBOL on Visual Studio has the tedious bits defaulted and hidden, or shrunk to something just as informative but not as verbose, that would be something. (For all I know, this has already been done, ages ago.) Click the little plus sign in the left margin, and it will show you the actual COBOL code, in all its verbosity, if you need to see it for some reason.
For horribly-structured ancient code -- a certain program with a multi-screen nested-IF statement comes to mind -- this could be the start of a refactoring that turns it into something maintainable.
There's no time like the present. Well, the past used to be.
The original NoSQL database language!
I, I still, I ...
I love you Grace.
There should be an OO COBOL. I propose we call it ADD COBOL TO COBOL GIVING COBOL.
Micro Focus Cobol has been available in Visual Studio since pretty much the beginning of .NET. This is just the 2015 version announcement.