I'm pushing out a new version of the Notebook today.

This update has been a longtime coming thanks to work commitments, but it looks like I can now get back to writing regularly and that will hopefully make up for the dearth of new content in recent years.

I know that several Notebook readers have attended talks I've given on Go over the last couple of years, and I'd like to thank them for the positive feedback they've provided. I'm finally comfortable that the material I've been demonstrating is sufficiently mature to be useful and will now start adding it to the book and building upon it to explore topics which could never fit into a 45 minute conference talk.

The first instalment is extracted from my "Going Loop" talk and focuses on iteration in collection data structures. I know this probably sounds like a very dry subject but it's surprising just how much of comp sci iteration touches upon.

I've a feeling that by the time this new chapter is completed it will be of similar length to "Hello World" so I'm cautious of setting any kind of deadline, however I'd really like it to be sufficiently complete by Christmas that I can increase the minimum price for the book by $1 with a clear conscience.

As always, please let me know if there's anything in the new material which makes no sense to you and point out any general typographic errors so I can fix them.

Expect further updates over the coming weeks :)


Post has attachment

Post has attachment
I've a couple of talks coming up in London which draw from the material in Hello World.

First up is Code Mesh, the UK's answer to Strange Loop, which I'm speaking at on Wednesday 5th November.

This is followed on Saturday 15th November by GDG DevFest at Google Campus.

Post has attachment
Thank you to all the new readers who've recently signed up for the Notebook.

Development has been stalled for the past couple of months whilst I juggle earn filthy lucre from consulting with childcare, and each additional sale makes me feel that much guiltier. However the design for the Forth interpreter that I plan to include in a later chapter is coming along reasonably well and another couple of months should see my bank balance healthy enough to take time out for writing in the New Year.

In the meantime I've rewritten the code for Echo to remove the init() bug and as soon as I can get a free day I'll work through the text and amend it to reflect the changes.

And don't forget - if you're in London on November 15th I'm speaking at GDG DevFest so if you're attending feel free to pester me for help.

Post has attachment
Okay, I'm ready to say a little bit about what's next in the pipeline. Probably most of you are expecting Chapter 2, and at some point I will write that as obviously it fills the gap between Chapter 1 and Chapter 3 :) Right now though I'm cooking up the code for a chapter on implementing the Forth programming language.

Why Forth? Well, it was the first language I learned after BASIC back when I was a teenager, and I've a tradition of porting a ropey spaghetti BASIC interpreter for Forth whenever I want to learn a new dialect of BASIC.

Currently I'm playing with the beta of AGK 2.0 which provides a particularly primitive (but enjoyable) BASIC as its dev language for writing cross-platform apps. Initially I bought a license just to help fund development and didn't expect to do much with it, but you know how these things go!

Anyway, I'm half-way through porting my spaghetti code Forth to AGK's BASIC (not having touched the previous VB5 version in at least 12 years) and in the process the whole design is really starting to clean up. Seems when I was last messing with this codebase I'd added primitive support for multi-tasking and I'm now wondering how that would look translated into separate goroutines.

This leaves me two options I'll be playing with over the next couple of months. One is to implement a simplistic version of Go's concurrency model for Forth, the other is to port the BASIC codebase to Go.

It's possible I may write a short eBook on AGK, just to show what's possible outside its usual 2D/3D game setting. Of more importance though is that I'll add a Chapter to the Notebook that will explore the design and implementation of a language interpreter for Forth in as much depth as I can (i.e. it'll be in similar vein to Chapter 1).

As Forth is a mix of a simple stack-based virtual machine with a more traditional token interpreter this should provide a good intro to writing more complex language runtimes. As an added bonus there'll definitely be concurrency and possibly general memory management as well.

The current implementation is an amalgam of the Forth 79 and 83 vocabularies but I'm not wedded to that. I may instead aim for a subset of the ANS-92 standard or ColorForth (which is relevant to modern hardware like the GreenArrays multi-core Forth systems).

I have a question about the best way to nest structures.  These are for modeling a 1980s hexmap table top wargame

type Vector struct {
  hx int
  hy int

type Token struct {
  name string
  location Vector

I want the Vector objects to be immutable.  This means that to change the location I need to replace the location Vector object.

I tried creating a method MoveTo

func (t Token) MoveTo(destination Vector) (Token) {
t.location = destination
return t

When i test the value of t.location inside the method after the assignment, t.location has the new value.

token0 = Token{"foo", Vector(3, 4}}

token0.location is still Vector{3, 4}

I suspect I need to either consistently pass Vectors as references, OR not.  I think I need to remember my C coding style and suppress some scripting assumptions.

Post has attachment
I've managed to snatch a couple of days' free time to code and am poking around with porting a QuickBasic SNES emulator to Go. There are three reasons for this particular bit of madness:

1. QuickBasic gave me a lot of pleasure in the early 90s and was my goto language for prototyping until VB5 came along, so it's a nice trip down memory lane;

2. Home-micro Basic was where I first taught myself to code, and as one of the Notebook's aims is to inspire similar interest in a newer generation I'm interested to see how QB and Go compare;

3. For the virtual machines coverage in the book I'd like to include an emulator or two as these introduce interesting constraints which don't exist for say a JVM, and as the QB-NES codebase is currently single-threaded it'll be interesting to see how its components hang together when split into separate goroutines and plumbed together with channels.

So far it's proving a fun little exercise and if successful I'll spec out a clean-room implementation of the SNES architecture and write that up as time allows.

I have another question, this time on best practices with arrays and maps.

In a scripting language if I want an array of undetermined length, no problem.  Nearly all of them have arrays that automatically extend if additional elements are appended.

I want to have an array of structs which can be variable length.

Because Go stays closer to the machine memory structures (like C) the arrays must be fixed length and must be allocated before (or at) use.

I see that maps are dynamically allocated, but all I really need is a sequential set of elements.  I don't need the full expression of a map.

I see that slices can be used as "views" on an array and so behave as if they are variable length (at least up to the size of the underlying array).

Is there a Go idiom for modelling dynamic arrays?
Go does have maps

Post has attachment
I'm going to be at Strange Loop in September so I've prepped some business card size flyers to promote the book. The code's the same runnable example as on the front cover which probably isn't so clear here (photo taken with iPod 4) but on the cards it's very clear and readable.

Writing has been on hold for the past week or so as I've work on for a client, and it's looking like August will be a fairly busy month as well: another client looking to get a spec drafted and the school holidays means I'll be juggling paid work and the fraught experience of herding a 5 yo full time. Things should ease up after that.

On the plus side the client work should see my bank balance healthy enough for an extended period of writing, and some of the architectural intricacies are starting to give me ideas for the next couple of chapters. These will develop the themes laid out in chapter one by adding interactivity.

In particular I want to start building up the skeleton of a secure web application as I know this is something that many current readers are interested in. But I want to do so in a manner that allows the same basic architecture to be used for any kind of distributed application: web, socket or IPC.

This is really the meat-and-potatoes of continuing sales once I shift to the more avant garde areas I've outlined for later chapters. And don't worry, there will still be the occasional bit of mad code working its way into those as I've time to play and do research.

My current aim is to have chapter 2 reasonably well fleshed out for late August or mid-September with everything through the end of chapter 3 completed before the end of the year.
Wait while more posts are being loaded