Hah, wrong button. Sorry all! Meant to hit forward, as I really enjoyed this one and wanted to share it:)
On Tue, Jan 1, 2013 at 6:40 PM, Casey Ransberger <casey.obrie...@gmail.com>wrote: > Read this guy! > > On Tue, Jan 1, 2013 at 7:53 AM, Alan Kay <alan.n...@yahoo.com> 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? >> >> 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). >> >> 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. >> >> 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. >> >> 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). >> >> 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.) >> >> 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). >> >> 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.) >> >> 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). >> >> 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. >> >> 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. >> >> 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? >> >> 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 >> fonc@vpri.org >> http://vpri.org/mailman/listinfo/fonc >> >> > > > -- > Casey Ransberger -- Casey Ransberger
_______________________________________________ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
