3 ms·

I am by no means the best to judge functional programming implementations but I find the examples provided as pretty confusing. The parts where the library is s

I am by no means the best to judge functional programming implementations but I find the examples provided as pretty confusing. The parts where the library is supposed to make things better actually look worse to me. The original Python examples also looks like cherry picked code that was already not written very well. if user is not None: balance = user.get_balance() if balance is not None: credit = balance.credit_amount() if credit is not None and credit > 0: discount_program = choose_discount(credit) I would probably write the python closer to this for readability. Don't judge me too harshly I just rewrote this quickly. if user is None: return balance = user.get_balance() if balance is None: return credit = balance.credit_amount() if credit is not None and credit > 0: discount_program = choose_discount(credit)

NoboruWataya 3y ago
What I really want (but Python doesn't have) is: credit = user?.get_balance()?.credit_amount() if credit is not None and credit > 0: discount_program = choose_discount(credit)
- Izkata 3y ago
  I swear I remember once seeing a library that enabled this by wrapping the first object: Foo(user).get_balance().credit_amount() Maybe with an additional .get() at the end to unwrap it? Though I imagine a dynamically-created class could avoid that.
- hprotagonist 3y ago
  https://peps.python.org/pep-0505/ https://peps.python.org/pep-0505/ there's a PEP. But it's been pocket-vetoed, i think.
BerislavLopac 3y ago
IMO, the problem with the original code is not in the way it nests ifs, it's in the bad design. If it is properly nested in a function, user should not ever be None (any user-less behaviour should be in a completely separate execution branch, likely in a different module), while there is no reason for get_balance and credit_amount to ever return None.
- HelloNurse 3y ago
  without a context that might make it reasonable, the original code is fairly absurd: where is the error handling? The bad cases of several if clauses should be by far the largest and least obvious portion of the code, not silently omitted and further obscured by hiding branches.
- infecto 3y ago
  It really is both but I was attacking the angle of the library and not the overall design.
rmbyrro 3y ago
I'd also add a "return None" at the end to be explicit. Implicit behaviors (like Python's implicit return None in functions) creates a tendency for human mistakes.
wredue 3y ago
>the original python looks cherry picked My dude. I have yet to see an FP article that is not just badly cherry picked anecdotes, where the cherry picking itself is often somewhere between a misrepresentation and a blatant lie (nobody would ever do <that> but you can if you need to) It’s one of the reasons I strong advocate against functional programming. The community representation of it is, at best, highly misrepresentative of reality.
- MattPalmer1086 3y ago
  Regardless of how you feel it gets represented by various communities, it is a powerful form of programming. I'm not a functional expert, I have only dabbled. I once rewrote a fairly complex imperative Python text processing program in a functional style. It became much clearer. Most of the code was actually reusable higher order functions, and the program logic became very short and essentially declarative.
  - infecto 3y ago
    Do you have any good recommendations on introductory readings?
    - MattPalmer1086 3y ago
      No, I'm afraid not. I did this years ago. I'm sure there are good resources online somewhere.
PurpleRamen 3y ago
> if user is None: > if balance is None: > if credit is not None Why are people so obsessed with None? The explicit check is usually unnecessary. Just check directly. if user: if balance:=user.get_balance(): if credit:=balance.credit_amount(): discount_program = choose_discount(credit)
- mickeyp 3y ago
  Because if something can return None, you should explicitly check for that, to avoid truthy/falsy gotchas [1]. [1] https://www.inspiredpython.com/article/truthy-and-falsy-gotchas https://www.inspiredpython.com/article/truthy-and-falsy-gotc...
  - PurpleRamen 3y ago
    No, you should not. Checking for None is relevant when you care about the case where it's important. But that doesn't mean every case is one. In the example here, all we care is if we can do something, and everything else doesn't matter. Which is also the reason why I could shortened credit from two checks to one.
- infecto 3y ago
  Walrus is great but your example of nesting 3 deep looks just as terrible as the original example. As for being obsessed with None. I usually lean towards it when no type has been provided like in the example. I think its appropriate when we are expecting it to be a None just to miss any traps further down the road. Just like typing in Python, you don't have to do it but I find it eliminates issues later on and makes it easier for others to read.
