
Haskell in Production: Riskbook - NaeosPsy
https://serokell.io/blog/haskell-in-industry-riskbook
======
melling
"If I hadn’t measured, I probably would have forgotten that Yesod does indeed
make quite heavy use of Template Haskell to generate code. The core of our
application is still only a humble ~17,000 lines across 182 files — not
counting some external libraries we maintain — but if you were to dump the
splices generated by Template Haskell we would be looking at approximately
160,000 LOC."

I like to think of a programming language like a lever:

"Give me a lever long enough and a fulcrum on which to place it, and I shall
move the world." \- Archimedes

------
_bxg1
> [Our product] essentially involves enabling reinsurance brokers to create
> risk programmes and then market them to underwriters, all within our online
> platform. A risk programme has a fairly complex life cycle, and we model and
> digitalise all of the steps that professionals in the industry would
> traditionally have done on paper, which is of course far less efficient and
> far more expensive.

Sounds like an ideal use-case: complex, well-defined rules and procedures that
must be modeled in a fool-proof way. I think the issue for most people who
dream about using Haskell at work is that their use-case doesn't have these
kinds of needs, and so the tradeoffs (hiring difficulty, third-party API
support, etc.) just don't make sense.

~~~
nextos
Yes, it does look like an ideal use case.

I really really love Haskell, but I wonder if it's a rational decision to use
it in comparison to an eager ML (OCaml, F# or SML). Much simpler languages.
The amount of language extensions plus laziness make the learning curve of
Haskell quite steep!

Still, I love this. Keep up the good work.

I think that during the 2020s we will see a lot of efforts to move software
errors to compile time with fancier type systems (dependent, linear, etc). I'm
betting on a slightly different approach than Haskell, which I think is too
complex and will never fit all use cases. I think the best approach is to have
a great language to quickly build DSLs and formal verification methods
(ranging from lightweight like property-based testing or type systems to
heavyweight like abstract interpretation or theorem proving). So, essentially
Racket (Lisp) + lots of formal techniques in a nice package.

~~~
wespiser_2018
in the 2020s, I hope we can get learn out to make complex type systems simple
to use!

------
xvilka
Languages like Haskell, OCaml, Rust are a perfect fit for financial industry.
I would not trust my money to the Python runtime errors. It's always good to
see more and more companies who realize benefits of them.

~~~
owl57
Are there known real-world examples of miscalculations (as opposed to crash or
something like "None" printed) that would be prevented by Haskell but not
Python 3?

(Why "3"? Because the one thing that has bitten me is the old division
operator. They were right to kill it with fire. The new "/", just like
Haskell's one, always gives floats, which is good for estimates and
_consistently and obviously_ bad for money.)

~~~
buckminster
> The new "/", just like Haskell's one, always gives floats, which is good for
> estimates and consistently and obviously bad for money.

Doesn't Haskell's operate on the Fractional type class? Which includes
Rational. Or some money type you wrote yourself.

~~~
owl57
Yes. I wrongly remembered (and even checked the out-of-the-box output of ":i
Fractional"!) that it doesn't include Rational, but only different flavours of
floats. The original point stands: Python's Fraction defines arithmetical
operators in the same sane way, and the bespoke money type is about as free as
in Haskell to define them in whatever way seems useful, like throwing
exceptions on adding dollars to euros.

(And also throwing exceptions on adding dollars to generic ints — that one
would be a compile-time error in Haskell, which is of course a good thing. Is
this not only a good thing but a critical one in financial context?)

------
bcheung
For people using Haskell at work, how did it happen? I'm wanting to use it at
work but there is a lot of pushback and I am encouraged to use languages like
Go and Python.

~~~
solresol
I was in the senior leadership team of a company a while back (I was brought
on to build a software team from scratch). I worked with the other execs to
ask the question "what culture do you want in your software development team;
what will be compatible with the rest of the company culture?"

Some of the options we discussed...

\- Is your plan to sell the company in a year or two? Then you will probably
write a lot of throwaway code, and speed of development of basic stuff is most
important. If you want this, I'll hire you a team of Python or NodeJS or Ruby
programmers.

\- Is your plan to have software that supports your company over the long
term, but the goal of the software itself is more around cost savings? Is the
software development team going to be a cost centre? If so, you will end up
with a revolving door of programmers coming in for short periods of time to
work on it? If you want this, I will hire a team of Java or Go or C#
programmers.

\- Do you want to build very technically complicated software as a
differentiation strategy? Then you will be looking at a team of very smart
software developers who love their craft with a passion that will be a bit
foreign to non-technical staff. If you want this, I'll hire a team of Haskell
/ Lisp / Ocaml / F# programmers.

At the time, the rest of the leadership team wanted the last option, so that's
the software team we built. As far as I remember it worked quite well, I
remember that there was only one significant bug that made it into production.

