On Fri, Oct 8, 2010 at 5:04 PM, Paul D. Fernhout < pdfernh...@kurtz-fernhout.com> wrote:
> > But, the big picture issue I wanted to raise isn't about prototypes. It as > about more general issues -- like how do we have general tools that let us > look at all sorts of computing abstractions? > > In biology, while it's true there are now several different types of > microscopes (optical, electron, STM, etc.) in general, we don't have a > special microscope developed for every different type of organism we want to > look at, which is the case now with, say, debuggers and debugging processes. > > So, what would the general tools look like to let us debug anything? And > I'd suggest, that would not be "gdb" as useful as that might be. > > Computer scientists stink at studying living systems. Most computer scientists have absolutely zero experience studying and programming living systems. When I worked at BNL, I would have lunch with a biologist who was named after William Tecumseh Sherman, who wrote his Ph.D. at NYU about making nano-organisms dance. That's the level of understanding and practical experience I am talking about. As for making things debuggable, distributed systems have a huge need for compression of communication, and thus you can't expect humans to debug compressed media. You need a way to formally prove that when you uncompress the media, you can just jump right in and debug it. There have been advances in compiler architecture geared towards this sort of thinking, such as the logic of bunched implications viz a viz Separation Logic and even more practical ideas towards this sort of thinking, such as Xavier LeRoy's now famous compiler architecture for proving optimizing compiler correctness. The sorts of transformations that an application compiler like GWT makes are pretty fancy, and if you want to look at the same GWT application without compression today and just study what went wrong with it, you can't. What you need to do, in my humble opinion, is focus on proving that mappings between representations is isomorphic and non-lossy, even if one representation needs hidden embeddings (interpreted as no-ops by a syntax-directed compiler) to map back to the other. There are also other fancy techniques being developed in programming language theory (PLT) right now. Phil Wadler and Jeremy Siek's Blame Calculus is a good illustration of how to study a living system in a creative way (but does not provide a complete picture, akin to not knowing you need to stain a slide before putting it under the microscope), and so is Carl Hewitt's ActorScript and Direct Logic. These are the only efforts I am aware of that try to provide some information on why something happened at runtime. > I can usefully point the same microscope at a feather, a rock, a leaf, and > pond water. So' why can't I point the same debugger at Smalltalk image, a > web page with JavaScript served by a Python CGI script, a VirtualBox > emulated Debian installation, and a semantic web trying to understand a > "jobless recovery"? > > I know that may sound ludicrous, but that's my point. :-) > What the examples I gave above have in common is that there are certain limitations on how general you can make this, just as Oliver Heaviside suggested we discard the balsa wood ship models for engineering equations derived from Maxwell. > > But when you think about it, there might be a lot of similarities at some > level in thinking about those four things in terms of displaying > information, moving between conceptual levels, maintaining to do lists, > doing experiments, recording results, communicating progress, looking at > dependencies, reasoning about complex topics, and so on. But right now, I > can't point one debugger at all those things, and even suggesting that we > could sounds absurd. Of course, most things that sound absurd really are > absurd, but still: "If at first, the idea is not absurd, then there is no > hope for it (Albert Einstein)" > > In March, John Zabroski wrote: "I am going to take a break from the > previous thread of discussion. Instead, it seems like most people need a > tutorial in how to think BIG." > > And that's what I'm trying to do here. > Thanks for the kind words. I have shared my present thoughts with you here. But a tutorial in my eyes is more about providing people with a site where they can go to and just be engulfed in big, powerful ideas. The FONC wiki is certainly not that. Most of the interesting details in the project are buried and not presented in exciting ways, or if they are, they are still buried and require somebody to dig it up. That is a huge bug. In short, the FONC wiki is not even a wiki. It is a chalkboard with one chalk stick, and it is locked away in some teacher's desk.
_______________________________________________ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
