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

131–140 of 167 posts

Re: Haskell in Production: Standard Chartered

#131

Post by garrisonj »

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…

Really? I can’t imagine people turning off the lazy evaluation. It’s a deep part of the language. You can force things to evaluate strictly, but that’s not disabling it.

Re: Haskell in Production: Standard Chartered

#133

Post by mtl77 »

YetAnotherNick wrote: post #2

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

Gergo and I are working on a new implementation of the Mu compiler that uses GHC up to Core; from which we translate to the legacy Mu bytecode format.

The original Mu compiler is not designed for separate compilation, our new version is, based on GHC's binary representation of compiled interfaces with unfoldings.

Re: Haskell in Production: Standard Chartered

#134

Post by mtl77 »

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?

The reason is that we don't have a general solution for tail-call optimisation for computations made of a mixture of Mu code and C++ primitives. We have higher order functions defined in C++ that can be called from Mu, and can call back Mu functions passed to them. This back and forth between languages has occurred naturally in recursive definitions, and we don't have a way of reusing stack frames between the Mu interpreter and the native C++ code for these higher-order functions. We decided a long time ago to disable recursion by default, encouraging programmers to use recursion operators. We do however have a Mu language extension that enables recursion, which is used when the recursion depth is known to be bounded.

Re: Haskell in Production: Standard Chartered

#135

Post by mtl77 »

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.

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.

Re: Haskell in Production: Standard Chartered

#136

Post by hgsgm »

nequo wrote: post #87
scns wrote: post #52

Earlier quoted context omitted.

> 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. IIRC he wrote or said that lazy evaluation, was a mistake in hindsight.

Do you have a source for that? From what I recall, SPJ says that the grass is always greener on the other side. So if Haskell was strict by default, some of us would be pining for a lazy version of it.

Here: https://news.ycombinator.com/item?id=1924061

Re: Haskell in Production: Standard Chartered

#137

Post by hgsgm »

scns wrote: post #117
nequo wrote: post #87

Earlier quoted context omitted.

Do you have a source for that? From what I recall, SPJ says that the grass is always greener on the other side. So if Haskell was strict by default, some of us would be pining for a lazy version of it.

Sadly no. I think it may have been the answer in an interview to what he would have done differently with all the hindsight experience he now has.

It's here: https://news.ycombinator.com/item?id=1924061

Re: Haskell in Production: Standard Chartered

#138

Post by riwsky »

aranchelk wrote: post #130
riwsky wrote: post #114

Earlier quoted context omitted.

If a candidate is primarily interested in your company because of your particular tech stack, they are probably the wrong candidate. If your company needs to find candidates primarily on the basis of their familiarity with your particular tech stack, that is probably the wrong tech stack.

I’ve seen versions of the first statement several times from different users on HN, so know I’m not singling you out, but I believe this to be a deeply flawed view: It’s not the candidate’s job to be interested in your company. As a founder, leader, or even hiring manager it’s your job. Create a positive working environment. Get to know your employees and what their goals and interest are. Do your best to find ways t…

> It’s not the candidate’s job to be interested in your company. As a founder, leader, or even hiring manager it’s your job.

It’s my job to do that for the right candidates. Positive working environment, caring about employee growth, long term goals—all these things you mention are extremely important, and they are what we should be competing on. If an engineer would forgo an opportunity that provides those just so they can compose monoids in the category of endofunctors, that’s unfortunate—but I am under no obligation to indulge them.

> Should it ever the primary criterion for hiring? Probably not.

I explicitly referred to when it’s the primary concern; we don’t disagree here.

Re: Haskell in Production: Standard Chartered

#139

Post by riwsky »

ParetoOptimal wrote: post #121
riwsky wrote: post #114

Earlier quoted context omitted.

If a candidate is primarily interested in your company because of your particular tech stack, they are probably the wrong candidate. If your company needs to find candidates primarily on the basis of their familiarity with your particular tech stack, that is probably the wrong tech stack.

> If a candidate is primarily interested in your company because of your particular tech stack, they are probably the wrong candidate. I disagree. I believe that most candidates are likely only interested in your salary, benefits, or other things not relevant to what your company does. A necessary state of affairs where worker rights and worker loyalty don't count for much in the face of the horribly named "right-to-…

I agree that “here for the tech stack” is generally better than “here for the money”, but I’ve just been fortunate enough to work in situations where people were there for the mission and there for the people. It’s also really hard to blame people for being there for the money when, hey, we don’t know what kind of student loans or life financial situation they have. And when you don’t know a domain or company really well, “we pay more” is a harder-to-forge signal about prospective coworker quality than “oh our mission is really inspiring”.

Re: Haskell in Production: Standard Chartered

#140

Post by mrose11 »

WJW wrote: post #100
mrose11 wrote: post #80

> 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. wtf

What's weird about that? Excel is absolutely everywhere in finance, so if you have a special programming language that you consider to be part of your secret sauce it makes sense to integrate it into excel as well. A friend who works as a at risk manager at a major bank sometimes shares horror stories about the giant spreadsheet they have for some part of their holdings. They have disabled the "automatic recalculatio…

Excel is everywhere used everywhere and for very important things.

I just never... thought about writing a Haskell plugin for it. It makes sense! Better than using some other language. Functional for Excel makes sense.

I love hearing horror stories about small (and large!) governments and companies abusing and misusing Excel. https://sheetcast.com/articles/ten-memorable-excel-disasters

Post reply on HN