[dead]
Haskell in Production: Standard Chartered
11–20 of 167 posts
Re: Haskell in Production: Standard Chartered
#12So many questions left unasked! In particular they have "recursion disabled by default" but "we have all the usual recursive combinators". Does this mean that they can't explicitly write recursion buy may achieve recursive effects only through the combinators? I'd like to know more about this. Is it as expressive as recursion only through "properly optimised" combinators?
By combinators they mean things like folding/reducing over lists, i.e. combinators/higher order functions for operating on potentially infinite structures.
It's not as expressive as raw recursion since many uses of recursion are hard to express through combinators, albeit a great deal of research has been done in this area (look up recursion schemes).
Re: Haskell in Production: Standard Chartered
#13> Haskell in Production
Does not use Haskell.
Is it just me or is this... weird?
Re: Haskell in Production: Standard Chartered
#14Interesting 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.
Re: Haskell in Production: Standard Chartered
#15> Mu can easily take several minutes to compile a single large application. We will circumvent those problems by switching our front-end to use GHC directly What does he mean by this?
I'm also interested. Just guessing, but I guess it means that while they use their own (slow compiling) 'Mu' dialect for most applications, they have switched to using 'standard' GHC for their front-end apps.
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_...
Re: Haskell in Production: Standard Chartered
#16> Haskell in Production Does not use Haskell. Is it just me or is this... weird?
Sure, it's a bit weird but not that weird as they have a huge codebase in a specific domain. Also, they still end up using a lot of Haskell code (and semantics) although they write in a thin layer of "DSL" on top of Haskell and GHC (which itself is a lot of "Haskell in production").
> 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 crucially on lazy evaluation.
Re: Haskell in Production: Standard Chartered
#17I'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 evaluation. Simon Peyton Jones is reported to have said that lazy evaluation has been kept "to keep us honest about side effects", i.e., that size effects become immediately painful with pervasive lazy evaluation. But in a production system, functional purity (no side-effects) is a means to an end, and lazy evaluation comes at a pretty extreme performance cost. Not everyone disables lazy evaluation in production Haskell, because not everyone thinks they need to for performance, but I've definitely heard about it enough times that it seems like a relevant pattern.
Production users of Haskell do seem to be happy about types, years into projects, so I'd take away that types are a benefit, but I do wonder if one might get those same benefits in another language without the problems which seem to crop up with Haskell, such as laziness causing performance issues, monadic complexity, and difficulty hiring.
Re: Haskell in Production: Standard Chartered
#18> Haskell in Production Does not use Haskell. Is it just me or is this... weird?
Mu is essentially Haskell. It's not clear to me where you got "does not use Haskell" from.
Re: Haskell in Production: Standard Chartered
#19> Haskell in Production Does not use Haskell. Is it just me or is this... weird?
Should probably be 'Dialect of Haskell in Production'
Re: Haskell in Production: Standard Chartered
#20I'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…
Small distinction that does not detract from your excellent point: the question is not about laziness vs. strictness since any reasonably large program uses both extensively. Rather, it is about the properties of laziness or strictness as a default evaluation strategy.