The Power and Significance of COBOL: A Language for the Ages

There are very good reasons for Coccupying a special place in the firmament of languages, although I think one thing to say at the outset is really it finds its maximum power - it's maximum raison d'etre for even existing at all - if you think of it as being the classical system implementation language. This perspective may be challenging for younger viewers to understand and comprehend, but exploring this idea further will provide valuable insight into the significance of COBOL.

For those unfamiliar with the term "classical system implementation language," let's take a step back in time. We're talking about the early mainframe era, which spans from the 1960s onwards. By these standards, computers were incredibly powerful and expensive, to the point where they had to be shared among multiple users. This necessitated the development of system software that could multitask between different people, programs loaded onto the machine at the same time, all being time-sliced with a little bit of time.

As computers evolved in the early 1970s, one of the biggest challenges facing programmers was not just about output and answers but also about storing data in files. This required operating systems that could manage file systems effectively. At this point, one of the hardest challenges in programming was reduced to nothing more than the operating system itself.

The Wisdom Behind COBOL

One of the earliest and most influential programmers of COBOL put it this way: The wisdom behind COBOL is that it's not just a language, but a way of thinking about how computers work. This perspective highlights the significance of COBOL as a system implementation language. By recognizing its importance in managing multiple tasks and file systems, we can appreciate the innovative spirit behind its creation.

As COBOL continues to be used today, its legacy is undeniable. From its role in implementing mainframe operating systems to its use in a wide range of industries, including finance, healthcare, and government, COBOL has proven itself to be an incredibly versatile language. Whether you're a seasoned programmer or just starting out, understanding the significance of COBOL can provide valuable insights into the world of computer programming.

In the next section, we'll delve deeper into the features and capabilities that make COBOL such a powerful language, as well as its continued relevance in today's digital landscape.

