in the physical world you have build-in constraints that help you out, in the software world the only laws that apply are the laws of imagination. (richard gabriel)

most of the programs are "technically turing complete", but we hardly make use of it. turingcomplete (foo/bar, 568 KB)

programs don't care about things like beauty of code. they don't even need to proof steadiness as their fleshy partners keep the good practice of "there is a life outside the screen" ( as tom sherman advises his computer in one of his videos). they also don't follow ego-trips, search for a diva spot nor morality. to proof to be better is not a machine constraint.

what richard gabriel tried to do in his talk is as simple as - in my opinion - effective; even it depends of the will of the audience; something i am not too sure about, concerning the munich crowd; not too many seemed to have that much fun that i had. - well, i am not a programmer.

anyhow, his line goes like that: to try to consider an ultra large scale system, impossible design, can help to see things differently. it can be an eye opener, allow a brain to twist. - the word "impossible" should probably make it easier to realize the constraints of old habits and behaviour. some would call it a cheap trick, but after all it's not a bad one.

one of the problems he identified in today's code production is: abstraction (foo/bar, 796 KB) : "abstraction is about ignorance", he already wrote in his book PatternsOfSoftware, quoting bas van fraassen and paul feyerabend.

there is nothing like abstracting over time (foo/bar, 540 KB) which leads to a system that - compared with the real world - would mean that "if you go to the beach, you would need a place in your brain that let you remember that you went to the beach".

he also criticises the way people are taught to think about modularity (foo/bar, 938 KB) . aspect oriented programming maybe will bring a change, he says.

sometimes a user can have a strong argument with a programmer about correctness. kind of leaving the ugly taste in ones mouth, that programmer's imagination about what kind of behaviour is correct and what isn't doesn't go further than this often quoted sentence: user = loser. (google will let you find out what that means). the root of this common behaviour maybe goes back to programmers own constraints to think digitally, black and white. what a phobia. anyhow, correctness (foo/bar, 587 KB) is another field richard gabriel identifies as a burden and asks for a variation: a bug can be bad, but doesn't always have to be. just to begin with: there is a lot of software out there that wouldn't function at all without it.

analogies to other species can easily be identified.