conway's law: any organization which designs a system will inevitably produce a design whose structure is a copy of the organization's communication structure.

computer scientists follow the salami slice tactic, says richard gabriel. it appears to them to be 'natural' just to accept papers that differ the least. yet "their work must continue ... thefoundation (foo/bar, 472 KB)

one can't blame tony hoare of doing that. his project the verifying compiler doesn't sound like a small slice. i am still not sure if he got all the money yet, even there are some indications that he might be on track.
tony hoare wants to dedicate 15 years of research to find a way to fix bugs. - that's the time span of grand challenge projects by definition. (one might say since the genome project, i don't know.) in short: he wants to deliver a database with code for further use: tested and deemed as correct to start with.

Premature optimization is the root of all evil in programming. C. A. R. Hoare (quoted by r.garbiel in ArtOfLisp)

according to him "software works because people designed it to work; over time hard- and software has changed, but what remains is the old (foo/bar, 684 KB) code. "we now have to look at the remaining code as if it were a natural phenomenon (foo/bar, 621 KB) .

at the event where i heard tony hoare presenting his vision was also niklas wirth, the old swiss man, who once brought schoolkids pascal. he wasn't really amused of hoare: "as an engineer" he has some problems with the idea, because it will occupy a lot of people's mind for a long time; too long in his mind. and second because he doubts its performance: "what's my advantage if there are trains that arrive 100% on time, but consist of nothing more than uncomftable boxcars?"

what't the use of a programm, that's 100% korrekt (foo/bar, 314 KB) ? and what means verifikation (foo/bar, 254 KB) if also the formal specifications can be wrong, because they are made by humans?

in certain, well-defined areas, it's maybe secure to let genetic algorithms do the job, r.gabriel suggests. anyhow, it would be more important to teach some nuances in programming as when and where it's better not to fix an error than to fix it: he gives credit - if i understand it right - to martin rinard, for the line 'forgiving and unforgiving regions of code' and adds: "we are just at the beginning (foo/bar, 803 KB) ...

b. randell recalls 1968 and one of the early conferences on software engineering. at that time "software became to have meaning in normal business parlance" yet problems sound similar: reliability, bugs, software as a commodity, modularity and structuring, problem of large systems. maybe also the following quote (found in randell's paper) is not yet outdated.

"A contract research organisation had eight people who were to produce a COBOL and an ALGOL compiler. After some initial estimates of difficulty and time, five people were assigned to the COBOL job and three to the ALGOL job. The resulting COBOL compiler ran in five phases, the ALGOL compiler ran in three." (m.e. conway, how do committees invent?, datamation, 1968).

melvin conway 40years later ...

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.

after the speech of richard gabriel about "impossible design - ultra large scale systems" a small group came together to talk with him. one dropped the name of wolfram and gabriel replied: "did you read him? i don't know anyone who read more than one page. you did? let me shake your hand." yeap, thinks are taken real serious over here.

and there is something else that striked me: all these talks about xp, agile, pragmatic, you name it, has somehow brought a kind of hipster factor into the programming com.: hey, we are xp. ¿really? we make in agile now. ¿cmmi? 'com on that's really retro. ¿you still hang on manager's lap? ... talks like that are conceivable now.

religious wording over management methods instead of programming languages as there are few left, as gabriel points out.