Live data from Hacker News

Functional programming and reliability: ADTs, safety, critical infrastructure

blog.rastrian.dev

121–130 of 191 posts

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

#121
post #53

Earlier quoted context omitted.

You don't need a strong type system or even really ANY compile-time type system for this strategy to work! I use all these techniques in plain JS and I can still get the benefits of correct-by-construction code style just by freezing objects and failing fast.

You're about a decade too late with that argument. The best argument for dynamic types systems, is enjoying debugging in production. In dynamic languages, you are the type system.

> The best argument for dynamic types systems, is enjoying debugging in production.

This comment is either severe snark or severe ignorance.

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

#122

It's acceptable to state, without evidence, that functional programming and static typing make things more reliable. But this isn't a falsifiable claim. We cannot possibly know if this is true or not. - Not all of banking and telecom use functional programming or even static typing. - Functional programming often leads to write-only incomprehensible code; the exact opposite of what you need to have a reliable system.…

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

If you're going to start citing research, you should look at the Cooley finding on verilog vs VHDL.

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

#123

Earlier quoted context omitted.

> Wait. This doesn’t make sense to me. Statically typed programming languages cannot be deployed nor can they run with a type error that happens at runtime. Untyped languages CAN run and error out with a type error AT runtime. The inevitable consequence of that truth is this There is nothing inevitable about the consequence you’re imagining because statically typed languages also reject correct programs.

It is 100 percent inevitable. Your reasoning here is illogical. How does a statically typed language rejecting a correct program affect reliability? The two concepts are orthogonal. You’re talking about flexibility of a language but the topic is on reliability. Let me be clear… as long as a language is Turing complete you can get it to accomplish virtually any task. In a statically typed language you have less ways t…

>How does a statically typed language rejecting a correct program affect reliability?

Because in some cases it will reject code that is simple and obviously correct, which will then need to be replaced by code that is less simple and less obviously correct (but which satisfies the type checker). I don't think this happens most of the time, but it does mean that static typing isn't a strict upgrade in terms of reliability. You are paying for the extra guarantees on the code you can write by giving up lots of correct programs that you could otherwise have written.

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

#124

It's acceptable to state, without evidence, that functional programming and static typing make things more reliable. But this isn't a falsifiable claim. We cannot possibly know if this is true or not. - Not all of banking and telecom use functional programming or even static typing. - Functional programming often leads to write-only incomprehensible code; the exact opposite of what you need to have a reliable system.…

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

The benefits of static typing with regard to reliability are unclear, at best:

https://danluu.com/empirical-pl/

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

#125
post #122

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

If you're going to start citing research, you should look at the Cooley finding on verilog vs VHDL.

That's certainly an interesting data point, but it was a 90 minute programming contest, not peer-reviewed research.

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

#126
post #103

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.

> In fact, I'd argue that all you need for reliability is determinism and tests of all equivalent scenarios. Any insights as to how to get effective determinism without pure functions? Pure functions win here because we only have to reason about the function arguments. Reasoning is easier when you have to less of it! Without pure functions, the state space explodes, because anything anywhere could have a side-effect…

> The arguments against pure functions appear to be somewhat contingent: current adoption levels, practice, convenience, and taste.

At least with many GUIs, the time it would take to know, document and/or test all combinations of UI behaviors quickly exceeds the time available to humans. It's at least tractable to start with vastly more states than could ever be measured, and then gate or special-case certain ones to try to make things minimally safe/sane/reliable for the user.

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

#127
post #122

Earlier quoted context omitted.

If you're going to start citing research, you should look at the Cooley finding on verilog vs VHDL.

That's certainly an interesting data point, but it was a 90 minute programming contest, not peer-reviewed research.

The second paper shown above is firewalled.

The first paper shown above was presented at ICPC, which has a history of bias in reviewing, and typically only assigns one or two reviewers in any case.

Which makes it not surprising that the paper itself doesn't really prove anything, except that the authors themselves are good at creating dissimilar situations.

Subjects had to modify existing systems, which were provided by the experimenters.

The experimenters deliberately removed any semblance of anything that might hint at types (comments, variable names, etc.) and did who the fuck knows what else to the dynamically typed code to make it difficult to work with.

They also provided their own IDE and full environment which the participants had to use.

Now, of course, we've all seen the graphs which show that for simple problems, dynamic is better, and there's a crossover point, and, of course Cooley's experiment is on the far left of that graph, so it certainly doesn't prove that strict static typing isn't better for large programs, but it's at least honest in its approach and results, using self-selected working practitioners (and there was never any shortage of working practioners swearing by how much better VHDL is).

https://danluu.com/verilog-vs-vhdl/

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

#128
post #6

Earlier quoted context omitted.

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

Static types and ADTs are orthogonal to being FP, as Rust clearly shows. But to speak in terms of FP when those are the important things for you is just wrong since even non FP languages now have ADT, including also mainstream languages like Java, Kotlin, Dart, C# and more.

Even purity is not something exclusive to FP, D and Nim also support separating pure from impure functions. And if you ask me, the reason not many other languages have support for that is that in practice, it has been demonstrated again and again that it’s just not nearly as useful as you may think. Effects, as in Unison and Flix, generalizes the concept to include many more concepts than just purity and may perhaps prove more useful in general purpose programming, but the jury is still out on this.

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

#129

Earlier quoted context omitted.

I’ve worked in Brazilian banking stacks that were literally FTP + spreadsheets for years. So yes, the ecosystem is often messy and protocols can be flaky. That’s exactly why I argue for stronger internal modeling: when the boundary is dirty, explicit state machines/ADTs + exhaustiveness + idempotency/reconciliation help ensure bad feeds don’t silently create invalid internal states.

I totally agree as a fellow fintech engineer. It was a battle getting approval for all that from Product for us. While we were battling for it, we rushed multiple projects without literally any of it. And then spent a year+ each time cleaning up the mess.

And your pockets were being filled in that year while you were just doing cleanups. Mission accomplished.

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

#130

> In banking, telecom, and payments, reliability is not a nice to have. It is table stakes. Haha as someone who has worked in one of these domains using FP even - I wish the people in charge agreed with you! Reliability is a cost center and Product-oriented Builders treat it as such.

Perhaps someone can enlighten me on this. I never quite understood the sentiment of treating money-related tech as somehow more critical than others. The effects of large SaaS services failing and the bank failing can be quite similar - businesses interrupted, money lost, etc. but it’s typically not life and death, so the importance of reliability should be similar. I can understand treating social network sites as l…

Compare discussions about banking with discussions about evoting ! One is totally fine for software to handle, the other is absolutely not!! That tells you which one people really consider critical.
Post reply on HN