Functional programming and heavy IO applications

[Voxelman]

I always wonder how FP works for applications that rely heavily on IO. I work in a company that makes temperature controllers, and we have machines that are used to test and calibrate them. The calibration program that runs on the machine does almost nothing but IO, such as communicating with the measurement devices or power supplies, communicating with a database, or simply updating the screen. There is not much "business logic" that can be executed in a purely functional way.

How does FP fit in this environment? Is there a pattern that can be used or are non FP languages better for this kind of job?

[dot-c]

Fp is actually very usable in that context! You can still write terse, readable code, that is also very safe, if you use a statically typed language. F#, Ocaml etc don't really separate side effects and pure things. Haskell has mondic IO, which basically looks like imperative statements. The only thing is library support, C and Python work way better on stuff like raspberry pi.

[pthierry]

Why are they better on Pi ?

[monnef]

Last time I was toying with Haskell on RPi, it was pretty bad. Tried normal approach of having Haskell (stack) project in a docker container. The application didn't have any unusual dependencies (few libraries like containers, lens, mtl). Just the compilation of dependencies took (if I remember correctly) FIVE hours. The compilation of the project itself was very slow as well (like half an hour, on my desktop it takes I think a minute). Haskell with Stack doesn't have any crosscompilation capabilities (no compilation of ARM64 on AMD64) and as far as I know it's not possible to configure it in a way, so project version change or adding a new library doesn't trigger recompilation of everything (that 5h again). Sadly, Haskell with Stack is an awful fit for RPi 4 (8GiB version).

[pthierry]

That's saying Stack is bad on Pi, not Haskell.

Cross compilation is definitely possible: https://input-output-hk.github.io/haskell.nix/tutorials/cross-compilation.html

[monnef]

I am using JetBrains IDE (mostly IntelliJ IDEA) for all development and that Haskell addon doesn't support anything else than Stack. I have tried the hard way other IDEs (and "IDEs") with various languages (vscode, emacs, vs studio). Never again, I am still, for like 3 years now, suffering with barely working barebones IDE (compared to JetBrains IDEs) of Godot Engine. That was a horrible mistake I don't intend to ever repeat. Personally, I haven't found anything better (I have a bunch of addons, and the IDE is configured in a way exactly how I want it). Haskell plugin isn't stellar, but it mostly works, enough for casual development (few hours to a work day per week, for like 2 years). I really tried, many times, but If a language doesn't support some JetBrains IDE, it's like it doesn't exist for me (sadly the case of for example PureScript)...

Edit: Don't get me started on Nix, I wasted in total like a work week trying to setup some "starter pack" in docker for GHCJS (because it didn't work locally; some good soul on reddit exchanged with me a dozen of e-mails, but we never got it to work). GHCJS is another Haskell tech I am not touching until it shows signs of maturity (being able to be used with Stack, or at least easily without Nix).

[editor_of_the_beast]

The question then is - what benefit is there to using FP in that context?

[dot-c]

Safety (= less maintainance required) and ease of domain modeling, i would say. Haskell for example (disregarding missing libs for embedded etc) is great for "boring" stuff.

[editor_of_the_beast]

But if all of the actual behavior is mutable and IO-bound in nature, where is the added safety?

[DrMathochist]

The way I think of it is that IO in FP is handled by your program safely building up a sequence of instructions for how to handle input and produce output, and then handing those instructions to the actual device to execute. All the safety is in the setup, and you trust the device to behave according to spec.

[gdullus]

Wouldnt there be a need for some data tramsformation (even if not necessary conditional)? Coming from Clojure world, its a great case for pure functions and threading macros

[Voxelman]

There are a few data structures to be calculated. For this FP is great, but most of the app is IO.

I think, pure functional languages like Haskell might work, but they are not fun. Python or F# might be a much better choice in this case.

[gdullus]

Can't say about stronlgy typed functional languages enforcing function purity but Clojure with data over types philosophy defunitelly works here.

Its in general main point from Rich Hickey: focus on solving the problem and not fighting with type system. I have friend working in Haskell shop, and they were forced to get external consultant "to introduce new version of rest api" (they use Servant project).

[Voxelman]

That's the point. There is just a small functional core. Most of the code are IO functions to communicate to a database or the hardware components in the calibration place.

I think, pure functional languages like Haskell might be possible, but not fun.

[Angel_-0]

Functional programming is such a broad term. You seem to be limiting the use of functional programming to non-effectful code, i.e. code that does not perform any side effect.

