Inline. On Tue, Jan 1, 2013 at 7:53 AM, Alan Kay <[email protected]> wrote:
> The most recent discussions get at a number of important issues whose > pernicious snares need to be handled better. > > In an analogy to sending messages "most of the time successfully" through > noisy channels -- where the noise also affects whatever we add to the > messages to help (and we may have imperfect models of the noise) -- we have > to ask: what kinds and rates of error would be acceptable? > Depends on the context, I'm sure. When I'm solving a Project Euler problem in Squeak, my heart isn't broken if I manage to bork the image, because I'm writing the code to throw it away, and nothing depends on it but my own flights of fancy. A missile guidance system, eh, well now that's something I'd like a bit more well tested. Etc. > We humans are a noisy species. And on both ends of the transmissions. So a > message that can be proved perfectly "received as sent" can still be > interpreted poorly by a human directly, or by software written by humans. > > A wonderful "specification language" that produces runable code good > enough to make a prototype, is still going to require debugging because it > is hard to get the spec-specs right (even with a machine version of human > level AI to help with "larger goals" comprehension). > Makes me think of debugging grammars. The grammar is quite specified, but the specification is deceptively complex, recursive. Hard to hold in the lobes all at once. > As humans, we are used to being sloppy about message creation and sending, > and rely on negotiation and good will after the fact to deal with errors. > > We've not done a good job of dealing with these tendencies within > programming -- we are still sloppy, and we tend not to create negotiation > processes to deal with various kinds of errors. > Contracts. I think I might grok how we arrived upon the law metaphor. > However, we do see something that is "actual engineering" -- with both > care in message sending *and* negotiation -- where "eventual failure" is > not tolerated: mostly in hardware, and in a few vital low-level systems > which have to scale pretty much "finally-essentially error-free" such as > the Ethernet and Internet. > I had a manager once who said "The reason what we do isn't engineering is people aren't dying from it often enough." Bridge collapses with people on it, career over. Kernel panic? Tell them to reboot, and ship a hot fix as soon as possible. My prejudices have always liked dynamic approaches to problems with error > detection and improvements (if possible). Dan Ingalls was (and is) a master > at getting a whole system going in such a way that it has enough integrity > to "exhibit its failures" and allow many of them to be addressed in the > context of what is actually going on, even with very low level failures. It > is interesting to note the contributions from what you can say statically > (the higher the level the language the better) -- what can be done with > "meta" (the more dynamic and deep the integrity, the more powerful and safe > "meta" becomes) -- and the tradeoffs of modularization (hard to sum up, but > as humans we don't give all modules the same care and love when designing > and building them). > Right. Again, the missile guidance system (ironically?) gets more love than my solutions to Project Euler problems. > Mix in real human beings and a world-wide system, and what should be done? > (I don't know, this is a question to the group.) > Don't panic:) > There are two systems I look at all the time. The first is lawyers > contrasted with engineers. The second is human systems contrasted with > biological systems. > > There are about 1.2 million lawyers in the US, and about 1.5 million > engineers (some of them in computing). The current estimates of > "programmers in the US" are about 1.3 million (US Dept of Labor counting > "programmers and developers"). Also, the Internet and multinational > corporations, etc., internationalizes the impact of programming, so we need > an estimate of the "programmers world-wide", probably another million or > two? Add in the *ad hoc* programmers, etc? The populations are similar in > size enough to make the contrasts in methods and results quite striking. > > Looking for analogies, to my eye what is happening with programming is > more similar to what has happened with law than with classical engineering. > Everyone will have an opinion on this, but I think it is partly because > nature is a tougher critic on human built structures than humans are on > each other's opinions, and part of the impact of this is amplified by the > simpler shorter term liabilities of imperfect structures on human safety > than on imperfect laws (one could argue that the latter are much more of a > disaster in the long run). > Yeah, the short term liabilities, and the yelling executives interfering with the process. Also, being able to retroactively fix DOA systems remotely produces weird effects that are hard to think about naturally, e.g., working in two different branches where one of them fixes a blocking bug (which is only a minor nuisance for "end users") in the bits you shipped last week, and simultaneously working on next week's release, which depends on the changes in the hotfix. When you're perpetually overworked in that scenario and working on several systems at once, the whole business starts to look like a big ball of wobbly-wobbly, timey-wimey... stuff, and our brains like to view things as a strict progression of cause to effect. What day is it again? > And, in trying to tease useful analogies from Biology, one I get is that > the largest gap in complexity of atomic structures is the one from polymers > to the simplest living cells. (One of my two favorite organisms is > *Pelagibacter > unique*, which is the smallest non-parasitic standalone organism. > Discovered just 10 years ago, it is the most numerous known bacterium in > the world, and accounts for 25% of all of the plankton in the oceans. Still > it has about 1300+ genes, etc.) > 25%? That's like finding out that the world has been round the whole time, ten years ago. > What's interesting (to me) about cell biology is just how much stuff is > organized to make "integrity" of life. Craig Ventor thinks that a minimal > hand-crafted genome for a cell would still require about 300 genes (and a > tiniest whole organism still winds up with a lot of components). > The kernel is a big thing for such a small thing, as usual! > Analogies should be suspect -- both the one to the law, and the one here > should be scrutinized -- but this one harmonizes with one of Butler > Lampson's conclusions/prejudices: that you are much better off making -- > with great care -- a few kinds of relatively big modules as basic building > blocks than to have zillions of different modules being constructed by > vanilla programmers. One of my favorite examples of this was the "Beings" > master's thesis by Doug Lenat at Stanford in the 70s. And this influenced > the partial experiment we did in Etoys 15 years ago. > Partial experiment? Can you be more specific? Should I assume that you mean to point at e.g. Morph (and by extension, Object) in Squeak as largish general purpose base objects or "cells" or "genomes?" > There is probably a "nice size" for such modules -- large enough to both > provide and be well tended, and small enough to minimize internal disasters. > I've had lots of fun arguments about this with coworkers. I have a prejudice: I hate having to scroll down, so I tend toward deeply factored systems (like most of Squeak.) The disadvantage there is I probably spend more time mousing about unraveling the timey-wimey ball than I would if I were looking at files with thousands of lines of code. A friend, though, and I wish I could remember the name of the paper, but he put me onto a study where they tried to measure the relationship between defects and function/method size, and the results surprised me. The systems with the shortest methods had more failures than the systems with slightly longer methods, but that fell off a cliff shortly afterward. Longer than a certain size, defect density seemed to hockey stick. Right through the roof, and at least that part I would expect. BCC friend and former coworker, who might be able to find the paper so I can site my source on that:/ > An interesting and important design problem is to try to (a) vet this idea > in or out, and (b) if in, then what kinds of "semi-universal" modules would > be most fruitful? > (a) I think this is going to be hard to actually measure on a number of levels, which is to say, fun! > One could then contemplate trying -- inducing -- to get most programmers > to program in terms of these modules (they would be the components of an > IDE for commerce, etc., instead of the raw programming components of > today). This tack would almost certainly also help the mess the law is in > going forward ... > Note that desires for runable specifications, etc., could be quite > harmonious with a viable module scheme that has great systems integrity. > > Cheers, > > Alan > > > > > > _______________________________________________ > fonc mailing list > [email protected] > http://vpri.org/mailman/listinfo/fonc > > -- Casey Ransberger
_______________________________________________ fonc mailing list [email protected] http://vpri.org/mailman/listinfo/fonc
