Some of the folk that built that (or worked on it) ended up at JPM and Merrill where they built the Python centric version - Alpha and Quartz respectively. Barclays Capital has/had a similar system as well I think, but it’s not one I know about offhand - they did though, memorably, have a system that was pretty much Haskell-in-Excel.
[0] https://www.slideshare.net/slideshow/managing-python-at-scal...
> Time to drop a bit of a bombshell: the [Barbara] source code is in Barbara too, not on disk. Remain composed. It's kept in a special Barbara ring called sourcecode.
The answer is often that the battle-hardened mature off-the-shelf solution did not exist at the time the code was written. You're doing software archaeology.
I’ve had clients ring up about pennies… it can be crazy what some people are motivated by
Quite common in accounting, the accounting equation must balance, it's like a checksum
Of course, financial institutions have a lot of “secret sauce” - such as financial models - you’d never expect them to release.
But this kind of underlying infrastructure isn’t really “secret sauce”
The more they use cloud-hosted LLMs, the more likely it will get leaked into training data.
Also...these things tend to have fuckin terrible documentation. Good luck figuring any of this out. And you can't google it and your AI is just as lost as you
Right out of the gates, it's crazy how this contrasts with Mercury's Haskell infra
Barbara is a company wide database, it handles data storage.
When I read about internal app state being stored in Barbara I'm interpreting that the policy is for the data to be centralized for more vertical control.
While the Temporal thing sounds like if something is written, it's done so in a containerized like manner, and other processes can't just read it.
But also I suppose you may be saying exactly this?
Is this really the case? I'm sure there are plenty of transactions that for umpteen different reasons must not be exposed on a global level.