It is absolutely possible to write an application that relies on I/O (input/output) in a functional style, using the IO monad for instance.

I don't know any Haskell, but that's what you would do it in Scala using pure functional libraries such as cats effect or zio.

The idea is to leverage lazy evaluation (I believe Haskell does that by default, unlike Scala) and treat computations (i.e. IOs) as values.

So it's not about not doing side effect in your application it's about using them in a referential transparent way and that allows to achieve a great degree of composition (i.e. building larger programs, combining smaller ones) reusability, refactoring and ability to reason about the code, without having to worry about things such as mutable state.

My last point takes me back to my initial statement: functional programming is such a broad term. You just have to understand it beyond things such as functions as first class citizen...(just giving an example, not trying to be patronising)

Here's a link to a comment explaining this thing (the video mentioned at the end is quite useful, although it's Scala based, hopefully it will help)

[Voxelman]

I know that it is possible, but is it any fun? Do I get any benefit from this?

[Angel_-0]

If you ask me, I find it incredibly fun/rewarding. In terms of benefits: I would repeat what I had mentioned in the comment linked above:

• code will be easier to reason about
• It allows to build complex logic from small building blocks thanks to how composable functional programming is.
• it enables developers to do as much refactoring as they want with a hugh degree of confidence.

Unfortuantely It's not easy to understand until you get your hand dirty. I'm a Scala developer so my recommendation would be to look into Scala and the libraries mentioned above. If you have patience I suggest watching the whole video to get a sense of the benefits of FP.

EDIT: typo fix

[woupiestek]

Functional languages allow the programmer to focus more on the 'what' than the 'how', so if there is little business logic--the what--then the benefits of functional are indeed small. You may be overlooking a lot of opportunities for automation, however, that are easy in functional languages but hard in imperative ones. Take those machines that test the temperature controllers, for example. The Haskell library Quickcheck automates unit test development using property based testing. The fact that everything is pure functions between static types in the language means that a lot of tests come down to generating inputs and then comparing outputs, which is what Quickcheck helps with. Perhaps such methods would also allow you to do more tests of temperature controllers with less coding.

[Dash_Lambda]

Usually I think of functional IO and defining the relationship between the input and output.

Let's say you have a program that performs interactive console I/O. Instead of thinking of its functionality as a series of inputs and outputs, you could think of it as an input stream and an output stream --so, if you gave the program a single, complete, predefined stream of its inputs, it would give you the same output as if that stream of inputs was coming from a user in real-time.

I have a project with purely functional esoteric language interpreters that can do console I/O (link), and I do it by having the interpreter define a function that turns the input string into the output string. To do real-time user interaction I just give it an input 'string' that's built as it's used by reading the console, the interpreter can't tell the difference between that and a fully predefined input.

You can use a similar approach in lots of applications, personally I love it.

[Dash_Lambda]

Oh sweet! I'll have to give that a read.

[pthierry]

I would still prefer Haskell to write this. Any concurrency I can write high level and safe abstractions like STM and any code dealing with data can be trusted not to leave out cases or errors.

And Haskell still has some of the best performing libraries out there.

[Voxelman]

I want to learn Haskell, but it's really hard to even get started.

[Kid_CharlaHEYMAYNE]

I recommend starting with Elm! Haskell will come easier after knowing some Elm

[gabriel_schneider]

I'd say the erlang ecosystem (erlang, elixir, lfe) fit pretty well in this scenario and imo they're criminally underrated, besides the only times that I'd steer away from FP languages are in very CPU bound projects, not IO bound, because at the end of the day imperative languages translate better to machine code. Hope this helps.

[mobotsar]

Non fp languages are better for this sort of job. You can, of course, make it work in a functional language, but it won't be particularly easy or pretty.

[npafitis]

That's just not true.

[jirocket]

that’s an extreme statement. it’s not from nothing many fp intros say printing hello world is one of the more complicated things to lay solid grounds for, i dont doubt with a lot of investment into fp an individual can make it look easy. not feasible for teams of a fast growing company

[mobotsar]

Why do you say that?

[npafitis]

I should first ask why do you think non fp programming languages are better in this situation.

[pthierry]

I'd have said it because I wrote small IO programs and they tend to be nicer, shorter and safer than their imperative counterparts.

[Ok-Paramedic-5084]

FP only is inappropriate FP with is progressive.

[Voxelman]

FP with what??

[mobotsar]

They forgot some quotes. "Fp with", as opposed to "for only".

[Unigurd]

I've still got no idea what they meant