
Ask HN: What has Haskell ever done for us? - Maro
The latest cycle of hype around FP&#x2F;Haskell, which started around 2013, seems to have died down.<p>What was your experience with FP&#x2F;Haskell in the last 5 years?<p>How did your projects go?<p>Are you using it in production today?
======
agentultra
I tried to start a project to take a Haskell prototype of an important project
into production. Haskell was a great choice because it allowed us to focus on
the business problems. We didn’t have hundreds of lines of defensive code we’d
normally write in a less strict language. It was also nice being able to trust
code from developers of different skill levels: our tooling and tests gave us
enough confidence to merge faster and move fast.

I’m currently using Haskell in a side project for work to parse, formalize,
and migrate a lot of schemaless data.

I’ve spent much more than a decade in dynamic languages. I still use
JavaScript as a primary language in most of my work because that’s what our
company settled on. I’m done with dynamic languages and nominal type systems.
Haskell isn’t perfect by far but it’s simply better than everything else that
there’s nothing to compare it to. I prefer to write code in Haskell and I feel
more confident in code I write in Haskell. I also like the assistance I get
from Haskell and miss it when working in other languages.

------
Nokinside
As a someone who don't use Haskell: Pandoc and Detexify.

As someone who has written safety critical software where you are willing to
pay big buck for verification tools and software, Haskell has done nothing. I
would love to use Haskell type FP but people who work with Haskell are
thinking about correctness abstractly and real world (and earning lots of
money) is not their priority.

All talk about correctness, absence of runtime errors are futile when you
limit your definition to errors you want to deal with and ingonre the rest.

Having sound type system means nothing if you can have runtime memory errors,
can run out of stack, pause for GC too long, don't know how much memory you
may use in the worst case, can't detect divisions by 0, or float/fixexd point
range errors ... etc.

Writing MISRA C and using verification tools like Astree, or SPARK +
verification tools are not as elegant, but their weakest point is stronger
than Haskell's.

If I sound salty, it's not because I think FP is bad idea, it's because I
think the potential is wasted.

~~~
AnimalMuppet
For your world, I think FP _is_ a bad idea. GC is a bad idea. ( _Allocations
after startup_ are a bad idea, too, and a language that allocates without
being asked is a terrible idea.) Recursion is a bad idea. (Yes, tail-call-
optimization can essentially turn it into recursion. Mis-write one TCO in the
whole program, though, and your stack just became extremely unpredictable.)
And considering Haskell specifically, in your world lazy is a _terrible_ idea.

FP is a tool. It has potential to solve some problems. That potential won't be
wasted, but _the problems it will solve aren 't the problems you have in your
world._

On the other hand, FP could be just fine for writing the tools that will help
you in your world.

~~~
Nokinside
FP is good idea for safety critical systems. It just has to be designed
differently.

You want uniqueness typing that allows you to have functions that modify the
variables without breaking the functional abstraction in straight forward
manner. You could also reason about the memory use and have fixed amount of
memory. Ordered typing would be nice feature to have. You also want hooks in
the compiler for a additional tools for static analysis and proof assistants.

Recursion itself is not bad idea. It's strictly forbidden in safety critical
code today for reasons that can go away. If you allow recursion, compiler must
be able to reason and define the limits. Recursion is not good idea in safety
critical code when it obfuscates the execution, but that is not always the
case.

~~~
AnimalMuppet
If I understood what you said correctly, you could have FP that allowed
(controlled) mutation of the existing variable rather than allocating a new
one. I suppose that could be done. But it seems to me that many people regard
immutability as an _essential_ part of FP, because without immutability,
composability is no longer guaranteed. So to get what you'd like FP to be, you
may have to step outside the existing FP community.

~~~
Nokinside
The essential part of what makes FP FP is referential transparency not
immutability. Having referential transparency with mutation is what the
uniqueness typing provides.

------
turingspiritfly
The things I have learnt from Haskell

1\. Functors, Monads, Applicative Functors, Monoids are extremely good design
patterns, and to me seems like at some point you invent approximations of them
if you're not using them

2\. Raw recursion should be eschewed in favour of recursive schemes or atleast
do folds

3\. If Math is the language of clear thought, those closest to it like Haskell
ought to be used where clarity is required which is pretty much everywhere in
software

4\. Composable software has to be based on something more concrete but one-
time feel good look good pieces that fit together but a handful of cases, and
if a language doesn't back it up with some sort of math structure, then the
language is no good. That is why I think Category Theory's place in Haskell as
something akin to a first class citizen is extremely important

Where do I use Haskell?

1\. When I am not allowed to code in Haskell which is pretty much 99 percent
of my projects, I re-do critical pieces in Haskell but Haskell code acts as a
clear documentation and my go-to when trouble brews for trouble-shooting

2\. The monadic abstractions are the best tools in my tool-set and I use them
abundantly and it has paid off quite a bit

Haskell and the Future of software

1\. Haskell is extremely difficult and since my first contact with Haskell
almost 10 years ago, I've seen people turn away from it because of it seemed
too complicated.

