41–50 of 167 posts
I'm struggling to understand how possibly inventing your own language -- one not even compatible with the Haskell eco-system -- was ever a good idea in production.
It was written to replace an existing functional DSL called "Lambda", and to target Lambda's runtime.
The reason the moon is made of cheese is because it is made of yellow cheese.
> I’m the head of the Core Strats team at Standard Chartered Bank. Core Strats consists of over 40 developers using Haskell (well, actually Mu) as their main programming language.
wow - this team used to be 8-10 people? amazing to see its grown so much. our old head used to be https://donsbot.com/about/ . i have a pet theory that Don and gang ensured Haskell's viability by building so much stuff at SCB that SCB was kind of pot-committed to Haskell, thereby ensuring that they would keep investing and hiring until the end of SCB. Similar move was played by Cheng Lou over at Facebook, for Reason/Rescript. if you want to grow a programming language at a bigcorp, embed it in a biz critical application and you have job security for life
> Our core financial analytics library, Cortex, consists mostly of Mu/Haskell code (over 6.5 million lines) and forms the basis of our price and risk engine across all asset classes. It’s also pretty full-stack; we use it for everything, from server-side long-running batches handling millions of trades a day to front-end desktop graphical user interfaces.
yep i can attest to this - i will say that Mu was the best developer experience i've had for a long time. It comes with its own storage/persistence layer (simple KV store iirc) but the joy of not having to choose or maintain or scale was great. also the entire internal package ecosystem was searchable via function signature (via Neil Mitchell's Hoogle) and versioned daily (so if any regressions happened you could just jump back day by day - we didnt use git in my day). i also missed if there was a testing suite.
> We can seamlessly call C++ functions from Mu and vice-versa, and pure Mu functions can be used in Excel formulae via our Excel add-in
yeah this was used a bunch. however the traders rarely touched this code so it probably required a lot of support from the devs and probably some misunderstandings where had.
> What benefits do you see for using Haskell in banking and fintech areas? One great advantage is static typing..
no no no. correct me if i'm wrong but dont large fintechs like stanchart and jane st use functional languages because its so much better to parallelize for risk scenarios and complex option pricing?
> Does Standard Chartered have an in-house training program for upskilling Haskell developers? For training absolute beginners in Haskell we typically engage an external training partner.
ha. in my day i was just given Learn You A Haskell and told good luck!
SCB people reading along, i hope some of my FXO apps are still around. Coriolis, Corona, and i'm blanking on the main pricing one. 10 years wipes away a lot.
Earlier quoted context omitted.
OCaml may be seen as more pragmatic solution.
It cannot. Arbitrary side effects allowed by strict-by-default language without types constraining these ruin easeness of software development provided by Haskell. When your Haskell program works and walks, add bangs and it will run. Lately I heard from my colleagues it will run even without bangs as ghc has improved.
Purity is Haskell's fundamental killer feature.
Other languages now also have quite sophisticated type systems, some of which can do specific checks beyond Haskell in certain areas (Rust's control flow analysis, TypeScript's ways to do "gradual" typing of JS), while Haskell can do more in general.
But only in Haskell can I look at a function's type and know it doesn't do any IO.
In development and production, this allows you to immediately skip over large amounts of code when debugging issues. Pure functions are a key reason why Haskell is good at correctness and maintainability.
Earlier quoted context omitted.
It cannot. Arbitrary side effects allowed by strict-by-default language without types constraining these ruin easeness of software development provided by Haskell. When your Haskell program works and walks, add bangs and it will run. Lately I heard from my colleagues it will run even without bangs as ghc has improved.
I find that too: Purity is Haskell's fundamental killer feature. Other languages now also have quite sophisticated type systems, some of which can do specific checks beyond Haskell in certain areas (Rust's control flow analysis, TypeScript's ways to do "gradual" typing of JS), while Haskell can do more in general. But only in Haskell can I look at a function's type and know it doesn't do any IO. In development and pr…
Earlier quoted context omitted.
Frontend here refers to the first stage of the three-stage structure of compilers, ie. the functionalities such as parsing and type checking that come before the optimization and target code generation phases: https://en.wikipedia.org/wiki/Compiler#Three-stage_compiler_...
Didn't know that, thanks! But then I'm wondering how they can do parsing and type checking with GHC when they are using their own dialect, "Mu". How come GHC can parse that?
I've talked to a lot of people using Haskell in production over the years, and one of the things I've consistently noticed is a disconnect between the Haskell features that are often touted, and the Haskell features that people use in production. This isn't always a quiet omission, like "we didn't end up using this" either. The best example is that a lot of people end up doing some significant work to disable lazy ev…
A few minor corrections > Simon Peyton Jones is reported to have said that lazy evaluation has been kept "to keep us honest about side effects" Rather, one of the main benefits of laziness was to force purity and thereby to instigate the development of typed effects. By contrast, the reason that laziness has been "kept" is simply that switching to strictness now would break (almost) all Haskell programs! > lazy evalu…
It's because it's objectively harder to reason about performance with lazy evaluation as performance becomes non-local. You can no longer reason about a function's performance just by looking at its body, instead you have to know the nature of the inputs passed to it (whether they're thunks or materialised values).
Each single uses of lazy evaluation also imposes a latency overhead as the thunk/value must be behind a pointer. Yes the compiler can remove unnecessary thunks, but that's "unnecessary" in the sense of "unnecessary given the semantics of the program", not "unnecessary given the problem the program's trying to solve". I.e. lazy by default will generally result in someone writing code that's lazier than necessary unless they're very careful with annotating to the compiler everywhere laziness isn't needed.
Earlier quoted context omitted.
Frontend here refers to the first stage of the three-stage structure of compilers, ie. the functionalities such as parsing and type checking that come before the optimization and target code generation phases: https://en.wikipedia.org/wiki/Compiler#Three-stage_compiler_...
Didn't know that, thanks! But then I'm wondering how they can do parsing and type checking with GHC when they are using their own dialect, "Mu". How come GHC can parse that?
I'm shocked, in the first paragraph they assert that they handle 6 million lines of code. Is it common for the fintech industry to have codebases of that magnitude? I'm aware that for example OSes and browsers can achieve similar sizes (if I'm not wrong certainly more) but I'd have never thought that a fintech company could approach such size. It just seems way too much... Edit: Question out of ignorance for people t…
Don't sleep on these finance companies, they're big development shops.
Earlier quoted context omitted.
A few minor corrections > Simon Peyton Jones is reported to have said that lazy evaluation has been kept "to keep us honest about side effects" Rather, one of the main benefits of laziness was to force purity and thereby to instigate the development of typed effects. By contrast, the reason that laziness has been "kept" is simply that switching to strictness now would break (almost) all Haskell programs! > lazy evalu…
>The reason that lazy evaluation leads to performance problems is that programmers don't know how to use it correctly It's because it's objectively harder to reason about performance with lazy evaluation as performance becomes non-local. You can no longer reason about a function's performance just by looking at its body, instead you have to know the nature of the inputs passed to it (whether they're thunks or materia…
Earlier quoted context omitted.
It cannot. Arbitrary side effects allowed by strict-by-default language without types constraining these ruin easeness of software development provided by Haskell. When your Haskell program works and walks, add bangs and it will run. Lately I heard from my colleagues it will run even without bangs as ghc has improved.
I find that too: Purity is Haskell's fundamental killer feature. Other languages now also have quite sophisticated type systems, some of which can do specific checks beyond Haskell in certain areas (Rust's control flow analysis, TypeScript's ways to do "gradual" typing of JS), while Haskell can do more in general. But only in Haskell can I look at a function's type and know it doesn't do any IO. In development and pr…