It was written to replace an existing functional DSL called "Lambda", and to target Lambda's runtime.

Reminds of an epistemology joke.

The reason the moon is made of cheese is because it is made of yellow cheese.

Main reasons at the time: * strictness was preferred for consistency 1) with the C++ execution model (a lot of our code base is written in C++ by quants, and a typical Mu program will make extensive use of these external calls; they can even be higher-order, calling back into C++); and 2) because we have a lot of end-users who are not Haskell experts and are much more confortable with a strict execution model * code mobility is essential to what we do, and was not directly available in Haskell: we often capture computations on our users' desktops running Windows, and stream them to a Unix compute farm. * GHC was not openly available as an API years ago; this is different now which is why we have started a new implementation that is GHC-based.

Why is it any different to "bank python" used by e.g. JPMorgan or BAML? Or Google writing Dart?

I don't think they ever touched the interpreter. It's more like a huge framework on top of regular py.

It's an entire fork of the Python ecosystem. So not really that much different to what we have here. Maintaining an ecosystem of libraries and tools is the hard part, not a compiler or interpreter.