eighty-twenty

Today I stumbled across “Guidelines for Choosing A Computer Language: Support For The Visionary Organization” by Patricia K. Lawlis, written back in 1997.

Appendix Q deals with Smalltalk. Here are the categories in which Smalltalk scores well:

• Clarity of source code - Rating: 9
• Complexity management (architecture support) - Rating: 6
• Maintainability - Rating: 7
• Object-oriented programming support - Rating: 10
• Reusability - Rating: 8
• Support for modern engineering methods ¹ - Rating: 7

Here are the categories in which Smalltalk scores poorly:

• Concurrency support - Rating: 2
• Distributed system support - Rating: 0
• Mixed language support - Rating: 3
• Portability - Rating: 3
• Real-time support - Rating: 0
• Reliability - Rating: 3
• Safety - Rating: 0
• Standardization - Rating: 3

Those low scores are ripe for correction!

People often speak of Smalltalk as if it were just another programming language. It is that, of course: Smalltalk the language is pure-object-oriented, class-based, memory safe, reflective, and dynamically typed. However the same name, Smalltalk, also denotes a complete operating system in a virtual machine on top of a traditional OS. Smalltalk’s operating-system nature is to blame for its poor performance in the categories shown above.

The (implied) criticisms of the low scores above are absolutely spot on:

• Smalltalk’s support for concurrency (isolation of processes; management of processes; isolating failures; transactional behaviour; etc.) is very low-level and old fashioned. Exactly what one would expect from an operating system designed in the early 80s.

• Its support for distributed programming is also not great. (I have a hypothesis about why that is, that I’m researching at the moment.)

• No isolation between processes makes mixed language support difficult.

• Reliability and safety are nonexistent in an environment with no isolation boundaries.

• Smalltalk is a heavily imperative language. Data structures are mutated internally all over the place, giving a straightforward shared-memory concurrency model.

So what can be done? Let’s look at another Application Operating System², this one designed with fault-tolerance in mind: Erlang/OTP.

• Erlang’s support for concurrency is very strong. Processes are, by default, isolated from one another, in that they share no mutable state, and a failure in one process cannot affect another process in an unstructured way.

• Its support for distributed programming is also very strong. Processes communicate by shared-nothing message passing. Scaling from a non-distributed system to a distributed system starts with the simple substitution of a TCP socket for an in-memory message queue.

• Isolation between processes makes the decision of which language to use to handle received messages within a process an essentially arbitrary one, though in practice Erlang doesn’t support anything other than its built-in functional fragment.

• Reliability and safety follow from the strong isolation boundaries between system components and from the structuring principles embodied in the OTP libraries.

• Erlang is a heavily functional language. Data structures are immutable, giving a straightforward shared-nothing message passing concurrency model.

Erlang has its problems, of course: it doesn’t support object-oriented programming other than either awkwardly (processes look a bit like objects) or in a trivial sense (function closures and objects are the same thing). As a result, generic programming (e.g. ignoring whether you have a list of numbers or an array of numbers) is poorly supported, syntactically unpleasant, and/or slow. It also enjoys none of the rich reflective support provided by the Smalltalk virtual machine, which makes the monitoring tools feel ad-hoc and not very general.

My instinct is that a system that supported a combination of Smalltalk’s smooth generic and reflective programming styles and Erlang’s ability to construct robust, concurrent and distributed systems, would make a great foundation for personal computing.

What can be done to Smalltalk’s operating-system nature to improve isolation of components within a running system? Mutability is a key concern, as is failure isolation. Can Smalltalk be refactored into a hybrid Smalltalk-Erlang system?

The 0MQ team has just released a draft specification of the 0MQ transport layer. It’s a sweet little spec—go take a look! The nice thing about it is that it concentrates on building a flexible transport layer without putting any constraints on the content, routing or meaning of the datagrams it carries.¹

Another interesting aspect of it is that messages are structured as a list of segments (frames)—and that structure is exposed to the next layer up! Such a seemingly small decision has large, and favourable, consequences: the next layer up can use the segmented structure of messages to represent many interesting patterns:

• a split between message envelope and message contents;
• a split between message headers and message body;
• a list of addresses to use in routing a message, like the old-school bang paths;
• a stream of content being delivered in chunks as it becomes available; and so on.

