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

21–30 of 167 posts

Re: Haskell in Production: Standard Chartered

#21

Post by ackfoobar »

nemoniac wrote: post #10

So 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?

It has been argued that unrestricted recursion is like GOTO. I have some limited experience with "recursion schemes", they're quite expressive. But I feel like it's trying to give every possible pattern of recursion a name, to the point that it's almost becoming a joke - e.g. "zygohistomorphic prepromorphism".

Re: Haskell in Production: Standard Chartered

#22

Post by yodsanklai »

kerkeslager wrote: post #17

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…

OCaml may be seen as more pragmatic solution.

Re: Haskell in Production: Standard Chartered

#23

Post by weavie »

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.

Did you get the job?

Re: Haskell in Production: Standard Chartered

#25

Post by thesz »

kerkeslager wrote: post #17

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…

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 focusing on the automatic analysis and removal of thunk creation for lazy evaluation. There is a project now to implement GRIN (graph reductin intermediate notation) [1] which supports such analysis and GRIN is early 90-th.

[1] https://grin-compiler.github.io/

GRIN also automatically gives you many benefits of supercompilation.

We could have a much better Haskell code now if ghc decided to support several backends back then, not only STG/C--.

Re: Haskell in Production: Standard Chartered

#28

Post by yodsanklai »

kerkeslager wrote: post #17

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…

Regarding hiring difficulty, some say it's a feature rather than a bug. There are always good candidates. And good engineers can learn and be proficient in any language. Haskell is certainly not harder than C++.

I see some issues though.

Some niche languages enthusiasts can be very picky and reluctant to work on other languages, and would pick Haskell when a simple python script would be more appropriate.

People from Academia interested in Haskell may be good in PL theory, and writing compilers or static analysers, but may lack in other fields such as system programming, which incidentally is harder in Haskell too. So you also need to find devops, system guys and so on who can also be productive in Haskell, and those are more rare.

Re: Haskell in Production: Standard Chartered

#29

Post by thesz »

yodsanklai wrote: post #22
kerkeslager wrote: post #17

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…

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.

Post reply on HN