Hacker News Reader

Comment by tantalor | Hacker News Reader

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

Reply on news.ycombinator.com