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

Functional Programming Self-Affirmations

norikitech.com

Post reply on HN
Print view View original

51–60 of 119 posts

Re: Functional Programming Self-Affirmations

#51

Post by greener_grass »

yazzku wrote: post #48
greener_grass wrote: post #24

Earlier quoted context omitted.

> Is immutability exclusive to functional programming? No, but immutable defaults are powerful. E.g. in JavaScript / Python, the built-in lists and dictionarys (which are blessed with special syntax) are mutable. > Is the ability to use data/values exclusive to functional programming? No, but expression-orientation makes this less painful > Are monads exclusive to functional programming? You can hack them in by abusi…

You don't need coroutines or async or anything complicated to model monads, just functions and data structures. Search for "c++ monads" and you'll find a ton of examples.

You need the syntax if you want it to actually work well in practice.

Re: Functional Programming Self-Affirmations

#52

Post by jandrese »

keybored wrote: post #32
jandrese wrote: post #26

> Make illegal states unrepresentable This is a nice ideal to shoot for, but strict adherence as advocated in the article is a short path to algorithmic explosions and unusable interfaces on real life systems. For example, if you have two options that are mutually incompatible, this principle says you don't make them booleans, but instead a strict enum type populated with only legal combinations of the options. A gre…

Where does this exponentional size requirement come from?

Imagine you have a program where there are 4 options, W, X, Y, Z. Y and Z can't be set at the same time, and X can't be set unless W is set. If Y is set then X must be set as well.

How do you represent this in a way that makes it impossible, even through programmer error elsewhere in the program, to have the flags in an invalid state?

You can create en enum that looks like:

    enum program_state =
    (
      W_X_Y_NZ,
      W_NX_NY_Z,
      NW_NX_NY_Z,
      ... and so on
     );

Re: Functional Programming Self-Affirmations

#53

Post by munificent »

It's hard not to giggle when the conclusion right after "Smart constructors" says "Do these ideas belong only in functional programming? While they are practiced more there...".

Ah yes, because using constructors to ensure that new objects are in a valid state is virtually unheard of in object-oriented programming.

Re: Functional Programming Self-Affirmations

#54

Post by beders »

In many (but not all) scenarios "Make illegal states unrepresentable" is way too expensive to implement.

Especially when dealing with a fast changing domain, having to support different versions of data shapes across long time periods: dynamic data definitions are more economic and will still provide sufficient runtime protection.

"Errors as values" - what is an error? I see this pattern misused often, because not enough thought was put into the definition of an error.

"Disk is Full" vs. "data input violates some business rule" are two very - very - different things and should be treated differently. Exceptions are the right abstraction in the first case. It's not in the second case.

"Functional core, imperative shell" - 100% agreement here.

Re: Functional Programming Self-Affirmations

#55

Post by joe_the_user »

kccqzy wrote: post #37
jandrese wrote: post #26

> Make illegal states unrepresentable This is a nice ideal to shoot for, but strict adherence as advocated in the article is a short path to algorithmic explosions and unusable interfaces on real life systems. For example, if you have two options that are mutually incompatible, this principle says you don't make them booleans, but instead a strict enum type populated with only legal combinations of the options. A gre…

Nobody says you have to have a single enum type containing all the combinations. Chances are, you can use sum types (discriminated unions) to factor things nicely if you think about them. For example if option B is only relevant when option A is set to true, you can have something like data OptA = ATrue OptB | AFalse data OptB = BTrue | BFalse There are three valid combinations but no type has three alternatives. Nob…

Nobody says you have to have a single enum type containing all the combinations.

No, no one would continue up to 2^16 and the code would get unmanageable long before that. But it's illustration of the problems starting out dealing with the invalid states of two variables using an enum because what happens when more and more variables arrive? Sure, the standard answer is "just refactor" but my experience is no client or boss wants to hear "adding this small state is going require a lot of change" and a trickle of binary conditions is a very common occurrence as is code expanding to handle these (and become excessively complicated).

