Hacker News new | past | comments | ask | show | jobs | submit login

I used to work on mainframe COBOL during the Y2K times. While the language is easy to pick up and the OS specific things are not too hard, the style of programming can lead to issues. Typically, shared data structures are often stored in separate files called copybooks and they can be hard to track down. Most of the code is not in any source control repositories which means no one knows which is the actual deployed version. It was all fun times then..



Site standards would play a huge part, you can write code without using GOTO in COBOL fine, and some programmers loved JSP (Jackson Structured Programming), yet modifying that code would make things open to whoever modified it and so the nuances and quirks of the programmer play out and code that has had many years of evolving standards and programming styles can be a right nasty mess that always begs a rewrite but the budget is for the change and no time for the rewrite. So the legacy snowballs.

Hence not all code equal and the site standards and that history as well as knowing that can make an almighty difference.

Never had copybook issues with ICL or Honeywell BULL platforms ;). That would be an IBM thang, but then, is there anything else still running - probably.


Usually you just compile the code to get the copy books. Ezpz. But yes its common practice in my office to carry a thicc black binder around for each companies’ copy book.

I’m newer to the mainframe industry but not that new and I’ve never seen a place that doesn’t have a source control repository. In fact, it’s required by law in every company I’ve worked for.


Man I remember copy books. I could do... just no where near NJ. And I am not interested in re-writing anything. Just the stuff working. :)


That's not an issue with "style of programming", it's just complete disregard of software engineering basics.


Easy there. We're standing on the shoulders of those COBOL giants.

What's obvious in 2020 was cutting-edge and forward-thinking in 1960. The rude kids of 2080 may sneer at your best code circa 2020.


Don't mean to brag, but I already sneer at 2020 code!


I've certainly found myself sneering at code I wrote just last week.


In an effort to be more efficient, I've begun sneering at it as I write it.


I just go m-x auto-sneer-mode and Emacs automatically sneers at my code as I write it!

I like to edit the source code to auto-sneer-mode.el in sneer mode, so it sneers at itself! Nothing more snarky than self-sneering code. I had to manually sneer by myself while writing it, to get it bootstrapped.


I just don't write any code to avoid the sneer!


A classic JIT sneerer.


Why not sneer proactively ahead of time?


We used to maintain multi-user machines with useful software preinstalled. It took tremendous post-deployment sneering to get from there to Docker.


We are not standing on the shoulders of COBOL. We are standing on the shoulders of ALGOL and LISP. Those languages influenced everything that came after in every field of computing. COBOL has had little influence outside of its silo.

We should absolutely respect the history of our field, but the mere fact that COBOL is old doesn't make it an important part of history.


That fact that the many industries, most importantly the financial industry heavily rely on it makes it an important part of history.

I agree cobol as a language is not particularly glamorous in terms of what it brought it computer science. I say this as a cobol dev, so I’m laughing, but it’s true: cobol sucks.


Did software engineering exist back then.


Yes, it did. In fact, CASE tools were going to be all the rage: computer-aided software engineering.

One of them was METHOD/1 from Andersen Consulting (now Accenture). If you wanted to create a variable to hold, for example, a part number... you'd create an entry in the CASE tool for it and from then on, everyone was supposed to use that one. It would have validation rules, like 30 characters, alphanumeric, whatever.

The CASE tool would do code generation for screens and forms and whatnot. And.... that's about as much as I remember at the moment.


CASE tools are widely used today, but, you will see them scoped very specifically the databases in systems where everything is built around the massive pillar of a major db implementation.

I worked for a company for little while that made extremely effective use of this approach allowing hundreds of devs to effectively work simultaneously on a single monolithic system. It was shocking. I was so impressed. I've still never seen any software organization so... organized. And they owed it largely to the protocols revolving around their use of a CASE tool.


Had source code control, albeit printed manual audited to the nth degree with any production changes having to be fully audited and signed off and compared with original with light boxes twice by separate people level of SCC. Yeah experienced that back in the 80's, it got easier though.

As for standards you would see from one company to another - early days and lucky to have separate department use same standards. So payroll would have different standards than marketing, but separate ecosystems and less of an issue, beyond team cultural changes and analysts quirks.

But then, standards change over time and become usurped.

So could very well ask the same question in 20 years time as the approach is always changing. May even be a call for C programmers then.


COBOL was created in 1959. The term software engineering was coined in the 1960s. So it existed for most of COBOL's lifetime.


The term teleportation was coined awhile back too.


The term "software engineering", at least as used by Margaret H. Hamilton in the 1960s, was used to describe existing practices.

"Teleportation" was not.


That's an incredibly bad argument. If they wrote the programs 40 years ago and still use them they had 40 years to fix the business process. You can't argue that something is broken because it's old and then argue that you didn't have enough time to fix the process.


I wouldn't assume the fault is with the people who built the system. There is a reason they're looking desperately for people who know COBOL. Implied: they don't have any, and the systems have been ticking along for decades with the occasional call to a consultant who asked more than they would pay to modernize them.

Now management will pay even more because they're desperate and end up with a rushed solution that breaks again in the next crisis.


No. Nothing existed before you started using Javascript in your moms basement a couple of years ago. Wirth, Booch, Brooks, Neumann, Bachman, Dijkstra, Belady, Parnas and the rest never did anything worth much.

Why do some people take joy in wallowing in ignorance. Sad.


Did you ever wonder how Internet was created before the Internet


COBOL copybooks are just .h files basically.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: