I need a holiday! (by alaric)

This year, I've been alternating between bleak depression and enthusiastic elation.

Luckily, it's easy to see a pattern - the elation is when I let myself get distracted by interesting things; the depression is when I have to tear my attention back to what needs to be done rather than what I feel like doing!

It's been a funny year. On the one hand we've moved into a much larger house, with much better facilities, that's warmer and easier to keep clean and tidy. My work is great, and I've managed to catch up on some things that have been hanging over me for years - tax paperwork, terminating my limited company (that had become nothing more than a thorn in my side since I stopped freelancing), simplifying and upgrading my server setup, tidying up my home directory and organising my life. On the other hand, I've been so busy that the new home has mainly been a place to eat and sleep rather than something I've had much chance to enjoy, and I'm behind on the (small, reasonable) list of projects I wanted to do this year - with no year left to do them; I've so far spent only a handful of days on my own projects in the entire year.

I spent a whole day sorting out my workshop on my birthday in April, and ended that day with a few little things to finish off - which are still waiting for me. I've not finished the ring casting, which should only take a couple more days, nor rebuilt my furnace, which should take a few days more.

I've done a bit better on computer-based projects as I can do them wherever I have my laptop; I've done some work on my fiction project, and made progress on my organisational infrastructure to convert a huge pile of "things that need investigating to even begin to decide what needs doing about them" into a tractable TODO list, and done some writing for the ARGON project web site.

But, with my ability to concentrate on what I'm supposed to be doing rapidly waning, it's clear that I need some time off. So, I've booked the week before Christmas off of work, and I hope to:

1. Do what I can to fix the roof in the workshop.

   • It leaks. This will be hard to fix properly, as it'll require spending lots of money on materials; and possibly can't be done until there's some warmer, drier, weather to dry the decking out. But I'll see if I can improve on the current bodge somewhat, at least to give the decking a chance to dry properly without regular re-soakings.
   • There's great big gaps in the eaves, all round the walls, varying from a centimetre up to about twenty centimetres, through which an icy wind blows. All the warm air from the heater disappears, and ivy creeps in. I need to seal them up (minus a controllable air vent to let out humid air and fumes from welding - perhaps an air vent plus an extractor fan with a fume hood would be the way to go in the long run). I plan to saw some strips of wood to length so they can go between the rafters, nail them in place, and use judicious amounts of sealant to keep the tenacious ivy at bay and to account for my general inability to cut wood to exact lengths properly.

2. Run Ethernet to the workshop so I have an Internet connection there. This will involve spending some money on outdoor-suitable conduit and fittings, and trunking for the interior runs, then drilling lots of holes in walls and running cables through and sealing the gaps. But the result will be that I can actually do computer work at a desk with a comfy chair, rather than hunched over a laptop on the sofa with children tugging at me.

3. Start building the computer infrastructure in the workshop. I'm looking at a battery-backed low-voltage power system feeding a Raspberry Pi (which I already have, waiting - Sarah got me one for my birthday), bristling with sensors. Because sensors are fun.

4. If the weather and time permit, work on my ring casting and the furnace, although that somewhat requires dry weather. We'll see.

5. Chill out, play computer games, write fiction and ARGON prose.

6. Order the bits to build a chord keyer - I doubt I'll have time to build it by the time they arrive in the post, so I'm saving that for a project I can do at Bristol Hackspace in the new year.

But I need to take care that next year isn't like this one. Taking on so many responsibilities that I struggle to maintain my productivity means I get less stuff done, not more, and makes it hard to prioritise my effort sensibly. I'm going to book three weekend days each month, in advance, for my projects or simple relaxation, rather than just thinking I'll do them "when I get a free day" only to find that all of my weekends are booked up months in advance. I'll be open to rearranging them in order to fit around the days when Sarah or the children need me, or we're visiting people for events - most of the time, it doesn't matter what actual day I do things on. Sometimes this will involve getting a whole weekend, and then just a single day at the other end of a month; that's fine, just as long as it lets me keep making progress on my projects, and giving me a chance to unwind from the stresses of constantly doing what I must do, rather than what I want to do.

Static Typing (by alaric)

I read this fine blog post

And this is precisely what is wrong with dynamically typed languages: rather than affording the freedom to ignore types, they instead impose the bondage of restricting attention to a single [sum] type!

Ah, bless. The author means well, but is confusing matters. They're kind of right that the distinction between so-called "dynamically typed languages" and so-called "statically typed languages" isn't what people think it is, but I think they've still not quite grasped it, either.

