5 ms·
Author here. A few have mentioned already, but this is to practice, to force you to understand what FP brings to the table, and lead you in path of discovery. W
by MiyamotoAkira 9y ago
Author here. A few have mentioned already, but this is to practice, to force you to understand what FP brings to the table, and lead you in path of discovery. When it comes to production code, you apply what you have learned, and make the decisions that you think more convenient. As an example, if you want certain performance gains on F# you do go to mutable state (Phil Trelford did a talk about it). Doesn't matter how pretty/OO/pure is the code if your application doesn't do what is supposed to ;-)
- maxxxxx 9y agoCool. I commend you for having a team that is willing to practice new things for fun. That's pretty rare.
- pygy_ 9y agoThanks for the article. There's a class of problems that I wouldn't know how to solve using the constrains you propose. Given { a: { b: { c: 4 } }, d: 2 } return { 'a.b.c': 4, d: 2 } My go to solution uses mutable state, self-recursion, and intermediate variables: function flatten(source) { var result = {} _flatten(source, null, result) return result } where `_flatten(source, prefix, result)` is self-recursive (`prefix` accumulates the keys) and populates `result[prefix]=value` when value is a string. `result` is conceptually an IO monad that's passed along. I guess the general problem would be traverse a tree of arbitrary depth and accumulate structured data on the go. Prominent examples would be compilers. Any hints on where to start?