4 ms·
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 programm
by vaidhy 7y ago
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..
- zozbot234 7y agoCOBOL copybooks are just .h files basically.
- tantalor 7y agoThat's not an issue with "style of programming", it's just complete disregard of software engineering basics.
- RickJWagner 7y agoEasy 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.
- BurningFrog 7y agoDon't mean to brag, but I already sneer at 2020 code!
- Twirrim 7y agoI've certainly found myself sneering at code I wrote just last week.
- Falkon1313 7y agoIn an effort to be more efficient, I've begun sneering at it as I write it.
- LeoTinnitus 7y agoI just don't write any code to avoid the sneer!
- omgwtfbyobbq 7y agoWhy not sneer proactively ahead of time?
- erik_seaberg 7y agoWe used to maintain multi-user machines with useful software preinstalled. It took tremendous post-deployment sneering to get from there to Docker.
- DonHopkins 7y agoI 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.
- deleted 7y ago[deleted]
- Kye 7y agoA classic JIT sneerer.
- asfgitnuinb89u 7y agoWe 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.
- OGWhales 7y agoThat 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.
- WrtCdEvrydy 7y agoDid software engineering exist back then.
- ptx 7y agoCOBOL was created in 1959. The term software engineering was coined in the 1960s. So it existed for most of COBOL's lifetime.
- PunksATawnyFill 7y agoYes, 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.
- ztjio 7y agoCASE 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.
- Zenst 7y agoSite 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.
- OGWhales 7y agoUsually 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.
- tonetheman 7y agoMan 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. :)