Certainly, almost all languages have types of some kind (the only real exceptions are ones that directly operate on memory as an array of bits, and expect the user to request the interpretation of any given region of memory in each operation, such as assembly language). So-called "dynamically typed languages" (let's call them SCDTLs from now on, and SCSTLs for so-called "statically typed languages") usually have numbers, and strings, and so on as separate types. What is missing in them compared to SCSTLs is the ability to say "This variable will only ever hold variables of a given type"; and the argument of the author is that, therefore, SCDTLs force every variable to be of a single "could be anything" type, while SCSTLs let you be more expressive. And in an SCSTL you could indeed create a big sum type of everything and use that for all your variables and, pow, it'd be just like a SCDTL, once you'd written all the clunky wrappers around stuff like addition to throw a run-time error if the arguments aren't all numeric, and unbox them from the sum type, and box the result up. Oh, and you need to maintin your giant Anything Sum Type, adding any user-defined types to it

That's what the author omits to mention. SCDTLs have all this automatic machinery to do that for you, while in SCSTLs you need to do it by hand! Eugh!

Working with sum types is useful. It's handy for writing programming tools such as generic container data structures. SCSTLs tend to have tools such as parametric types to act as a short-cut around the difficulties of doing that stuff with explicit sum types, but it boils down to the same kind of thing under the hood.

Now, a lot of the rhetoric around SCSTLs via SCDTLs comes from a rather blinkered viewpoint, comparing something like PHP (almost everything fails at run time!) to something like C (sum types are like pulling teeth!) - both sides have come together a long way.

Haskell is perhaps the shining example of a SCSTL nowadays, with its polymorphism and parametric typeclasses offering advanced ways to express huge sum types without having to spell them out.

And from the SCDTLs side, Common Lisp lets you declare the types of variables when you want, meaning that they are assigned the "Anything" sum type by default, but you can narrow them down when required. That gives you the convenience of an automatically-specified and automatically-unboxed Anything sum type when you want it, plus the static checkability (and efficient compilation) of finer-grained types when you want them. (And Chicken Scheme's new scrutinizer and specialisation system is a rapidly-developing example of a similiar model for Scheme, too).

And there's no reason why the SCSTLs can't come further, with an inbuilt Anything type and automatic boxing and unboxing of sum types, and more flexible type systems that can express more subtle distinctions, reducing the cases where "it's just too complex and we need to go dynamic".

Then we'll meet in the middle, and the only difference will be that SCDTLs have a syntax where type declarations are optional and default to Anything, while SCSTLs have a syntax that makes you declare types, even if they're Anything. They'll largely become interchangeable, and instead, we'll compare languages' type systems on a different scale: how complicated they are.

You see, Haskelll's type system can be hard to understand. It's quite complicated, in an attempt to be able to statically describe all the sorts of cases where people might wish they had a SCDTL instead. The development of type systems has largely been one of dealing with this; starting with things like generic container classes, then getting into complex stuff about being able to make the types of parts of a product type dependent on the values of other other members and whatnot, fine-grained types such as "odd integer", and so on. As SCDTLs gain the ability to declare types, they tend to start off with quite simple type systems, as it's easy to "just go dynamic"; they're initially happy to put in a bit of typing to speed up inner loops of numerical code and to tighten up error checking on interfaces. While languages without easy access to an Anything type rely on having a type system that can express lots of things, because it's a real pain when they have to escape it. But if they meet in the middle, the tradeoff will, instead, be one of a more complete type system that lets you check for more at compile time and gain more efficient code generation - versus the mental burden of understanding it.

I suspect that Haskell is, perhaps, a bit too far in the "complex" direction, while the support for parametric containers in Chicken Scheme is weak (why can't I define my own complex type if I create a "set" or "dict" container implementation, for example?) - we'll meet somewhere in the middle!

[Edited: Clarified the initial paragraphs a bit]

Getting kids into programming (and what the Raspberry Pi is lacking) (by alaric)

Back when I were a lad, if you bought a computer, you'd bring it home and plug it into the telly and turn it on and a BASIC prompt would appear.

Tough luck if you wanted to do practical tasks like word processing, but you could type a single command (such as CIRCLE 100,100,50) and be instantly treated to a circle appearing on the screen. Before long, my generation were writing programs to crunch numbers for our statistics homework, and lots and lots of games. And thus a generation of software engineers was born.

Getting started in programming is trickier for the contemporary twenty-first-century child; they have to install a software development environment (their computer probably didn't come with one), and then go through a wizard to Create New Project, write initialisation code to open a window, then write a redraw event handler that takes a graphics context and draws a circle with it. A little less approachable than "CIRCLE 100,100,50". At least you get a simple word processor and a Web browser out of the box, though... I'm no nostalgic Luddite 🙂

Now, the Raspberry Pi has been widely hailed as the answer to our woes; costing just twenty pounds and usable given access to a TV and a dirt cheap USB keyboard and SD card, it's cheap enough to be purchased and given to a child to play with, unlike Mummy's laptop. Also, it has a user I/O port, meaning it should be relatively easily to integrate with home-built robots and other such fun electronics projects.

However, that's just the hardware side. What's seriously lacking is the software. If you buy a Pi and install one of the available Linux images onto an SD card and boot it up, you'll be presented with a Linux desktop environment. You'll be able to get to a shell prompt with little effort, and start learning shell, or get into a Python prompt and start to write Hello World, but that's not incredibly inviting; the effort required to do anything interesting from there is quite high. In particular, getting graphics going is hardly a job for a beginner.

So, I set out to improve on this situation. I've written a turtle graphics engine on top of Chicken Scheme, called Simple Graphics. Installing it is often painful as you need to get all the required bits of SDL and Cairo installed, but once that's done, thanks to Chicken's excellent egg system, installing simple-graphics is easy. And once you've done so, it's just a matter of:

(use simple-graphics)
(forward 10)

...to get started with drawing things on the screen.

However, that initial installation pain can be bypassed by making a Raspberry Pi image, based on the existing excellent work on basic Linux distributions for the Pi, that has Chicken and simple-graphics pre-installed, with a desktop icon to fire up a Chicken prompt with the simple-graphics library already loaded so you don't need the use line. But then I'd also like to add Chicken eggs to drive the I/O port on the Pi, including I2C and SPI. And sound generation, so you can make noises to go with your graphics while driving a real robot turtle through the I/O port...

It would also be good to have a version that boots straight into a full-screen Chicken prompt (which, if you start doing turtle graphics commands, splits into two, a graphics area that can be hidden/revealed/made full screen with hot keys, and the command-line area), for people using small screens.

That way, kids of all ages could immediately have an interactive environment that lets them program the full range of capabilities of the Pi. And being based on Scheme, it wouldn't be a "dumbed down" environment they'll grow out of and have to learn a new language in order to do more powerful things; they'll be able to use all the Chicken Eggs available, as well as being able to write their own code in a language eminently capable of the full range of programming tasks - yet still simple enough for anybody to get started with. Sure, I could have based Simple Graphics on Python or Ruby; but anything they can do, Scheme can do better.

ORG-mode and Fossil (by alaric)

I'm always moaning about how I have too many ideas and not enough time, so it's quite important to me to manage my time efficiently.

My biggest concern, with many projects on the go at once (and I don't just mean fun personal projects, I'm including things my family depends upon me for as well), is that I'll forget something important I'm supposed to do. And I'm also concerned that I'll forget a fun personal project, so that when I do get a moment, I can't think of anything to do, or that I spend my time on something that doesn't get me as good a reward for the available resources as I could have had.

Therefore, I've always been a big fan of "To Do" lists in one form or another. I've tried a few apps to manage TODOs for me, from the excellent personal information management facilities of the Palm Pilot to Things on the Mac, but I've tended to find such things restrictive. For a long time I had a complex OmniOutliner setup that also computed my timesheets with AppleScript, which suited me well; indeed, I've still yet to completely migrate all of the content out of that file (tricky now I no longer have a Mac, but I've looked at the underlying XML file and it seems reasonably parseable), and I think it still contains some notes about ARGON that I've not written up anywhere else!

However, I've had the most success with text files, adding hierarchic structure with headings, so it was fairly natural for me to try Org Mode one of these days. For those not in the know, this is an Emacs package designed to help you organise things with hierarchically-structured plain text files. You write heading lines prefixed with an asterisk, indicating the level of nesting by adding more asterisks, and Org helps by syntax-highlighting the header lines, hiding entire subtrees so you can see the large-scale structure, editing operations to cut and paste entire subtrees (properly adjusting the levels to match where you paste the subtree too), and so on.

But that's just the start. That's what it inherits from the Outline Mode it's based on.

What Org Mode adds on top of that is really hard to list. You can add workflow tags (TODO -> INPROGRESS -> STALLED -> DONE, for instance; you get to define your own little state machine), along with optional priorities, to mark some headings as tasks requiring attention (and obtain a report in the "agenda view" of all headings in certain states, ordered by priority, for instance). You can attach tags to headlines (and use them as filters in the agenda). You can attach arbitrary key-value metadata lists to headings (which are folded down into a single line, and opened up on request, so they don't clutter it), and use those to annotate things with deadlines, or scheduled dates, and have a calendar view in your agenda. Or use the key-value properties to filter the agenda view. Or have Org Mode automatically record a log book of state transitions of a task in the metadata. Or take metadata keys out and display them as extra columns in the hierarchy of headings, in a manner reminicent of OmniOutliner. You can embed links to other files that can be opened in Emacs; if it's an org-mode file you can link to a heading by a unique ID, or you can link to any old text file by line number or by searching for nearby text. There's a feature you can use, while editing any file, to create an Org-Mode heading containing text you are prompted for and a link to the place you were at in the file you were editing, timestamped, inserted under a specified heading of a specified org-mode file, so you can trivially create tasks referencing the file you're working on. Or you can embed executable elisp code to perform arbitrarily complex operations.

I'd been using Org Mode for a while, but I wasn't really using it properly; I had a whole bunch of .org files for different areas of my life, but it was sometimes difficult to fit things into the taxonomy. However, lately, I've had a big tidy-up of my home directory.

I've migrated old projects from Subversion or Git into Fossil, for a start, so now all of my projects - open-source ones at Kitten Technologies, and personal ones, are in their own Fossil repos, which means they have their own ticket trackers for their individual tasks. But each and every one of them has a heading in my new single tasks.org file, which is a unified repository of things I should, or would like to, think about. Fossil projects have a single heading, tagged with "FOSSIL", that lists the place in my home directory where I have the repo working copy, and the URL of the master repository on my server; ŧhis exists to prevent me from forgetting about a project.

I've migrated our long-standing home wiki (mainly a repository of recipies and other such domestic stuff) into the inbuilt wiki of the Fossil repo I already use to store documentation about the house, such as network configuration, a PDF of the plans from the Land Registry, and stuff like that; and the ticket tracker in that repo is now the domestic TODO list. Running the Fossil web interface for that repo off of the home fileserver means that Sarah and I can share the Wiki and task list. And I've configured the Fossil user roles so that anonymous users can't see anything too sensitive.

So in general I've moved as much as I can to Fossil repositories, combining versioned file storage and ticket tracking with a wiki as appropriate; and my tasks.org exists to act as an index to all of them, and to store actual task list items for things that don't naturally map to a fossil repo, although I may find ways to deal with those as well (for instance, I have a fossil repo I use to store my org files, encrypted password database, household budget, address book, and the like, that I'm not using the ticket tracker on; that could be used as a place to put my general administrative tasks as tickets).

However, although putting tickets in the repositories that store individual projects is conceptually neat, and allows for third parties to interact with my task list for open-source projects on Kitten Technologies, it does mean that I have a lot of separate task lists. tasks.org means I won't forget about any of them, but I still have no simple way of knowing what the most urgent or interesting task out of all of my twenty-five repositories is. That's not a great problem in itself, but the next logical step will be to use the automation facilities of Fossil to pull out the tickets from all of my repos and to add them into tasks.org as tasks beneath the corresponding Fossil project heading (including the ticket URL so I can go and edit them easily), so I can see them all consolidated on the agenda view...

Part of this process which has been interesting, though, is digging out various old TODO lists (such as the aforementioned OmniOutliner file) and project directories scattered over archives of old home directories and consolidating them. I've found various projects I'd forgotten about, and neatly filed them as current projects or into my archive tree as old projects (and, oh, how I look forward to being able to put things like that as archives into Ugarit, automatically cross-referenced by their metadata...). Having brought everything together and assembled an index reduces the horrible, lingering, feeling of having lost or forgotten something...

Turing Centenary (by sarah)

Alan Turing one of the most important people in the history of the computer would have turned 100 today if he had lived. Though the chances of living to 100 are not great Turing didn't even manage to get as far as he should have.

It is occasionally argued about but it is considered that he committed suicide due to being hounded by the powers that be and given chemicals to subdue his sex drive. The reason for this was that he was Gay and in 40's and 50's being homosexual was not just illegal but thought to be a security risk.

Alan was faced with the choices of chemical castration or prison and exclusion from his work. He chose the chemicals. They had nasty side effects but he seems to have taken his treatment mainly in his stride.

Mr Turing wasn't just a mathematical genius he was a war hero having worked at Bletchley Park during the second world war cracking codes and thus saving at least allied lives. He is most often mentioned in association with the enigma machine.

His contributions to modern computing are huge and he is considered one of the founders of the subject Computer Science.

His achievements are great and yet the first time I heard of him was when I picked up one of Alaric's computing books after our move to Gloucestershire. It is strange that like Ada Lovelace he seems to have fallen through the cracks some what. And worse than that his centenary year is plagued by arguments of how to portray him.

Is it good or bad for those on the autism spectrum to know of him and so on. If he had been alive to day he would have probably been diagnosed with Aspergers syndrom but why is this a problem? Yes that was a facet of his personality but that is all. Use him to show others in the same situation as him that they can achieve by all means but that is not what is happening - I think there needs to be a gear shift in society. After all with the modern world lets face it the Geek shall inherit and that is all geeks, the meek, mild, argumentative, know it alls and the distracteds.

His achievements are his and he should be being portrayed as a founder and hero to everyone and I mean everyone. I will twist Alaric's arm into writing a blog post about Alan's achievements.

We made a Turing Machine Cake and drew the shamefully bad picture at the top of the post.