Jean Programming Again :) (by sarah)

So I resigned myself to the fact that Alaric would turn the new TV into a giant computer screen.

Of which my main concern is that he will work on it rather than going down to the 'lab' to work, but instead he set things up so Jean could play with Turtle Graphics which is a new version of an old thing he has implemented. Basically she has to actually programme in order to get a little turtle to draw. She has produced me some lovely flowers and a house and things 🙂

The pictures she's created are on Al's laptop so he'll have to pop them on here when he gets a spare moment (haha). She is using Chicken Scheme and using a programme called Simple Graphics which is what Al created initially though I believe it is open source and others have since added stuff 🙂

She also started to 'compose' scenes for photography today - which was a shock to me!

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.

Vomit-induced implementations of the 9P protocol in Chicken Scheme (by alaric)

Last Saturday, I came down with what I suspect was Norovirus - the rest of the family (apart from the baby) having come down with it on Thursday and me having spent the past few days mopping up after them, this was probably unavoidable; although I'd tried my best by wearing a respirator when performing clean-up operations (it was also nice to not have to smell what I was clearing up...).

But, it meant I spent Monday off of work recuperating. I was too weak and exhausted to do any work from home, but I was bored senseless of just lying there on the sofa, so I decided to try and extend Chicken Scheme's 9p egg, which is a client implementation of the 9P2000 file server protocol, to also be able to act as a server.

This is something I want for Ugarit; it means that a Chicken Scheme app will be able to provide a virtual filesystem that can be mounted from a computer and used like your "real" filesystem. In particular, I want to be able to let people access their backed-up snapshots from a Ugarit vault as a live read-only filesystem, rather than needing to go in and manually "restore" their desired files back into the filesystem to access them. And it'll really come into its own when I implement archive mode, as it will make it possible to actually use the Ugarit archive seamlessly.

Unfortunately, being rather fuzzy-headed, I kept making rookie mistakes, but I eventually managed to get the core protocol implementation working. In doing so, I found out that a 9P server that puts incorrect lengths in the stat structures returned from directory reads causes 9P mounts in Linux to "hang" in a way that can't be unmounted and you need to power-cycle the machine as it won't even shut down cleanly... so be careful of that when mounting the few public 9P servers out there!

In order to test it, and as a utility for Chicken apps that would like to provide a 9P "control/status filesystem" in the manner of wmii et al, I started to write a simplified high-level virtual filesystem server library on top of the core server implementation. At the point where I made this status update to my friends in the Chicken Scheme IRC channel, directory listings weren't working (they now are), but you can see the idea - create a filesystem object from Scheme and register files and directories in it, and it appears as a live filesystem under UNIX.

Now I'm feeling a bit better today I've realised several other rookie errors I've made (not ones that cause bugs, I hope, but ones that complicated the code unnecessarily) - I'll fix those up before I submit all of my changes to the 9p egg's maintainer for merging in...

Then it'll be time to start on the Ugarit integration. THAT will be fun 🙂

Alaric’s projects for this year (by alaric)

This year's going to be pretty busy with settling into the new home, but I have a few projects.

1. Finish the ring casting I nearly finished before the move. That's a priority.
2. Resurrect my aluminium foundry. In particular, it's our bronze wedding anniversary, so Sarah's going to design a pattern for a sundial, which I will cast in Aluminium bronze, a nice alloy that I can make myself from my scrap aluminium and bits of old plumbing...
3. Continue with minor stuff on Ugarit, but as a milestone, build the distributed storage backend, which will rock.
4. Work on my wearable computer project. No specific milestone for this, as it's currently a long drawn out research/prototyping phase as I sort out many details.

Wish me luck... I usually suffer from "all my weekends getting eaten up", but as my New Year's Resolution has been to spend at least one day every two weeks doing something fun with my children, I'm going to be booking weekend days in my calendar in advance through the year for that and my own projects. Before they get filled up!