In my opinion, the AMQP spec should have been split up into similarly small, flexible pieces as part of the work leading up to the current 1.0 drafts. In defence of the working group’s current approach, a monolithic spec can make it easier to build a coherent whole; but on the minus side, it can make it so difficult to gain experience with the system being designed that coherence remains out of reach. For instance, it is not now (and probably never will be) possible to write a one-line message sender using bash for AMQP.

Travis Griggs relates a story of being burned by the use of lazy initialization in Smalltalk. It’s an interesting problem, and I sympathise. The way I see it is that the underlying cause is too much reliance on mutable state, and/or not enough declarative specification of intent. This is a general problem in languages like Smalltalk and Java, nothing specific to particular pieces of code anyone writes, of course!

Some other languages and systems supporting lazy initialization (memoization) avoid the problem by detecting circular dependencies. As each initial-value-computing thunk is entered, a bit is set if it isn’t already, or an exception is raised if the bit is already set. Any kind of non-cyclic dependency graph ends up computing its result as expected, and cycles are detected and signalled.

The trick is to declaratively let the system know what your intent is.

What would be a good Smalltalk-like way of letting the system know you mean to build a lazy initializer? A few options spring to mind:

• one could use a pragma on methods acting the part of lazily-initializing getters;

• one could mark the initializing closure specially somehow (foo ifNil: [...] lazyInitializer), where the effect of #lazyInitializer is to set up the circularity checks (initial experiments along these lines stalled when I realised I didn’t have enough understanding of the way BlockClosures work in Squeak);

• one could set foo initially to some object representing a Promised value, which internally has support for the necessary circularity-checks;

and no doubt many other variations.

(Incidentally, I just tried Haskell, to see what it did with

let a = b + 1; b = a - 2 in a

and unfortunately it suffers from the same infinite recursion problem Travis’s code was suffering from: neither a value nor an error is produced.)

In our Systems course here at Northeastern, we’re working with Prex as our experimental platform this semester. A recent assignment called for the implementation of some virtual-memory-like features, using Prex’s exceptions to deliver information about faulting memory accesses to the faulting process, which is thereby given an opportunity to arrange for some memory to back the accessed address.

The problem is in the x86 code implementing system call handling for the exception_return() system call. The logic for detecting that an exception_return() has occurred neglects to take into account the fact that returning from an exception replaces the active context. The fix is to check %eax before calling syscall_handler.

Without the patch below, %eax will be smashed in the context of the code that was interrupted by the exception.

I emailed this patch to the Prex list, but something about my message triggered Sourceforge’s spam detection software, or something equally tedious and annoying, and it hasn’t made its way through yet; so I’m posting this here in the hopes that those in need of it might find it.

Here’s the required change:

--- a/bsp/hal/x86/arch/locore.S
+++ b/bsp/hal/x86/arch/locore.S
@@ -313,11 +313,23 @@ ENTRY(syscall_entry)
	pushl	$(SYSCALL_INT)		/* Trap number */
	SAVE_ALL
	SETUP_SEG
-	call	syscall_handler
+	/* We check the saved value of eax here, before calling syscall_handler,
+	   because if it's zero (i.e. exception_return), we will completely
+	   obliterate the saved registers in context_restore() within
+	   exception_return() within syscall_handler(), which will make the value
+	   of 0x10(%esp) contain whatever random eax value happened to be around
+	   at the time the exception was delivered. For example, if the exn
+	   was a page fault, eax could be anything at all. If we check 0x10(%esp)
+	   after syscall_handler has returned, it will in the general case contain
+	   junk. */
	cmpl	$0, 0x10(%esp)		/* Skip setting eax if exception_return */
	je	1f
+	call	syscall_handler
	movl	%eax, 0x10(%esp)	/* Set return value to eax */
+	jmp	2f
 1:
+	call	syscall_handler
+2:
	call	exception_deliver	/* Check exception */
 syscall_ret:
	RESTORE_ALL

I recently, upon reading something somewhere that irked me, tweeted the old adage

