@raganwald @pluralistic please tell me the MUMPS part was only the tellers terminal, maybe emulating an IBM2970 or (hopefully) 3600 financial terminal. Not the core banking applications. Even more, tell me the core was COBOL or PL/1 running IMS or CICS transactions.
@raganwald @pluralistic
Not disagreeing, but people who promote "moving fast and breaking things" will also use "code is a liability" as a justification. They don't want software engineering, they just want quick growth and/or profit.
@AdamDavis An old rule when talking about these things is to first sync up on context.
I agree with your statement when we're talking about the tech industry, But I disagree when talking about other industries that consider tech a tool. So, yes, OpenAI don't care if ChatGPT hallucinates. But Air Canada learned the hard way that an airline must care whether its chatbot hallucinates.
https://www.mccarthy.ca/en/insights/blogs/techlex/moffatt-v-air-canada-misrepresentation-ai-chatbot
@raganwald @pluralistic
Excellent point:
> I agree with your statement when we're talking about the tech industry, But I disagree when talking about other industries that consider tech a tool.
@AdamDavis I am known for my extremely sincere flattery: https://www.joelonsoftware.com/2002/05/06/five-worlds/
@raganwald @pluralistic
Hmm. Not sure how to take that. I've got 30+ years of experience working in software development positions. The majority of that time was not spent working for software companies. So I understand that side of corporate life well.
However, I associate the phrase "move fast and break things" with the software industry. Plus, the linked article spent a bit of time discussing Microsoft. So I assumed you were making a general statement about software development attitudes.
Speaking of the fragility of enterprise software… Here's the robust architecture of an online banking system I used to lead. 3.5 million people trusted this with their life savings.
That TUI app written in MUMPS(!) once powered the terminal a bank teller would use to process an in-person transaction. It embodies and unambiguously encodes every business rule for transactions that have been developed over decades.
@raganwald @pluralistic please tell me the MUMPS part was only the tellers terminal, maybe emulating an IBM2970 or (hopefully) 3600 financial terminal. Not the core banking applications. Even more, tell me the core was COBOL or PL/1 running IMS or CICS transactions.
@jguillaumes I am not going to go any further into the specifics of that particular bank, but here is something you might find interesting: There is enough MUMPS in FinTech to support an entire company dedicated to supporting a superset of MUMPS just for FinTech!
@raganwald @pluralistic well, MUMPS was THE nonSQL database at those times ;)
(Unless you went to big iron and used IMS or IDMS)
@raganwald I worked for a very large fortune 50 and the entire financial stack for the company was held together by backup tape archives and bailing wire
Little sobering when you have the realization that the entire financial system is antiquated and super fragile @pluralistic
@mxjaygrant @raganwald @pluralistic counter perspective.
The realization that the entire financial system *IS* antiquated, super fragile.
::waggles eyebrows::
@faraiwe That *is* my perspective! We don't need tools for making more "asbestos," we need a cultural reset to value our users more than some hockey stick growth chart on a powerpoint made by AI. And what we really need are robust, proof-based tools that can dissect a MUMPS app and develop a process for safely porting it to something more developers can work with.
@raganwald @faraiwe @mxjaygrant @pluralistic You know if the financial system was made of more small players using stable APIs rather than shared software, and circumvention laws were not a thing, we probably would have upgraded the financial system a few times by now.
@mxjaygrant In the 1900s, "Baler" was an incredibly popular compiler that turned spreadsheets into applications. I personally love that it existed for the same reason thatI loved thatHyperCard existed. Democratize the means of compilation!
But I draw your attention to the name. They knew damn well that when a financial institution is held together with duct tape and baling wire, spreadsheets are the bales.
@raganwald @pluralistic my career started with writing in-house database code using Informix 4GL, so I’m in this meme and i don’t like it
@raganwald @pluralistic I have actually worked with MUMPS. If I remember correctly, one of the big "special features" of the language was that it wrote to the hard drive immediatly. Another was the weird structure of it as a database.
I suspect if those are still desirable traits, then we still need a new language for it.
@Epic_Null @pluralistic Yes! Semantically speaking, MUMPS is organized around a data collection type that has certain guarantees about search performance and persistence.
In the mid-nineteen sixties, you couldn't just buy BTrieve, so it became a language feature.
> Massachusetts General Hospital Utility Multi-Programming System (MUMPS)
I thought Maurice Hilleman eradicated that when his daughter caught it.
@pluralistic That bank licensed the MUMPS source code from its vendor and employed a small team that did nothing except keep that MUMPS app alive.
Nobody else could touch that code for many reasons, one of which was security. The closest I came was updating the JDBC code in concert with changes they would make.
This is a single but compelling example of “Increasingly heroic measures to keep legacy software in good working order.”
In the physical world, it's called "asset management". At some point, the cost of maintenance exceeds the cost of replacement, but until then, replacement is throwing money away.
"Accountants don't care about your feelings on the subject of elegance", says it.
That said: real asset management applies a cost to potential sudden failure, and a probability to it...which also goes up.
When you add in a best-estimate "risk cost", replacement can suddenly become obvious.
@RoyBrander @pluralistic There is a massive difference between "Rewrite it because it is extremely inefficient to work with it," and, "Replace it because it threatens to become a material risk we must disclose."
In my Finance experience, the latter is the driver. As for that app, it persisted because the risks associated with maintaining it were thought to be less catastrophic than risks associated with replacing it.
