It was ubiquitous in GS by the mid-2000s, and was rather instrumental to GS navigating the crisis in 2008.
Being able to accurately and quickly compute risks across the entire firm's books, rather than manually merging across separate systems was key advantage, which encouraged JP, Citi and BofA to build a SecDB clone themselves.
https://www.goldmansachs.com/our-firm/history/moments/1993-s...
I've not heard the term "twiddle scopes" before; in Athena it is "tweaking".
For finance applications (risk) the whole concept works quite well, doesn’t it - combining the natural advantages of code and Excel.
[Disclosure: I was part of the Quartz Core team in 2011/2012.]
I suspect the Common Lisp influence was beneficial.
The weirdest thing, language-wise, that I noticed was scoping. It's neither dynamic nor static scoping, but weird scoping. (But there are work-around to get something like static scoping.)
Outside of the language, the whole CVS-based version control and review process was weird. But understandable as a product of the late 1990s, when review-before-going-into-permanent-history must have been way ahead of its time.
Not the spaces in variable names?
But I was used to different and exotic conventions from the obscure languages I played with over the years.
JPM's actual pixie code is proprietary, extremely performant after 12 years of pushing into bigger and bigger scale problems, and is definitely not on GitHub!
I remember my first few months unlearning normal Python and figuring out how to build the 'pixie graph', a lazily-evaluated Python DAG suited for calculating financial instruments. It took a while to get your head around this, but when you did it was a very powerful and productive way to building trading and risk management applications.
To get some sense in how this worked, here are two public projects on github with good introductions:
* https://github.com/timkpaine/tributary
* https://github.com/janushendersonassetallocation/loman