"WEBVTTKind: captionsLanguage: enThere are very good reasons for Coccupying a special place in thefirmament of languages, although I thinkone thing to say at the outset is reallyit finds its maximum power - it's maximumraison d'etre for even existing at all - if youthink of it as being the classicalsystem implementation language. Again, foryounger viewers, it's going to be hard tounderstand and comprehend this. But ifyou go back to the early mainframe erayou're getting really, really, powerfulcomputers - well by those days' standards -coming along, from the early 60sonwards. They were so expensive they hadto be time-shared between lots of usersand that in turn means you've got tohave system software that can multitaskbetween different people, differentpeople's programs loaded in themachine at the same time, all being time-sliced with a little bit of time. But atthe same time, increasingly, computersystems had to evolve into not justbeing able to print out your output andyour answers but to store it in afile; they had to run file systems. Andby the early 1970s you are in thisincredible situation that one of thebiggest challenges in programming - areal-time challenge where you had tokeep people happy - was nothing more orless than the operating system in yourcomputer. One of the hardest challengesgoing. And, yeah, the wisdom was: \"You willonly ever be able to do this inassembler\". Some of the low-level tricksyou need to do in operating systems - youknow the `real man' attitude: \"Real Men useassembler!\" And I think a lot of peoplesaid: \"No, there's some truth in that buton the other hand just a little bit ofhigher-level operations - if only it couldbe done without slowing the languagedown too much would help us stay sane.I think a lot ofpeople, gradually, were, if you like,embellishing assemblers to become macro-assemblers to try and give the kind ofhigher-level approach to things that yougot in high level languages. But on theother side the opposing armies were alwayssaying: \"High-level languages - they're soinefficient! You need assembler foreverything, ideally\". Moore's Law put paid tothat, y'know. Yes, we can afford to usehigh-level languages for a lot morethings in the early 70s. Then therewere a lot of experiments in trying,usually, to adapt existing languages forsystem implementation use. Andparticularly ones that had started tobuild in some low-level operations forbit twiddling. It was getting importantto be able to dig down to the byte level andget out characters. Looming up, just onthe horizon, shock! horror! as if 16 bitswasn't a toy computer - 8 bits coming.So you needed a language to evolve thatcould cope with different widths ofobjects. Of course as it becomes ... you gothrough a sort of - like a minimum - in thecurve. You know - we have to chop thingsdown in size because otherwise we can'tmake it at a price that people will buy.But then, as hardware becomes cheaper,generally you then turn the corner. Andyou could see it even in DEC andtheir PDP-11 minicomputers. Soon enoughthey come along with a 32-bit computerwhich they can afford to make at longlast. And, of course, that was the era whendiscrete transistors and components, onprinted circuit boards, gave way to chiptechnology. So you have, like, LSI-11s.It's large-scale integration, it's notseparate components any more. Andgradually the curve turns the other way>> Sean: How did this change in architecturefeed back into the language choices then?>> DFB: Well, I think that it's two things. Firstof all, can you get a system implementationlanguage that helps you do low-levelthings at a higher level? And I stillthink that, probably, you could saythat the most successful of all time - and onthat front - was C. It's not that there weren'tothers. There were things like Bliss, therewere things like, even, Algol 68. And otherhigh-level languages, BCPL, were tried out.But C had the great advantage that youcould see how you might port it. Ah! yeah!Dennis, Ken all that. They're doing it onthe PDP-11; they'll be doing it on theVAX but up come the SUNs, all of asudden. The SUN servers. Hey! can we portUNIX to this? We're porting UNIX - we got toget the C compiler working! Can you getthe C compiler working - yes ofcourse you can. And it really stood thetest of time. I mean when you look now, inthe `gcc' compiler, at the architecturesthat are supported, it just writes itsown brochure saying: \"Just look at this, wecan cope with anything!\" However, the otherside of that, was then thedifferentiation to, if you like,higher-level languages - even imperativeones - just became more marked. And I thinkit was very interesting that - I think itwas in the mid to late 80s - James Goslingof Sun effectively ... it's people whorun programmers and see how manymistakes they make when they're usingpointers. And, as far as I recall it, oneof the design requirements of Java was:\"We're gonna ban pointers at user level\".When we start looking at whyprograms go wrong it's people who'vemade mistakes with pointers. So thereforewe're gonna ban them. I'm actually notagainst that. If you really don't need todo low-level manipulations of pointersthen let the language do it for you.Or if it's like C++ where you could dothem and you say I don't want to do allmy clever stuff under the hood - I'm notwriting an operating system. Yeah! gethold of a library full of functions andtrust them because they'll have beentested. They'll be efficient and all this kindof thing. So, yes, things like functionallanguages, which of course always used to -still do! - get flak for being so slow,They became more and more possible to doI suppose Brian might say they got`less and less inefficient' y'know. Butno, it was a liberation to have that muchcompute power around that you didn'thave to think too much. I'm glad thatmany sensible souls on the commentstreams of recent videos have said this.It's no good getting theological about:\"You're not a real programmer if you don'tprogram in C\" or anything silly likethat. You've got to have an attitude of`horses for courses': the right programminglanguage for the right task. If it'syelling out to use Python, use Python. Ifit's yelling out to use AWK - as I'vebeen known to do ... Yeah! I tried out, as youknow, my Reed-Muller `messages from Mars'I got it ... hacked it together in AWK.Well, why not? You can always take theview that if it's not efficientenough we can drive down to a lowerlevel, more efficient, language. But theability to try things out, without themtaking hours and hours - because of reallyfast hardware - is probably about thebiggest liberation I can think of interms of my professional career as acomputer scientist.>> Sean: You know I'm not a programmer.I mean, one day it might make avideo - my bad exploration of BASIC in myyouth. But, as a non programmer I supposeI come at this and think, well, why can'tthere be one thing that fits all and mykind of taking examples fromother parts of life. Presumably certainthings are good for certain things like you say>>> DFB: I think that's right. I think thatyou see it in all sorts of other realmsin life. It's that you know the trueprofessional tool for doing something - itwas probably very different from a user-leveltool. Y' know, I mean, if you go to ahardware store and buy yourself a drillwith a hammer action, you know that's avery different object from what theywould use industrially to hack intobuildings. It's in principle the same butthe whole spec. and construction of itis very different. And that's what wenow have the ability to do, is to fit thelanguage to the task.Of course, it still leaves a big problemthat lots and lots of software ideallyshould have been rewritten years ago.Because the moment you get somethingthat's good for its time, and works, thetemptation is just to leave it in placebecause it works and we daren't change itbecause so many things are dependent on it.So, this is why there are still 8-bit Z80programs doing heaven knows what in theArmed Forces. There are probably still companies outthere, in the wild, still using COBOL onmainframes. You know cost of a mainframesimulation these days? Peanuts! Thatprogram cost us a fortune to rewrite it.And it's bound to go wrong, And it's knownand reliable so that thing about havinglegacy software and hardware and it's sodifficult to trust to replacing it. It'sstill is going to be a problem eternally I think, that.>> Sean: well there is awell-known phrase: \"If it ain't broken, don't fix it!\">> DFB: What's helped the `ain't broken'bit, you see, that's the thing, is that ifthere's something rather exotic on thehardware front, from the 1960s, you nolonger have to literally build one ofthose. You can simulate its action. So aslong as you put a lot of effort intogetting a good simulator going, then youcan carry on with the code you've hadfor 30-40 years in some cases.\n"