To the best of my knowledge much of this originated with SecDB/Slang at Goldman - SecDB (securities db I believe) being the object store and slang the somewhat quirky C like language that ran with it (also the only language I’ve used professionally that let you have spaces in the variable names).
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.
What a well-written account of "how things are done".
> 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.
When first encountering these ecosystems and looking at the various pieces they contain, one may repeatedly ask: "why didn't they just use <off-the-shelf solution> for this problem instead of writing this component/subsystem from scratch"?
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.
That's only half the answer. These large investment banks' value-add is partly that they can integrate everything they know into these closed-world environments (kind of like a Smalltalk image), which is something that simply isn't done in the wider world because you can't accrete it out of smaller pieces and it doesn't make sense at all for smaller entities.
Morgan Stanley's version is open-source at https://github.com/morganstanley/optimus-cirrus , although I don't know how practical it is to actually run yourself. (They don't go quite as far as having the code itself be bitemporal and kept in the datastore, but most of the stuff in the article exists there)
People turning up in hedge funds (i.e. much smaller) and trying to rewrite the bit of a bank they used to work in's equivalent of this article is so annoying.
I've seen similar inside large financial orgs - what struck me was how there are these huge amounts of people that spend their entire working life inside this alternate IT reality. It's not unlike SAP consultants where their skillset is tied to one company.
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
>Applications also commonly store their internal state in Barbara - writing dataclasses straight in and out with only very simple locking and transactions (if any).
Right out of the gates, it's crazy how this contrasts with Mercury's Haskell infra
Eh, to be fair, this post is about a _bank_, and the one you've linked is about _fintech_. They are not even close to the same space, even though they both deal with money.
But also I suppose you may be saying exactly this?
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.
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.
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.
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
https://blog.haskell.org/a-couple-million-lines-of-haskell/
But also I suppose you may be saying exactly this?