dissabte, 21. de gener 2006

build-in constraints

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.

... Comment

Online for 6351 days
Last update: 24/08/17 19:06
Youre not logged in ... Login
... Home
... Tags

novembre 2018
recent updates
aus gegebenen anlass damals märz,
2002 en barna ... |
by motzes (07/07/17 13:33)
rksv Bin gespant wie es
mit den Paragons nach dem 1. April aussieht. findet sich...
by Christoph Schachner (27/03/17 11:18)
stupidity revisited ah, finally some
parts are back: by Giancarlo Livraghi older version:
by motzes (30/01/17 23:18)
albots the difference of ai
today: authors don't hide that they have more questions than...
by motzes (20/12/16 09:28)
ai , via EPSRC
towards "social interaction": constructivist A.I. approach: replicode tutorial:
by motzes (04/04/16 12:37)
gut so! danke.
by motzes (08/02/16 13:21)
Btw heute hierüber gestolpert:
by tobi (08/02/16 11:47)
early devices and ideas nice
and humorous history presented by j.c.r. licklider in the 1980s...
by motzes (07/02/16 10:36)
paragon beim lesen von texten
von finanzbeamten stösst man auf worte, die schön sind, aber...
by motzes (18/09/15 23:07)
if-when, what-if there is a
so called "". done by human who work on machines...
by motzes (11/08/15 14:33)

RSS Feed

Made with Antville
Powered by
helma object publisher