Inheritance
-
I’m sitting here looking at C files that have existed for well over a decade, and this thread makes me feel like I’m living in luxury and only one notch below vibe coding.
I've got Java code older than a decade I have to deal with too...
-
COBOL is still on my to learn list.
I can't recall if it was COBOL or FORTRAN, but I tried learning one of them after being pretty confident in picking up any other programming language I've tried to learn, including assembly (wouldn't want to use that for large projects but I've written context switches and such), but I ended up giving up because it felt like the learning materials themselves were in some other language.
Which sucked because I'm the kind of guy that thinks a task like refactoring millions of lines of legacy code into a more modern language would be fun (or satisfying at least). Phase 1 would be a 1:1 conversion (probably involving implementing various old language features in the new language or assembly to do it piece by piece), followed by phase 2 which would be a full redesign and rewrite, using the knowledge from phase 1 to ensue full feature parity. Because "we rewrote software but the new version doesn't do x, y, z that the old one did" sucks. Glances at Blizzard.
-
I can't recall if it was COBOL or FORTRAN, but I tried learning one of them after being pretty confident in picking up any other programming language I've tried to learn, including assembly (wouldn't want to use that for large projects but I've written context switches and such), but I ended up giving up because it felt like the learning materials themselves were in some other language.
Which sucked because I'm the kind of guy that thinks a task like refactoring millions of lines of legacy code into a more modern language would be fun (or satisfying at least). Phase 1 would be a 1:1 conversion (probably involving implementing various old language features in the new language or assembly to do it piece by piece), followed by phase 2 which would be a full redesign and rewrite, using the knowledge from phase 1 to ensue full feature parity. Because "we rewrote software but the new version doesn't do x, y, z that the old one did" sucks. Glances at Blizzard.
FORTRAN is godawful, I can only image what COBOL is like. They're my counter to the people think languages essentially don't matter. No guys, there has been progress over the eras.
-
This post did not contain any content.
When “What idiot wrote this?” is replaced by “I should call my mom.”
-
This post did not contain any content.
COBOL isn't hard to read, it's just hard to understand why someone made that decision. Context is key.
-
COBOL is still on my to learn list.
wrote on last edited by [email protected]Opencobol or gnucobol is good. You vmcam install it on any Debian based system no issues.
-
I’m sitting here looking at C files that have existed for well over a decade, and this thread makes me feel like I’m living in luxury and only one notch below vibe coding.
Any COBOL program is closer to vibe-coding than a C program that works.
But not dealing with vibe-coding is the luxury.
-
For some reason, COBOL has had OOP features since 2002.
For some reason
It's because "every language must do OOP".
Every SQL engine does it... SWI Prolog seems to have escaped, but COBOL had no chance.
-
Tangential, but I'm working with some code that started out in the punch card era (I'm doing particle physics, it's in fortran)
My first coding experience was as a kid on punch cards (and I'm not even 60 yet). This was in the late 70s and I had an older neighbor friend who was in high school but taking some classes at the local university. The intro programming class that he took still used punch cards on mainframes (though this was being phased out even then) and my friend sort of Tom-Sawyered me into helping him with his homework. It was actually kind of fun to sit there punching the holes in the cards, and then we'd take the stack of cards over to the CS building and leave it in his mail slot, and then a few days later you'd get a giant stack of that old green- and white-striped computer printout paper deposited there with the program's results.
It's interesting, it really taught me to check and recheck my own code extremely thoroughly and carefully before "running" it, rather than pumping out some slop quickly and relying on the compiler and/or the output to identify any problems. Because with multiple days between submitting the code and seeing the results, you really had to make sure stuff was working from the get-go. In my career as a programmer, I subsequently ran into many similar situations that required basically just your own eyeballs to make sure the code was right. When I was writing Blackberry applications circa 2010 (!) for example, RIM's utterly fucked-up developer environment meant that the delay between starting to compile an application and having it running on a test device could be 30-45 minutes or more (if it finished compiling at all) even if I'd only made a single one-line code change. So I had to get back in the habit of very carefully writing a lot of code before attempting to compile, and making sure it was going to work correctly just by inspection.
-
Impressive to work that long on something and not change the code at all. The mom('s team) was either very competent at writing configurable code or very good at pretending to work.
I wrote a web app for a client back in the late '90s that is still in (heavy) use at the company. It was actually a "Classic ASP" app and they kept one old PC around to act as the server for it for a couple of decades (they eventually replaced that with a virtual machine and the app is still going). The output is straight HTML + CSS so they've never had any problems using it with progressively more modern browsers. Ironically, this app is a front end sitting atop an unbelievably clunky mainframe application that dates to the 1970s, so my app's continued existence means that mainframe application is still running as well.
