Writing and programming: the act of turning an idea into reality

A curious thing happend recently. Primo* (the eldest child, 4.5 years, going on 45) handed me an iPad and asked where her favourite game had gone, Peppa Pig Party Time

I knew immediately “where” it had gone. Secondo (the youngest child, 2.8 years, going on 1) likes holding the home button, making icons jiggle and then randomly deleting them while laughing hysterically.

No matter though. It’s easy enough to re-install them on the iPad – or you can just “write it”

Writing and programming: making things real

Primo has connected that the verb ‘write’ can be used to mean ‘create’ or ‘make’. She will spot it’s missing and say, “that’s ok Dad, just write it” or “please, can you write it.” or “can we write this game”.

She knows that my job is primarily “making computers do things” and she’s been watching what that is, which externally is seen as the act of writing/typing – after a lots of serious thinking of course 😉

The gap between typing something and having it appear is unknown to her right now, and to some degree irrelevant, but what is particularly interesting is the association that writing can yield the creation of something digital, tangible and that hopefully plays Happy Mrs Chicken (It’s a Peppa Pig mini game for those of you lucky enough not to be sleep deprived from young kids demanding ipad apps during the night!)

Tying this back to one of the central underpinnings of Papert’s Mindstorms book, it’s becoming clear that the language we choose to convey metaphor is crucial to the novice programmer if we are to help excite and encourage people to become creators with technology.

If we check the language we currently use we find many examples which aren’t clear or just anachronistic as we’ve been too lazy to think of a better replacement. For example I have an ongoing issue with the word “Loading” especially when I see it in the middle of a video game screen on a PS3, pad, etc.

What on earth does “Loading” mean to someone who didn’t grow up with 8-bit micros and BASIC?

Papert describes the connection of Logo’s Turtle to the creation of words to encourage programming abstraction

The idea of programming is introduced through the metaphor of teaching the Turtle a new word

The idea of programming is introduced through the metaphor of teaching the Turtle a new word. This is simply done,
and children often begin their programming experience by programming the Turtle to respond to new commands
invented by the child such as SQUARE or TRIANGLE or SQ or TRI or whatever the child wishes, by drawing the
appropriate shapes. New commands once defined can be used to define others.

The key factor here is that Papert’s Logo puts the creative power of abstraction, through the creative use of language which comes naturally, into the hands of the child, they can use whatever word they like.

Primo* -I know the gender is wrong but I’m a big fan of Stanley Tucci and Big Night.

Super Hexagon Kid: Children don’t always want super cute and simple games

This really surprised me. For those of you that have played Terry Cavanagh’s Super Hexagon you’ll know how hard it is.

What you might not know is kids love it. Here’s a pic of my four year old daughter having a quick session before school. I watched her play, she’s pretty good and what’s really interesting is you can see her working out different strategies on this maddeningly addictive and unforgiving game.

photo

Reading, Writing, and Programming: Mitch Resnick at TEDxBeaconStreet

Reading, Writing, and Programming: Mitch Resnick at TEDxBeaconStreet

Here’s a fantastic video of MIT’s Mitch Resnick talking about why kids (and adults!) should learn programming as well as reading and writing. As director of the Lifelong Kindergarten group at the MIT Media Lab, Mitch Resnick designs new technologies that, in the spirit of the blocks and finger paint of kindergarten, engage people of all ages in creative learning experiences.

Unix Runes For Those Playing With Servers: Part 1 How to mysqldump all databases on a server

How to mysqldump all databases on a server

Yes, this is a little digression from the usual gaming/educational programming posts but I wanted to jot a few “runes” down for those playing with servers – assuming you’re using a *nix server – this one looks is for anyone that wants to mysqldump all databases.

Sometimes you need to move your MySQL database to another machine, this little rune ‘mysqldump all databases’ will dump everything out into a single file which you can then import into the new machine. Watch out, this could be quite large so you can also compress (gzip) the output (just enter ‘gzip dumpfilename.sql’ and it will turn dumpfilename.sql into dumpfilename.sql.gz)

The dumpfile that is created by MySQL should include all the necessary create database instructions and maintain the encoding that was specified with the database and corresponding data.

mysqldump -u USERNAME -p –all-databases > all_my_dbases.sql

This will ask you for USERNAME’s password and then create the file in your current working directory.

How to mysqldump a single database

You can use a similar rune to dump out a single database e.g.

mysqldump -u USERNAME -p DATABASE_NAME > DATABASE_NAME.sql

Restoring all the database

The following will take your dump file and “insert” it into the MySQL database server. Warning, if you already have databases with the same name, they will be overwritten by this action.

mysql -u USERNAME -p < all_my_dbases.sql

Restoring a single database

The following will take your dump file and “insert” it into the MySQL database server. Warning, if you already have databases with the same name, they will be overwritten by this action.

mysql -u USERNAME -p DATABASE_NAME < DATABASE_NAME.sql

Powerful Ideas in Mind Sized Bites

Reading Papert’s Mindstorms book the phrase ‘Powerful Ideas in Mind Sized Bites’ is repeated several times throughout and gradually you begin to see why learning programming is potentially so useful a ‘tool’ for children (and adults). That is, because learning to program provides skills and tools that are useful beyond the discipline of programming. It is not that we want to create a nation of developers, though some have that agenda, it’s that learning it can help you with other non related subjects.

It helps us to break problems down into ‘mind sized bites’ and learn how to ‘debug’ our solutions. That is, when we’re confronted with a large problem, if we’ve been exposed to learning via programming, we are not over awed by the problem’s size. We know that we can break it up, divide and conquer it using decomposition. This technique can then be used in the “real world”