1. Make it work 2. Make it right 3. Make it fast. So many projects start at 1 and skip to 3, or worse, start at 3… :-(

In reply, Conal Elliott tweeted

What does it mean to work but not be right?

which is a great question. If a program can be said to be “working”, what can that possibly mean except that it is in some sense a “right” program?¹

That’s a pretty decent point. Software is a tool for getting stuff done, after all.

However, I’m not quite ready to abandon my idealism about these things, so let me have a stab at expressing myself more clearly: a “right” program follows the design implied by its own implementation. Implementing programs can lead to improved designs through deeper understanding of the underlying domains.

Now, programs can “work” just fine and yet not follow (or not expose) their own internal logic. It’s when programs are composed that their little warts and kinks start to add up quickly into serious distortions. Let’s revisit the adage:

• Step 1: make it work;
• Step 2: make it right;
• Step 3: make it fast.

I have in my mind the image of two mirrors roughly facing each other (step 1): improving their alignment even slightly (step 2) can cause the tail of reflected images to grow asymptotically longer. Polishing the mirrors (step 3) helps sometimes, but only if they’re in good-enough alignment to begin with.

I don’t care about step 2 for every piece of software. For example, most embedded systems software (microwave controllers, digital watches) is so throwaway and terminal that polishing it beyond a certain point isn’t worth it.²

Foundational software, though, is where a “make it right” step becomes crucial. Software upon which other software is constructed³ has to be made right because of the costs of correcting for design flaws downstream. The total effort involved in working around kinks and warts in a foundational artifact often exceeds the effort required to fix the foundations.⁴

There are countless examples where an almost-right product has gained wide influence without being “made right”: Unix, whose distortions have led to X-windows and monolithic walled-garden applications; Excel, whose distortions particularly with respect to naming and scope have led to horrible kludges and workarounds in any application beyond the trivially simple; AMQP, whose original model was simple and promising, but which is now moving in the direction of the irredeemably complicated; and on, and on.

In each case, lots (and lots) of effort has been spent on optimizing the current artifact, and because very little effort has been spent on learning more about the domain and revisiting the artifact’s design decisions, even more effort has been spent downstream on workarounds for each system’s design flaws.

Lots of these cases have been successful because the software involved has happened to line up well enough with the underlying domain that new kinds of useful work can be done: getting the foundations closer to being “right” has opened up previously-unimagined spaces for new applications. Getting the foundations “right” really does increase the power and the reach of a system.

This is a dialog that popped up just now from iTunes:

It has several noteworthy interactive features:

1. It is not resizable.
2. The two choices are visually identical.
3. Copy-and-paste is disabled for the text of interest.

It also possesses a few less visible but no less interesting attributes:

1. There is no undo once I click OK.
2. iTunes remembers my choice¹ for future insertions of the same CD.

I shall choose at random.

Moral: Current environments for interacting with computers are, putting it mildly, irretrievably broken. Our only hope lies in disruptive innovation.

I’ve just finished building and deploying this website. It uses jekyll to render the content, and the content author uses git to push the changes up to the hosting machine. From there, a nice little chain of programs arranges for the site to be rebuilt on the server and made live:

• A git post-receive hook uses curl to HTTP POST an empty message into a RabbitMQ exchange via the RabbitHub plugin.

• D. J. Bernstein’s daemontools supervises an instance of amqp-consume, which connects to a queue bound to the exchange the post-receive hook delivers into, and whenever a message is received, invokes a shell-script. The command-line for invoking amqp-consume is roughly

  amqp-consume \
      -s localhost \
      --username=... --password=... \
      -e exchangename \
      -A \
      /path/to/rebuild-website-script

• The shell-script invoked for every message from RabbitMQ checks out a fresh copy of the website, compiles it, and deploys the resulting static HTML into the correct location on the file system for Apache to pick up.

• I’m also monitoring the RabbitMQ exchange using the rabbitmq-xmpp plugin talking to my desktop XMPP client, Adium, so whenever anyone does a git push, I get a message appearing in my IM client from exchangename@my.rabbitmq.hostname letting me know a new version of the site has just gone live.

A few days ago, I chanced across http://i.imgur.com/WKeVH.gif on twitter¹. It occurred to me that you could use the same style of diagram to show all three of sin, cos and tan simultaneously. If you project downward at the same time as you project sideways, the two projections will be 90 degrees out-of-phase, just as sine and cosine are.

An hour or so’s hacking in Squeak resulted in the following. (Click here to hide the animation.)

The source code is available for the curious. (Automatic syntax-highlighting courtesy of github. If the previous link doesn’t work for some reason, a less-pretty but almost certainly available link is this one.)

I’ve installed comments, courtesy of disqus. It looks like a very cool system; certainly, installing it and getting it running the way I wanted it was dead straightforward.

Update 2014-08-23: I’ve removed disqus again, in favour of other methods of feedback.

Hee hee! This paper, on Scheme Program Documentation Tools, references docscm :-)