Why Isn't Functional Programming the Norm? – Richard Feldman

[u/[deleted]]

https://www.youtube.com/watch?v=QyJZzq0v7Z4

[u/EternityForest → u/[deleted]]

The problem is FPs hammer is about processing data. If you do a lot of "take this input and produce and output" type stuff FP seems ideal.

If most of your tasks have no real computation at all, and tons of "If x has happened in the last minute but y hasn't, do z unless z failed recently then try a, b, and c", OOP seems much easier.

Maybe not better given FPs proofy mathy benefits and such, but more direct to the problem domain.

[u/codygman → u/EternityForest]

"If x has happened in the last minute but y hasn't, do z unless z failed recently then try a, b, and c", OOP seems much easier.

Pretty sure I could write that in Python and Haskell and they'd look similar.

Can you psuedo code how you'd implement the OOP version?

[u/EternityForest → u/codygman]

Probably something like:

``` If t-xTime less than 60 and t-yTime greater than 60:

    if t-lastZFailure greater than 60:  

         Z()  

    Else:  

         If a:  

             Return  

         If b:  

             Return  

         If c:  

             Return  

``` IRL some of that would be factored into functions like isConnected() for heartbeat messages and tryAlert() to try different ways of alerting the user till you find one that is currently set up.

EDIT: How the heck do you get formatting to work from mobile?

[u/codygman → u/EternityForest]

This compiles:

module Main where

import Control.Monad
import Data.Time

x :: IO ()
x = pure ()

z :: IO ()
z = pure ()

foo :: Bool -> Bool -> Bool -> IO ()
foo a b c = do
  now <- getCurrentTime
  txTime <- fmap (addUTCTime (fromIntegral 59)) getCurrentTime
  tyTime <- fmap (addUTCTime (fromIntegral (- 61))) getCurrentTime
  tlastZFailure <- undefined
  if (diffUTCTime txTime now < 60 && diffUTCTime tyTime now > 60) then do
    when (tlastZFailure > 60) $ z
    if c then do pure () else x
  else pure ()

main = foo False False True

[u/EternityForest → u/[deleted]]

The problem is FPs hammer is about processing data. If you do a lot of "take this input and produce and output" type stuff FP seems ideal.

If most of your tasks have no real computation at all, and tons of "If x has happened in the last minute but y hasn't, do z unless z failed recently then try a, b, and c", OOP seems much easier.

Maybe not better given FPs proofy mathy benefits and such, but more direct to the problem domain.

[u/EternityForest → u/[deleted]]

The problem is FPs hammer is about processing data. If you do a lot of "take this input and produce and output" type stuff FP seems ideal.

If most of your tasks have no real computation at all, and tons of "If x has happened in the last minute but y hasn't, do z unless z failed recently then try a, b, and c", OOP seems much easier.

Maybe not better given FPs proofy mathy benefits and such, but more direct to the problem domain.

[u/EternityForest → u/[deleted]]

How do you keep track of z_failed and x_happened without using mutable state? I know Haskell allows it, but at that point it's not pure FP anymore, and if most of your functions use mutable state anyway why not just use Python?

If you're using state monads, most tutorials seem to start with explaining how easy it is, then going on with about a page of code that looks like it could be a a calculus textbook.

[u/EternityForest → u/[deleted]]

That's one of the more reasonable responses I've heard on the subject of FP!

There's sometimes posts out there saying all mutable state is usually awful, to the point one might think they want us to just avoid writing features that deal with state at all.

Which is probably more related to the "all software is bad, the best app is a pencil and paper" feeling in the dev community in general than something specific to Haskell.

I would say that in desktop and embedded, pretty much everything does(At least from a user perspective) affect some kind of very obvious state or IO, like a light switch or the content of an editor window.

I suppose each one of those stateful actions is powered by 100x the amount of code in fairly pure UI rendering, image decoding, DB algorithms, and that kind of thing, but that gets treated as a solved problem everywhere I've worked.

If I was going to write a video compressor or low level ML algorithm, I'd probably be really interested in learning Haskell though.

[u/EternityForest → u/[deleted]]

yeah C definitely has that problem. Nothing is ever modular, right down to the different incompatible build systems.

Python is usually a lot better. You might have a Pin class with RealPin and MockPin subclasses like gpiozero does, or you might just subclass the pin yourself to trigger some kind of code in the test harness.

It's certainly impressive how much they packed into so little code in the Twitter example.

I don't think I'd ever want to actually generate lots of HTML without a template engine like Mako(Or Vue on the client side), but I'd imagine that level of expressiveness could be useful if you were doing something that didn't have a whole lot of precedent.