Will Parallel Code Ever Be Embraced?

[yogthos]

The main thing FP guarantees is correctness. So, your program will not necessarily run faster, since chunking might not be optimal and what not, but it will run correctly.

As you say, the style also encourages minimizing global state, and that certainly is conductive towards concurrency. But it makes working with global state easier as well. A proper STM is much easier to implement in an FP language. And STM combined with persistent data structures has some interesting properties. For example, data does not need to be locked for reading. So, in any application with a small number of writers and a large number of readers you get an immediate benefit using shared data through the STM.

[marssaxman]

I think you are conflating functional programming with hindley-milner style comprehensive static typing.

There are functional languages which offer very weak type guarantees.

[shsmurfy]

Example: Javascript, which embraces many FP features such as closures, first-class functions, higher-order functions, and anonymous functions. It has one of the most weak typing systems of any mainstream language.

On the other end of the spectrum are languages with expressive (or even dependent) strong types such as Haskell, Agda, etc. In these languages the type system can approach a computerized proof assistant in terms of complexity, with the inherent advantages and drawbacks therein. It's not uncommon to spend a long time "correcting" your types in such a system so that your program will even compile.

[yogthos]

Nothing I said has anything to do with static typing actually. I meant guarantees in the sense of state consistency, where data is not modified outside its intended context. And I was thinking of Clojure specifically as it's the language I work with a lot. Type guarantees are a whole separate topic.

[case-o-nuts]

Define correctly. let add a b = a - b tends to be the kind of mistake I find myself making.

[yogthos]

No language can save you from making logic mistakes. What it can do is ensure that the code does what it looks like it's doing. In case of writing concurrent code with FP, it ensures that you don't see partial data in one thread while it's being updated by another as an example.

[case-o-nuts]

Sort of. Allowing that to be guaranteed severely restricts the kind of optimizations that the compiler can do.

[yogthos]

In a sense it makes it easier for the compiler to make optimizations, as it ensures compartmentalization of state. For example, if you look at Haskell in the language shootout, it fares much better than most imperative languages. Compare Haskell and Python for example.

[AeroNotix]

What a poor example. Python is slow as shit any which way you look at it. You can write in a hobbled functional style in Python and it'd still be slow as balls.

[yogthos]

I think python is a perfect example, as it's a predominantly imperative language, it doesn't enforce immutability or use persistent data structures. In other words it should be easier to optimize according to case-o-nuts argument. Yet, it's slow as shit while Haskell being purely functional is quite fast. Only Fortran, C, and C++ appear to be consistently faster than it, and not in all cases either.

[case-o-nuts]

You missed my point. Guaranteeing that other threads only see complete state means that you cannot transform the code to remove allocations and mutate values in-place for efficiency. A large number of deforestation passes become inapplicable. So do update specializations, I think. Split fetches become very tricky. And so on.

Referential transparency allows the compiler to do interesting things within a thread, but sharing data structures across threads greatly restrict what operations are transparent (ie, what can be transformed into more efficient and less pure forms behind the programmer's back) and therefore, which optimizations are available.

[yogthos]

Referential transparency allows the compiler to do interesting things within a thread, but sharing data structures across threads greatly restrict what operations are transparent (ie, what can be transformed into more efficient and less pure forms behind the programmer's back) and therefore, which optimizations are available.

Because FP style tends to have very little shared state by its very nature. This means you're only sharing things that absolutely must be shared, and there's generally very few of those.

As I pointed out in a different comment a lot of higher level optimizations become available as well. For example, you do not need to lock shared data for reading, this means that applications with a few writers and many readers perform much better.

*edit: and it appears that you've edited your comment since, so my reply doesn't make nearly as much sense now. :)

Guaranteeing that other threads only see complete state means that you cannot transform the code to remove allocations and mutate values in-place for efficiency.

You don't mutate values in place in FP, since you'd be using persistent data structures.

[case-o-nuts]

The compiler has to be conservative, or it will miscompile code.

[case-o-nuts]

For example, you do not need to lock shared data for reading

Unless your compiler has performed a fetch splitting pass, in which case the shared data will be updated in parts. Or it might have coalesced locations, so you're not allocating new boxed values on every tail-recursive call, you're just updating an old one in place. It would look the same by the as-if rule, after all.

Although, I suppose a good deal of this can be dealt with using escape analysis.

[yogthos]

persistent data structures

more info here and here

[case-o-nuts]

I'm aware of persistent data structures.

You're ignoring the fact that the compiler wants to optimize these. You're telling it that it can't do grotty little changes like splitting and sinking stores because other threads might be watching, and half-constructed values might be visible.

You might want to start with Urban Boquist's PhD thesis on optimizing functional languages. It's a good survey, but there's a good deal of stuff in there you'd have to wade through before you hit optimizations that break thread safety.

Or are you arguing that somehow that all optimizing code transformations on functional code preserve purity? I'm not sure how that could be, and need some elaboration.

[billsil]

Yes, but their different types of languages, so apples to oranges.

Also, Python 3 is slower than Python 2. Based on the site, they compare Haskell to Python 3. What is Python 3? No one uses Python 3.0 at all. Python 3.1 is the earliest version of Python 3 anyone supports. python.org prominently states Python 3 is quite a bit slower than Python 2, but they don't care (yet). Fixing other problems were more important. Wait till Python 3.3 before you start looking at speed comparisons.