4 ms·
Okay but now this is just imperative lol, it's no longer functional at all, since your function is now just a sequence of instructions, i.e. it's a procedure ra
by bowsamic 2y ago
Okay but now this is just imperative lol, it's no longer functional at all, since your function is now just a sequence of instructions, i.e. it's a procedure rather than a pure function. You've just proved my point
- xigoi 2y agoIt’s a mix of functional and imperative style. Most functional languages (other than Haskell) allow you to easily write code like this.
- bowsamic 2y agoYes I know but that's not the point of my original post, which is about people who claim that a pure functional style would be considered easier if it were taught first. I'm saying that falling back on imperative is almost always easier than sticking with pure functional
- Akronymus 2y agoFalling back on imperative is orthogonal to what to teach first. My original argument was that, when just starting programming, it is better to go with FP, as it is easier to learn PP or OOP additionally. While, when starting with PP or OOP, it is incredibly hard to then learn FP.
- bowsamic 2y agoI wasn't responding to your specific point. I was addressing this general idea that the only reason people find imperative programming easier is because they were taught it first
- tome 2y agoHaskell also allows you to easily write like this for numbers $ \x -> do Console.log x return (x * x)
- bowsamic 2y agoOkay and now you’re using monads which I pointed out are not easy to understand
- nequo 2y agoMonads are not hard though. You use them every time you put a ? on something in Rust.
- bowsamic 2y agoI'm not sure if this is a joke but no using something that might fulfil the laws of a monad doesn't mean you need to know what a monad is generally. Many features of imperative languages can be described using category theory, but only in Haskell do you need to actually understand the generalisation. Why is that? Why can't you just "use monads and not worry about it"? Well the problem is that in Haskell there is a huge leveraging of very general functions that apply to these entities generally, for example "fmap" ">>=" ">>" "<>", etc. and those are simple examples. Therefore understanding the rules and definition of the generalisation* is required. It's not enough to just point at an example of a monad and say "look, the example is simple, therefore the generalisation is simple". As many philosophers have pointed out, particulars are easier to point out than universals. The latter requires a lot of thought.
- nequo 2y agoI meant it sincerely, not as a joke. > As many philosophers have pointed out, particulars are easier to point out than universals. The latter requires a lot of thought. Fair enough, that’s a good point. You don’t have to use >>= and >> if you don’t want to though. Use the do notation instead and the code will look much more familiar. You also mention fmap; that’s `.map` in Rust, etc. in other languages. All I’m trying to say is, there are many parallels between Haskell and other languages at the level of particulars. The concepts behind >>= and >> are not unique to it anymore. So there is hope if you want to reconstruct the universal concepts in your mind from those particulars, especially if you use fitting abstractions like the do notation.
- Iceland_jack 2y agoI write this in my Haskell day job every day.