Why uncommented?
I took a beginning course in programming in 1980(Fortan IV), and there was a huge emphasis, both from the professor and in the textbook. on adding comment lines everywhere.
Comments made it much easier to correct your own work a day later when , after drawing up a flow chart in pencil, and then typing in your code for a couple hours, you pressed the magic button to run your program, and…it didn’t do anything, or it did it all wrong. But your session time had expired, and you had to wait a half a day to sign up for another hour or two of time on at the keyboard in the computer room.
You HAD to use comments to submit your project on time before the end of the semester .
Why didn’t engineers writing more complex code use comments? It would have been for their own benefit,making their job easier.
Sorry, but your post makes me smile. You described a beginning course in programming. The real world is just so way much different.
There are a number of answers to your question, like this attitude: “I’m paying you guys to write code, not comments”. There’s plenty more like that. I hope you weren’t expecting any good reasons.
Had a jerk of a temporary supervisor refer to me as “a lazy m~ f~” for the reason that I was writing comments at the same time as I was learning the damn programming language he insisted I use, a program obviously not fit for the purpose. His “idea” was that I was taking time away from productive work by writing the comments.
I felt like a new person when I walked out of that job that day. And I began to do so much better at college after leaving that job, too!
I cannot imagine how professional and trained programmers deal with such nonsense on a daily, if not hourly, basis.
I would hope that very few managers are as stupid as that one was.
The very word “comments” is somewhat misleading. What it really means is “description of the logical function” of a statement or procedure. But for complex systems, such commentary is only the lowest layer of understanding for someone trying to maintain a legacy system. It’s critical to have a well-written overall system design document, sometimes called a system architecture document, that describes all the components and their interfaces, and how they interact to fulfill the system requirements, which should also be well documented. For large software systems, the individual components should also have detailed design documents. The code comments are just the lowest level of that hierarchy, but often extremely essential details of how the code was actually implemented, including clever “tricks” that programmers had to use in legacy systems to optimize limited resources like memory. Without that kind of well-structured documentation hierarchy, maintaining large complicated legacy systems is virtually hopeless.
I did COBOL programming for a utility company 30 years ago. Wasn’t really a bad gig except for the pay. I’d dust off those neurons if sufficiently motivated. But NJ and volunteer? Hell to the NO^2.
We were on a rocky relationship after I had informed him earlier on that his plan of having the department’s site visit counter automatically increase at random increments at random times is unethical.
I’m not quoting the rest of your post, but that’s essentially what my high school math teacher way back in the late 1970s told us when he taught us computer programming. He did not accept programs without comments.
Speaking of those long ago days, one of my brushes with fame is that i got to know Admiral Grace Hopper. Too bad she’s not still around. She’d take care of New Jersey’s problem in nothing flat!
One of the nice features of COBOL is that it’s so verbose that it’s largely self documenting, as long as the coder is reasonably well trained in naming when declaring variables. Sections say what they are. Function and procedure calls, same.
Still, in line commenting was always encouraged as a good habit.
The problem is not the differences between modern implementations of COBOL and the 1968 one, or modern implementations now being able to write code that runs on whatever hardware they have. Someone who knows COBOL-2014 would have no trouble with COBOL-68 specifically. The problem comes in with 40-year old code that they might not have source code to anymore, and if they do that has sparse comments and no documentation, and that interacts with lots of other 10-20-30-40 year old programs in ways that also aren’t documented.
Just knowing how to write a program to COBOL-68 spec is not what they need - they need someone familiar enough with the language and the kind of apps written to delve through all of the old code and update it without breaking any of the weird functions that no one even realizes it does anymore. If they do mess up, then it probably involves money going to someone that shouldn’t get it or not paying someone who should, and is likely in violation of state law.
I’ve worked at a state agency that was running their main app’s web server on Windows 2000 software until last year for similar reasons, things were written in a modern programming language but untangling all of the weird interactions and unknown source code were too much to do. They couldn’t upgrade the OS from Win2k because they relied on specific versions of supplementary software like Merchant Server that was only available on win2k and weren’t sure what would be needed to use more modern ones. They were stuck on hardware upgrades around 2014 because vendors started saying ‘what the hell is wrong with you’ when you asked about win2k drivers. They finally replaced the whole web site with a completely new app rather than try to update, and that project took about a decade to finish.
“40 year old mainframes” is what you end up with after a reporter hears from a press person who was told by a manager who was told by a tech person that the application software they’re trying to update is 40 years old and runs on a mainframe. I’d be willing to bet good money that it’s the code that is 40 years old and not the hardware, as IBM was really big on backwards compatibility and moving a system to more modern hardare is not that difficult. Would not surprise me if the hardware is 20 years old or more, but 40 years is far enough back that I’d expect that they actually did a physical upgrade at some point.
Q. for developers: if you had to roll out a large statewide mainframe-based payroll or unemployment system today from scratch, what language (if not COBOL) and what components would you use?
Constraints are the usual: has to work as intended, be rock-solid enough to operate for decades without any downtime, etc.
I wouldn’t take part in such a fiasco. I can make plenty of money from it a couple of years later when the projections show the existing plan won’t be complete until 2093 and they start considering reasonable solutions.
The behaviour of computer programs can (in theory be formally specified. Don’t know if that’s on the computer science curriculum or industry standards.
If the state did not buy an UI software package they would probably get someone to write it in Java with HTML and possibly PHP or JavaScript. Storing data could be Oracle or SQL server or a free package like Postgres.
I wouldn’t think lack of COBOL knowledge really makes a lot difference. In the modern era, programmers have to use a wide variety of languages and rarely get any traditional education for them. The last time I was in a class was to learn C++ back in the 90’s. Since then, I’ve had to learn at least 10 new languages and programming environments on my own, and the only education provided has been “find a tutorial on the web”. COBOL has its quirks like any language, but it’s generally readable and any reasonably competent programmer will be able to teach themselves what is necessary to make the changes.
be formally specified. Don’t know if that’s on the computer science curriculum or industry standards.