Is concurrency hard?

[Robert Raschke]

mats wrote:
> Robert Raschke wrote:
>> I believe that concurrent programming is hard to most people, because
>> of the poor abstractions used by most programmers, i.e., state, lots
>> of it.
> 
>    how's that?

The kind of code I see in day to day life:

A = something
B = something else
routine_reading_and_writing_A_and_maybe_reading_B_and_writing_to_C_and_D()
E = D /* because the next routine works only on E, not on D */
routine_reading_E_writing_to_F()
routine_reading_A_and_F()

... and so on ...

This kind of Basic style programming is extremely widespread,
regardless how advanced the underlying technology.  Although
functional and declarative languages make it just that little bit
harder to program in such a style, not much, but a little.

I get the impression a lot of people think about where and how to
store data when programming (i.e., how do I manipulate the data),
instead of concentrating on the transformational aspect (i.e., what am
I doing to the data).

I think that as long as you are concentrating on manually moving data
about in piecemeal fashion, you are unlikely to notice any
opportunities for making use of concurrency.

I feel that the best way of noticing concurrency in your application
is by carefully crafting the vocabulary that describes your problem
and its solution.  Very often you will find that storage does not rate
very highly in such a vocabulary, allowing you to concentrate on the
functional ascpect of you application.  Even more fundamentally, if
your vocabulary does end up with words for things that need storage,
you can be sure that they are the ones that will limit your
concurrency.

Robby