5 ms·

> I strongly believe that functional programming is not a good fit for 100% of software architecture. The best is some sort of hybrid. Haskell would be a bette

> I strongly believe that functional programming is not a good fit for 100% of software architecture. The best is some sort of hybrid. Haskell would be a better language in every domain where C# is applicable. That is from a language perspective, abundance of libraries is a different question, as it's a matter of the community size and attention.

dboreham 5y ago
I think enforced purity is problematic (although obviously useful for some purposes such as program correctness proofs). I still want to be able to write: doThing1(); // thing1 has finished doThing2(); Where the functions block. Async and Monads and Futures and all are useful for some things, but mostly I just want to do stuff sequentially, blocking, and not confuse myself. Scala allows this, although the widespread Future-ification of libraries makes it hard to actually practice.
- ghostwriter 5y ago
  Haskell allows this too, users can just code everything within IO until they feel comfortable with adding extra purity through refactoring: main :: IO () main = do myBusinessLogic myBusinessLogic :: IO () myBusinessLogic = do doThing1 doThing2 doThing1 :: IO () doThing1 = do putStr "Hello " doThing2 :: IO () doThing2 = do putStrLn "World" --- ghc -o main main.hs [1 of 1] Compiling Main ( main.hs, main.o ) Linking main ...  ./main Hello World
  - dboreham 5y ago
    True. Perhaps my issue is that I know how that's implemented and my brain can't see it the same as sequential statement execution ;)
    - JoelMcCracken 5y ago
      This is a function of familiarity though. Get familiar with it and you'll understand it just fine. If you want to talk more about it, feel free to email me.
      - tome 5y ago
        I think dboreham's objection was exactly the opposite!
        JoelMcCracken 5y ago
        Idk i mean simply knowing what the code for >> looks like doesn't mean you're used to thinking in that way. There was a time years ago when someone was showing me the types of (>>) and (>>=) in Haskell and my question was "ok, but what does that have to do with IO?!?"

dboreham 5y ago

I think enforced purity is problematic (although obviously useful for some purposes such as program correctness proofs). I still want to be able to write: doThing1(); // thing1 has finished doThing2(); Where the functions block. Async and Monads and Futures and all are useful for some things, but mostly I just want to do stuff sequentially, blocking, and not confuse myself. Scala allows this, although the widespread Future-ification of libraries makes it hard to actually practice.

ghostwriter 5y ago
Haskell allows this too, users can just code everything within IO until they feel comfortable with adding extra purity through refactoring: main :: IO () main = do myBusinessLogic myBusinessLogic :: IO () myBusinessLogic = do doThing1 doThing2 doThing1 :: IO () doThing1 = do putStr "Hello " doThing2 :: IO () doThing2 = do putStrLn "World" --- ghc -o main main.hs [1 of 1] Compiling Main ( main.hs, main.o ) Linking main ...  ./main Hello World
- dboreham 5y ago
  True. Perhaps my issue is that I know how that's implemented and my brain can't see it the same as sequential statement execution ;)
  - JoelMcCracken 5y ago
    This is a function of familiarity though. Get familiar with it and you'll understand it just fine. If you want to talk more about it, feel free to email me.
    - tome 5y ago
      I think dboreham's objection was exactly the opposite!
      - JoelMcCracken 5y ago
        Idk i mean simply knowing what the code for >> looks like doesn't mean you're used to thinking in that way. There was a time years ago when someone was showing me the types of (>>) and (>>=) in Haskell and my question was "ok, but what does that have to do with IO?!?"