Enseñar Smalltalk en primer año y oooSmalltalk

Does it Compose?

In large lock-based systems we have a lot of difficulty avoiding race-conditions and deadlocks and priority inversions and starvation and convoying. In a large system with locking, you need to grok the whole system to prevent problems; independently valid components that use locking code might deadlock when composed. That makes locks very difficult to reconcile with large systems - especially those involving open (third-party pluggable) modularity.

We have a much easier time with data-parallelism, where we split large calculations into different threads (Cilk, Intel Concurrent Collections, OooJava, Data Parallel Haskell). Where we need concurrent semantics, we have easier time with shared-nothing and lock-free architectures (SOA, Actors, FBP, Publish/Subscribe), or event-loop concurrency (E, Croquet, Win32), or single-assignment concurrency (Oz, concurrent constraint), or temporal logic concurrency (FRP, Dedalus, TCC, UTCC), or transactional systems (databases, tuple spaces, blackboard, hibernate, gemstone, STM).

The fact that so much of our computing infrastructure explicitly uses semaphores and mutexes and shared-resource threading speaks of some odd perceptions of the subject, widespread ignorance of other options, maybe a naive considerations for performance and hand-optimization, or perhaps just inadequate language design - the fault of a language community that too easily dismisses concurrency as something to 'tack on' later (excusable for C in 1972, but less so for Bit-C in 2008).

There is also a lot of inertia: the prevalence of synchronous IO from the OS (such as every process having three synchronous ports by default) - despite the fact that modern CPUs perform almost no synchronous operations. The limited tools offered by the OS make it difficult to implement other concurrency models efficiently, which certainly resists migration away from thread-based shared resource concurrency, which in turn discourages experiment with providing other concurrency models from the OS. Fighting against inertia is difficult, sometimes radical.

Finally, there are also extremely low standards for success. Somehow, in a manner I find nigh incomprehensible: developers that struggle to get the locking right, fail, fight off recurring concurrency bugs repeatedly, discover rare race-conditions months after shipping, fix one bug to create another... these developers will turn around and say that threading and locks were successful and comprehensible. Consider this reportwhere students consistently reported that locking was 'easier' even though they consistently made more mistakes. Is this confabulation? selective memory? unconscious incompetence? Maybe there's something about human nature that associates a retrospective 'triumph' with'good tools' even though it really means 'your tools sucked, you fool; you built this with your own blood, sweat, and parentheses'. Real progress is measured by the extent to which we no longer need to think about or struggle with what we are doing, yet can still accomplish our goals effectively and efficiently - thereby leaving us open to higher-level goals, but offering no 'triumph' for whatever the tool purposes.

Modern OS kernels are examples of 'triumph'. That should tell you just what I think of the tools the developers were using. Of course, until better tools are available (and the OS itself can in many ways be considered such a tool) a triumph every new kernel will be.

-- 
Simplex Veri Sigillum