4 ms·

Explaining how to use a Javascript Promise is simple. Explaining how to write idiomatic pure code using Monads is hard, and impractical in most cases, despite w

Explaining how to use a Javascript Promise is simple. Explaining how to write idiomatic pure code using Monads is hard, and impractical in most cases, despite what FP purists will tell you.

anonzzzies 3y ago
Yes, that's true, but in general programming is not easy, especially when there is something at stake (so probably most professionally written software) and as i'm work as an enterprise troubleshooter mostly in banking/insurance/trading, the depressing amounts of javascript/typescript code I encounter that should never have been put in production, while I hardly ever encounter bad f#, ocaml, rust, haskell or c++ (modern versions). Sometimes it's not excellent, but it's never as bad as the vast majority of nodejs running projects. The programmers of the latter are far more rigid, because it's hard to do anything, but when you do, you get rewarded. People learn JS in 2 days, slap on :any and blam, typescript gurus, get a job, create a system that processes millions$ and then leave for the next 'adventure'. People who invest in rigidity create better software. But yeah, they are far thinner in the 'get shit done fast' arena. So yes, I agree, if you want something done quickly and don't mind if it expires a few months later, you don't grab haskell, rust and definitely not a dependently typed language or proof assistent.
- deleted 3y ago
  [deleted]
- FrustratedMonky 3y ago
  Have to concur. SO many people grab Python or Javascript for a 'quick short script' and it turns into a real production system and then becomes un-maintainable. But F#, functional languages, they maybe take more time to learn, or become proficient, but the errors drop way down, because the langue doesn't allow those types of errors that are common in 'scripting' languages.
- c_crank 3y ago
  Looks like my previous comment was too mean towards JavaScript, so trying this again... Just using some form of static typing offers easy guarantees without much effort. Trying to Monad-ify everything for a much smaller level of compiler guarantees involves much higher dev effort (as most devs do not understand Monads), and much higher effort involved in anyone reading the code.
  - anonzzzies 3y ago
    I agree with this, but I still think it has benefit, if only giving a lot of skill to the dev pulling it off. It’s a trade off of course. I myself like writing and reading it more, and I detest ‘move fast, break many subtle things you will find out only after it’s too late’. I carved out niches for myself that are hard but fulfilling and I don’t really need to worry about spending months on something some ‘gunslinger’ can put together in 3 days as my clients like long term robustness. There are devices out there 2-10 years and replacement is painful, so let’s not. We see cases with clients (I wish I could name: you will know some of them) were they have a server in the cloud and client in embedded hardware and needing to replace all devices because either client or server or both popped a security issue that would mess certification. It is also expensive to fix things without hardware: everything is iso/pci and needing recertification to changing anything. So the 100k you spend for going for perfection pays off. So far at least.
    - c_crank 3y ago
      What I would take issue with is describing a non functional or non Monadified code as something written by a gunslinger without care for robustness, as if writing things in Monads has a guarantee of robustness or correctness or even maintainability.
      - anonzzzies 3y ago
        My time to peddle back; you are right. Didn’t mean to imply that, but did. I do see (irl) that it improves the odds though.
jimbob45 3y ago
Couldn't agree more. I wish we could replace the moniker "functional programming" with "aesthetic programming" because it feels like Monads are less practical than they are hygienic for the code.
vore 3y ago
I really don't like how monads get couched in this way: they're a fundamental concept that you can see everywhere (at least understood by functional programmers with Promise.then/Promise.resolve, Array.flatMap/[x], etc.). Railing on how "using Monads is hard" makes no sense because it's a bit like talking about how using, say, Abelian groups are hard when, surprise, you use them every day.
bPspGiJT8Y 3y ago
That's because monads are way more general than promises. Explaining how to use Maybe to write total functions is just as easy as explaining promises, if not easier.
- c_crank 3y ago
  So long as you're using a single Monad like a black box. Haskell people repeatedly fail when trying to generalize them or explain the underlying premises.

Explaining how to use a Javascript Promise is simple. Explaining how to write idiomatic pure code using Monads is hard, and impractical in most cases, despite what FP purists will tell you.

anonzzzies 3y ago

Yes, that's true, but in general programming is not easy, especially when there is something at stake (so probably most professionally written software) and as i'm work as an enterprise troubleshooter mostly in banking/insurance/trading, the depressing amounts of javascript/typescript code I encounter that should never have been put in production, while I hardly ever encounter bad f#, ocaml, rust, haskell or c++ (modern versions). Sometimes it's not excellent, but it's never as bad as the vast majority of nodejs running projects. The programmers of the latter are far more rigid, because it's hard to do anything, but when you do, you get rewarded. People learn JS in 2 days, slap on :any and blam, typescript gurus, get a job, create a system that processes millions$ and then leave for the next 'adventure'. People who invest in rigidity create better software. But yeah, they are far thinner in the 'get shit done fast' arena. So yes, I agree, if you want something done quickly and don't mind if it expires a few months later, you don't grab haskell, rust and definitely not a dependently typed language or proof assistent.

deleted 3y ago
[deleted]
FrustratedMonky 3y ago
Have to concur. SO many people grab Python or Javascript for a 'quick short script' and it turns into a real production system and then becomes un-maintainable. But F#, functional languages, they maybe take more time to learn, or become proficient, but the errors drop way down, because the langue doesn't allow those types of errors that are common in 'scripting' languages.
c_crank 3y ago
Looks like my previous comment was too mean towards JavaScript, so trying this again... Just using some form of static typing offers easy guarantees without much effort. Trying to Monad-ify everything for a much smaller level of compiler guarantees involves much higher dev effort (as most devs do not understand Monads), and much higher effort involved in anyone reading the code.
- anonzzzies 3y ago
  I agree with this, but I still think it has benefit, if only giving a lot of skill to the dev pulling it off. It’s a trade off of course. I myself like writing and reading it more, and I detest ‘move fast, break many subtle things you will find out only after it’s too late’. I carved out niches for myself that are hard but fulfilling and I don’t really need to worry about spending months on something some ‘gunslinger’ can put together in 3 days as my clients like long term robustness. There are devices out there 2-10 years and replacement is painful, so let’s not. We see cases with clients (I wish I could name: you will know some of them) were they have a server in the cloud and client in embedded hardware and needing to replace all devices because either client or server or both popped a security issue that would mess certification. It is also expensive to fix things without hardware: everything is iso/pci and needing recertification to changing anything. So the 100k you spend for going for perfection pays off. So far at least.
  - c_crank 3y ago
    What I would take issue with is describing a non functional or non Monadified code as something written by a gunslinger without care for robustness, as if writing things in Monads has a guarantee of robustness or correctness or even maintainability.
    - anonzzzies 3y ago
      My time to peddle back; you are right. Didn’t mean to imply that, but did. I do see (irl) that it improves the odds though.

jimbob45 3y ago

Couldn't agree more. I wish we could replace the moniker "functional programming" with "aesthetic programming" because it feels like Monads are less practical than they are hygienic for the code.

vore 3y ago

I really don't like how monads get couched in this way: they're a fundamental concept that you can see everywhere (at least understood by functional programmers with Promise.then/Promise.resolve, Array.flatMap/[x], etc.). Railing on how "using Monads is hard" makes no sense because it's a bit like talking about how using, say, Abelian groups are hard when, surprise, you use them every day.

bPspGiJT8Y 3y ago

That's because monads are way more general than promises. Explaining how to use Maybe to write total functions is just as easy as explaining promises, if not easier.

c_crank 3y ago
So long as you're using a single Monad like a black box. Haskell people repeatedly fail when trying to generalize them or explain the underlying premises.