What’s interesting is that he gives ample examples of children as young as 6 demonstrating this learned skill, something I only remember learning when I was 18 at University. Papert highlights that Computer Science is really now the science of software but in essence Computer Science is doing a great job at classifying these approaches, giving them words which allow them to be assimilated into our culture. e.g. input, output, debugging, looping, feedback, etc

The second interesting skill that stems from breaking things into these mind sized bites is the skill of being able to debug your own solution – even one that’s perhaps a mental solution in your mind. The idea being that now you have small morsels of solutions strung together to solve a much larger problem, a ‘bug’ in one of your small pieces is easy to spot and fix.

Powerful Ideas in Mind Sized Bites

If you’re a programmer you’ll be familiar with that horror of horrors, ‘monolithic code’. Monolithic code is a large, seemingly never ending slab of programming instructions. It is not in ‘mind sized bites’ and doesn’t make use of abstraction to make it ‘readable’. Papert argues that we display similar organisational traits in our minds and those who can decompose and abstract their solutions are also better at coping with revising their solution if they don’t get it right first time.

Here’s a nice picture of monolithic versus modular:

mind sized bites - monolithic versus modular

Abstraction is a technique that is positively encouraged in Papert’s LOGO and gives the child insight into the rewards of debugging. By spotting patterns in the solution, e.g. a few lines that draw a Square, the child can create new ‘word’ e.g. Square and then abstract their mind size bite away into that word.

Powerful stuff!

“Above all else, always show comparisons” – Edward Tufte

Minard Map of Napoleon's March by Charles Joseph Minard

This is the “Minard Map” made famous by Edward Tufte. It illustrates the futile march of Napoleon into Russia and back. The main line shows the ever decreasing size of Napoleon’s army as they encounter obstacles and the ever hardening environmental changes.

Tufte uses this map to re-enforce one of his main tenets by highlighting the far left of the map:

“it is there, at the beginning and at the end of the campaign, where we have a small but poignant example of the first grand principle of analytical design: above all else, always show comparisons.”

Between Bret Victor’s notion that we should “follow a principle and not a dream” and Tufte’s “above all else, always show comparisons” that seems to be a pretty decent launch pad for the design of our kids coding tools.

Teaching Children Algorithms: Update February 3rd 2013

The past weekend I decided to start teaching my four year old daughter algorithms. I astonished how quickly she picked up the concept. So much so that it go me thinking of Tufte again in terms of writing a small algorithm app in the LOGO vein. As we talked about it, it was obvious that the way she was relating to the idea was through what she loves, painting. And that this was also a great way for her to ‘test’ her algorithms so she could “see the comparisons”. It’s a great boost for returning to LOGO and in particular, seeing if we can provide a simple HTML5 version.

Does the fact that we need Developers tell us that our interfaces for programming are not good enough

I’ve been thinking a lot about the root of the problem that I’m trying to solve. That is, making it easier for children to understand how to program computers and I’m coming to the conclusion that it doesn’t have to stop with children.

One of the most important reasons why I think “programming” a computer is useful is that you can use it to create solutions to problems: e.g. make an animation for someone’s birthday, create reports to find out why some of your customers are leaving, modelling a bridge and seeing it under the stress of high winds, seeing what a new colour paint would look like on your bathroom walls, etc. The length of that list is only limited by our imaginations and our ability to articulate it to a computer.

Being able to write or modify programs gives you the power to solve your own problem. That’s an incredibly empowering and liberating thing, particularly if you do not have the resources to ‘buy’ a solution.

To help me understand how we can approach teaching this, I wrote a list of (rough) axioms about programming and learning (bourne out of some recent readings by the leading people in this field, such as: Seymour Papert, Alan Kay, Ralph Knoster and Bret Victor.)

Axioms for learning programming

What was interesting was the final rhetorical point it ended on:

“Does the fact that Developers exist tell us that our interfaces for programming are not good enough”

By this I mean has the formal role of the developer only arisen because computers are not easy enough to use, as tools.

I keep thinking of my good friend Evan Rudowski (@evanrud) who I worked with at subhub.com. Evan is the CEO of Subhub – they sell a paywall/membership publishing platform that allows the publisher to restrict access to their premium content. Evan’s a pretty remarkable guy with a impressive career in journalism and Internet Publishing (he came from America to run Excite Europe in the late ’90s and ended up staying!) but I think he’s a product developer at heart, only he’s never learned to ‘develop’ aka write code. So in order to run Subhub and develop products he has to hire developers, which is logical, and therein lies the principal problem I’d like to solve.

I want anyone with a creative idea to be able to implement it themselves on a digital device.

Perhaps not to production level (well, not yet anyway), but enough to test out new ideas, play with them, prototype them, make toys to play with, show them to clients, get feedback, etc. That is, at a level good enough to for the person with the idea to get immediate feedback which they can be use to develop further (or not).

Going back to Bret Victor and the previous post on Inventing on principle, that’s the principle behind this project and one I think worth striving for: that is, to provide anyone with a creative idea the resources to learn how to implement them on a computer

Inventing on Principle – Presentation by Bret Victor

Here’s a wonderful presentation by Bret Victor @worrydream talking about the “principle” that he follows throughout his work, as opposed to following a “passion”. With regard the previous post about developers been great teachers Bret’s a wonderful example of this 🙂

Bret’s principle is that he wants “creators to have an immediate connection to what they are creating” i.e. if they make a change they can see it instantly. If we think about that in context to programming (and especially teaching children) it’s a very powerful principle. That is, the creator can see what they are creating and a modification to it is an instantaneous, visual piece of feedback.

What I love about this presentation is he’s using live coding to demonstrate this and it’s probably best to just start watching to see what he means …

Bret Victor – Inventing on Principle from CUSEC on Vimeo.