Chances are, you can use sum types (discriminated unions) to factor things nicely if you think about them.

Maybe you have a good chance of combining these binary conditions in a good way. But I mention you've substituted a hard problem instance (factoring binary conditions) for an easy problem instance (checking binary conditions). Functional programming has a weird dual personality where on the one hand you hear "A functional programmer is always a smarty and solve hard problems as a matter of course" but also you hear "functional programming would be the dominant paradigm if only ... we taught people young so they wouldn't have their bad procedural habits"

Re: Functional Programming Self-Affirmations

#56

Post by jandrese »

kccqzy wrote: post #37
jandrese wrote: post #26

> Make illegal states unrepresentable This is a nice ideal to shoot for, but strict adherence as advocated in the article is a short path to algorithmic explosions and unusable interfaces on real life systems. For example, if you have two options that are mutually incompatible, this principle says you don't make them booleans, but instead a strict enum type populated with only legal combinations of the options. A gre…

Nobody says you have to have a single enum type containing all the combinations. Chances are, you can use sum types (discriminated unions) to factor things nicely if you think about them. For example if option B is only relevant when option A is set to true, you can have something like data OptA = ATrue OptB | AFalse data OptB = BTrue | BFalse There are three valid combinations but no type has three alternatives. Nob…

Imagine a case where you have 4 options. W, X, Y, Z.

Y and Z are mutually exclusive.

X can only be set if W is set.

If Y is set then X must be set.

Going down this road you end up encoding your business logic into your datatypes. Which is good to a degree, but makes things messy when new options are added or requirements change. Imagine a new option U is introduced that is only valid when W is unset and Z is set but allows X to be set. Your interface becomes very hard to manage with even a small amount of complexity added to the options.

Re: Functional Programming Self-Affirmations

#57

Post by wrenky »

munificent wrote: post #53

It's hard not to giggle when the conclusion right after "Smart constructors" says "Do these ideas belong only in functional programming? While they are practiced more there...". Ah yes, because using constructors to ensure that new objects are in a valid state is virtually unheard of in object-oriented programming.

One thing this article does is assume extreme functional mindset, I dont even think OOP enters into the authors mind- With that context, I think that statement isn't about object constructors but type constructors.

Re: Functional Programming Self-Affirmations

#59

Post by neonsunset »

bunderbunder wrote: post #39
greener_grass wrote: post #14

Earlier quoted context omitted.

I'm not convinced that you can follow all of these outside of Functional Programming. How can you "Make illegal states unrepresentable" with mutable state and sequences of mutations that cannot be enforced with the type system? How can you do "Errors as values" at a large scale without do-notation / monads? How can you do "Functional core, imperative shell" without the ability to create mini DSLs and interpreters in…

Maybe not in literally every language, but, to cherry pick some examples: Java (along with many other object-oriented languages) lets you create objects that are effectively immutable by declaring all fields private and not providing any property setters or other methods that would mutate the state. Errors as values is one of the headline features of both Go and Rust, neither of which has do notation and monads. Func…

Coincidentally, "functional core, imperative shell" is how most companies get to adopt F# from what I was told (and had seen). It integrates really well. C# itself is a proper multi-paradigm language nowadays, and so is also quite successful at employing functional constructs.

Re: Functional Programming Self-Affirmations

#60

Post by reval »

jandrese wrote: post #26

> Make illegal states unrepresentable This is a nice ideal to shoot for, but strict adherence as advocated in the article is a short path to algorithmic explosions and unusable interfaces on real life systems. For example, if you have two options that are mutually incompatible, this principle says you don't make them booleans, but instead a strict enum type populated with only legal combinations of the options. A gre…

This is technically correct but disingenuous. This reminds of the climate change comic where a scientist asks “What if climate change is a big hoax and we create a better world god nothing?”
Post reply on HN