A new specification format

It’s time for another rushed-off-my-feet debrief. I wish I had more time to spend on these each week, but it looks like once every three weeks is about the best I can achieve during the semester. Time is a-ticking, and the grades aren’t going to earn themselves.

Bedrock specification, rev. 3

This new third revision of the specification is going really well, it’s finally looking like something that people will want to read. I’ve so far completed the core specification, assembler specification, program metadata specification, and I’ve gotten a start on the device specifications.

A new format

My difficulties with the device specifications in the past have been to do with making them readable without either repeating whole paragraphs or forcing the reader to jump between multiple sections as they read. A lot of devices contain identical behaviour across ports: the memory device contains two identical read-write heads controlled by each half of the port space, the clock device contains four identical 16-bit timers, the input device contains ports for four identical game controllers, that sort of thing.

My earlier solution to this mess was to structure each specification using two subsections, one to list the ports and one to list the abstractions (like text buffers and sprite formats). This worked fine in terms of specifying things, but it meant that the reader was expected to jump around between sections while reading, which was a pain.

I spent some time coming up with and testing out a bunch of alternate formats to improve on this situation, and I’ve finally come up with something that’s concise, easy to read, avoids repetition, and also makes the whole dynamic with ports, port groups, and port aliases a lot clearer. The new approach is to explain the abstractions in full paragraphs up front while also explaining at a high level how the device works, and then afterwards to list the port groups and what they do. With this format, I can offload the denser explanations to the high-level overview, making the port descriptions shorter and easier to follow. It’s also just so much more enjoyable to read this new format from top to bottom. You can see a good example of the format in the new memory device specification, which is the only one that I’ve completed so far.

I’ve also been able to do away with the ports tables entirely, because I’m able to write out all of the port mapping information with just plain sentences. I’ve wanted to remove these tables for a long time — they add a lot of visual clutter and up-front complexity to the specification — but I just hadn’t been able to figure out how to convey the same information with just plain text until now.

Sneak peek

The current draft specification is here if you want to take a peek. It’s a bit messy because it’s the same working document that I’m typing into every day, but I figure that if you’re following my work then you’re probably interested despite the mess.

Velocity ideas challenge

I’ve spent a bit of time thinking more on the ‘Velocity ideas challenge’ that I talked about last time. I’ll be submitting my entry for next year, so I’ve got a whole year to work on it, but it’s something that’s been bouncing around in my head a lot recently. My main problem has been with figuring out how to turn my vague ideas into a compelling business case.

Looking for a target audience

I’m wanting to aim for the education category, selling Bedrock as something that’s good for teaching young people how to program, but I need to build a solid case for this. The current meta for teaching programming seems to be to start with a block-based language like Scratch, usually in combination with a hardware system like the BBC micro:bit or a small wheeled robot with lights, and then to jump from there straight into Python or HTML/CSS/JavaScript, with the transition point being somewhere around ten or twelve years of age.

There’s not much room in that setup to teach a novel programming system. The problem that I feel I’m having is that Bedrock isn’t a mainstream system, the design is quite different from the usual way of doing things (by design, more or less), and so there’s a friction when slotting it into a pathway that’s aimed at teaching people how to use mainstream programming languages for future employment.

I can’t replace Scratch, there’s no way that a textual programming language will be able to outcompete a colourful drag-and-drop language for young children, and I can’t really replace Python and JavaScript, because people want to learn them because they’re ‘the big languages’. I think, though, that there could be an opportunity somewhere in the middle, where someone is old enough to be interested in a textual language, but young enough that they haven’t yet been gripped by the gravitational pull of industry. Bedrock can slot into the space where a young person just wants to make a game or some other graphical program, but doesn’t yet have the stomach for Python or JavaScript.

High school computer science

I spent an evening this weekend diving into computer science standards in the NZ curriculum to see if I could find places in high school that Bedrock could slot into, and it looks like it isn’t entirely hopeless (this is the NCEA curriculum I was looking at, not the new one that’s being worked on, but it’ll probably be much the same in the end).

Starting from level 1 (15 year olds), the standards are based around developing a program or ‘digital outcome’ (any digital product, such as a game or website), which is assessed against a set of fairly high-level criteria. For a program, for example, the criteria involve ‘using succinct and descriptive variable names’, ‘using conditions and control flow effectively’, and ‘documenting the program with comments’, so any standard iterative programming language could be used. The challenge is in convincing schools or students to use or learn a different system that isn’t used in industry, when most schools are probably stretched as is with providing these courses.

Advantages of Bedrock

I think that the comparative advantage for Bedrock is in the following three points:

• The language (Peak) will be far simpler than Python or JavaScript, so it’ll be easier for a beginner to learn. Python is great to learn until you want to do anything other than string manipulation or printing to the terminal, and then you’re thrown into the world of classes and modules. In comparison, graphical programs will be able to be created with Peak using a small built-in framework, and drawing to the screen will be at least as easy as in PICO-8.
• The Bedrock system is lightweight and ultra-portable. Programs can be turned into lightweight native executables or run inside a web browser. Even the weakest Chromebook will have no issues with running the development tools or finished programs, which means that students can learn the system using what they’ve already got.
• The same programming system can be used to teach basic programming concepts, to make games and graphical user interfaces, and to control robots and other electronics projects (in conjunction with a custom GPIO device and basic hardware).

The handheld console that I’ll be proposing as the product for the challenge can be used for all three types of program, but the most salient will be the electronics aspect. Teaching programming by controlling little robots is really popular. The micro:bit seems to be incredibly popular, but you can’t really do much with it other than a few gimmicks like reading accelerometer data or blinking a few LEDs. Bedrock can be taken way further in order to make any kind of program, and the hardware system isn’t going to be that much more expensive than the micro:bit for what it can do (maybe $75, compared to $40 for the micro:bit).

Future work

I want to dig into the literature around methodologies of teaching computer science to young people, so see if I can find support for the angle I’m aiming for. I’m particularly interested in finding studies about the efficacy of block-based programming languages over textual languages, and about the benefits of teaching, say, command-line programming versus robot programming. I have a hunch that developing programs that you can run on a little handheld thing and can control robots would lead to better outcomes than ‘problem-solving programming’, but I have no idea in practice.

The other thing that I want to do is to start putting together the proposal itself. I’ll need to figure out how to condense all of this down into a few hundred words, and I’ll also need to start doing market research and all of that good business stuff. I might start locking down the hardware plans for bedrock-pocket as well and make a project page for it.

Thanks

Thanks for your patience with my slow posting, the uni work is piling up at the moment but it’ll all be done in a month. I’m looking forward to sinking more time into this stuff, the new spec format is making it easy to chip away an hour at a time on the new revision. Thanks heaps for supporting me, I’ll catch you next time!