Category Archives: Coding

TIS-100 JMP POST

POST:

It’s not often (never) that I feel moved to review a computer game. It’s not so much that I don’t play them, because I do – quite a bit sometimes, but because they are generally “good” and an awful lot of people already review games.

Enter TIS-100; it’s a modest little thing, and it’s interface is both nostalgia-inducing retro and modern convenience. It looks like you should be using an ancient IBM model M keyboard, but actually allows mouse clicks and control-c/v commands just like modern software would. With very little fanfare you’re dropped into a broken operating system, where the corrupted segments of the kernel have to be fixed up by you.

Welcome to TIS100
Here’s the welcome screen – feel that 1970’s vibe.

The first part of the charm here is that there is no hand-holding. None. You’re provided with a short manual detailing the valid processor op-codes, a little brief on how the node based architecture works – and then you’re out in the wild. Each node has a short code limit of around 15 lines, and each node also allows access to two registers. And that’s it. You’re set a task, and provided with some tests to run with the expected output detailed on the left hand side of the display. This is coding stripped down to it’s barest nuts and bolts.

Part of the novelty is that the TIS stands for Tesselated-Intelligence-System – processing is divided out into separate nodes, each with their own codebase. Calls to access the values of other nodes block the callee, making simple swaps a more considered operation and deadlocks ever present. Once you’ve got the swing though, you quickly find that you can use nodes for parallel processing, or as quick scratch-RAM for a main processing node. Each task that you are set to repair a segment is also non-trivial, in that it’s a real operation you could expect to find in an embedded environment (signal peak detection, pattern matching – even an interrupt handler), and that there’s a genuine sense of accomplishment when the output column of the test matches the required values – and it’s extremely instructional.

Tis Running
A mid-level problem solved in drunken enthusiasm

I spend most of my working life dealing with a fourth generation language, and I’m abstracted away from the hardware by a considerable degree – but I’ve often yearned to get some assembly coding done (even maybe start a hobby operating system), and all of my attempts to “get in” to assembly have been thwarted. Either I wasn’t experienced enough, the documentation was patchy, or the build environment wasn’t sane; I’ve had several cracks at learning – but nothing in my twenty-plus years of developing has been as useful or informative as a (slightly drunken) hour with this little beast.

One of the joys is that coming from some much (.NET, SQL server) down to this level forces you to do far more with far less. I tend to float up objects and variables with wild abandon, expensive database queries and non-optimal execution trees don’t consume a lot of my thinking time because modern machines are so fast and have so much RAM.  I do sometimes go back over old code to correct my more egregious assumptions or requests (when they pile up into seconds), but here we’re given two registers two work with – and one of the register operations is destructive. Suddenly we’re up into The Art of Computer Programming territory, using a notional system to achieve realistic results – and with such little room to manoeuvre that optimisation is almost impossible to avoid.

This really has helped me enormously in terms of my feeling of “completeness” as a developer, and has refueled my desire to work through the Art of Computer Programming and GEB (Godel, Escher Bach – an eternal golden braid to the unfamiliar) – it’s the same feeling you get when a beautiful algorithm unfolds in your head, and when it gets down to it, it’s one of the reasons I’m in this business. I love to code, and I love good code – but we don’t often get paid to write good code; just stuff that works. If you feel the same then get this game, because it will put you back in touch with that feeling.

If you’ve never coded before, you may need a little more time bootstrapping yourself – but I reckon that you’d be far better off spending a day puzzling over this than almost any “fundamentals” programming course. This will get you in at the sharp end, and the techniques you learn will give you a better understanding of what various library functions do, their overhead – and insight into how much has gone into providing all that padding for you to keep you safe from the sharp edges of the hardware.

Please – go buy. It’s only a fiver, and I want to encourage the developer to keep adding more segments and more challenges; they’ve managed to re-awaken my hidden low-level developer, and I want more!

Coding Chickens

In a short break from our usual programme (while I finish writing up the details of my fast), I feel the need to explore some of the horrors developers face; if only to make myself feel a bit better.

Sometimes being a developer is rewarding, sometimes you get the strong feeling that you should be able to do more to help. Sometimes you get the feeling that you just can’t get people to understand that you are trying to help. You’re not giving long time estimates out of a desire to be difficult, you’re not trying to make something “sound more difficult than it really is”. You’re just trying to help.

Nowhere do I bump into this more than when managers congregate to work on ‘systems’.

A system is a nebulous thing, or at least it is before someone like me gets involved – I’m a systems developer, so I think in terms  outcomes and inputs, and minimisation of interaction. My job (which I am ok at, or so I’d prefer to think) is to take the fluff of a user requirement and turn it into a practical improvement. This unfortunately means that I bump into a lot of people who also believe that they can create systems.

I have the opportunity to watch this process of creation from a short range, and in one of the businesses I’ve dealt with for a very long time the effect is similar to watching a small clutch of argumentative chickens trying to work out a mirror. This mental image is far more amusing in the mind than it is in the flesh – as someone who really wants to improve an overall work environment, phrases like “Oh, I think we should have another form filled in and scanned before we let users do that” make my blood boil. At the end, there’s a lot of noise, some feathers in the air and nothing remotely looking like a system in place.

There are people in these meetings who squawk because all the other chickens are making noise, there are people who add redundant checks and measures and steps because they realise their own make-work may be reduced, and there are people who really shouldn’t be allowed to add their tortuous mental loops into the process.

You know you’re in the presence of the latter when the subject of outcomes comes up on the agenda. These people want to track and report on everything it seems. Mistaking visibility for control, they want to see “every stationary order under £15 for the year 2001” (a genuine phrase heard in a chicken-fest). What then unfolds is a system where a huge amount of ROD – my own coining for wRite Only Data – is captured. Every user, at every point in the process is suddenly burdened with entering data they may barely understand (or indeed know) into the system – resulting in a massively bloated interface that nobody wants to use. Quite simply, the clichéd ROD for your back.

Don’t get me wrong, I have some good clients relationships; many lasting over years where such happenings don’t take place, where the chickens are carefully cooped before a requirement meeting even takes place. One has even got themselves to the point where they are able to judge how long it’s going to take me to deliver their requirement – and how I love them and cherish them as a client, and how much more willing to stretch things we are when things go to the edge of the specification.

Waterfull
A waterfall is an elegant system for getting water downhill.

These people capture only the data they need, only generate the documents they need and only capture the data they need – and they can take advice about how best to organise these into an overall business solution. People who are of genuine value to their business are never worried about “systems” taking over their part in the organisation, they instead relish the chance to get away from the make-work and get on with their job – making the business better, and not carefully crossing off items on a printed report with a biro and a rule. This latter of course would be a firing offence in my own business!