Uni profs: Kids today could do with a bit of 'mind-crippling' COBOL Want a guaranteed job in IT? Learn COBOL, even if it cripples you mentally – that’s the advice of university profs teaching tech. Ignore, for a second, the fact COBOL doesn’t feature in the top 20 of languages developers are using in anger today. Those in charge of setting university IT curricula reckon there’s no better …
Turning Award winner Edsger Dijkstra, who invented the Dijkstra search-graph algorithm for selecting the shortest point between two nodes..
Path.
Regarding the article, I don't know anyone who knows COBOL (or at least will admit to knowing it). I know a lot of well paid engineers, and almost all of them are C/C++, Java programmers.
If we are going to start picking pet languages to teach at university, I would like to propose Ada. Makes you write less buggy code.
And just how is it 'mind-crippling'?
I haven't done a huge amount of COBOL but the two things I found crippling about using it was attempting to write a PONZI scheme for a bank and pretend it wasn't a PONZI scheme cos it was several organisations running it, and the restrictions applied to all languages in the financial sector.
It may seem a bit restricted compared to 'modern' languages but it was a bit like taking a 10 minute walk rather than spending 2 minutes cleaning the ice off the car, 3 minutes driving there, 3 minutes parking and 3 minutes walking from the parking to the destination but with 1/3rd the exercise.
A bad workman blames his tools - I blame management for almost everything.
I agree. I know COBOL and don't find it mind-crippling, even though I don't program in it anymore.
COBOL has many advantages in helping the programmer understand what they're actually doing. Understanding the actual format of data for instance. It's even possible to become a far better programmer, by banning things like GOTO and actually having to think about what you're doing and coding proper structured code rather than the rubbish I often see. Branching in and out all over the place. Makes it a right mess.
"COBOL has many advantages in helping the programmer understand what they're actually doing."
Agreed. I also learned a lot about eliminating unnecessary I/O and ending up with a program which ran efficiently.
"COBOL writer's cramp" was a myth too once you got away from pencil and paper.
With a decent editor you could be very productive.
Whilst I'd agree that 'writers cramp' wasn't such a problem after terminals, that was pretty late in the day; for years it was writing your source on box-paper, to be handed over to the punch-room where, although likely as not, the punch-girl would spot that you'd missed a full-stop in the Identification Division but was forbidden to correct it, your opus would be faithfully rendered, over the course of a day or two, into a monumental stack of punch-cards which, when compiled, produced a goodly quantity of processed trees, manuscript style, telling you several thousand times that there was a compilation error.
I still like COBOL though, a lot: it's a pretty damn good language for collating data. Loved Redefines in the Data Division. Although the source is very wordy and precise, it compiles small and efficient.
(Oh goodness - just remembered Segmentation - actually had to use it once!!)
> A bad workman blames his tools
EWD a "workman who blames his tools"? That's the guy who writes an Algol compiler in assembler and invents a few new things doing it.
It is "mind-crippling" because it doesn't help you to think about the problem, nor formulate the solution (trips you up and cripples you), nor help you prove that the solution is correct. But EWD may have been mistaken in thinking COBOL is a general-purpose programming language.
He also not not much good things to say about the several others:
https://cs.uwaterloo.ca/~shallit/Courses/134/dijkstra.html
Even if I started with Fortran, Algol and Cobol I think Cobol is not good as ones first language as I think it makes it harder to learn Object-oriented programming well. Still I consider any language just a tool and no language prevents you from writing bad or good code. I probably still like assembler and machine code more than the rest. Cobol is not that bad to maintain, however.
I did some commercial COBOL programming, and as the previous poster said, it was not that awful.
Sure, it isn't very powerful and you would not really want to write a compiler or such in COBOL, but it is pretty good at COBOLly tasks.
What worries me is all this bollocks about what language schools/universities should teach.
This is an industry that is forever changing and absolutely requires that people can continuously teach themselves. Any half decent programmer can pick up COBOL (or C, ADA, Pascal,...) without a university course.
Not sure that the language of choice at University should be COBOL, but it needs to be a language where you have to actually know what you're doing. Too many of the languages today are abstracted to the point where the programmer isn't really aware of what the instructions do. This is one of the reasons why much of the code todays is horrifically inefficient. You only need to speak with DBAs and see some of the SQL produced!! Whilst efficiency isn't the be all and end all of programming, a program should be at least reasonably well written.
Good points. This is one reason we went back from Java (still used by us for teaching OO) to C for our initial programming course. We find the students learn to understand what is going on better. Having to do your own malloc and free can be a pain, but learning what memory management actually is about is useful.
More importantly, I think it is important to teach the students programming rather than teaching them a programming language. The first is a way to think about solving problems, the second is a tool to achieve a result. You need to learn both of course. In terms of programming languages, the most important skill is to learn how to teach yourself a new one.
Another point is that there are two reasons to learn a new programming language:
1) because you want to work on a project written in that language
2) because you want to learn new ways of thinking about programming
If you have learnt to program in Pascal, learning C does not give you a fundamentally different way of approaching programming problems, but Haskell or Erlang will. A thoughtful discussion on this is found here.
"More importantly, I think it is important to teach the students programming rather than teaching them a programming language."
My degree involved both things, in fact. The whole data structures, algorithm analysis and similar courses were actually designed for teaching them without relying on a specific programming language. At first I thought "cut off the stupid pseudolanguage stuff, let's C how it's really done!" but when we hit complex stuff like binary self-balancing trees, I saw the advantage of doing stuff using this approach. It also led in the long run for me to actually appreciate OO; it's much easier to implement a data structure class and just create instances of that than go on doing the funky function juggling that comes with the lack of OO support in a language.
Not sure that the language of choice at University should be COBOL
No language should be the "language of choice at University". If you're doing a degree in computer science, software development, or any discipline that involves programming[1], you need to work in multiple languages. There's no excuse for confining yourself to a single one; that's what "cripples the mind".
In my CS BSci program, I had multiple courses that required assembler (we used VAX and 68030, but the particular architecture isn't important), C, Pascal, and LISP variants (I'm lumping Scheme in with LISP for these purposes). I had individual courses that required Fortran, ML, Modula-2, and C++. Various scripting and domain-specific languages were involved too, if not necessarily required by the curriculum.
[1] Yes, I'm aware that a lot of computer science doesn't involve programming. But even if you intend to work solely with the theory, you need to put in some laboratory time.
I agree with all y'all on this thread; universities teach computer science, not a programming language. One has to be mentally equipped to pick up a new language when needed. If you move from one platform to another, you may need to learn Java, Objective-C, even the native assembly language or a new scripting language. That's just how it is.
We all heard the stories about making a fortune out of our COBOL experience back in the run up to Y2K, but even though I lived in an area chock full of financial institutions I couldn't get an interview with any of them.
The agents were insisting that you needed to have worked on a particular version of COBOL and JCL, and in the last 3 months at that. They completely missed the point that you would be dealing with some pretty ancient code.
So much for 15 years solid experience, albeit not in the preceding couple of years.
COBOL is good for another 10 years...
- 2013 6th year entering Uni to study CS (inc majoring in COBOL module) = 4 years
- Exits Uni 2017
- If lucky, gets on apprentice schemes at bank for 1 year
...leaving his valuable skills with a shelf life of 5 years.
Lets hope the rest of his Uni education can cover the shortfall of the remaining 40 years of his working life.
Caveat: I did Biology and yet worked in IT for 20 years, so pretty much all of the above is bollocks at the end of the day.
COBOL is good for another 10 years...
That's a vapid statement to begin with, so your analysis is pointless.
COBOL is a hugely entrenched technology. There are some new COBOL applications being developed (I occasionally work with some of those customers[1]), but even if there weren't, the enormous installed base of critical, often largely opaque applications guarantees that the language will be around for decades, assuming civilization doesn't collapse entirely. Businesses couldn't possible afford to migrate all of those applications in the next 10 years even if they wanted to take the enormous risk of doing so.
Mind you, I'm not claiming everyone starting a CS program should study COBOL, and certainly not confine themselves to it. (I don't know about the UK, but here in the US you can't "major" in a programming language, at least not in any accredited CS program.) If you're competent, the languages you study in school shouldn't matter, so long as there's a sufficient diversity of them.
[1] I work for Micro Focus, though not on the COBOL implementation.
COBOL was "good for another 10 years" for the last few decades. It simply is one of the technologies which are used in serious applications which won't go away. And since COBOL abstracts away the operating system to some degree, it's even portable. Just to contrast that, try porting a C program which stored integers in binary files from a 32-bit machine from 2000 to a 64-bit machine from 2010 if it wasn't explicitly using sized integers.
I know Java has been gaining some ground and for a while it looked like Java might become the new COBOL, but then Oracle killed it off with their famous "Java is not the new COBOL" statement.
So seriously, if you wanted to start a program which needs to be maintained for the next 30 years, you don't have much choice.
I remember some guy coding up the stack in a database table (this on IBM big iron system) because there was no way to correctly handle the inherently recursive structure of the problem (which had to do with telecom cabling, but I digress)
COBOL wasn't even good at what it was designed to be doing. It just appealed to management types who went all "Oh english words! now I can understand computers too and I WILL CONTROL THOSE IDIOTS IN ICT". Retarded premise, retarded results.
And also, these you can have a DSL that compiles to whatever you want in about a week. Why use one of the first stumbling attempts at a business-oriented DSL in the first place (except for maintenance, rewrites and flushing down the toilet). These ain't the 90's anymore.
"because there was no way to correctly handle the inherently recursive structure of the problem"
I remember doing recursive stuff in the mid 80s, so it's been possible for a long time now. Quite often though, the problem was the person knowing and understanding how to do it.
"COBOL was born thanks to the US Department of Defense rather than from the brains of fellow computer scientists"
So basically you're saying that Grace Hopper was not a computer scientist because she was a Navy Reservist? COBOL's based on FLOW-MATIC y'know. And by saying that, you're also saying that neither were any of the people who worked at any of the other contributors?
Its late and I'm tired but it really comes across that way, at least to me. She only invented the first compiler (albeit incomplete) and saying that isn't the work of a computer scientist is rather puzzling. I'm a Reservist myself, so does that mean if I create something while I'm not on active duty and working for a private entity (Hopper was an employee of Remington Rand at the time she was working on the A-0 Compiler and languages such as FLOW-MATIC and later with Sperry Rand when they were working on COBOL before going back to the Navy full-time in 1967), though my employer is a Vendor to the Defense Department, its really just the DoD doing it instead? If so, that's certainly news to me.
And really if you want to break it down, COBOL was the product of the efforts of IBM, Sperry Rand, Burroughs, RCA and two others that escape me at the moment as well as the Air Force, Navy and NIST's predecessor. Two organizations out of six really can't be considered the lion's share.
And by the way, Dijkstra was given the Turing Award for his work on ALGOL if I'm not mistaken. I've never heard of a Turning Award though. Do you get that for not running over cones at the DMV or something?
"COBOL is good for another 10 years thanks to its huge presence in mainframes and on Unix systems running mission-critical apps in banks and government."
Right, and how many jobs do they think that is, in total? People making occassional updates to overnight batch or inland revenue systems? How many people do they think these organisations already have who are in their late 40s/early 50s who are just looking towards retirement?
I have lots of mates that once knew COBOL and a couple of them are still doing it. Most have moved on to .net, PHP, Java or whatever else.
There are 17 jobs that come up for COBOL on Jobserve, most of which have it as a minor skill. That compares with 2000 C# jobs and 600 PHP jobs.
Language good for another 10 years, great. That means some sucker student may just about have it mastered before it becomes extinct. No thanks.
If its mission-critical that must mean its worth a lot of money to keep running. If its worth a lot to keep it then it should be worth enough to deserve the investment required to modernise it - in C++, Java, .NET whatever. Oh, no one knows how the existing code works? Well, that's not a problem that's gonna change and your odds of understanding this code will be better WHILE there are developers left who understand the code.
So, quit being cheap, moaning about lack of skills and just migrate/upgrade.
You clearly have no idea of the economics involved.
I regularly deal with customers who have small-to-medium COBOL installations (relative to average sizes in the industry).[1] That's a few hundred to a couple thousand individual COBOL programs, generally a mix of interactive (CICS and/or IMS) and batch (JCL) processing, with all the associated resources: flat files, databases, JCL scripts, screen definitions, system resource definitions, ...
Migrating to a compatible COBOL dialect and emulated mainframe environment on Windows or UNIX usually takes a year or more for an application suite like that. And that's with no source code changes. The customer has to figure out what they have in the application portfolio and its resources, build a test suite, get the gear in place and figure out how to administer it, decide how they're going to develop in parallel until the switchover happens (because development doesn't stop on the old code just because you're trying to move to a new platform), assign resources, figure out the environmental differences, take care of compliance and other legal issues, migrate, test, plan the switchover...
Migrating to a different language is orders of magnitude more expensive, in time and money. Yes, periodically organizations decide to junk all their COBOL and replace it with whatever turns the CIO on - Java used to be the popular choice, and often still is, though other languages are making inroads. We see a lot of those projects fail, when they're years behind schedule and have run over budget by several times the initial estimate.
Even our customers often do phased migrations, where they tackle one application at a time. That has complications of its own - because generally the migrated apps still need to interact with the ones still on the mainframe, so you have additional communications, data-access, and distributed-processing complexity to deal with - but it's simply not economically feasible for those organizations to do the whole migration all at once. And that's despite the fact that they reliably see savings for each application that they migrate, starting as soon as they can reduce their mainframe capacity, thanks to mainframe leasing terms. They know the investment pays off; but they only have so much to invest in it at any given point.
Saying that organizations should simply rewrite all of their COBOL applications is like recommending everyone immediately switch to plug-in electric cars. It's the same sort of pie-in-the-sky thinking.
[1] As noted above, I work for Micro Focus; not on COBOL, but on tech that's used by many of our COBOL customers.
There's a reason why COBOL is still running many important parts of our lives. Simply, for many tasks, COBOL is still the ideal tool. The languages which came and flourished later have their own ideal applications, but when large amounts of hierarchical data are to be handled then COBOL is an efficient, clear, easily written and maintained way of modelling that data and the associated processes. I still maintain a lot of affection for COBOL, even though I haven't used it in anger for a long while now. I would be happy to return to coding in it for reasons above and beyond that affection though; for a lot of jobs it's just the best way to do it.
I wonder though if the professors are thinking more of the mindset that cam with COBOL programming rather than the language itself. COBOL programmers in a mainframe environment had to learn how to write code that worked with the hardware and knew that there were great rewards in doing so. Shaving a few clock cycles from a database query could take an hour off the run-time of the overnight batch or bring TP response times down to something more more acceptable to the user. There was no option of throwing more hardware at it to speed thing up, or rather it was prohibitively expensive.
I smile when I get an odd look when I ask if things could be made more efficient by moving initial read/tests outside the loop to save a couple of processing steps ("Why bother? If it's slow we'll double the processor ...") or alternatively suggest defensive checkpointing ("Nah ... those boxes never crash ..."). I know they'll learn, even if it's at 2:00 a.m. with a big hairy live support bod looming threateningly over them.
That being said, there is part of me that likes the idea of a boot camp in the basics with COBOL being used as the assault course.
I will add in a further salute to my namesake. The language that she framed still has things to teach us.
I can reassure you there are still quite a few C++ developers around who care about efficiency. STL is all about efficiency, even though armies of idiots are using it in the wrong way. There are quite a few use cases where effiency matters very much and main memory cannot be expanded. If your app is sold to millions of end-users or runs inside the limits of an air- or spacecraft.
I assume there are even three Java and two C# developers out there who know what they do and care about efficiency.
When you interview at Google, they will ask you to quite a few undergrad questions related to algorithm complexity. Then they will present a problem and demand you to describe the most efficient solution you can think of.
In MFC you will see the exact opposite, but who said the MS folks are in any way representative ? Just because the IT sector is stuffed full of lazy, amateurish developer does not mean all of us have this mindset. My guess is that about 1 in 20 developers is a well-educated professional who cares about these things.
Ah yes, another story brought to you by the department that thinks university is for teaching vocational skills. When at university, students are learning how to be computer scientists. They'll be exposed to a number of languages and rather a lot of stuff about how you actually conceptualise problems as a programmer. The idea that one should be taught because they're going to get a job in it... it's just wrong on so many levels.
They're there to be learn how to be programmers. Picking up a new language isn't hard for a fresh faced grad. I'm struggling to think why any employer would be that interested in exactly what you did in your course work. As always, what they'll most be interested in is seeing a bright flexible student, hopefully with a bit of initiative to learn something about <insert vocational language here>.
Of course it seems rather unlikely someone is going to go off and learn COBOL off their own bat?
The problem with that argument is that employers expect you to be skilled in the programming language you will be using in the job. I've applied for loads of jobs as a "programmer" only to be told, sorry we need a "<insert here> programmer". Employers refuse to acknowledge that "programming" = "driving", not "driving a ford focus with exactly three passengers".
To extend your analogy, most employers dream of candidates walking through their door who have a motorbike license, an HGV license, and an F1 license. Because we know then that it doesn't matter what vehicle we give you to drive, it will go bloody fast and you probably won't crash it.
Very few candidates actually demonstrate anything even approaching this level of generic ability and understanding though; and the time-cost of interviewing candidates who don't look qualified on paper, in hope of unearthing a gem is enormous. So most employers are generally limited to looking for people who can hit the ground running in Technology X (e.g. HGV driving).
I've said it before, and I'll say it again - there is an unfilled niche in the recruitment market for an agency that actually understands developers, and screens them properly to make sure that those that turn up for interview actually have shit-hot brains, rather than just "5 years experience in Java (for some shitty little software house with tons of bad practise and actually no real idea of OO, SoA, Design Patterns, or any other useful skills)".
I've lost count of the number of hours of my life I've lost interviewing complete fuckwits who are either braindead, or completely fucking incapable of articulating to me how brilliant they actually are.
Totally right, the problem is businesses tend to use Recruitment firms and generally the people you meet for most of the recruitment process are HR people who know nothing about programming, it's just a totally esoteric subject to them. They just check the boxes. If you can't prove you have worked on that language at all before, you're off the list to them, if you have that language but not the particular version or platform etc, you are off the list. If you meet those points but have not been employed on those languages on those platforms for a couple of years you're off the list, like they think you're Homer Simpson or Peter Griffon and have no memory retention whatsoever.
The Primary skill in any programming is analytical thinking and problem solving, not the tool.
If a CS grad applies for a job and can't demonstrate the 'vocational skill' of actually being able to program well, they're screwed.
The reality is, picking up a new language is indeed not hard for a new grad. A new physics grad, a new maths grad, a new chemistry grad, any real science or engineering subject. And if we're going to have to train them all or give them all time to train themselves, the guy with the math skills is getting the job, not the CS grad.
The world needs many more competent programmers than computer scientists, a bit more vocational training would serve everyone better at undergrad level.
I had professors who were experts in COBOL, APL, FORTRAN, LISP, Pascal and Prolog. They were each inspiring. But it was the LISP advocate who pointed out the flaws in the Pascal implementation, the dynamic scope rules of APL, the implicit typing of FORTRAN, that Prolog's backtracking was cleverer than your formulation and that if you write the plain English command: 'DIVIDE cake INTO 3 GIVING slices.' it is not a valid COBOL statement. He also carefully explained that garbage collection and list traversal in LISP were not for free.
Since graduating I like to think that this breadth of education has helped me learn and appreciate the strengths and weaknesses of a various assemblers, C, Perl, Rexx, Natural, Python, C++, Java, Haskell, C#, Go and the next 700 programming languages.
COBOL is actually the first Domain Specific Language (DSL) - or at least the first extensively-used one. Indeed, it was instrumental in expanding the market for computers by at least 2-3 orders of magnitude. Back in the 1950s, even computer manufacturers like IBM thought of their machines as being essentially high-speed scientific calculators - akin to today's research supercomputers. Then along came COBOL, and made it possible for anyone with a superficial understanding of computers to write working programs to handle common business tasks like payroll, accounting, invoicing, stock control, etc. For example, COBOL provides decimal types that let you program accurate money transactions easily, whereas most modern languages force you to write code if you don't want random rounding errors to mount up and render your balances laughable. It contains all the features that business programmers are likely to want, in the form they want them - and as little as possible of anything else. Above all, it does a great job of hiding all the internal complexity that a programmer does not need to see.
As for Dijkstra, he was of course exaggerating for effect. And, Gavin, I'm fairly sure he didn't use a greengrocer's apostrophe.
COBOL will still be a major language in use when the current top 20 are dead and forgotten.
What makes it so great is the very reason that nobody new wants to learn it. COBOL was designed (as always: when properly written) to be MAINTAINABLE, that's why coding it takes a bit longer, and nobody wants to maintain anything. Everybody wants to write all of their own, shiny, new code. And as all coders know, maintenance sucks, no matter what language it's in.
What aspect of COBOL makes it maintainable? If the COBOL developers are retiring then the code base is at risk of no longer being maintained, just as spoken languages die out when there are no longer any speakers.
Teaching university students an archaic procedural language would fail to equip them with the considerably more demanding OO design and dev skills required for modern software. Modern applications are usually orders of magnitude more complex that what computers could handle back in the 1950s and 60s, so an OO approach to managing that complexity is a prerequisite.
The obvious solution is to run the source code for legacy COBOL software through auto translation tools into modern languages. Admittedly the output would be way below the code quality expected, but it would run and would work as a starting point.
At university 30 years ago I submitted as a COBOL assignment a single sheet of paper with the sentence "I refuse to go anywhere near this troglodictic abomination" or some such. It got me an "unmarked" instead of a "fail" :)
Despite that, I was offered a COBOL programming job in the run-up to Y2K and keep getting head-hunted for a COBOL jobs now. ;)
Listen, academics have a bad enough time with language wars when discussing the merits of C++ versus java. Throw COBOL into the arguments and there'll be blood on the senior common room carpet.
The only valid arguments for choosing a first language for teaching should be educational. Any good students should be able to pick up their second (third, fourth and fifith) language pretty easily after that.
Of course we should only be teaching Module-2.
I just suggested it here, and various beverages got sprayed on the floor. A few tears of laughter were added shortly afterwards.
If our students want to learn COBOL, we point them to the library where there are a few books on COBOL. When they look blank, we tell them the library is the place with all the books and stuff.
I remember learning being taught how to program at university, and only the first term had much to do with a specific language (PAscal as it happens). The rest of the time was taken up learning how to use the tools of the day - Ada, C, COBOL, assembler, Prolog ... and how to build those tools - algorithms + data structures and all that ...
An in depth knowledge of PHP syntax and grammar does not a programmer make ... knowing how to program does.
I reckon that a lot of the arguments for using COBOL in teaching are about the same as the arguments for using BASIC.
And, yes, I know BASIC allows people to do some rough stuff. That's what a teacher's red ink is for.
Maybe Pascal would be better. And being exposed to a variety of languages is definitely a good thing. Anyway, recruiters ask some stupid questions about experience such as expecting new programmers to have language experience that pre-dates the existence of the particular language. How can we rely on what is being said here?
should commence with assembly language. Students will then be able to see why most high level statements are not atomic operations, and explore the implications. They will be better able to identify which high level language expressions map efficiently to machine instructions. Should it be necessary, they will also be able to look at mixed source code + disassembly listings to spot compiler inefficiencies, and work around them. It will even provide them with additional debugging tools if they ever work with embedded code.
After that (having achieved enlightenment), they will be ready to concentrate on something more abstract.
Most organizations which use COBOL are big financial institutions e.g. banks, insurance companies. Most of these have outsourced or off-shored the work to India and beyond, which uses COBOL. Only a crazy person would learn COBOL today at a Western University, to think it could lead to better job prospects in the Western World. And don't forget what's happening with modernizations of batch processes etc. - wasn't there an article on here about Nationwide moving to a SAP based solution ?
Yes, Nationwide have moved to SAP but all the development and testing was done by offshore resources as is the ongoing support. For those of us in the industry it can hardly have escaped anyone's knowledge that as many businesses as possible are seeking to cut costs through offshoring. I suspect COBOL is suffering less from this than newer languages.
You use the tool that is best suited for the job.
The arguments set forth here are like a bunch of carpenters trying to argue the merits of a drill over a router.
If you cant get your head round cobol then maybe you just aren't cut out for a career in IT (I have written in Pascal, C, c++, java, cobol, zos assember).
There is some truth in your argument and some "dumbing down".
If you don't have destructors, you will need to be more diligent at every point you leave a block of code.
If you don't have bounds checking and some automagic with pointers/references, you will inevtiably shoot yourself into foot sooner or later.
If you have all the low-level stuff of C and C++, your optimizer will be crippled in its options as compared to Fortran.
Just because you could be forced to do something in language X does not mean you should use X for the job at hand. A good carpenter will know when to use a nail and when to use a screw.
This post has been deleted by its author
"If you cant get your head round cobol then maybe you just aren't cut out for a career in IT (I have written in Pascal, C, c++, java, cobol, zos assember)."
IT professional and no mention of 'apps'? As any government minister knows, all we need for a booming jobs market and individual wealth is to be making 'apps' like "Quite Irate Fowl" ... you don't need to know any of these languages as long as you know how to make 'apps'.
Cynicism is me ...
This post has been deleted by its author
I had a COBOL course for one term on my CS degree. I also had a one term course in assembler. The majority of the rest of the coding was done in Pascal, not because it was a widely used language but because it allowed you to reasonably easily code the approach to analysing problems that was being taught.
COBOL and assembler were taught because they were used in industry and you had to use slightly different approaches to implementation than the standard procedural languages.
FORTRAN was taught in a couple of weeks with the lecturer explaining that we really should be able to pick it up quickly based on the other things we were taught and should bring ice cream to the second and subsequent lectures.
I've picked up BCPL, C, Modula-2, Ada, C++, Perl, Python, VB, bourne shell, the only difficulty coming when moving to objects. None of which would have prepared me for COBOL or assembler. Based on that I'd still make both available at undergraduate level as they are important in providing a good grounding of different approaches rather than following the flavour of the month languages.
I said a week or so on here but I'll say it again: "Dead" languages are a great way to make scads of money & keep work for many, many years. We just completed a hiring search for two COBOL developers. One was retired but the money involved changed his mind and the other came from Japan of all places & it cost a fortune to relocate him.
Some of the banks we've worked with aren't remotely interested in "upgrading" to a newer language as what they've got is extremely stable and reliable. Unlike so much of the sloppy "high availability" stuff slopped out now a days.
Old languages aren't for everyone but some if them will keep you in high payed jobs for a very long time.
I have been programming for 33 years and haven't touched COBOL since the mid-90s having started to use it in the mid-80s in order to get dosh as I couldn't get basic and assember (68000, z80 & 6502) to pay.
I still remember it fondly and do think that it made you think about your code structure far more than you "have to" these days and allowed you a lot of controls over data structures.
While there are still companies still using COBOL there is a market for people to learn it but I am not sure if the world of academia is the place.
As bad as COBOL might have been (ok, still is, it's still in use) there's a worse abomination that didn't have a Dijkstra to axe it like COBOL.
Visual Basic.
That particular language has caused far more damage to programmer's brains than COBOL. People who learned to do the "On Error Resume Next" trick evolved their nasty tricks to the Diaper anti-pattern on both .NET and Java. So now you can see a VB or former VB dev having breaky code that can't be debugged nicely thanks to this.
COBOL is probably a minor offender by now. At least the language did teach you basic stuff you needed to know, especially in the 60's when most coding was basically assembly stuff. Oh, and it was much better than the other monstrosity out there: MUMPS.
Actually, it has been revived. There's an open source clone called "Lazarus" which has all the ugly things removed and platform independence added. It's great for GUI applications. At work we have made a little piece of software which compiles statically for Linux, win32 as well as MacOSX with only very minor changes. (MacOSX needs a few lines more to configure the language) It displays a time series of values and can do up to more than a million data points (then the RAM runs out) with 10 channels at decent speed. The display algorithm is fairly straight forward. There are no summaries made to speed it up. (would have meant a lot more code in our example)
The great thing was, that it was statically linked. So you just send the user a binary, he drops it onto his system and runs it. It just works. That's something .net will probably never be able to do since you'll always need the runtime environment.
Back in 94, I was working on "marketing simulations" for a car company's commercial division. A typical scenario, would have a batch pgm take the "94 sports package" of car X and move it to the 95 models, on Oracle DB.
My first run at this took me 6 weeks, using PL/SQL, coding/testing/interviewing the users/injecting weird test data. Stable and worked like a charm.
Others programmers followed, but were much quicker. 2 weeks to code to completion for similar tasks, to my 6.
Then things didn't work so well. Turned out PL/SQL, for everyone else, was flakey and error prone.
Lessons were learned. Decisions were made. The second phase of the project, 3 months long, would be using reliable, portable, proven, technology. Plain old C.
From bitter personal experience, I humbly pointed out that C had no inbuilt strings, was tricky to use, not Oracle-friendly, too powerful and most of all utterly unsuited for my rather green coworkers (C virgins all). This was 94, remember: no C++, frameworks, Linux, stackoverflow and few competent C programmers in the business world.
Fresh from mainframes a few years before, I suggested... COBOL. Got a great big laugh out of everyone, but I didn't care much as I wasn't working on that feature anyway. A wizkid consultant was gonna write some C libraries and my concerns were dismissed as groundless.
Three months later, as phase 2 was about to wrap and I was leaving to join a new employer, our code wizard's C libraries were nearing the point where other programmers could try using them.
Unsexy COBOL would have been done twice over ;-)
"Except it's more cost efficient to push the cost somewhere else..."
In the short term, at least (this quarter) - which is all most businesspeople think about. In the long term, it's disastrous for the organization, but by then one has retired to one's little Caribbean island with one's stash and one's creature comfort's (and probably some kind of medieval decoration for services to industry).
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
