Feeds

back to article 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 …

COMMENTS

This topic is closed for new posts.

Page:

P_0

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.

4
1
Silver badge
Coat

> 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.

I propose Miranda!

/ducks very low, runs very fast.

1
0
Silver badge

'mind-crippling' COBOL

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.

6
2
Silver badge

Re: 'mind-crippling' COBOL

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.

4
0
Thumb Up

Re: 'mind-crippling' COBOL

"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.

2
0
Silver badge
Holmes

Re: 'mind-crippling' COBOL

> 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

0
0
Silver badge
Pint

Re: 'mind-crippling' COBOL

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.

0
0

Re: 'mind-crippling' COBOL

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!!)

0
0
Silver badge

Why worry what languages a programmer knows?

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.

2
0

Re: 'mind-crippling' COBOL

With a decent editor you could be very productive.

Haven't we just had this discussion?

So vi it is then.

0
0
Silver badge

Proper programming language

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.

3
0
Silver badge

Re: Proper programming language

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.

11
0
Bronze badge

Re: Proper programming 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.

3
0
Anonymous Coward

Re: Proper programming language

Students should be taught Haskell and assembly language. If you can program well in both you can easily pick up any other language.

0
1
Silver badge
Boffin

Re: Proper programming language

"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.

0
0

Re: Proper programming language

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.

0
0
Bronze badge
FAIL

Oh COBOL, reminds me of a friend who went for a programming job years ago. The interviewer ask him what he knew about COBOL and my friend was up front and very honest with his reply'

"The only thing I know about COBOL is that it is an anagram of BOLOC!"

Needless to say, he never got the job...

0
0
Anonymous Coward

Memories of trying to get on the Y2K gravy train with COBOL were not good

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.

3
0
Happy

Timescales?

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.

3
1
Bronze badge

Re: Timescales?

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.

2
0
Silver badge

Re: Timescales?

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.

1
0
Silver badge
FAIL

Can it do recursion yet?

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.

4
2
Bronze badge

Re: Can it do recursion yet?

Yes. For decades now. Try to keep up.

4
0
Silver badge

Re: Can it do recursion yet?

"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.

1
0
Bronze badge
WTF?

Let me get this straight....

"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?

4
0
Bronze badge
FAIL

Re: Let me get this straight....

>>Two organizations out of six nine really can't be considered the lion's share

See I wasn't kidding about being tired, Ive been up almost 24 hours. Forgetting how to count. Should be a fun drive home.

0
0

Re: Let me get this straight....

Hopefully you're not in Scotland then:

http://www.bbc.co.uk/news/uk-scotland-21733521

A snowy ditch awaits your tired brain.

0
0
FAIL

Very Bad Advice

"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.

2
0

you devil you

not a single mention of that wonder of wonders RPG!

0
0
Silver badge
Joke

Re: you devil you

Rocket-Propelled Grenade?

Duck!

0
0
Bronze badge
Coat

Re: you devil you

No, he probably meant: really putrid garbage.

0
0
Silver badge

Learn COBOL, even if it cripples you mentally

I still have flashbacks about writing sequential files to tape.

Sometimes, late at night, I can still hear the tape flapping, and the anguished screams of someone that's just dropped a box of punch cards.

The horror.

2
0
Facepalm

Sigh

There's more to the IT industry than coding, but it seems that coding is all "computer science" students learn these days.

0
0

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.

0
3
Bronze badge

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.

4
0
Bronze badge

Not necessarily COBOL, but the way COBOL was used.

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.

3
0
Stop

Re: Not necessarily COBOL, but the way COBOL was used.

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.

2
0
Bronze badge

Re: Not necessarily COBOL, but the way COBOL was used.

@Tasmanian God - I quite agree. It was writing COBOL that made me the C++ programmer I am today. That also makes me old and embittered, by that is also probably more down to the environment than the language.

0
0
WTF?

Learning a language at uni for a job?

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?

3
0
Bronze badge
FAIL

Re: Learning a language at uni for a job?

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".

3
0

Re: Learning a language at uni for a job?

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.

2
0
Silver badge

Re: Learning a language at uni for a job?

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.

0
0

Re: Learning a language at uni for a job?

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.

0
0
Silver badge
Devil

Mind crippling

I was under the impression that was Java.

2
1

horses for courses

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.

2
0
Silver badge

The first DSL

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.

3
0
Stop

Re: The first DSL

Every capable C++ programmer will create his own Decimal class which will in most cases execute as a native 64 bit integer and be ten times faster than the Cobol DECIMAL stuff.

Plus, he will use containers with bounds checking and catch array index overflows any time.

0
1
Go

Re: The first DSL

Something like this: http://code.google.com/p/big-decimal/downloads/list

0
0
Go

Re: The first DSL

In DEBUG mode, the Decimal class will of course have a string attached which will nicely display the current value of the object in a debugger. In RELEASE mode, that string won't be there.

At least, that is how I would do that.

0
0
Bronze badge
Boffin

It is Eternal

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.

1
0

Page:

This topic is closed for new posts.