5 ms·

Right, like one of the examples is summing two amounts of money. As far as I know, that's just adding integers if you're doing it right. It's not clear what all

Right, like one of the examples is summing two amounts of money. As far as I know, that's just adding integers if you're doing it right. It's not clear what all the formalisms are bringing to the table there.

jstimpfle 9y ago
I agree. But in some cases it might be nice to omit an explicit 0 or use some higher order combinator that is ergonomic just because it expects a monoid instance to be already prepared.
- whipoodle 9y ago
  So they make things a bit nicer, sometimes. Alrighty then.
  - tome 9y ago
    Amongst the things they do is that they sometimes make things a bit nicer in a completely generic way which is reusable across many problem domains.
tome 9y ago
If you know that amounts of money are a monoid under addition then you know that sum (map sum xs) == sum (concat xs) And there starts a whole slew of possible optimizations, including MapReduce. See, for example, https://userpages.uni-koblenz.de/~laemmel/MapReduce/paper.pdf https://userpages.uni-koblenz.de/~laemmel/MapReduce/paper.pd...
- whipoodle 9y ago
  I don't really know what you are trying to say.
  - deleted 9y ago
    [deleted]
  - bhrgunatha 9y ago
    It's saying that the operation can be made parallel. Applying an operation to a total workload is identical to: 1) Split the total workload into smaller workloads. 2) Apply the operation to each smaller workload. 3) Apply the operation to the results from step 2. Each smaller workload in step 2 can be run in parallel. While that may seem obvious for adding numbers or money it may be less obvious when you have different operations for example a method in an OO class hierarchy.
    - deleted 9y ago
      [deleted]
    - deleted 9y ago
      [deleted]
    - deleted 9y ago
      [deleted]
  - deleted 9y ago
    [deleted]
- imtringued 9y ago
  It may not be clear because it's very obvious but one of the primary optimizations in haskell that make it fast despite heavily using currying and lamba functions is that haskell doesn't have dynamic dispatch. This is completely unrelated to purity and lazyiness. This means it's possible to inline every lamba and partial function therefore use them at zero cost without the overhead of a JIT compiler or vm at runtime. The JVM can do similar optimizations because it knows the class hierarchy at runtime and therefore declares every method as final until it finds a class with a method that overrides the previous definition. It's also capable inlining dynamic dispatch by profiling the type of the object it's dispatching on. If 99% of all calls go to class X then it can inline the method of class X and catch the remaining 1% with a fallback clause. Of course this comes at a cost. You need to retain the bytecode, class metadata, profiling information and duplicated code that is generated from inlining in memory.

jstimpfle 9y ago

I agree. But in some cases it might be nice to omit an explicit 0 or use some higher order combinator that is ergonomic just because it expects a monoid instance to be already prepared.

whipoodle 9y ago
So they make things a bit nicer, sometimes. Alrighty then.
- tome 9y ago
  Amongst the things they do is that they sometimes make things a bit nicer in a completely generic way which is reusable across many problem domains.

tome 9y ago

If you know that amounts of money are a monoid under addition then you know that sum (map sum xs) == sum (concat xs) And there starts a whole slew of possible optimizations, including MapReduce. See, for example, https://userpages.uni-koblenz.de/~laemmel/MapReduce/paper.pdf https://userpages.uni-koblenz.de/~laemmel/MapReduce/paper.pd...

whipoodle 9y ago
I don't really know what you are trying to say.
- deleted 9y ago
  [deleted]
- bhrgunatha 9y ago
  It's saying that the operation can be made parallel. Applying an operation to a total workload is identical to: 1) Split the total workload into smaller workloads. 2) Apply the operation to each smaller workload. 3) Apply the operation to the results from step 2. Each smaller workload in step 2 can be run in parallel. While that may seem obvious for adding numbers or money it may be less obvious when you have different operations for example a method in an OO class hierarchy.
  - deleted 9y ago
    [deleted]
  - deleted 9y ago
    [deleted]
  - deleted 9y ago
    [deleted]
- deleted 9y ago
  [deleted]
imtringued 9y ago
It may not be clear because it's very obvious but one of the primary optimizations in haskell that make it fast despite heavily using currying and lamba functions is that haskell doesn't have dynamic dispatch. This is completely unrelated to purity and lazyiness. This means it's possible to inline every lamba and partial function therefore use them at zero cost without the overhead of a JIT compiler or vm at runtime. The JVM can do similar optimizations because it knows the class hierarchy at runtime and therefore declares every method as final until it finds a class with a method that overrides the previous definition. It's also capable inlining dynamic dispatch by profiling the type of the object it's dispatching on. If 99% of all calls go to class X then it can inline the method of class X and catch the remaining 1% with a fallback clause. Of course this comes at a cost. You need to retain the bytecode, class metadata, profiling information and duplicated code that is generated from inlining in memory.