4 ms·

I think learning functional programming is harder with a statically-typed language as there's so much more to learn which revolves solely around the type system

by cutler 5y ago

I think learning functional programming is harder with a statically-typed language as there's so much more to learn which revolves solely around the type system. I would recommend anyone new to FP to try Clojure first. No mon[a|oi]ds necessary. I also think the transition from procedural languages is easier than from OO languages. I was lucky not to be exposed to Java or C++ in the early days of my programming career, opting for Perl instead. When I transitioned to Ruby I also encountered Clojure at the same time and could appreciate the functional/lisp elements in the design of Ruby.

stadium 5y ago
I had only one FP experience with scala. I actually liked that it was statically typed. I have nothing to compare it to though. But, higher order functions and type parameters are still a bit mind bending for me. I didn't have to write much code for those, but when I did it was really hard. I'm sure I'd need at least couple days of reading and playing around to somewhat grasp how to implement them again.
valzam 5y ago
I actually think that FP programming and FP type systems are almost completely seperable and most of the FP jargon comes from FP type systems. Elixir is another example that makes FP programming very straightforward. That being said I think once you get the basics of FP programming learning about FP type systems is worth it. Especially FP effect systems (i.e. IO monad).
deltasixeight 5y ago
I mean it's not like this type system is exclusive to functional programming. You can tack it on to an imperative language (see rust). It's mostly the type theory that is hard here but people talk about functional programming because of association thanks in large part to haskell.
mjaniczek 5y ago
> No mon[a|oi]ds necessary. Mon[a|oi]ds are everywhere, but in some languages you just don't know about it. Which of course lets you not have to learn those concepts knowingly, but they're still there and you still could be a better developer for at least knowing they're there and they're behind some of the repeating patterns you see (string concatenation / promises / etc.) I believe "not worrying about them at first" is actually a good path to learn these patterns. Using them first, some time later having a thought "oh hey, the API of how JSON decoders are written is kinda similar to how I'm generating random values, that's cool" and only later on learning that the it is in fact monads/monoids/functors/whatever and that they have laws and you can exploit that (eg. [repeated squaring for anything that's a semigroup](https://blog.jle.im/entry/shuffling-things-up.html https://blog.jle.im/entry/shuffling-things-up.html)) and whatnot.

by cutler 5y ago

stadium 5y ago

I had only one FP experience with scala. I actually liked that it was statically typed. I have nothing to compare it to though. But, higher order functions and type parameters are still a bit mind bending for me. I didn't have to write much code for those, but when I did it was really hard. I'm sure I'd need at least couple days of reading and playing around to somewhat grasp how to implement them again.

valzam 5y ago

I actually think that FP programming and FP type systems are almost completely seperable and most of the FP jargon comes from FP type systems. Elixir is another example that makes FP programming very straightforward. That being said I think once you get the basics of FP programming learning about FP type systems is worth it. Especially FP effect systems (i.e. IO monad).

deltasixeight 5y ago

I mean it's not like this type system is exclusive to functional programming. You can tack it on to an imperative language (see rust). It's mostly the type theory that is hard here but people talk about functional programming because of association thanks in large part to haskell.

mjaniczek 5y ago

> No mon[a|oi]ds necessary. Mon[a|oi]ds are everywhere, but in some languages you just don't know about it. Which of course lets you not have to learn those concepts knowingly, but they're still there and you still could be a better developer for at least knowing they're there and they're behind some of the repeating patterns you see (string concatenation / promises / etc.) I believe "not worrying about them at first" is actually a good path to learn these patterns. Using them first, some time later having a thought "oh hey, the API of how JSON decoders are written is kinda similar to how I'm generating random values, that's cool" and only later on learning that the it is in fact monads/monoids/functors/whatever and that they have laws and you can exploit that (eg. [repeated squaring for anything that's a semigroup](https://blog.jle.im/entry/shuffling-things-up.html https://blog.jle.im/entry/shuffling-things-up.html)) and whatnot.