>I can understand some of the things FP gets you I really don't think you do understand, as an example in the last thread we ran into each other you completely

>I can understand some of the things FP gets you I really don't think you do understand, as an example in the last thread we ran into each other you completely missed the fact that Futures allow concurrency for free since you're already in a monadic context 90% of the time. https://news.ycombinator.com/item?id=7751605 https://news.ycombinator.com/item?id=7751605 > The problem is that the kind of code it enables reuse of more than OO is very small, simple loops. This is never a big issue. This is called a straw man argument. People aren't claiming that FP helps you write four line loops in one line. This article and others talk about orders of magnitude improvement in LOC on a large scale. >"transactional" mutable state is simpler than the pure FP one, and just as safe. You clearly don't know what these words mean. Mutable and purity are not mutually exclusive. Purity is a slang term for referential transparency. You can have mutable, referentially transparent functions. You can also have transactional memory in pure languages. >Finally (and I've said this before on HN), a language like Haskell discounts the very useful choice of reasoning about your code after it runs, favoring, instead, all-upfront reasoning, often at the expense of facilitating the former. Citation needed. You’re making things up. The bottom line is you’ve created a product that solves many of the same problems functional programming solves. Your product looks very nice and advanced, but your unfamiliarity with functional programming makes you fear it, so you’ve decided to spread FUD across HN to the detriment of the community.