4 ms·

Purely FP lang guys are having a good laugh now. :)

by alrex021 16y ago

chadaustin 16y ago
Why? I know short comments are easy, but you have a real opportunity here to teach us something new. Can you elaborate?
- pyre 16y ago
  I'm assuming b/c purely FP languages have handled this for a long time without the need to program around the language.
  - bad_user 16y ago
    Monad comprehensions are not necessarily a trait of purely FP languages. Yes, in Haskell or F# (the 2 languages I've played with) ... monads are so natural you don't even notice them many times. But this goes both ways, what's natural to do in Python, isn't so in other languages. Also in this particular case you're not programming around the language ... dynamic OOP languages are all about late-binding, that's their strength. If you're using something like Python as if it were Java, you're missing on lots of useful stuff.
    - pyre 16y ago
      Sorry. My entire statement was an assumption as I have little experience with functional programming outside of fooling around with my xmonad.hs file. I was just responding with that I took from the GP comment.
- chc 16y ago
  Functional languages like ML and Haskell use option types instead of nulls, and they have tools to work with option types that go far beyond what most languages have for nulls. For example, in Haskell, that chain of function calls might be written like this: find "table" [("class", "search-params")] soup >>= findParent "form" >>= find "td" [("class", "elem")] >>= find "input" [] >>= get "name" If the result of any call in the chain is Nothing (equivalent to null), we get Nothing. Otherwise, it keeps on going and (if, for example, the name of the relevant element is "signup") we get Just "signup". Simulating Haskell's option type is actually the article's proposed solution.
- deleted 16y ago
  [deleted]
zbanks 16y ago
It's kind of funny. Everyone mocks the complexity of monads, yet this guy basically implements his own version of Haskell's Maybe in order to make his code easier. It's really hard not to gloat.
- bad_user 16y ago
  Monads are wonderful when applied properly, and I think everyone fears Haskell because every I/O api is a monad and composition becomes difficult without having some background on the theory involved.

Purely FP lang guys are having a good laugh now. :)

chadaustin 16y ago

Why? I know short comments are easy, but you have a real opportunity here to teach us something new. Can you elaborate?

pyre 16y ago
I'm assuming b/c purely FP languages have handled this for a long time without the need to program around the language.
- bad_user 16y ago
  Monad comprehensions are not necessarily a trait of purely FP languages. Yes, in Haskell or F# (the 2 languages I've played with) ... monads are so natural you don't even notice them many times. But this goes both ways, what's natural to do in Python, isn't so in other languages. Also in this particular case you're not programming around the language ... dynamic OOP languages are all about late-binding, that's their strength. If you're using something like Python as if it were Java, you're missing on lots of useful stuff.
  - pyre 16y ago
    Sorry. My entire statement was an assumption as I have little experience with functional programming outside of fooling around with my xmonad.hs file. I was just responding with that I took from the GP comment.
chc 16y ago
Functional languages like ML and Haskell use option types instead of nulls, and they have tools to work with option types that go far beyond what most languages have for nulls. For example, in Haskell, that chain of function calls might be written like this: find "table" [("class", "search-params")] soup >>= findParent "form" >>= find "td" [("class", "elem")] >>= find "input" [] >>= get "name" If the result of any call in the chain is Nothing (equivalent to null), we get Nothing. Otherwise, it keeps on going and (if, for example, the name of the relevant element is "signup") we get Just "signup". Simulating Haskell's option type is actually the article's proposed solution.
deleted 16y ago
[deleted]

zbanks 16y ago

It's kind of funny. Everyone mocks the complexity of monads, yet this guy basically implements his own version of Haskell's Maybe in order to make his code easier. It's really hard not to gloat.

bad_user 16y ago
Monads are wonderful when applied properly, and I think everyone fears Haskell because every I/O api is a monad and composition becomes difficult without having some background on the theory involved.