4 ms·

Functional programs encode their dependencies as arguments/return-values. In Haskell, using the par combinator is guaranteed to only affect performance, and no

by Peaker 15y ago

Functional programs encode their dependencies as arguments/return-values. In Haskell, using the par combinator is guaranteed to only affect performance, and not the actual result of the program. This is already a huge boost.

anamax 15y ago
> This is already a huge boost. Like I said, I've been to this rodeo before. Heck, I even drank the Kool-aid one of the previous times that functional languages were going to enable parallel execution. Since there's nothing new this time, I think that it's safe to say that the result will be the same. Easy to find and nicely separable dependencies may be necessary, but they aren't anywhere close to sufficient. (BTW - the relevant criteria is not "huge boost" but significant boost, and I don't mean distiguishable from random chance.)
- Peaker 15y ago
  What functional languages did you see before? Were they pure? Could they guarantee that parallelism did not affect the semantics of their programs like Haskell can? Did you actually see the use of the "par" combinator?
  - anamax 15y ago
    > What functional languages did you see before? If you're going to argue novelty, shouldn't you be the one describing past work? > Were they pure? Could they guarantee that parallelism did not affect the semantics of their programs like Haskell can? Yes. Why is this surprising to you? > Did you actually see the use of the "par" combinator? Do you really think that "do something before it is strictly needed in a lazy language" is new? In other news, your generation didn't invent/discover any sex acts. (Neither did mine.)
    - Peaker 15y ago
      It is surprising because pure functional languages have not been around for a long time, especially not ones with good optimizers. > Do you really think that "do something before it is strictly needed in a lazy language" is new? That's not what the "par" combinator does. "par" along with "pseq" is already used, today, to achieve parallelism in Haskell code, and it already is easier to parallelize than in other environments. Additionally, STM in Haskell is usable in practice, unlike other implementations of software transactional memory, and it also relates to purity (in this case, the ability to distinguish different types of impurity).

by Peaker 15y ago

anamax 15y ago

> This is already a huge boost. Like I said, I've been to this rodeo before. Heck, I even drank the Kool-aid one of the previous times that functional languages were going to enable parallel execution. Since there's nothing new this time, I think that it's safe to say that the result will be the same. Easy to find and nicely separable dependencies may be necessary, but they aren't anywhere close to sufficient. (BTW - the relevant criteria is not "huge boost" but significant boost, and I don't mean distiguishable from random chance.)

Peaker 15y ago
What functional languages did you see before? Were they pure? Could they guarantee that parallelism did not affect the semantics of their programs like Haskell can? Did you actually see the use of the "par" combinator?
- anamax 15y ago
  > What functional languages did you see before? If you're going to argue novelty, shouldn't you be the one describing past work? > Were they pure? Could they guarantee that parallelism did not affect the semantics of their programs like Haskell can? Yes. Why is this surprising to you? > Did you actually see the use of the "par" combinator? Do you really think that "do something before it is strictly needed in a lazy language" is new? In other news, your generation didn't invent/discover any sex acts. (Neither did mine.)
  - Peaker 15y ago
    It is surprising because pure functional languages have not been around for a long time, especially not ones with good optimizers. > Do you really think that "do something before it is strictly needed in a lazy language" is new? That's not what the "par" combinator does. "par" along with "pseq" is already used, today, to achieve parallelism in Haskell code, and it already is easier to parallelize than in other environments. Additionally, STM in Haskell is usable in practice, unlike other implementations of software transactional memory, and it also relates to purity (in this case, the ability to distinguish different types of impurity).