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.

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.

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.

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.

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.

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

> Recursion is a bad idea

Raw recursion or recursion using recursive schemes?

Any recursion. The problem is that, without tail call optimization, you create one stack frame per recursion. In Nokinside's world, you have to prove that you will never exceed the stack size. To prove that, you have to prove an upper bound on the number of recursion calls, and multiply by the size of a call's stack frame. Proving it for iteration is much easier, partly because (under the MISRA C rules or similar) iterations must have fixed bounds, but mostly because you don't create a stack frame for each iteration.

My turn: What's a recursive scheme?

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

That's why we need more Haskell-hosted system programming DSLs - with fancy sound types, proofs, extraction and stuff.

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.

Re: math, composition and universal abstractions

Folks please read https://github.com/hmemcpy/milewski-ctfp-pdf

Re: learning Haskell

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

Stitching together apis to create business value is accomplishing the basic function of any company or startup. Masturbating over math proofs by themselves don’t keep bread on the table. Just a thought before dismissing the work of others for being “less rigorous”. Though obviously the best is a combination of both.

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.

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

On the topic of time/space leaks in functional programming. Folks are working on enabling intensionality which will have profound implications for programming language design.

See https://m.youtube.com/watch?v=4i4SNvlWnmM and https://github.com/Barry-Jay/SF and https://arxiv.org/abs/1410.7103

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

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.

See http://blog.ploeh.dk/2017/10/04/from-design-patterns-to-cate... and https://github.com/hmemcpy/milewski-ctfp-pdf

Thanks, got those T-shirts already :-)

Xmonad.

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.

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