1,115 karma · joined March 13, 2008
The problem with this analogy is that everything being an object doesn't by you much. But in Haskell, the type system helps you keep track of what's pure and what's not. So having a type system that keeps track of purity buys you something: lots of pure and extremely easy to reason about code. Non-deterministic (unpure) code is the same difficulty to reason about in any language. Isolating it from pure code just reduces the amount of code which is difficult to reason about.
I'd be interested to see how they compare.
cdx.co
dirigible.co
Instances can't be explicitly imported either.
Another thing I don't like is if you have two different functions with the same signature but different implementations meant to give swappable functionality, there's no way of specifying that explicitly. As a user of a library, you just have to realize the functions can be swapped out with modules. For example:
http://hackage.haskell.org/packages/archive/bytestring/0.10....
http://hackage.haskell.org/packages/archive/bytestring/0.10....
It's really not that bad but I do like how other languages allow the programmer to make this explicit.
I still stand by my assertion that you misunderstood the quote from the Haskell wiki:
"Rule of thumb: use Pure Parallelism if you can, Concurrency otherwise."
as something that supports your claim that parallelism is not concurrency.
From Wikipedia:
"In computer science, concurrency is a property of systems in which several computations are executing simultaneously, and potentially interacting with each other. The computations may be executing on multiple cores in the same chip, preemptively time-shared threads on the same processor, or executed on physically separated processors."
I find it hard to believe that parallel execution of multiple threads aren't "computations executing simultaneously" and therefor aren't concurrent.
Do you have any more detail about why you (or Rob Pike) think that parallel execution is not also always concurrent execution?