I'm thinking that there are two kinds of input to such an effort. Domain specific knowledge formalized to varying degrees in various ways, and cross domain interpretation of such formalized knowledge. In my mind we are all to occupied with encoding domain knowledge into machines with little though on how to preserve the knowledge as such or how enable it, or its translation to a machine, to be reused. Most of the knowledge is at best preserved in informal documents and peoples minds, and the translation procedure as such is an entirely ephermal activity only preserved as the experience of the developers involved in the project. The problem isn't so much of how to manage various abstractions of machine descriptions,but rather how describt the meta machine and how to preserve and reuse it's input for new meta machines. If I understand it correct, not entierly unlike how category theorists went from studying morphisms, to functors, to natural transformations. Which as an analogy implies that when we talk about abstractions we are still only reaching for morphisms, the meta machines (functors) and meta meta machines (natural transformations) are still both hidden and unexplored.
BR, John On Wed, Jan 2, 2013 at 3:15 AM, Paul Homer <[email protected]> wrote: > My thinking has been going the other way for some time now. I see the > problem as the need to build bigger systems than any individual can > currently imagine. The real value from computers isn't just collecting the > input from a single person, but rather 'combining' the inputs from huge > groups of people. It's that ability to unify and harmonize our collective > knowledge that gives us a leg up on being able to rationalize our rather > over-complicated world. > > The problem I see with components, partically a small set of large ones, > is that as the size of a formal system increases, the possible variations > explode. That is, if we consider a nearly trival small set of primitives, > there are several different possible decompositions. As the size of the > system grows, the number of decompositions grows probably exponentially or > better. Thus as we walk up the levels of abstraction to something higher, > there becomes a much larger set of possibilities. If what we desire is > beyond any individuals comprehension, and there is a huge variance in the > pieces that will get created, then we'll run into considerable problems > when we try to bring all of these pieces together. That I think is > esentially where we are currently. > > My sense of the problem is to go the other way. To make the peices so > trivial that they can be combined easily. It may sound labour intensive to > bring it all together, but then we do have the ability of computers > themselves to spend endless hours doing mundane chores for us. The trick > then would be to engage as many people as possible in constructing these > little pieces, then bring them all together. In a design sense, this is not > substantally different than the Internet, or Wikipedia. These both grew > organically out of relatively small pieces with minimal organization, yet > somehow converged on an end-product that is considerably larger than any > individual's single effort. > > Paul. > > ------------------------------ > * From: * Alan Kay <[email protected]>; > * To: * Fundamentals of New Computing <[email protected]>; > * Subject: * [fonc] Current topics > * Sent: * Tue, Jan 1, 2013 3:53:25 PM > > 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 > [email protected] > http://vpri.org/mailman/listinfo/fonc > >
_______________________________________________ fonc mailing list [email protected] http://vpri.org/mailman/listinfo/fonc
