The old advice was “Go west, young man”... but it seems the new one should be “Learn Cobol, youngster”. That at least is the implication of a report from Australia on the languages and environments that are heavily used. The Sydney-based Object Consulting has released a paper detailing those languages which will no longer be …
Coulda, woulda, shoulda, still not going to happen.
"...or FoxPro should be junked or moved to a new system immediately as a result of non-support and no further development of the environments."
I know of Australian sources of software (expensive licence structures, not 99c iPhone bullshit), who still ACTIVELY use foxpro as their base. And have no immediate plans (or any plans as it appears) to junk or move at all.
Sadly (for them) that's the LEAST of their worries. The raft of other issues with the software had us eventually jump ship.
Kinda makes sense now, crappy software = crappy developers/project managers = continued use of an obsolete product.
Delphi is a 1990's derivative of Pascal, which is a 1970's derivative of ALGOL (50's?)
Calling it an old language doesn't make you sound very professional in the coding field.
I have no knowledge of Australian coders but Delphi and Pascal knowledge certainly hasn't disappeared in Europe where many DOS/Win coders in their 30's/40's may have started their careers with either one.
...and the company I work for still uses a cobol-based software for sales and mgmt reporting...
What happened to MODULA 2?
FORTRAN: first appeared in 1957
Delphi: first appeared in 1995
There's old, and then there's OLD...
Modula-2 / COBOL
Ah Modula-2 (or son of Pascal as I used to refer to it). This is what I was confronted with w-a-y back in 1992 when I started my compsci degree. Having only touched BASIC and COMAL before was a bit of a shock!
The idea of the course was to teach us how to program, not specifically to learn one language. So as mentioned above all you'd have to do was learn some language specs and off you go. Nice theory, but I was useless at programming which may explain why I'm now a sys admin.
Meanwhile on the first day the lecturer said something like "...we could teach you something commercially viable like Ada, but we're not into that so we use Modula-2...". And the next year what did they tech? Ada.
Back before Y2K I knew of someone who made a pretty penny doing COBOL. Unfortunately after that the work dried up and he never got round to learning another language. I don't think he's worked in IT since.
Same old in Switzerland
Well, at least Cobol was still on the mainframe of the bank I worked for in 2003. With 3-4 greying coders managing the code.
...at the time, they were talking on replacing it with Java, but I left before any of that was on rails.
Have 72 columns...
Will code Fortran for food (or nice US greenbacks, with pictures of presidents or other elder statesmen).
Of course, I also have C skills and live in Silicon Valley as well (*SIGH*)
Reminds me of a story current a few years back. A programmer had himself cryogenically frozen on the 1st January 2000. He had worked all the hours given him and a few more, had been well paid for his pains but could not face the thought of all those parties and worse still the people who said that the Y2K bug was all a hoax.
Eventually he was de-frosted into a very different world. He was treated like royalty and taken to see the World Presedent. He asked the World Presedent why he had been de-frosted now and why he was being treated so well. The World Presedent explained that it was January 2999 and looking at a peice of paper he said 'It says here you know COBOL' (or BAL, PL1 etc).
Sorry, I'll get my coat and leave quietly.
It ain't broke
So why fix it? COBOL* remains an effective, if somewhat prolix, language for capturing business logic; though probably not the best way to specify the layout of a web page. Anyway, a week's course ought to be more than enough to convert any competent Java or C# programmer - the only unique skill is searching for those pesky missing full stops (periods).
*Yes, I know the official style is to use lower case, but I prefer to capitalise my acronyms. (Although I suspect the choice of COBOL may have been influenced by the German word for 'Hell'.)
Replace with C#
I kinda sorta agree.
I would totally agree if they were suggesting replacement with a modern RAD language that didn't inherently add a massive support and development cost.
But replacing RPG with C#? There has to be a better way.
Who remembers Y2K then?
I know three retired COBOL coders that came out of retirement on silly rates to rewrite COBOL for Y2K, apps that had been originally intended to be retired long before that date. Funnilly, we have recently found some Russian programmers that are pretty hot COBOL coders, the suspicion being they were once trained to do nasty things to Western banking systems!
A message from the year 9999
Oh God, please stop!
We're running COBOL object code (we've lost the sources) from your era that contains 4-digit fields for year! It will cost us dear (the planetary GDP) to fix! Not to mention that English is a dead language (what does "perform" *really* mean?).
Death to COBOL!
What language can get you in the most trouble
One thing people don't appreciate is that COBOL doesn't give you enough rope to do serious bodily injury to yourself or others. It is a 2.5 ton lorry, not a Porsche. The worst systems I have ever had the grave misfortune to try and maintain were written in C. I never worked professionally in C++ but it seems to have ALL the problems of C plus an entire suite of additional severe handicaps. It is probably presumptuous, but my gut feel is C++ is likely the worst language to ever gain widespread acceptance.
You normally only hear 2 complaints about COBOL. First, "it's old". Which actually seems to mean it's formal rather than the language specification was set down many years ago. If the latter is the actual complaint the person making it might be too immature to be left alone with your business' data. If the former... perhaps they are too reckless.
The second complaint is that there is too much typing involved. I never understood this at all. You can certainly have variables named A and X, it's just more likely that in a COBOL shop they will have things called coding standards that will give you the opportunity to work late and take every last little bit of cute, witty, obfuscation out of your code.
None of this should be interpreted as expressing my unrequited love for COBOL. I firmly believe in OO and would not choose a procedural language for any serious application. I have not seen OO-COBOL but am very skeptical of attempts to teach that old dog such a complex new trick. I believe JAVA is the very best implementation of OO and am crushed that Oracle is going to destroy the language. I sincerely hope Apache or someone will fork the language so it can continue.
So as is so often the case I cannot agree with those who are ostensibly on my side. Java is the state of the art. But COBOL is vital and a completely valid, if no longer the optimal, choice.
>> I believe JAVA is the very best implementation of OO
Not used it since 1.4 - but remember all those lovely things (ints shorts reals etc etc) that *weren't* objects. Believe that it automatically turns them into objects when it needs to now.
Also - why does everything have to be attached to a noun? Why can't you just define a method that does stuff?
And don't get me started on Strings being final - "we don't trust you, because we're drones like you are". Nah.
Who needs Ruby?
When you've got www.coboloncogs.org
Before an educational institution picks a language to teach it should look at the contractors rates that programmers can get.
Java? Two a penny.
C#? Buy one get one free.
Ada? Name your price.
I'm amazed that anyone wants to use Fortran these days other than the super computing crowd, and aren't they're all academics (= doing it for free???) anyway?
But it's more than just programming languages. How many universities teach semiconductor engineering? Virtually none. I know of a guy who was lucky enough to learn it, and now works freelance for 6 weeks a year before resuming his perpetual cruise round the world on his luxury yacht. A lifestyle superior to that of many a banker, businessman, etc. Yet how many school career advisers would ever suggest that to a pupil as a line of work likely to be profitable?
Chicken and egg?
Isn't part of the problem that you can't teach yourself how to properly code for an enterprise class banking or engineering package at home, or on a week's course. To really learn these languages to a level where you can then hire out your skills you need to be working somewhere that uses them, and get a few months hard experience at the coal-face.
So the less shops that use these languages, the less people become/stay skilled in them, and the more those who are can charge...
You seem to forget...
The bankers/businessmen etc can _afford_ to do it. Even without the six weeks a year. They just choose not to, because that's not what they do.
Work-to-Live types vs Live-to-Work types.
It really doesn't take a HYOOOOGE pot of money to jack it all in. Merely an attitude that doesn't require vast amounts of money and flashy material toys.
if it ain't broke don't fix it
it certainly creates a great market for those that do know the old9er) languages to charge like wounded bulls when the time comes. Great gigs if you can get them.
But are there any jobs?
I took a COBOL class in 1999 (but still was in school so did not work on any Y2K projects). COBOL programmers may get good pay, but are there any job openings for them? I haven't seen any in my area, despite plenty of regional banks in the area. The COBOL systems just keep running, so the hiring rate is very very low; they should hire people to "mentor" so when the older sysadmins retire or die, someone knows the system, but I don't think they are.
That said, absolutely if you're in school take a COBOL class. It really can't hurt; you'll find COBOL much more restrictive than you are probably used to (it's really focused on stepping through records (which originally would have been cards), doing some math or whatever on the data, and when it's gone through all the cards generating a report.) But this means there's not loads of frills, bells and whistles that make it complex to really learn.
COBOL classes don't hurt, in fact they can be fun
My degree course had a COBOL class (at the time, it gave the degree-holders an exemption from some BCS exam, which for some reason the uni thought worthwhile) and it was quite relaxing, indeed amusing at times. The geekier types sat at the back of the class devising vaguely-plausible extensions to the language, such as "PROCEED CAUTIOUSLY." and "PROCEED CONFIDENTLY." statements for turning runtime checking on and off, and the "VIA" clause for the GOTO statement, such that "GOTO A VIA B." which would execute one statement at B and then jump to A; and roman numeral formats (which in fact Common Lisp does have).
The verbosity was amusing, too; we had to do a numeric (payroll) programming exercise in it, which I then repeated for a laugh using the local sed-like editor language, which had no numeric facilities, no variables, and no comparisons, all of which I had to write in-line with text manipulation... and still the program was shorter than the COBOL program (although admittedly somewhat less readable).
And then there's always the option of COBOL poetry...
For years ...
When my students ask me what other language(s) to learn, I've been suggesting K&R C, COBOL and Fortran. Not a month goes by that I don't get a "THANK YOU!" email from a former student, now making a real salary coding in one of the three.
With more than a couple billion lines of code in current use, COBOL's not going anywhere soon. Same for Fortran and C. They might not be sexy, but they do real work, in the real world ... and that's where the big bucks are.
Remember, kiddies, the Web and associated languages are ephemeral. COBOL, Fortran, and good old K&R C are here to stay. Learn one or all three, and you'll be employed for life ... or, as in my case, until you decide you want to retire.
Somewhere, Admiral Grace is smiling that evil smile that only she could get away with :-)
I truly hope
That she is.
"Modernization" Is Usually A Misnomer
The reality is that most of the languages being touted as "newer" than COBOL are 'C' derivatives. 'C' is an older model language, basically patterned on macro level assembly languages. As such, it is a more primitive evolution than COBOL- more a 2.5GL if you must, than anything else. C++, java & etc all suffer from this common heritage. While it is certainly possible to "upgrade" applications written in COBOL to one of the 'C' derivatives, it is often an impractical and expensive excercise. COBOL survives because it remains the optimal solution in a very large number of areas.
Delphi is dead, it's Lazarus now
Lazarus is the open source re-implementation of Delphi. It does many things and at work we are using it for cross-plattform GUI development.
Alive and as well as could be expected
I think the chaps at Embarcadero would be surprised to learn of it's death.
I've coded Delphi since D2 and am currently employed on a nice salary, travelling the world (3-weeks in Oz coming up next month) looking after a legacy product written in "dead" Delphi. Amusingly enough, the bright young things have been trying for 2-years to build the same application in C# and are perplexed that their code is x20 slower than "dead" pascal.
Tools are tools. Just use the one that best fits the job in hand.
the problem with this kind of whining
is that it ignores the fact that once you know any programming language it is relatively easy to learn another. As an undergraduate I learned fortran during a six month general comp sci course. During that same course I realized that programming is just the expression of logical algorithms in code. Any useful language should be able to express the algorithm; and the algorithm should be able to be deduced from the code. The idea that once all the fortran / Cobol / Basic / Pascal progammers are dead, the language is not recoverable is pure nonsense. That is why the programming guides and user manuals were written. If you don't like paying some old geezer to fix your legacy code, give the manual to an intelligent intern for six months at a tenth of the rate. Viola! Instant Cobol coder.
Patient: Will I be able to play the viola after my accident?
Doctor: Of course!
Patient: That's great news, doc, 'cos I couldn't before ...
I THENK YAOU!
And you happen...
...to know where there's a nest of those "intelligent interns"?
Finding competent programmers among the supposedly fully educated ones can be hard enough.
I thought the rule was "You always program in the first language you learned, no matter what language you're actually programming in."
Which explains why my VB and PHP stuff always looked like franken-Pascal.
When will companies learn
That you should be able to hire any developer*, send them on a language course, and then let them at it.
They may not know all the fiddly details, but they should be able to follow and amend existing stuff. If the code is commented properly ( Ha!) and they have a reference source to look things up, they should have few problems. Of course, it will take a bit longer than if you hired someone who's been living and breathing it, for years, but it's hardly going to be a skill that disappears off the face of the earth.
*Possibly more difficult with some developers who've just been spoonfed the latest, greatest, managed language, who can knock out simple applications in no time, but have no idea what is actually going on behind the scenes. ie, we had an offshore team working on an older system, who really struggled with the concept of how code was linked to the interface, because it "just happens" in .net via the IDE.
Experience counts too
To take an example.
Pilots need conversion courses to change from single engined light aircraft to multiple engined ones, or from props to jets.
There is a case where an experienced engineering officer (with "wings" on a trainer) accidently took an RAF fast jet up but he nearly killed himself several times before landing it.
Anon - "Of course, it will take a bit longer than if you hired someone who's been living and breathing it, for years, but it's hardly going to be a skill that disappears off the face of the earth."
That's the point. Companies aren't willing to wait and/or don't have the time for the developer to get up to scratch. Many a time through bad management and planning but also through external factors, eg. goverment regulations/law, they only realise that they need to update some legacy app a very short time before it has to go live. If they could really plan ahead then getting in a few developers on the cheap, training them up, and getting them to update the codebase would be better in the long ter.
An old saying: A real FORTRAN programmer can write FORTRAN in any language!
And why is there no time?
Because they didn't plan ahead and train the guy in advance of the requirement, because they knew damn well that as soon as he was trained/skilled/experienced, he'd bugger off and contract at megarates for the competition...
Indeed, this is a downstream effect of saving money by cutting the training budget. Now, instead of hiring entry-level folk and training them up, we can only hire people with experience in technology X and they're more expensive. And they have no great attachment to the company.
Ah yes, I remember it well
I loved COBOL coding. Could never remember how to spell Enviroment - sorry environment division the first time round and could work out why it would compile.
in my first cobol class in 1988, we were on a Burroughs B9000 (I think). The rule was, the first compile was free, but each subsequent compile deducted 10 points off the grade. On my first program, I scored a -30 (yes, negative 30) because I had spelled "PROCEEDURE" thinking, "well, it's like proceed, innit?". Finally my fiance pointed out my error...
I'm from the old school who learnt assembler, Basic, Fortran, Cobol a few others and dare I say it, Bliss-32. After many years doing other stuff I decided to have a go at an object orientated language and as I have a Mac it happened to be Objective-C which I'm told is based on C. I have so far written three small applications (apps?) and two of them were from examples in books.
Compared to any of the older languages Objective-C is difficult to read, difficult to understand and don't get me going on the subject of header files in different directories to the source code. I can't see how anyone but the original developer can support an application written in this language.
And this is supposed to be progress?
Objective-C is very easy to learn if you know how to program already.
Being a Certified NeXTStep developer since the early 90s, I can tell you that any proficient C programmer can learn Objective-C faster than they could learn C++. And it was safer too.
C is one of those 'perfect' languages, but you really have to know what you are doing.
Someone is still maintaining VB3 code for the ATO
Thanks to the ATO's appetite for 16-bit applications, Australians are "recommended" not to install 64-bit operating systems...
Shallow report analysis ....
"...while anything on Smalltalk or FoxPro should be junked or moved to a new system immediately as a result of non-support and no further development of the environments."
This is rubbish! Smalltalk may - for a number of reasons - never have achieved its true potential, it is re-gaining popularity in the web development world (see www.seaside.st, www.world.st)
"Francis said: “I have seen examples of developers on older technologies like RPG and Delphi charging twice the rate of a developer on a newer technology.“
Having started my career as a PowerBuilder developer I perfectly understand why RPG or Delphi experts NEED to charge twice the rate of newer technologies. There are no or few new projects being started using these older technologies (understandably), so they are only required to make changes to existing systems, now these jobs are few and far between compared to the plethora of new projects in the newer technologies, so they need to cover themselves for the time spend between contracts to feed their families!
viva la COBOL
Several years ago I made the choice of getting out of the programming game. The major reason being was that I had nothing but a COBOL background and nobody around where I lived was actively using it anymore, and I have no desire to move. It seemed that the dominant reason for people converting away from it was simply "it's old" and all the new graduates and the guys that had to be "cutting edge" always talked about how the multitude of new languages were so much easier and faster to develop with.
It seemed to me that everybody completely lost sight of a major advantage that COBOL had over the newer popular languages, in that none of them were anywhere near as easy to actually *maintain* when you weren't the original developer.
One part of COBOL that I absolutely loved, is that when working with smaller systems it was often completely possible to sit down with a user who had absolutely no capacity for programming, but because of the simple English wording (assuming that fields were named in any sort of manner that made sense to the operation at hand) they could actually follow along and help you figure where processes weren't doing what the user needed them to actually do.
Sorry but the article that El Reg is reporting on shows a bit of self serving publicity.
Econ 101, that's the US Freshman course on Economics,
Supply and Demand will always drive the price of a resource.
The reason people who are proficient in technologies like Delphi, COBOL, and other 'dead' languages can charge more money is that the demand outstrips supply of those capable of delivering service.
It also goes beyond just knowing the syntax, but something about the underlying system.
And the author is wrong, that net new software is still being developed. That is if you discount enhancements or new code written for existing systems.
Why are banks and other large organizations willing to put up with this 'gouging' by the elder programmers?
Simple. Its the lower cost and lower risk alternative.
The plain simple truth is that those who attempt to convert, or rewrite new applications that do the same thing as their older mainframe existing systems, tend to fail.
Considering that migrations are expensive and do not yield any real 'net gain' and with large scale projects having a failure rate of 50% or higher, you have to agree with the banks.
So paying 2X for a single or a couple of resources is in fact a good thing.
If you want to see this change, then you need to change that statistics of high cost and high risk of migration. Until then... COBOL lives.
Cobol Like No Other!
In the early 1980's the Cobol environment I used, had a Data Dictionary System which held all data definitions in common, including screen interfaces with company standard defined validation rules which were all checked for in Cobol by the Validate verb so you only had to do was add in the logic,
RPG is alive
Somebody needs to tell them that IBM are still adding features to RPG, it isn't dead by a long way.
If it ain't broke don't fix it
Old rule: If it ain't broke don't fix it
Whilst I would not be building new systems in Cobol (unless there was a very good reason to), trying to junk and re-write business systems, just so you can get it in colours other than green and black, seems like a lot of money and business risk for no cashable gain.
Why is this article hidden away in the dark corners of ChannelRegister?
It ought to be front page news, even though it's terrifically untrendy (or maybe because it's terrifically untrendy).
Or did I miss it when it was front page news?
- Ex-HP boss Carly Fiorina sacked one week into new job
- Monster Cloud and an angry customer wanting a refund: A Love Story
- Analysis Intel has driven a dagger through Microsoft's mobile strategy
- Old, complex code could cause another UK banking TITSUP – study
- Who you callin' stoopid? No excuses for biz intelligence's poor stats