2\. For those you thinking I am a nut for thinking that this sort of mentality
spells doom for the future of software devs remember this, what is the general
attitude of the public towards our best tool at modelling reality aka Math? Is
it a good one? Heck half of the programming community is still at odds with
Math. While you may argue that not everybody needs math, I argue the fact that
everybody has this we-don't-need math mentality is the reason a many a things
that should have been automated haven't been automated , and loads of people
have these bs jobs where all they do is stitch together apis and then call it
a day and go home and think they've accomplished something

3\. My point: The current average relationship that devs have towards a
language like Haskell and it's future descendents is/will be a metric of the
state of software now and in the future.

~~~
ghuntley
Re: math, composition and universal abstractions

Folks please read [https://github.com/hmemcpy/milewski-ctfp-
pdf](https://github.com/hmemcpy/milewski-ctfp-pdf)

Re: learning Haskell

Best way is to do it [https://github.com/data61/fp-
course](https://github.com/data61/fp-course) and
[https://m.youtube.com/playlist?list=PLly9WMAVMrayYo2c-1E_rIR...](https://m.youtube.com/playlist?list=PLly9WMAVMrayYo2c-1E_rIRwBXG_FbLBW)

------
Maro
My own answer:

The team I was in in 2013 invested a lot of time to learn Haskell. We tried to
use it in production for 1-2 projects, mostly as an ETL framework. It didn't
work out, we found the it's not a good fit for changing requirements, plus GHC
was a bitch to use for debugging in production (cryptic). There were a lot of
disappointments around this type, for example "if it compiles it's probably
correct", or the often recurring "you can actually do that with an extension,
there's a paper on that" answer to pretty basic questions. Although these
projects were ultimately a failure, they produced some of the funniest war
stories which we remember fondly, which we still recite over beers to scare
our juniors :)

Other teams had more success and put small Haskell projects into production,
but these were later replaced with imperative versions, when Haskell produced
hard to debug/fix memory (list) leaks and/or noone was around who wanted to
maintain a Haskell service.

I also tried to use Haskell for personal projects, which I thought would a
good fit for strong typing: a library for physical units/dimensions. I also
failed on that, it quickly became a mess. Oddly, I found C++ templates a lot
more straightforward (even though I try to avoid C++ templates in general).

Today, I would not use Haskell in production, and would be highly skeptical of
a company doing so --- but while trying to keep an open mind.

~~~
sridca
> I also tried to use Haskell for personal projects, which I thought would a
> good fit for strong typing: a library for physical units/dimensions. I also
> failed on that, it quickly became a mess.

In what specific way we could have improved Haskell so that you'd succeed in
this scenario?

------
ghuntley
Howdy folks, I look after a team responsible for R&D and AI within a much
larger, financially successful / bootstrapped SaaS company. In the new year
I'll be hiring and/or building more Haskellers.

# hypothesis

there is a huge pool of people out there wanting to do Haskell as their day
job and use it build real products that make money. This is a way companies
can solve their talent acquisition problems.

# timebox & decision

I'm not currently hiring at the moment but please leave your digits at
[https://ghuntley.com/im-hiring](https://ghuntley.com/im-hiring) and when I am
you'll be on the shortlist of people to catch up with before publicly
advertising any positions.

# implementation

\- stimulating work at a SaaS product company w/competitive renumeration and
perks (inc flexible working)

\- existing knowledge of functional programming not required as new faces
bring new perspectives and ideas.

\- building an inclusive (gender, sexuality, neuro, kids/no-kids) aka diverse
team that teaches and shares knowledge freely

\- usage of functional programming in the industry to build products that make
money

\- optimising for approachable codebases that are easy understand and work
with

\- regular deployments into production (min once a day) with appropriate
telemetry

\- building local and international brand awareness by:

    
    
      - contributing back to open-source projects (financially & labour contributions) 
    
      - teaching people who attend the https://www.meetup.com/SydneyHaskell/ study group
    
      - authoring technical content on medium
    
      - attracting and building public speakers by supporting them via T&E
    

# goal & success metric

build a short-list of people who:

\- are currently doing functional programming OR are interested in switching
to Haskell / functional programming

\- live in Sydney, Australia or Chicago, Illinois and/or would consider a
relocation to Sydney, Australia or Chicago, Illinois.

hiring candidates from this short-list or through word of mouth
recommendations based upon activities our team does in the community

------
quickthrower2
C# is such a rich language due to language research type people, who bring
across ideas from Haskell. Look at typescript too with it’s discriminated
unions etc. And any language with the async keyword.

~~~
ghuntley
See [http://blog.ploeh.dk/2017/10/04/from-design-patterns-to-
cate...](http://blog.ploeh.dk/2017/10/04/from-design-patterns-to-category-
theory/) and [https://github.com/hmemcpy/milewski-ctfp-
pdf](https://github.com/hmemcpy/milewski-ctfp-pdf)

~~~
quickthrower2
Thanks, got those T-shirts already :-)

------
brudgers
Xmonad.

------
InGodsName
We used Haskell in an adnetwork to filter traffic and detect traffic fraud.

Railway oriented piplines are ideal for this kind of processing where Haskell
proved to be very useful.

That said now we code exclusively in Rust/Go but the fraud detection is still
built in Haskell.

------
steerpike
apart from the sanitation, the medicine, education, wine, public order,
irrigation, roads, a fresh water system, and public health?