fluidcruft 3y ago
Beyond that I found that .bind_optional(...) chain full of lambdas that was supposedly superior to be far less readable than the original. But like, you my main complaint about the nesting not being my style and not that "is not None" is offensive. Particularly if you understand python... despite the links in that section, None is not a null pointer. Otherwise railroading (which this sort of thing enables) is pretty powerful. It's just about always ugly, but it's nice at times.

NoboruWataya 3y ago

What I really want (but Python doesn't have) is: credit = user?.get_balance()?.credit_amount() if credit is not None and credit > 0: discount_program = choose_discount(credit)

Izkata 3y ago
I swear I remember once seeing a library that enabled this by wrapping the first object: Foo(user).get_balance().credit_amount() Maybe with an additional .get() at the end to unwrap it? Though I imagine a dynamically-created class could avoid that.
hprotagonist 3y ago
https://peps.python.org/pep-0505/ https://peps.python.org/pep-0505/ there's a PEP. But it's been pocket-vetoed, i think.

BerislavLopac 3y ago

IMO, the problem with the original code is not in the way it nests ifs, it's in the bad design. If it is properly nested in a function, user should not ever be None (any user-less behaviour should be in a completely separate execution branch, likely in a different module), while there is no reason for get_balance and credit_amount to ever return None.

HelloNurse 3y ago
without a context that might make it reasonable, the original code is fairly absurd: where is the error handling? The bad cases of several if clauses should be by far the largest and least obvious portion of the code, not silently omitted and further obscured by hiding branches.
infecto 3y ago
It really is both but I was attacking the angle of the library and not the overall design.

rmbyrro 3y ago

I'd also add a "return None" at the end to be explicit. Implicit behaviors (like Python's implicit return None in functions) creates a tendency for human mistakes.

wredue 3y ago

>the original python looks cherry picked My dude. I have yet to see an FP article that is not just badly cherry picked anecdotes, where the cherry picking itself is often somewhere between a misrepresentation and a blatant lie (nobody would ever do <that> but you can if you need to) It’s one of the reasons I strong advocate against functional programming. The community representation of it is, at best, highly misrepresentative of reality.

MattPalmer1086 3y ago
Regardless of how you feel it gets represented by various communities, it is a powerful form of programming. I'm not a functional expert, I have only dabbled. I once rewrote a fairly complex imperative Python text processing program in a functional style. It became much clearer. Most of the code was actually reusable higher order functions, and the program logic became very short and essentially declarative.
- infecto 3y ago
  Do you have any good recommendations on introductory readings?
  - MattPalmer1086 3y ago
    No, I'm afraid not. I did this years ago. I'm sure there are good resources online somewhere.

PurpleRamen 3y ago

> if user is None: > if balance is None: > if credit is not None Why are people so obsessed with None? The explicit check is usually unnecessary. Just check directly. if user: if balance:=user.get_balance(): if credit:=balance.credit_amount(): discount_program = choose_discount(credit)

mickeyp 3y ago
Because if something can return None, you should explicitly check for that, to avoid truthy/falsy gotchas [1]. [1] https://www.inspiredpython.com/article/truthy-and-falsy-gotchas https://www.inspiredpython.com/article/truthy-and-falsy-gotc...
- PurpleRamen 3y ago
  No, you should not. Checking for None is relevant when you care about the case where it's important. But that doesn't mean every case is one. In the example here, all we care is if we can do something, and everything else doesn't matter. Which is also the reason why I could shortened credit from two checks to one.
infecto 3y ago
Walrus is great but your example of nesting 3 deep looks just as terrible as the original example. As for being obsessed with None. I usually lean towards it when no type has been provided like in the example. I think its appropriate when we are expecting it to be a None just to miss any traps further down the road. Just like typing in Python, you don't have to do it but I find it eliminates issues later on and makes it easier for others to read.

fluidcruft 3y ago

Beyond that I found that .bind_optional(...) chain full of lambdas that was supposedly superior to be far less readable than the original. But like, you my main complaint about the nesting not being my style and not that "is not None" is offensive. Particularly if you understand python... despite the links in that section, None is not a null pointer. Otherwise railroading (which this sort of thing enables) is pretty powerful. It's just about always ugly, but it's nice at times.