Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Haskell in Production: Standard Chartered

serokell.io

Post reply on HN
Print view View original

101–110 of 167 posts

Re: Haskell in Production: Standard Chartered

#101

Post by dybber »

Agingcoder wrote: post #79
mhh__ wrote: post #55

Earlier quoted context omitted.

6 million is easy, in fact its probably a small-ish fraction of their total code as a firm. Especially for a bank where their processes are a bit more defined than (say) a hedge fund. What do you think fintech companies do? (I'm not entirely sure either but I can potentially give a flavour of finance coding in general) If you want to come up with prices for things then you'll need a bunch of mathematical optimization…

That’s a fairly accurate overview. If you’re a bank, there is also code to handle market parameters/fits, software to handle positions/booking, exotic payoffs ( and the accompanying compiler to compile the dsl ), regulation, GUIs and custom tools for trading/sales, risks, etc. 6 million sloc is indeed a fraction of what you’ll find in an investment bank. It’s also (I think) what makes it very interesting: an IB is a…

6 million lines of Haskell. A language known for the ease of creating domain specific languages and thus writing the business logic declaratively. You would assume that is what is also done in Standard Chartered.

6 million lines of Haskell maintained by around 40-50 engineers. Sounds like a lot of tech debt in the making.

Maybe the 6 million lines includes their fork of GHC?

Re: Haskell in Production: Standard Chartered

#102

Post by tome »

foldr wrote: post #77
thesz wrote: post #25

Earlier quoted context omitted.

If you disable lazy evaluation, you would not be able to write arbitrary "where" sections, with definitions ordered as you want them, including tying-the-knot definitions, which are not exceptionally rare. So no one disables lazy evaluation. It is strict evaluation that is selectively enabled. I also have to say that focusing on the types in the compiler development was the right thing, but what was not right is not…

>So no one disables lazy evaluation. It is strict evaluation that is selectively enabled. True of vanilla Haskell, but from the article: > So we ended up with Mu, a whole-program compiler to a bytecode representation with a small runtime interpreter... Mu has a strict runtime, which makes program performance easier to analyse and predict – but prevents us from just copy-pasting some Haskell libraries that rely crucia…

Mu is strict because it was designed to target an existing strict runtime. That's all.

Re: Haskell in Production: Standard Chartered

#103

Post by fweimer »

thesz wrote: post #60
logicchains wrote: post #50

Earlier quoted context omitted.

Nim and D both have this feature. Among more popular languages, C++20 constexpr comes close: if you see a constexpr function, you know it's a "pure" function. Although there are still some things that can't be done in constexpr functions, the list is getting smaller and smaller with every new version.

constexpr reduces general side effects. Can we reduce specific side effects? For one very important example, consider software transactional memory. It has general side effects in the implementation behind the scenes, but inside transaction code they are not allowed. What will C++ solution look like? stmconstexpr?

GCC has this: https://gcc.gnu.org/onlinedocs/libitm/C_002fC_002b_002b-Lang...

But I have seen any use for it, besides every GNU/Linux program having code linked in to call _ITM_registerTMCloneTable in case libitm is used.

Re: Haskell in Production: Standard Chartered

#105

Post by nequo »

dybber wrote: post #101
Agingcoder wrote: post #79

Earlier quoted context omitted.

That’s a fairly accurate overview. If you’re a bank, there is also code to handle market parameters/fits, software to handle positions/booking, exotic payoffs ( and the accompanying compiler to compile the dsl ), regulation, GUIs and custom tools for trading/sales, risks, etc. 6 million sloc is indeed a fraction of what you’ll find in an investment bank. It’s also (I think) what makes it very interesting: an IB is a…

6 million lines of Haskell. A language known for the ease of creating domain specific languages and thus writing the business logic declaratively. You would assume that is what is also done in Standard Chartered. 6 million lines of Haskell maintained by around 40-50 engineers. Sounds like a lot of tech debt in the making. Maybe the 6 million lines includes their fork of GHC?

Perhaps it also includes (quasi) dead code that is not used anymore because regulations changed, and code for one-off analyses and experimentation?

Re: Haskell in Production: Standard Chartered

#106

Post by alex_lav »

koromak wrote: post #71

I'm just starting to learn Haskell and I honestly can't fathom how it gets written in production. Everything requires so much more consideration, which is fun and valuable in some situations, but not when you just need to get the damn thing done in time for a deadline. I'm not experienced enough to know, but it does feel like Haskell prioritizes "clever" code. Very beautiful, but hard to understand at a glance.

It's sad you're getting downvoted only because you've commented (ever so slightly) negatively about people's language de jour.

I would argue that "Can people understand a unit of code without experience in that language/domain" is valuable, even if not the _most_ valuable aspect of a language. I also think dismissing this desire is usually an act of gatekeeping. "_I_ understand it so it's fine."

Re: Haskell in Production: Standard Chartered

#107

Post by Agingcoder »

dybber wrote: post #101
Agingcoder wrote: post #79

Earlier quoted context omitted.

That’s a fairly accurate overview. If you’re a bank, there is also code to handle market parameters/fits, software to handle positions/booking, exotic payoffs ( and the accompanying compiler to compile the dsl ), regulation, GUIs and custom tools for trading/sales, risks, etc. 6 million sloc is indeed a fraction of what you’ll find in an investment bank. It’s also (I think) what makes it very interesting: an IB is a…

6 million lines of Haskell. A language known for the ease of creating domain specific languages and thus writing the business logic declaratively. You would assume that is what is also done in Standard Chartered. 6 million lines of Haskell maintained by around 40-50 engineers. Sounds like a lot of tech debt in the making. Maybe the 6 million lines includes their fork of GHC?

40-50 people is tiny indeed, but Haskell is supposed to help quite a bit here. 6 million lines of c++ and 50 people could be very hard. I’ve seen 4 million sloc of c++ and 80 eng, and it is hard.

Investment banks are extremely complex systems - 6 millions sloc, even in a very expressive language, make sense to me.

What’s harder to grasp is the real complexity of an IB - it took me years to get that. 30 years of random, non homogeneous software evolution, coupled with 30 years of funky human made rules in 200 countries. It’s going to be big and messy! And I really wish it were easier.

To some extent, it’s a bit like Unicode, or font rendering, or the tax code : on paper it’s just a bunch of rules, but for real, it’s big and complex.

Re: Haskell in Production: Standard Chartered

#108

Post by grumpyprole »

mark_l_watson wrote: post #14

Interesting interview. I applied for a Haskell job at Standard Charter in Singapore about eight years ago. I didn’t really expect to get the job because the only Haskell experience I had was my own Haskell projects and I had written a short book on Haskell. The guy interviewing me and reviewing my take home programming test had done a PhD studying aspects of Haskell. It was an interesting experience for me.

You won't need a Haskell PhD to work at a bank, even one that uses Haskell.

Re: Haskell in Production: Standard Chartered

#109

Post by stonemetal12 »

jsbg wrote: post #85
tildeheimat wrote: post #24

Should probably look into Haskell. Have absolutely no clue what's it best suited for?

It's a general purpose language, I wouldn't say it's more or less suited to this or that, other than the libraries available for it.

It is a garbage collected language so it is generally less suited for real time applications. As far as I am aware there aren't any implementations designed to run on very low memory embedded platforms.

As far as I am aware GHC's collector is not as good as Java's.

Re: Haskell in Production: Standard Chartered

#110

Post by grumpyprole »

usgroup wrote: post #27

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.

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