Is concurrency hard?

[Marthin Laubscher]

Micky Latowicki writes:

> Is concurrency inherently hard?

Concurrency itself is extremely easy - it's how the world works. What
difficulty people experience with concurrency stems from how our technology
patriarchs chose to deal with their limitations. "We" made two fundamental
choices (called breakthroughs at the time) that went directly against
reality and consequently still cripple almost every aspect of computing
today.
a) We represent things with digital approximations.
b) We forced things into sequences of instructions.
(You should easily recognise that those two things are seen as the
cornerstones of computing.)

This is not the time and place to wonder about where analogue computing
could have been today if all the money that was spent on digital computing
was spent on the analogue branch.

Micky's question does however require that we look a little deeper in to the
sequential aspect.

Most programmers are first introduced to programming in the sequential
programming paradigm (COBOL, Fortran, C, PL/I, Pascal, BASIC, ADA, Java,
etc.) To some this is easier than to others, but eventually student
programmers learn to align their thinking, reasoning and approach to solving
problems to that mindset, and they become programmers. Once set, many would
never grow beyond that mindset, not because they're stubborn or stupid, but
because the mindset dictates that everything you encounter should be
"brought back to a sequential set of instructions" and so even when faced
with different opportunities and environments, the "programmed behaviour" is
to force everything back to sequential thinking.

Programming techniques allowing us to address problems in a different
manner, even the successful ones, require that we adapt to that mindset
before we can hope to be effective in solving problems.

Some examples:
1) SQL: To harness the power of the relational database, we needed to think
in terms of sets and set theory. Once that mindset is in place, the
technique is so powerful that I was able to write two and a half
telecommunications billing systems purely inside the database. But the
gravitational pull of the masses of people and environments that don't grasp
set theory is so strong that the vast majority of relational database
activity ends up with very little usage of set theory and a lot of
sequential processing of data. Had the internet spread as much at the time
as now, we'd have all seen just how many times the "Is RDBMS/SQL/Set Theory
inherently hard?" issue was in fact raised. 

2) Event driven programming was another such technique that tripped up
countless very experienced programmers (and made life quite difficult for
the Windows and X11 worlds). But many did get it relatively quickly, in
particular the young and open-minded folk that Microsoft targeted at the
time - which accounts for a large part of it's success. Judging at the time
of it's rise who got into the swing of things and who stayed clear, the only
reason "Is Event Driven Programming inherently hard?" was asked perhaps a
little less often, was the ego's of the old hands hating how the "youngens"
took off.

3) Object orientation: Wow, didn't that take world through turmoil? The
extent to which the original concept was enhanced or retarded by traditional
sequential thinking, is another debate not worth having. Nevertheless, Micky
might as well have asked "Is OO inherently hard?"

In each of the example cases, including concurrency, the answer is the same:

No, it's not inherently hard. But it is hard to ignore our bad habits. It is
our bad habits, entrenched ways of thinking, of approximating the world
around us in order to deal with it inside a computer. That is what's making
it seem hard.
 
> 
> I've seen it stated elsewhere that writing concurrent software
> cannot be made easy. The author was writing in a context of a very 
> different approach to concurrent programming than erlang's and I was 
> curious if erlang developers feel the same way. If so, then what's 
> hard about it when working with erlang?

That's true in the same way as there being no such thing as a probability of
1 or 0.

For my liking, I find far too little reference to C.A.R. Hoare's CSP in the
Erlang community. Strange as it might seem, I "learned to program in Erlang"
a decade before the language was conceived. How? I learned to express
concurrency solutions in CSP at varsity in the mid 80's. At the time, CSP
was a notation, a concept, a specification language, an approach to
concurrency. I was over the moon with excitement a decade or so later when I
learned that (although largely extended with a lisp-like syntax and other
elements to make it practical) there now was a way of actually executing CSP
- Erlang.

CSP has formed a large part of my foundation to conceptualise concurrent
processes interacting, each of them sequential in nature, interacting.
With that, concurrency is easy, without it, a mess. 

Communicating Sequential Processes (CSP) is still alive and kicking today
and what's become of the 1985 textbook is now available at
http://www.usingcsp.com/ for free. 

In case anybody wondered, no, beyond what the original book meant to me 20
years ago, I am in no way affiliated CSP, Oxford, Tony Hoare or Jim Davies.

Maybe CSP's silent disfavour has something to do with what became of its
author - according to the usingCSP website, he's at Microsoft Research.

Marthin Laubscher