I like nice…

I blogged (ages) ago about how ’saving’ data in a computer is a bad idea. The concept of saving something in case it magically vanishes is new to electronic systems that store state as an internal electronic representation. During all of our human evolution, we’ve been in the situation that if you do ’something to something’ it changes it a bit, and you can’t go back. Cause and effect I guess… If you’re a carver and carve too much out of a bit of wood, it’s broken. If you’re a hunter and kill something, it’s dead. No going back, no un-carving or un-killing things.

Recently entering into the common lexicon is the phrase ‘turn it off and on again’, normally describing a computer that has broken somehow, and nobody can be bothered to work out what has happened, if it’s possible to anyway. So, turning it off and on again will restore some past state in its entirety, allowing you to carry on as if nothing bad has happened. Oh look, I just un-killed a gazelle!

Is this the right way of doing things?

Smalltalk is a programming language I have a lot of time for. Most programming languages seperate ’state’ from ‘code’. So a program boots, it gets told what it is by loading some state, then it springs into life. Assuming the program could understand the state, then it’s all ready to go. Why not kill it with a big frickin’ laser? Load it again, and it’s in the same state as it was when you killed it. Over and over you can restore state. Ok, so being able to do that isn’t inherently a bad idea as it’s one of the powerful things about computers, that you can ‘magically’ change things. One of the bad parts comes when you forget to save something, or something crashes. You don’t have a problem if something is written on paper; it doesn’t inexplicably vanish before your very eyes – unless you’re a 8 year old ’spy’ with one of those ‘invisible ink’ kits.

Smalltalk, and a number of other systems, were based on an ‘image’ which stored state. Similar to a ‘core dump’ which some may have seen when their computer barfs a load of crap onto the screen in the blue-screen death throes. Except for Smalltalk images are restartable, not just debugging data.

These kind of systems did require a larger overhead, so some weren’t convinced. But what would the electronic world be like now with solid state? Anything you do is fixed, and recoverable. Turning the machine off and on again would still present you with the same state. No get out, no turning back time…

Maybe programmers would be a bit more careful when hacking away at some wood, or is having a get-out clause a good thing?

New for C# 4.0 is the concept of ‘Dynamic lookup’, which aims to add ‘dynamic typing’ support to the C# programming language. If you’re not sure on what that is, it compares to ’static typing’, where you can define ‘types’ which are checked when you compile code. Dynamic typing means no checks are made at compile-time, making the code, theoretically, much more flexible. 

Examples of dynamic typed languages are Ruby and Python, although there are a lot. It seems that Microsoft, in my humble opinion, have seen another ’shiny object’ that they’d like to add to their language spec, so they’re creating a kludge to add it. Sometimes though, restrictions are a good thing…

If you take, for example, a team of programmers that understand a paradigm. Using a different paradigm ‘just because’, isn’t generally a Good Idea(tm). I consider real programming to be a creative process, no different to painting or sculpture, and limits are always good in any creative process.

I can hear people balking at this idea, that we would impose limits for the sake of it. Well, if you had a studio and were to create some ‘art’, and somebody asked you to ‘create something’. What would you come up with? Defining limits beforehand really focuses the mind to what you’re doing, and the starting-point of; “using oil paint and canvas with only 4 colours, represent how you feel about rock music” is much more emotive, inspiring and creative.

Of course, what I mean by this glib example is that often restrictions *inspire* the creative process, not hinder it. Constantly adjusting something to be a ‘one size fits all’ dilutes it..

It’s often said that C takes an hour to learn, and a lifetime to master. C is very small in its implementation, although the power is all in its simplicity and limits…