3 ms·

I wonder how to become a good functional programmer. I think I'm already decent at procedural/OO. Do I need to have a strong maths background? I didn't learn i

by b0rsuk 9y ago

I wonder how to become a good functional programmer. I think I'm already decent at procedural/OO. Do I need to have a strong maths background? I didn't learn it very well at university and this worries me. Many functional language fans seem to have degrees in maths.

_sdegutis 9y ago
Math isn’t required. FP is about thinking of data structures and transformations from A to B. If you’ve ever used underscore.js, you’ve probably used FP patterns and functions. Map, filter, reduce are all part of that.
lewisinc 9y ago
I don't think so. If anything I feel it's a bit easier as you don't need to reason about object state. It's also different, which is the main hurdle. If you use emacs you've already been exposed - Emacs Lisp is functional. If you're coming from a Web background both Elm and Elixir are great places to begin. You'll often hear stuff like "Javascript can be written in a functional style" - which is true, functional programming is a paradigm you can just go with - but seeing it really embraced by the language is really inspiring.
ff_ 9y ago
FP is mostly a state of mind - of course picking the language really helps about incentives, but you can do it even in Java/C# (in fact if you do C# there is the great LINQ library that helps). How to approximate FP in a mostly OOP language: - use immutable data structures: there is no way around being able to fearlessly modify something. The naive way is to copy the object before touching it, the better way is to use efficient structures, e.g. Clojure data structures from Java. - you either have data classes (no methods, no private fields), or execution classes (no data fields, only static methods), no mixing - of you stick to the above, you will find that returning void from a method is very difficult. Congrats, you're doing FP: the gist of it is that it's all about keeping state explicit; if you pass some A in a function, you will return a B at some point, and that's your result. No implicit state. Of course, we're missing the whole part about side effects, so to add to the above: if you cannot write a unit test without mocking something in your method, you're doing side effects. They should be done only at the "border" of the application, to (maybe) get you the data you need, so you can bring it and process it in the pure core. And this is where languages like Haskell help: to understand where the side effects are (because they are included in the types) and to prevent mixing them around (which only gets you an untestable mess in the end). HTH
- tome 9y ago
  What a great explanation of the "state of mind" of FP!
mnm1 9y ago
Pick a project. Pick a functional language. Code the project. That's it. It's not that different that, given enough willingness, you wouldn't be able to learn it yourself if you are decent at procedural / OO. You don't need any advanced math whatsoever.
scns 9y ago
Check out the humble functional bundle, two of the books in there are about the transition from imperative to fp.

by b0rsuk 9y ago

_sdegutis 9y ago

Math isn’t required. FP is about thinking of data structures and transformations from A to B. If you’ve ever used underscore.js, you’ve probably used FP patterns and functions. Map, filter, reduce are all part of that.

lewisinc 9y ago

I don't think so. If anything I feel it's a bit easier as you don't need to reason about object state. It's also different, which is the main hurdle. If you use emacs you've already been exposed - Emacs Lisp is functional. If you're coming from a Web background both Elm and Elixir are great places to begin. You'll often hear stuff like "Javascript can be written in a functional style" - which is true, functional programming is a paradigm you can just go with - but seeing it really embraced by the language is really inspiring.

ff_ 9y ago

FP is mostly a state of mind - of course picking the language really helps about incentives, but you can do it even in Java/C# (in fact if you do C# there is the great LINQ library that helps). How to approximate FP in a mostly OOP language: - use immutable data structures: there is no way around being able to fearlessly modify something. The naive way is to copy the object before touching it, the better way is to use efficient structures, e.g. Clojure data structures from Java. - you either have data classes (no methods, no private fields), or execution classes (no data fields, only static methods), no mixing - of you stick to the above, you will find that returning void from a method is very difficult. Congrats, you're doing FP: the gist of it is that it's all about keeping state explicit; if you pass some A in a function, you will return a B at some point, and that's your result. No implicit state. Of course, we're missing the whole part about side effects, so to add to the above: if you cannot write a unit test without mocking something in your method, you're doing side effects. They should be done only at the "border" of the application, to (maybe) get you the data you need, so you can bring it and process it in the pure core. And this is where languages like Haskell help: to understand where the side effects are (because they are included in the types) and to prevent mixing them around (which only gets you an untestable mess in the end). HTH

tome 9y ago
What a great explanation of the "state of mind" of FP!

mnm1 9y ago

Pick a project. Pick a functional language. Code the project. That's it. It's not that different that, given enough willingness, you wouldn't be able to learn it yourself if you are decent at procedural / OO. You don't need any advanced math whatsoever.

scns 9y ago

Check out the humble functional bundle, two of the books in there are about the transition from imperative to fp.