Hacker News Reader

Comment by dragonwriter | Hacker News Reader

Concurrent programming is hard because:

1. Reasoning about systems with multiple concurrent series of events which can interact with eachother is harder than reasoning about a single, serial chain of events, and

2. For a long time most programming environments (languages and libraries) -- and this is still true of many that are still widely used -- have only rudimentary support for concurrency.

Progress in language facilities and libraries is mitigating #2, but #1 is fairly fundamental.

View on HN

Agreed. All the talk about language constructs and better abstractions ignores the reality that reasoning about time is one of the hardest things that humans can do. It is one of our most fragile abilities, and we routinely fail to do it correctly when thinking about a single temporal sequence much less multiple temporal sequences interacting with each other.

No languages nor tools will ever entirely fix this. The promoters of Erlang and Haskell in this discussion are optimists. I'm particularly amused by the notion that Haskell threads only yield on memory allocation, which is the worst kind of imperative programming heuristic, forcing the programmer to worry a great deal about the ordered sequence of operations and the way in which it will change the state of the system in exactly the way Haskell is supposed to not to.

I don't think this is a fault in Haskell: it is just a pragmatic language designer bowing to the inevitable (although I'd argue that having the potential to yield as a side-effect of allocation is a sub-optimal choice for a side-effect-free language... I presume there must be an explicit instruction also that permits a yield to take place?)

Strictly speaking, the issue of Haskell threads only being preempted on memory allocation isn't a "language designer bowing to the inevitable", since its not a language feature, its a feature of the GHC implementation of Concurrent Haskell [1] (you have to have some heuristic like this if you are using green threads, but there's no reason Concurrent Haskell couldn't be implemented with native threads, but M:N green threads have advantages in practice, even with pathological cases that rarely occur in real programs.)

> although I'd argue that having the potential to yield as a side-effect of allocation is a sub-optimal choice for a side-effect-free language...

Preemption isn't a side-effect in the sense in which Haskell is side-effect free even in the single-threaded case, since timing isn't guaranteed to start with (and, particularly, a single-threaded Haskell program can be preempted by the host OS at any time, based on any heuristic applied by the host OS, and for any amount of time), and to extent that preemption effects semantics, it only effects the semantics of things like IO actions which are not, by design, side-effect.

> I presume there must be an explicit instruction also that permits a yield to take place?

Yes, Concurrent Haskell includes an explicit yield.

[1] https://hackage.haskell.org/package/base-4.7.0.0/docs/Contro...

3. Testing. It's really hard to properly test concurrent software and all the different outcomes situations.

Reply on news.ycombinator.com