(no title)
JohnMakin | 6 days ago
Often, understanding the code or modifying it is the easy part! I'm sure a decent amount of people on this website could master COBOL sufficiently to go through these systems to make changes to the code.
However, if I understand from my own career enough, knowing why those things are there, how it all fits together in the much broader (and vast) system, and the historical context behind all of that, is what knowledge is being lost, not the ability to literally write or understand COBOL.
habinero|6 days ago
whynotmaybe|6 days ago
labrador|6 days ago
I'm pretty sure they're talking about converting COBOL to Python or Go and that is the benefit. That doesn't require knowing the architecture and system design. I'm not familiar with COBOL and COBOL systems so I could be wrong... but Python programmers who can then study the system are easy to find.
JohnMakin|6 days ago
I've never worked on COBOL systems specifically, but just going from my experience working on fintech problems in dense legacy stacks of various languages (java is common), that are extremely hard to understand at times, the language itself is rarely if ever the problem.
"Just need to convert it to Go or Python" is kind of getting at the fallacy I am trying to describe. The language isn't the issue (IME). I do have my gripes about certain java frameworks, personally, but the system doesn't get any easier to understand from my POV as to simply rewrite it in another language.
Even let's say it was this simple in the case of COBOL - these are often extremely critical systems that cannot afford to fail or be wrong very often, or at all, and have complex system mechanisms around that to make it so that even trying to migrate it to a new system/language would inevitably involve understanding of the system and architecture.
ctoth|6 days ago
How big is your context window? How big is Claude's context window? Which one is likely to get bigger?
re-thc|6 days ago
paul7986|6 days ago