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

111–120 of 191 posts

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

#111

Post by agumonkey »

jghn wrote: post #109
mightybyte wrote: post #87

Earlier quoted context omitted.

The term "functional programming" is so ill-defined as to be effectively useless in any kind of serious conversation. I'm not aware of any broadly accepted consensus definition. Sometimes people want to use this category to talk about purity and control of side effects and use the term "functional programming" to refer to that. I would advocate the more targeted term "pure functional programming" for that definition.…

> The term "functional programming" is so ill-defined as to be effectively useless in any kind of serious conversation. This is important. I threw my hands up and gave up during the height of the Haskell craze. You'd see people here saying things like LISP wasn't real FP because it didn't match their Haskell-colored expectations. Meanwhile for decades LISP was *the* canonical example of FP. Similar to you, now I talk…

to add a grain of salt, some of the lisp world is not functional, a lot of code is straight up imperative / destructive. but then yeah a lot of the lisp culture tended to applicative idioms and function oriented, even without the static explicit generic type system of haskell.

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

#112

Post by jghn »

agumonkey wrote: post #111
jghn wrote: post #109

Earlier quoted context omitted.

> The term "functional programming" is so ill-defined as to be effectively useless in any kind of serious conversation. This is important. I threw my hands up and gave up during the height of the Haskell craze. You'd see people here saying things like LISP wasn't real FP because it didn't match their Haskell-colored expectations. Meanwhile for decades LISP was *the* canonical example of FP. Similar to you, now I talk…

to add a grain of salt, some of the lisp world is not functional, a lot of code is straight up imperative / destructive. but then yeah a lot of the lisp culture tended to applicative idioms and function oriented, even without the static explicit generic type system of haskell.

Sure, but that's part of my point in agreeing that definitions of "functional programming" are muddy at best. If one were to go back to say 1990 and poll people to name the first "functional programming" language that comes to mind, I'd wager nearly all of them would say something like LISP or Scheme. It really wasn't until the late aughts/early teens when that started to shift.

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

#113

Post by submain »

mightybyte wrote: post #87
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.

The term "functional programming" is so ill-defined as to be effectively useless in any kind of serious conversation. I'm not aware of any broadly accepted consensus definition. Sometimes people want to use this category to talk about purity and control of side effects and use the term "functional programming" to refer to that. I would advocate the more targeted term "pure functional programming" for that definition.…

I usually define functional programming as "how far away a language is from untyped lambda calculus". By that definition, different languages would fall in different parts of that spectrum.

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

#114

Post by zozbot234 »

xpe wrote: post #95

See also the type-state pattern. It is commonly used in Rust along with the builder pattern [1]. Quoting: """The typestate pattern is an API design pattern that encodes information about an object’s run-time state in its compile-time type. In particular, an API using the typestate pattern will have: - Operations on an object (such as methods or functions) that are only available when the object is in certain states,…

The type-state pattern is really just OOP implementation inheritance in a type-theoretic trench coat. The relevant difference is simply that most uses of type-state are not trying to span multiple modules like the OOP design approach does; the "state" variations are contained such that they don't impact modularity throughout the program, unlike the OOP inheritance approach.

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

#115

Post by cubefox »

jadsfwasdfsd wrote: post #107
jesse__ wrote: post #70

Earlier quoted context omitted.

The String|null example is just a nullable type; it's not an interesting use of unions either way. The conversation starts when it's Foo|Bar|Baz I'm unfamiliar with typescript, so in that language I don't have an opinion either way, but in C, you pretty much always want the tag

> but in C, you pretty much always want the tag We aren't discussing unions in memory layout, but in type systems. This also clearly indicates you aren't qualified for this discussion.

To be fair, even Wikipedia talks about "untagged unions" only in the context of C. The terminology is confusing and the literature often out of date.

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

#116

Post by agumonkey »

jghn wrote: post #112
agumonkey wrote: post #111

Earlier quoted context omitted.

to add a grain of salt, some of the lisp world is not functional, a lot of code is straight up imperative / destructive. but then yeah a lot of the lisp culture tended to applicative idioms and function oriented, even without the static explicit generic type system of haskell.

Sure, but that's part of my point in agreeing that definitions of "functional programming" are muddy at best. If one were to go back to say 1990 and poll people to name the first "functional programming" language that comes to mind, I'd wager nearly all of them would say something like LISP or Scheme. It really wasn't until the late aughts/early teens when that started to shift.

Yeah sorry i wasn't bringing much by commenting this above. And yeah lisp was the historical soil for FP (schemers took the lead on this).

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

#117

Post by cubefox »

rastrian wrote: post #93
cubefox wrote: post #67

Earlier quoted context omitted.

I believe there is a misunderstanding. The compiler can check untagged unions just as much as it can check tagged unions. I don't think there is any problem with "ambiguous narrowing", or "reliability". There is also no risk of "nullable everywhere": If the type of x is Foo|Null, the compiler forces you to write a null check before you can access x.bar(). If the type of x is Foo, x is not nullable. So you don't have…

I think we mostly agree for the nullable case in a sound-enough type system: if Foo | null is tracked precisely and the compiler forces a check before x.bar, then yes, you’re not “remembering” checks manually, the compiler is. Two places where I still see tagged/discriminated unions win in practice: 1. Scaling beyond nullability. Once the union has multiple variants with overlapping structure, “untagged” narrowing be…

I think the real promise of "set-theoretic type systems" comes when don't just have (untagged) unions, but also intersections (Foo & Bar) and complements/negations (!Foo). Currently there is no such language with negations, but once you have them, the type system is "functionally complete", and you can represent arbitrary Boolean combination of types. E.g. "Foo | (Bar & !Baz)". Which sounds pretty powerful, although the practical use is not yet quite clear.

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

#118

Post by jghn »

agumonkey wrote: post #116
jghn wrote: post #112

Earlier quoted context omitted.

Sure, but that's part of my point in agreeing that definitions of "functional programming" are muddy at best. If one were to go back to say 1990 and poll people to name the first "functional programming" language that comes to mind, I'd wager nearly all of them would say something like LISP or Scheme. It really wasn't until the late aughts/early teens when that started to shift.

Yeah sorry i wasn't bringing much by commenting this above. And yeah lisp was the historical soil for FP (schemers took the lead on this).

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

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

#119

Post by agumonkey »

jghn wrote: post #118
agumonkey wrote: post #116

Earlier quoted context omitted.

Yeah sorry i wasn't bringing much by commenting this above. And yeah lisp was the historical soil for FP (schemers took the lead on this).

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

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

#120

Post by garethrowlands »

pizlonator wrote: post #29

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

Citation needed.
Post reply on HN