I’ve been writing some string manipulation code with C, and I rather liked being able to just move pointers around and insert null characters to manipulate strings in place. Being able to split a longer string into many substrings just by making pointers and nulls is neat.

It may be relevant to consider here that document processing and publication was the first real use of the C/Unix system at Bell Labs. It was the justification that Ken Thompson and Dennis Ritchie used to get the PDP-11 that would give them the room to do more than the proof-of-concept experiments they were trying out on the borrowed PDP-7 they were using. Instead of selling it as an OS development project, which is what Thompson really wanted to do since they dropped out of the Multics project, they sold it as a document processing platform for their patent clerks to use to prepare patent documents. In the context of editing large text documents, this usage of substrings of strings as strings is probably a bit more well-motivated.

There’s now a github repository where a ‘development history’ such as can be reconstructed today from backup tapes captures the development of Unix from its start as PDP-7 assembly to relatively modern SysV and BSD forms. The really early versions, from when Unix was still entirely an internal project to Bell Labs, are pretty interesting. You’ve got the bare bones of a minimalistic multi-user operating system and then a whole bunch of sophisticated document preparation tools (roff and friends, the successors of which still format all our Linux man pages into nicely formatted ASCII text or Postscript) and compiler development stuff.

There is plenty to criticize about C in today’s context; if you look at the amount of change that pre-existing standardized languages like Fortran (or even C++, recently) have gone through over the years, C basically ended up fossilized once it got through the ANSI process in ‘89. There are plenty of design decisions that ought to be revisited in light of the sophistication of today’s compiler technology and developments in programming language theory, but the standardization committee seems content to let C be a legacy platform and have C++ be where all but the bare minimum of new features and fixes get integrated.

But in the context of the late 1960s and early 1970s when the key design points of C were set (most of the semantics were straight from BCPL, and the type structure owes much to Algol 68) C was a remarkably well-designed language for what it was intended to do and how it was used. For contrast, the MUMPS language was developed just a few years before on a PDP-7 as well; take a look at it if you want to see how terrible things could be. People still write MUMPS code to run hospital databases today….

It can be used for more general substrings than just suffixes if you’re willing to stick destructive NULL placeholders in the string during in-place manipulation. Since strtok() dates to an early version of C, that seems to have been, if not a common use, at least a use that the designers had in mind at the time.

It certainly doesn’t fix the poor estimates. But poor estimates are only a problem if the estimates themselves are providing value to the team/company. In my experience, they often aren’t. If you know that Feature X is the highest priority, taking time to estimate that it’s 1 day versus 5 days may be a total waste.

The first couple of chapters of the Kanban book are instructive in this regard. In that situation so much time was being spent estimating that no one was ever able to actually do any real work.

Perhaps you are right that they have problems yet that they need to deal with. But I would like to invite you to take a look back at the Agile Manifesto, which is supposedly defining the guiding principles behind Scrum, Kanban, XP, etc. Ultimately, all the practices and techniques and tools are meant to be subservient to self-directed teams that are continually examining their progress and changing things to get any perceived roadblocks to their progress out of the way.

There is little value in producing an estimate of the work to be done in some arbitrary amount of time if no one is asking for that particular fact and it’s not providing immediate value to the team in pacing their work. The relationship between developer and customer is different in various situations, and not all customers need precise work estimates at two-week intervals.

Furthermore, placing arbitrary time/size constraints on granularity of estimation can wreak havoc on a developer’s intuition for how long things will take. It could be that they’re, as a team, relatively good at estimation via a continual process like Kanban, but terrible when forced to break things down in ways they’re not used to in Scrum. Could they improve their Scrum estimates over time? Probably. Is it worth it to deal with the demoralization of the team in the mean time? That’s their call to make! That’s the point of the agile manifesto, as I understand it.

I am a firm believer in the value of processes, tools, and procedures. But I also believe just as firmly that there’s no “one size fits all” perfect set of processes, tools, and procedures that will fit every team and project. Ultimately, it’s the responsibility of development teams to be self-aware and self-directed enough to develop a set of these things that make them most effective. Kudos to the author for making an effort to do this!

It’s hard to tell for sure exactly how the STM composition he shows is working, but it looks to me like the sum type of possible changes is built there in the main display thread. In a CSP-style system, there would be something in each of the threads constructing a value of one of those variants and sending it to the main display thread.

It seems like the threads in this example just directly operate on some shared data structure. The display thread notices the changes by watching the structure and translates them into one of the display update variants, rather than getting a message and doing updates itself.

The trouble with a purely-messaging update system in Haskell, when each of the threads needs to read the shared state as well as update it, is that that without some sort of mutable reference like STM, you have to push the new state to each of the threads via message or have messages that update the state get performed once per thread. These are also valid ways of doing it, but in some ways it’s simpler for the mutator threads to simply each encapsulate their updates to the state in an STM transaction. In this scenario, the thread responsible for updating the display just watches for mutations of the shared state and translates them into screen updates rather than having to collect update requests describing data structure manipulations, perform them, and push out updates to all the other threads as well as the screen.

Describing arbitrary data structure updates via messages also leads to a fairly complex message structure, and possibly even a full embedded DSL for describing them. Haskell is well-equipped to define and interpret that kind of thing, but it’s a lot of heavy machinery for simply doing standard updates to a shared bit of data.

So, I think that when individual threads are interacting with a central thread via a fairly regimented protocol, the CSP approach is probably more efficient and understandable. But when the threads all share a fairly complex piece of state that any of them could potentially make arbitrary reads and updates to, the CSP model starts to be less attractive compared to an explicit shared-state model like STM. I think this particular ‘terminal multiplexing’ example could easily go either way, but some of the author’s design decisions early on (or maybe baked into an underlying library) probably led to the STM approach being the more comfortable one.