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

141–150 of 191 posts

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

#141

Post by chrisoverzero »

fuzztester wrote: post #108
chrisoverzero wrote: post #94

Earlier quoted context omitted.

> […] it shouldn't take long at all for people to learn the highly consistent naming conventions that tip you off to what type of data is being handled. I’ve used languages with an approach like this. The difference in what I’ve used is that you separate the conventional part from the rest of the name with a space (or maybe a colon), then only refer to the value by the non-conventional part for the rest of the scope.…

I don't get your 2nd sentence: "The difference in what I’ve used" ... Can you give an example, and name the language used?

Sure! Let’s say I want to enforce that a variable only ever holds an integer. Rather than put the conventional prefix and the name together, like this:

    var intValue = 3;
…I separate the conventional prefix with a space:

    int value = 3;
…so now my co-workers don’t need to remember the convention – it’s enforced by the language.

(I hope this makes the joke more obvious.)

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

#142

Post by threethirtytwo »

foldr wrote: post #123
threethirtytwo wrote: post #83

Earlier quoted context omitted.

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

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

It is a strict upgrade in reliability. You're arguing for other benefits here, like readability and simplicity. The metric on topic is reliability and NOT other things like simplicity, expressiveness or readability. Additionally, like you said, it doesn't happen "most" of the time, so even IF we included those metrics in the topic of conversation your argument is not practical.

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

Again the payment is orthogonal to the benefit. The benefit is reliability. The payment is simplicity, flexibility, expressiveness, and readability. For me, personally, (and you as you've seem to indicate) programs actually become more readable and more simple when you add types. Expressiveness and flexibility is actually a foot gun, but that's not an argument I'm making as these are more opinions and therefore unprovable. You're free to feel differently.

My argument is that in the totality of possible errors, statically typed programs have provably LESS errors and thus are definitionally MORE reliable than untyped programs. I am saying that there is ZERO argument here, and that it is mathematical fact. No amount of side stepping out of the bounds of the metric "reliability" will change that.

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

#143

Post by threethirtytwo »

foldr wrote: post #123
threethirtytwo wrote: post #83

Earlier quoted context omitted.

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

Also Did you read what I wrote? I Covered your argument here DIRECTLY in my response. It's like you read the first sentence and then responded while ignoring the next paragraph.

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

#144

Post by brabel »

yunnpp wrote: post #133
brabel wrote: post #128

Earlier quoted context omitted.

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

Help me with a tl;dr here, but are effects just monads?

Great question! But no, they are not the same, despite some similarities.

In Unison, effects are called abilities, and they wrote a very good post explaining the differences!

https://www.unison-lang.org/docs/fundamentals/abilities/for-...

In summary: both have advantages and disadvantages. Which one is "better" depends on which factors you value more.

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

#145

Post by jghn »

agumonkey wrote: post #119
jghn wrote: post #118

Earlier quoted context omitted.

No I think your point is good, it just wasn't contradictory and I think that was your intent. Defining FP is a dark art :)

maybe FP should be explained as `rules not values`. in scheme it's common to negate the function to be applied, or curry some expression or partially compose / thread rules/logic to get a potential future value that did nothing yet

I like it. I think I said this in a separate post in here but I've taken to breaking it down to different archetypes and discussing them separately.

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

#146

Post by conartist6 »

chrisoverzero wrote: post #141
fuzztester wrote: post #108

Earlier quoted context omitted.

I don't get your 2nd sentence: "The difference in what I’ve used" ... Can you give an example, and name the language used?

Sure! Let’s say I want to enforce that a variable only ever holds an integer. Rather than put the conventional prefix and the name together, like this: var intValue = 3; …I separate the conventional prefix with a space: int value = 3; …so now my co-workers don’t need to remember the convention – it’s enforced by the language. (I hope this makes the joke more obvious.)

I wasn't talking about Hungarian notation. I meant more like if you see a variable named `user` or `activeUser` you know that it's going to contain a predictably-shaped data object that describes a user. E.g. it will always have a `user.id` property. I would never call an string-ish ID a user, then. I would call it `activeUserId` or `userId` or just `id` if the distinction between those was already obvious from context... But that's very different from writing `strUserId` which I never do: I try to make sure my names always convey semantic distinctions.

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

#147

Post by kephasp »

yobbo wrote: post #139
Jeff_Brown wrote: post #88

Earlier quoted context omitted.

Amen. I've been coding a big hobby project in Rust since July, after having spent years using Haskell for such things. I chose Rust because the primary DB I wanted to use (TypeDB) only had drivers for Rust and Python at the time. Rust is popular relative to Haskell, so I thought others might be more likely to sign on, and the type system seemed almost as expressive. But since purity is not encoded in Rust's type syst…

Db access in rust typically needs some sort of handle and a mutex. Limiting access to the handle makes the rest of the code pure with respect to the db. The handle plays a similar role to the IO type. Actor-like patterns makes this nice. Message-objects can be passed to/from a module with db-access or other io.

How can you prevent code from creating a handle in a new place?

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

#148

Post by kephasp »

agumonkey wrote: post #110
mightybyte wrote: post #86

Was just talking with someone the other day who used to write Haskell professionally but is now using Python. He said that in his experience when there are bugs the "blast radius" is much larger in a dynamic language like Python than in a static language like Haskell. That has been my experience as well. Something I haven't seen talked about, though, is how powerful the type system is for constraining LLMs when using…

this makes me want to move to a haskell (or any hard fp language) shop in 2026..

I've been using Haskell professionally for the last 5 years, I definitely hope I can continue!

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

#149

Post by foldr »

threethirtytwo wrote: post #142
foldr wrote: post #123

Earlier quoted context omitted.

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

>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. It is a strict upgrade in reliability. You're arguing for other benefits here, like readability and simplicity. The metric on topic is reliability and NOT other things like simplicity, expressiveness or readability. Additionally, like you said, it doesn't happen "most" of the time, so even…

Readability and simplicity can increase reliability, because simple readable code is easier to review.

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

#150

Post by thundergolfer »

int08h wrote: post #61
thundergolfer wrote: post #24

All the line items are decent things, worth doing, but the claim about how much following the line items would improve reliability is super exaggerated. > [Most production incidents] are due to the code entering a state that should never have been possible. I have never seen evidence that this is even remotely true, and I've been looking at software reliability research in the last few months. Instead, it is more tru…

Hmm, it seems you actually agree with the OP: OP says (your quote): > [Most production incidents] are due to the code entering a state that should never have been possible. You say: > [...] it is more true that most production incidents are due to the system entering into one of thousands of unsafe states which were possible and latent in production potentially for years I see you both agree that a broken system ente…

The crux is in the "never have been possible" bit. In complex systems, it is impossible to eliminate these potential states with functional programming or any other technique, unsafe states are always potentialities that must be actively controlled.

Another way of casting it is like this. The goal may be:

1. Eliminate possibility code can enter invalid state 2. Control parameters of the system so that it remains in a safe condition

Those are very different goals.

Post reply on HN