Brian Marick <[email protected]> writes:
> Which raises the question: *is* concurrency actually a strong selling
> point for functional languages?
It definitely was/is for me. I'd avoided threads for most of my
career-to-date because in imperative languages any thread could mutate
any value to be anything at any point. This is difficult to reason
about when the code is written correctly, and then in C you have the
added fun that an error could lead to that malevolent thread writing to
absolutely any address in memory. Complete undebuggable madness!
So I'd generally reached for processes in order to achieve concurrency.
Using processes doesn't get rid of deadlocks etc, and introduces
additional copying overhead if e.g. communicating over pipes, but does
shrink the problem one needs to think about down to just the set of
mechanisms explicitly used to communicate between the processes.
IMHO, FP in general and Clojure in particular does two big things
regarding concurrency:
(1) By using immutable values, provides the same "conceptual
shrinking" as using processes does in imperative languages, only
without (well, with reduced) copying overhead. The concurrency
problem is limited to just the interactions over the relatively
small number of explicit concurrency points.
(2) The ability to build higher-order concurrency abstractions which
completely encapsulate recurring patterns. When using pure
functions on immutable data, e.g. `pmap` and `reducers/fold`
really do give you auto-concurrency for certain patterns of
concurrent operations.
Just my 2 cents,
-Marshall
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to [email protected]
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
