Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Functional programming and reliability: ADTs, safety, critical infrastructure

blog.rastrian.dev

Post reply on HN
Print view View original

41–50 of 191 posts

Re: Functional programming and reliability: ADTs, safety, critical infrastructure

#41

Post by adamddev1 »

mlavrent wrote: post #2

This article seems to conflate strong type systems with functional programming, except in point 8. It makes sense why- OCaml and Haskell are functional and were early proponents of these type systems. But, languages like Racket don’t have these type systems and the article doesn’t do anything to explain why they are _also_ better for reliability.

I worked through https://htdp.org (which uses untyped Racket), and funny enough, that's what really for me thinking about type driven development. The book gets you to think about and manually annotate the types coming in and out of functions. FP just makes it so natural to think about putting functions together and thinking about the "type" of data that comes in and out, even if you're using a dynamically typed language.

Re: Functional programming and reliability: ADTs, safety, critical infrastructure

#42

Post by charcircuit »

discarded1023 wrote: post #10
charcircuit wrote: post #3

>In banking, telecom, and payments, reliability is not a nice to have. It is table stakes. This reliability isn't done by being perfect 100% of the time. Things like being able to handle states where transactions don't line up allowing for payments to eventually be settled. Or for telecom allowing for single parts of the system to not take down the whole thing or adding redundancy. Essentially these types of business…

You'd like to know your fault tolerance is reliable and possibly even correct.

Not if proving so is more expensive to do than not. Reliability is only a means. Not the end. Also the human parts of the business would need to be simplified in order to model them. If deviate from the model that could invalidate it.

Re: Functional programming and reliability: ADTs, safety, critical infrastructure

#43

Post by rastrian »

aag wrote: post #6
mlavrent wrote: post #2

This article seems to conflate strong type systems with functional programming, except in point 8. It makes sense why- OCaml and Haskell are functional and were early proponents of these type systems. But, languages like Racket don’t have these type systems and the article doesn’t do anything to explain why they are _also_ better for reliability.

Thank you for saying that. I regularly attend the International Conference on Functional Programming, which grew out of the LISP and Functional Programming conference. Except for the Scheme Workshop, which is the reason I attend, it might as well be called the International Conference on Static Types. Almost all of the benefits of functional programming come from functional programming itself, not from static types,…

I get your point about ICFP drifting into “types, types, types.” I don’t think FP benefits are only static typing or immutability, pure-ish core/imperative shell, and explicit effects matter a lot even in dynamic languages.

My angle was narrower: static types + ADTs improve the engineering loop (refactors, code review, test construction) by turning whole classes of mistakes into compiler errors. That’s not “what FP is”, it’s one very effective reliability layer that many FP ecosystems emphasize.

Re: Functional programming and reliability: ADTs, safety, critical infrastructure

#44

Post by adamddev1 »

d--b wrote: post #12

Strong types: yes, it’s definitely better Functional programming: no, functional programming as in: the final program consists in piping functions together and calling the pipe. In my opinion, that tends to get in the way of complex error handling. The problem being that raising Exceptions at a deep level and catching them at some higher level is not pure functional programming. So your code has to deal with all the…

Mr. Error Monad enters the chat...

Re: Functional programming and reliability: ADTs, safety, critical infrastructure

#45

Post by rastrian »

mlavrent wrote: post #2

This article seems to conflate strong type systems with functional programming, except in point 8. It makes sense why- OCaml and Haskell are functional and were early proponents of these type systems. But, languages like Racket don’t have these type systems and the article doesn’t do anything to explain why they are _also_ better for reliability.

Agreed, I conflated FP with “typed FP.” My claim is mainly about static types + ADTs/exhaustiveness improving refactors/review/tests. Racket can get FP benefits, but absent static typing you rely more on contracts/tests (or Typed Racket), which is a different reliability tradeoff.

Re: Functional programming and reliability: ADTs, safety, critical infrastructure

#46

Post by adamddev1 »

cubefox wrote: post #16

I think there is a strong case that ADTs (algebraic data types) aren't so great after all. Specifically, the "tagged" unions of ADT languages like Haskell are arguably pretty clearly inferior to the "untagged" unions of TypeScript or Scala 3. Because the latter actually behave like a logical "or" rather than an artificial construct that needs to be wrapped and unwrapped.

I at first thought it was nice to save the wrapping, but you save yourself sooo much pain, ugliness and mistakes pattern matching trying to distinguish the types once you just use tagged unions.

Re: Functional programming and reliability: ADTs, safety, critical infrastructure

#47

Post by rowanG077 »

pizlonator wrote: post #40
ux266478 wrote: post #36

Earlier quoted context omitted.

> There's no hard evidence that static typing improves reliability. I'm curious how you came to that conclusion? https://pleiad.cl/papers/2012/kleinschmagerAl-icpc2012.pdf https://www.deepdyve.com/lp/springer-journals/an-empirical-s...

I don't consider a human subjects study to be "hard evidence". So, we can safely disregard these papers. They got exactly the result that they sought out to get, and the papers were published because they confirmed the preexisting groupthink.

Interesting, so you consider the entire scientific field of medicine to work without hard evidence?

Re: Functional programming and reliability: ADTs, safety, critical infrastructure

#48

Post by rastrian »

charcircuit wrote: post #42
discarded1023 wrote: post #10

Earlier quoted context omitted.

You'd like to know your fault tolerance is reliable and possibly even correct.

Not if proving so is more expensive to do than not. Reliability is only a means. Not the end. Also the human parts of the business would need to be simplified in order to model them. If deviate from the model that could invalidate it.

Agree on the economics. I’m not arguing for full formal proofs; I’m arguing for low-cost enforcement of invariants (ADTs/state machines/exhaustiveness) that makes refactors safer and prevents silent invalid states. Human processes will always drift, so you enforce what you can at the system boundary and rely on reconciliation/observability for the rest.

Re: Functional programming and reliability: ADTs, safety, critical infrastructure

#49

Post by pizlonator »

rowanG077 wrote: post #47
pizlonator wrote: post #40

Earlier quoted context omitted.

I don't consider a human subjects study to be "hard evidence". So, we can safely disregard these papers. They got exactly the result that they sought out to get, and the papers were published because they confirmed the preexisting groupthink.

Interesting, so you consider the entire scientific field of medicine to work without hard evidence?

You mean psychology? There’s no hard evidence there. The papers you’re citing are using human subjects in that sort of way. It’s pseudoscience at best

Medicine that involves testing human subject response to treatments is very different from the papers you’re citing and does involve falsifiable theses (usually, definitely not always).

Re: Functional programming and reliability: ADTs, safety, critical infrastructure

#50

Post by rastrian »

websiteapi wrote: post #30

A few mention on tests, but I expected more. The main value of pure functions is that now their behavior is representative in tests. In fact, I'd argue that all you need for reliability is determinism and tests of all equivalent scenarios. functional programming (and immutability) are only helpful to the extent that it's easier to have representative tests, but not necessarily required.

Agree, I didn’t give testing enough space. A proper treatment would’ve doubled the post, so I’m writing a separate follow-up on testing.

Pure functions/immutability help a lot because tests become representative and cheap. I’d only push back on “tests of all equivalent scenarios” being sufficient, the space explodes and many real failures live at I/O/concurrency/distributed boundaries. My intended claim is that FP/ADTs/types reduce the state space and improve the ROI of tests, not replace them.

Post reply on HN