Big Bee Consultants Ltd

The Actor Model originated in 1973 and allows easy description of stateful objects that execute concurrently with each other. They pass messages and, fundamentally, these messages are delivered without the sender ever waiting for the receivet to acknowledge receipt (i.e. the messages are exchanged asynchronously). PROC actor (CHAN? OF ANY in) WHILE TRUE SEQ : No control over aliasing It is easy to send mutable data structures, such as collections, in messages between actors.

The recently-concluded Principles of Reactive Programming Martin Odersky Good overview of using mutable code for event-based simulation Event-wheel model is an old idea, but solid Eric Meier rambling presentations without any summaries duality aside-remarks & category theory not really necessary sales job for Rx library complex api without good reference documentation suffers from immediate non-determinism potentially heavy memory footprint needed for re-imposing ordering on disordered events difficulty in making choices (no clear select/alternative) complex higher-order manipulation - clever but hard to understand unnecessarily complex compared to equivalent CSP-based lego race conditions are sometimes allowed - especially MultipleAssignmentSubscription() source code samples have syntax errors Rx library is alpha-grade version with bugs callback hell.

The Cake Pattern is a hugely popular way of constructing Scala applications based on mixed-in code components. So what’s wrong? global namespace; name collisions; broken locality of knowledge prefer composition over inheritance testing the wrong things - blurred responsibilities  refactoring - harder more perm-gen space, more classloading cannot have final classes (unless sealed)

Being of only modest mathematical achievement, I wouldn't claim much great insight. However, when doing my studies in earlier years, I was always unimpressed with the lack of simplicity of many equations featuring the constant 2π

At a recent conference, I had one of those 'aha!' moments when some existing pieces together to give a new insight. Sometimes, a glimpse of greater clarity sheds light on where we are and where we're going. In this particular case, I'd been wrestling with concurrency issues. All concurrent software needs to share state. Obviously, if this were not true, it would just be a bag of disjoint stuff otherwise. Sharing state is where the fun starts.

Good For … … … Not So Good For latter-day batch processing - limited model expressiveness poor performance limited abstraction limited applicability

I was asked to give a tour of Go to colleagues, so what better than to flatter Russ Cox by imitating his excellent tour of Go. The presentation material and code samples for my tour are here.

In an earlier article, four untestable dynamic problems were discussed: race conditions deadlock livelock thread starvation There is no panacea to solve these problems. However, there are quite usable steps that can be taken to deal with such situations. Race Conditions Although this article is about deadlocks, you wouldn’t have any if race conditions (instability due to concurrent threads changing shared data without sufficient protective locking) were not a concern.

It’s quite easy to install the Go language on Ubuntu and similar Linuxes. In fact, Ubuntu has an old version straight out of apt-get. However, if you want to install the latest, maybe you want to download the latest and install it in a clean way. Here’s how I chose to do it - YMMV. #!/bin/bash -xe V=go${1:-1.1} if fgrep $V /usr/local/go/VERSION; then echo Go $V is already installed in /usr/local/go echo To uninstall or upgrade, first echo " sudo rm -rf /usr/local/go" else echo Installing Go programming language $V .

I was very fortunate to join the London Scala Exchange conference over the last two days. A good range of quality talks were offered - some thought provoking, some highly entertaining. And most wrestled to some extent with concurrency. It seems that Scala is not yet at ease with itself in its concurrency model. The root of the issue is the JVM: threads are very expensive and limited to small numbers (say, 30).