The World Depends on 60-Year-Old Code No One Knows Anymore
byu/debordian inprogramming

Ancillas
Had to learn COBOL and JCL at my first job. It wasn’t tremendously hard, but there was a huge volume of programs to understand.

At one point I was maintaining code written in 1969 where there was a bug that no one was supposed to fix because there was 45 years worth of programs that assumed that bug was present.

midri
Load bearing bug

ejfrodo
I spent a while building a code analysis tool for an ancient proprietary language that was basically a superset of Pascal. A multi billion dollar company was built on this. Nobody at the company fully knew how it worked because they’d all retired years ago so I just had to be a code archeologist and hunt through the ruins. That was an interesting project

giantsparklerobot
Part of the problem with COBOL is it was meant for non-programmers to be able to encode/automate literal business logic. Maintaining or replacing a COBOL system isn’t only about just the code. The under-specified business process needs to be reimplemented with 50-60 years worth of special exemptions and in many cases load bearing bugs.

You can learn COBOL as easily as any other language. It’s much harder to bring in someone that understands the business process that COBOL automated.

RearExitOnly
Finally someone who gets it. I was well paid not because I was the worlds best COBOL programmer, but because I was an expert on grain contracts. In the Midwest I was never out of work and usually made more than double what PC guys were making back in the 80’s.

Maleficent_Mouse_930
I am currently leading a squad developing a replacement for a core banking program originally In COBOL, and the complexity is 100% in the actual operations. The code ain’t too tough, but it’s been 18 months so far of reverse engineering back and forth with the finance and compliance guys trying to nail down what’s needed. Every time we find a new intricacy and tell them, they’re like “Oh yeah, didn’t we tell you that?”

Morons. They’ve been relying on this software so long they don’t even know their own jobs any more.

Many of these books claim that by creating these abstractions, in this example Person, you can “re-use” them in other projects. However, in 15 years of my professional experience, I have hardly seen many (or any) examples of such abstractions being used across projects in a useful manner.

At one point, I started creating a class library of these abstractions that I could share across projects. After a little while, that class library ended up being bloated with lots of unrelated abstractions and versioning it across different projects ended up being a nightmare. If you have done this before, you may relate to this story.

Once I was engaged as a consultant for a greenfield project, and in the introductory session, the data architect of the project walked me through tons of UML class diagrams (more than 50 pages). Every class was inheriting from another class and eventually, they all led to a class that was called “Thing”! No joke!

What text books tell you about inheritance in OOP is wrong
Mosh Hamedani

There are multiple GUID generation algorithms, but I’ll pick one of them for concreteness, specifically the version described in this Internet draft.

The first 60 bits of the GUID encode a timestamp, the precise format of which is not important.

The next four bits are always 0001, which identify that this GUID was generated by “algorithm 1”. The version field is necessary to ensure that two GUID generation algorithms do not accidentally generate the same GUID. The algorithms are designed so that a particular algorithm doesn’t generate the same GUID twice, but without a version field, there would be no way to ensure that some other algorithm wouldn’t generate the same GUID by some systematic collision.

The next 14 bits are “emergency uniquifier bits”; we’ll look at them later, because they are the ones that fine tune the overall algorithm.

The next two bits are reserved and fixed at 01.

The last 48 bits are the unique address of the computer’s network card. If the computer does not have a network card, set the top bit and use a random number generator for the other 47. No valid network card will have the top bit set in its address, so there is no possibility that a GUID generated from a computer without a network card will accidentally collide with a GUID generated from a computer with a network card.

Once you take it apart, the bits of the GUID break down like this:

• 60 bits of timestamp,
• 48 bits of computer identifier,
• 14 bits of uniquifier, and
• six bits are fixed,

for a total of 128 bits.

The goal of this algorithm is to use the combination of time and location (“space-time coordinates” for the relativity geeks out there) as the uniqueness key. However, timekeeping is not perfect, so there’s a possibility that, for example, two GUIDs are generated in rapid succession from the same machine, so close to each other in time that the timestamp would be the same. That’s where the uniquifier comes in. When time appears to have stood still (if two requests for a GUID are made in rapid succession) or gone backward (if the system clock is set to a new time earlier than what it was), the uniquifier is incremented so that GUIDs generated from the “second time it was five o’clock” don’t collide with those generated “the first time it was five o’clock”.

Raymond Chen, devblogs.microsoft.com

Have you ever…

• Wasted a lot of time coding the wrong algorithm?
• Used a data structure that was much too complicated?
• Tested a program but missed an obvious problem?
• Spent a day looking for a bug you should have found in five minutes?
• Needed to make a program run three times faster and use less memory?
• Struggled to move a program from a workstation to a PC or vice versa?
• Tried to make a modest change in someone else’s program?
• Rewritten a program because you couldn’t understand it?

Was it fun?

These things happen to programmers all the time. But dealing with such problems is often harder than it should be because topics like testing, debugging, portability, performance, design alternatives, and style—the practice of programming—are not usually the focus of computer science or programming courses. Most programmers learn them haphazardly as their experience grows, and a few never learn them at all.

Kernighan, Brian W.. The Practice of Programming

It is hard to talk about a “chair” if nobody agrees on what a chair is. There is enough of a common example base in OO, the shape, animal, and device-driver examples; that one can start, but beyond that the nature of OO diverges from person to person.
I’ll take that challenge. Find a definition of chair. For any said definition of finite length, their is either an exception to the definition or a thing that is a chair that isn’t covered by the definition. And yet, we can still talk about chairs.

[A lot of this is because OO is a broad church embracing everyone from the prototype-based (Self, Io, JavaScript) to the class-based (Java, SmallTalk, etc ) to those who have built OO systems on top of other paradigms (CLOS, OCaml, various Scheme dialects, Python, Perl). Each of these have various flavors of usage as well so talking about OO without qualifying it usually becomes a meaningless debate about whose definition we shall use.

We can only talk about chairs if we first state that we’re only interested in wooden 4-legged chairs.]

I suppose we have beanbag chairs that are borderline “mini-couches”. But, this gets back to the need for a working classification system for OO. I don’t know if “modeling” can be separated from language or not.

Nobody Agrees On What Oo Is