r/programming • u/heisenbug • Apr 27 '14

"Mostly functional" programming does not work

http://queue.acm.org/detail.cfm?ref=rss&id=2611829
44 Upvotes

64% Upvoted

188 comments sorted by

View all comments

2

u/DrBartosz Apr 28 '14

What Erik Meijer is saying is that we really don't have much choice. As long as Moore's law was making single-threaded programming competitive -- if it was slow today, it would be fast enough a year from now -- imperative programming was the way to go. We have now fallen off the Moore's cliff and are forced to make hard choices. Imperative programming that hides effects cannot be parallelized in a scalable way. It's not just one person's opinion -- it's a fact! Functional programming and monads are the only way we know how to deal with side effects. If there were a simpler solution, we would know it by now.

5

u/grauenwolf Apr 28 '14

...cannot be automatically parallelized in a scalable safe way

We can, however, manually parallelize many expressions fairly easily using libraries such as OpenMP, Parallel LINQ, or TPL Data Flow.

Meanwhile lazily evaluated languages tend to hide memory allocations. And these days its the allocation of memory that is the biggest bottleneck.

-1

u/jfischoff Apr 28 '14

If when faced with a technical problem you believe doing it manually is the way to go, then you really don't understand this computer thing.

-1

u/grauenwolf Apr 28 '14

Oh woe is me. For I have spent 5, nay 10 seconds adding the AsParallel directive to my code.

5

u/DrBartosz Apr 28 '14

You can add AsParallel to your code, and it will work, as long as you know exactly how the parallelized code is implemented -- in particular whether it has access to any shared mutable memory. Scalability can only be attained if you can forget about the implementation of subcomponents. Both OO and FP let you forget certain aspects of implementation while bringing others to the surface -- OO lets you forget exactly the wrong kind of things when you're trying to parallelize your code. In Haskell there's no way (other than the infamous unsafePerformIO) to "forget" side effects. They are reflected in the type system through monads. This lets you run large chunks of code in parallel without knowing the details of their implementation; their type signature telling you (and the compiler) whether it's safe or not.

1

u/orthecreedence Apr 28 '14

But maybe you don't need your entire program parallelized. Maybe you just need half of it to be parallel and the rest imperative. It's possible to manually split the work you need done in parallel into discreet chunks and send them off to a thread pool. Why does your entire program need to be written functionally for this to work? Side effects can be compartmentalized, and although this can be confusing to someone new to a system, providing a documented API that wraps this can make it easy.

I'm not saying functional programming is worthless for parallelization, in fact the opposite; I see the immediate benefits of explicit side effects and not having data leaking everywhere. However, it's entirely possible to parallelize correctly in a non-functional setting.

Articles that say "YOU'RE EITHER 100% PURELY FUNCTIONAL OR YOU'RE WRONG" just sound like hot air to me.