7 ms·
On COBOL
- ketanmaheshwari 6y agoThe article mentions that COBOL was an easy programming language to learn. Personally, I disagree. As a beginner in a CS course, it was incredibly hard to comprehend why a program needs so many sections and why the various lines must start at a particular column. C seemed easy in comparison.
- pjmlp 6y agoWhen COBOL was invented C did not even exist, it only came to be about 10 years later. The alternatives were Assembly, FORTRAN and ALGOL.
- kyberias 6y agoBut they have coexisted at the same time haven't they?
- pjmlp 6y agoThey have coexisted since early 70s, back when C was invented. However where COBOL rules is on mainframes, which after Assembly have always used PL/I derived systems programming languages (like Unisys, IBM i and z/OS), so on those systems C is just another guest language and hardly anyone cares to use it beyond porting software to their POSIX runtimes.
- protomyth 6y agoUnlike Fortran, COBOL really hasn't evolved in the C dominated world. Although C is really dominant on the platforms COBOL lives on.
- pjmlp 6y agoWhat?!? Cobol has had its last revision in 2014, supports modules, OOP, and even has .NET and JVM backends. MicroFocus and Fujistsu also have frameworks for cloud deployments and writing microservices in Cobol. Almost no one cares about C on mainframes beyond porting some POSIX stuff, or running Aix/Linux on an hypervisor.
- protomyth 6y agoThat's basically it, no one cares about C on the mainframe so COBOL doesn't deal with the C competition and C flaws that fuel Go and Rust. COBOL itself has advanced but it doesn't have the same competition.
- pjmlp 6y agoThey don't care about C because mainframes always had better alternatives for systems programming, via PL/S, PL.8 and NEWP, as the three major surviving ones. Even BLISS and Mesa were better than C.
- protomyth 6y agoIf I remember correctly OpenVMS was programmed in something else also. It would have been interesting if one of the PC operating systems had decided to use one of those languages. So, no C, no interest in 'I need a C replacement language', enterprise software is boring, so no COBOL replacement. Plus, I know of at least one vendor who did develop something but it is kept in-house. I did expect someone to develop yet another REXX to address this need.
- skissane 6y ago> Almost no one cares about C on mainframes beyond porting some POSIX stuff, or running Aix/Linux on an hypervisor. I think, with Metal C, that's less true than it used to be. My understanding is that, for brand new z/OS components (e.g. Zowe, z/OSMF), IBM prefers Metal C to PL/X. It is also seeing increasing use by mainframe ISVs as a replacement for assembly and PL/X.
- fortran77 6y agoThe column requirements are a holdover from the days of punchcards, where column 1 was reserved for JCL commands and some columns were reserved so cards could be numbered and sorted by mechanical means.
- kens 6y agoMany of IBM's early mainframes could only read 72 columns from a punch card, which is why Fortran (and I assume COBOL) only used 72 columns. Specifically, the IBM 704 was a 36-bit machine and read punch cards one row at a time, filling two 36-bit words. There was a wiring panel that let you select any 72 columns to read, but obviously using the first 72 columns was most sensible. If you punched sequence numbers in the ignored columns 73-80, you could use an electromechanical card sorter to put the cards back in order if you dropped them.
- fortran77 6y ago> if you dropped them. Or if someone shuffled them (as we used to do in the computer room to people who annoyed us.)
- praptak 6y agoMy professor told us of a technique he used to recover from stack drops. Draw a pattern with a felt tip pen across the side of the stack (on the edges of the cards). This way a quick glance can tell you if the stack is out of order and it's also faster to sort manually.
- praptak 6y agoThe article focuses on technical skills and people who need to acquire them. Which may be a problem but I don't think it is the root cause of the COBOL problem as a whole. There are organizations which dug themselves into the COBOL hole. What are they doing to get people to learn the skills necessary to deal with the next crisis?
- pjmlp 6y agoTeaching them Visual Cobol or NetCobol, :) https://www.microfocus.com/en-us/products/visual-cobol/overview https://www.microfocus.com/en-us/products/visual-cobol/overv... https://www.fujitsu.com/global/products/software/developer-tool/netcobol/index.html https://www.fujitsu.com/global/products/software/developer-t... Who knows, that cool Kubernetes microservice deployed on Amazon might have been written in Cobol, https://www.microfocus.com/media/success-story/trasmediterranea-acciona_tcm6-210848.pdf https://www.microfocus.com/media/success-story/trasmediterra...
- dwheeler 6y agoThe Linux Foundation's "Open Mainframe Project" has a free COBOL training course. More info here: https://www.openmainframeproject.org/projects/coboltrainingcourse https://www.openmainframeproject.org/projects/coboltrainingc...
- epx 6y agoCOBOL was like so many 4GLs: easier for starters and vanilla tasks, but makes things increasingly difficult as you need to grow out.
- KineticLensman 6y ago> COBOL was like so many 4GLs: COBOL was one of the original 3GLs, and appeared in 1959. The concept of 4GL wasn't even formalised until 20 years later in 1981 [0] [0] https://en.wikipedia.org/wiki/Fourth-generation_programming_language https://en.wikipedia.org/wiki/Fourth-generation_programming_...
- epx 6y agoI said it was like 4GLs. And perhaps the creator was ahead of her time? :)
- mercantile 6y agoIf you don't know COBOL, Wikipedia has a pretty excellent overview of a lot of its basic syntax here: https://en.wikipedia.org/wiki/COBOL#Features https://en.wikipedia.org/wiki/COBOL#Features It's very verbose, and includes a lot of opaque language that almost seems designed to confuse (I know it wasn't actually, but it's pretty bad). For example, an alphanumeric variable type is called a `PIC` for "PICTURE". You can store an alphanumeric as a `PIC A`, or a numeric-only using a `PIC X`. Fields in a record get a "level number" that defines their behavior, and you just have to memorize which does what. 01 is a top-level record. 05 defines a subgroup. 88 is a conditional record. There are many parts of the language that are clearly anti-features in retrospect. A 66 level number allows you to redefine a field in a previously defined record. Convenient in some cases maybe, but something that will clearly lead to maintainability problems as the shape of a record doesn't match its original definition in code. Another example is that COBOL has a huge vocabulary, with the original idea that you could write things as much like English as possible (e.g. use a `GREATER THAN` instead of a `>`), which is one of those things that probably seemed like a good idea at one point, but which every modern language has abandoned or is abandoning (through the use of linters, etc.). The article makes quite a few salient points, but on the other hand, if there's ever been a language that got almost everything wrong in about as objective a sense as you can get when speaking about these things, it's this one. Instead of inspiring the next generation of COBOL programmers, IMO there's a good alternative argument to be made for getting a bunch of smart people together to write a transpiler that could transform huge legacy COBOL codebases to something more maintainable, like how the Go team transpiled from C to Go, and vanquishing this language to the history books. Obviously very difficult, but something that'd pay off in the long run.
- Yetanfou 6y agoIt helps to understand COBOL in the context of its environment: punchcards containing a single line of code, hierarchical (e.g. IMS) and network (e.g. IDMS) databases, the intended application being business data batch processing on mainframes, etc. In this context those field and record specifiers (etc.) make more sense.
- Smoosh 6y agoSorry to criticize, but as a daily maintainer/writer of COBOL, your characterization is a bit off. Besides technical inaccuracies (PIC 9 is for numerics, 88 is a conditional value in a field) you don't seem to grasp what's truly right or wrong with COBOL. Nor does the article. For example, ime no-one uses 66 levels, as the REDEFINES clause achieves the same result. While there _can_ be issues with maintaining code with overlapping definitions, _their use is deliberate_. For example, data read from a file could have two or more different record structures. It is read into one place in memory and the redefinition applies different formats/views to the same memory. The correct one is used as needed. There is no problem. You might be right that there are some anti-features, but like GOTO they simply aren't used in real codebases. The real problem with COBOL imo, is that the language hasn't much improved since it's creation. While there have been some useful tweaks and changes, it has missed out on major items such as variable scoping/user-defined functions (all variables are global - the workaround is to use sub-programs and pass data in the call). Even "object-oriented" functionality as mentioned in the article was badly tacked on to the language and only complicates it without really adding much in terms of capability. Also, the language doesn't really have strings as in other languages, and consequently lacks the applicable functions. Another major point that the article misses is that mainframe COBOL (most COBOL is/was mainframe and that means IBM) which does anything more than straightforward "read file,process contents,generate report" is inextricably linked to its environment. The article talks about poor form handling. COBOL doesn't do form handling. That would be CICS or IMS/DC software which the COBOL interfaces with. There is heavy integration in the code, but this is like confusing Java with Websphere or Tomcat. This is why it is so difficult to port COBOL systems to another language/environment. The COBOL code can be mechanically converted. But any complex system has calls to databases, transaction processing, and is built with batch jobs relying on JCL and system utilities. Replacing the environment while retaining the integration and reproducing the functionality is the hard part.
- greencore 6y agoI think that the problem is not that coders don't want to learn COBOL but that it's so niche language and you have almost no job mobility. If corporations would offer contracts with extra huge severance packages then IMO there would appear enough COBOL enthusiasts.
- spaced-out 6y agoSeriously. Every time I see one of these COBOL articles posted here, I just scroll through to see if there are salary stats, there never are. If you want to convince people to learn COBOL, convince people you can have a great career as a COBOL developer, or at least as a developer with COBOL in your toolkit. I've yet to see anyone convincingly make that case.
- praptak 6y agoAlso it's not like you are fighting Covid or the global climate change. Helping solve "the COBOL crisis" will just let some corporations save some money.
- JustARandomGuy 6y agoWe always have these articles about needing to learn COBOL, - I think we see more of them since there’s more pressure on old systems such as unemployment these days - but it’s important to note to anyone reading this that learning COBOL is not going to lead to riches: I know several COBOL coders and while they make a respectable amount, it’s nowhere near the amount they’d earn at a FANG company. Learn COBOL if you want - I learned COBOL early in my career and it’s very interesting how different it is - but if you’re attempting to maximize salary you’re better off spending time learning the bleeding edge tech.
- raverbashing 6y agoI don't think any salary would be enough to compensate for the opportunity cost of not working with a modern technology and the mental strain of working with something so quirky and archaic
- js8 6y agoIt also has upsides. It might be archaic, but the code is mostly self-contained, there are usually no layers of open source that might make behavior difficult to understand. (And for problems with middleware you just call the vendor.) Programs are typically designed to be algorithmically simple, the complexity mostly comes from history and changing business requirements. Mainframes are surprisingly transparent systems, if you learn where to look, compared to Unixes. There are many logging and tracing facilities that run all the time. For these reasons, some people actually enjoy it more to work with these systems.
- Yetanfou 6y ago> there are usually no layers of open source that might make behavior difficult to understand Ehhhh.... this in contrast to closed systems where there are layers of closed source which lead to all sorts of unexpected behaviour without the recourse of looking under the hood to find out what is going wrong. Closed systems are harder to debug than open source systems.
- acqq 6y agoI have written a pair of compilers (not COBOL) myself, so at one moment I've thought about that possibility: "maybe I should spend a little time improving my COBOL knowledge and move to that niche." I wouldn't have problem working in archaic language, thought I. Or with non-trivial codebases. But then I've got another impression: the companies don't expect a new candidate just to knew the language and work with old codebases. They expect also the people to be able to work with ancient terminals, as in: no grep for you. Even worse it's "no ASCII for you." I.e. not a single tool to which I'm used I'd be able to use. Whatever I'm used to work with, I won't be able to use. That's where I became demotivated.
- js8 6y agoI work on the mainframes. It's straightforward to download the code to modify it locally and re-upload it. Then you can use all the tools you're comfortable with. We are moving towards using Github as a main source repository, even for mainframe code. However, yes, knowledge of how to operate 3270 terminal is required. And it has a form of grep, actually, as well as compare tools. EBCDIC is just another encoding, not a huge problem.
- Animats 6y agoEBCDIC. That's still around? Ugh. COBOL apparently still has major problems with UNICODE. COBOL in IBM land can only do UTF-16. Some IBM products are big-endian UTF-16, and some are little-endian UTF-16. COBOL (PeopleSoft version) in Oracle land can do UTF-16 and, sometimes, UTF-8 in programs for fields not stored in the database. It's late for the language to be in that state.
- protomyth 6y agoI figured that one reason COBOL and RPG IV continue to exist is that a replacement language that can check all of the boxes hasn't been developed. It is just not that cool a job to write a COBOL replacement like it is to write a C replacement. Rust and Go need a bunch of libraries to do COBOL's work. Frankly even with the libraries, both are too complicated to replace COBOL. It just isn't a cool area like most Enterprise software.
- booleandilemma 6y agoJust pay COBOL developers an obscene salary. You'll have tons of eager applicants claiming to have years COBOL experience at your door in no time.
- zerr 6y agoExactly, and in general - there is no shortage of programmers - there is a shortage of programmers who are willing to work for 5-figure.