Re: [fonc] [IAEP] Barbarians at the gate! (Project Nell)
On Wed, Mar 14, 2012 at 12:54 PM, Alan Kay alan.n...@yahoo.com wrote: The many papers from this work greatly influenced the thinking about personal computing at Xerox PARC in the 70s. Here are a couple: -- O. K. Moore, Autotelic Responsive Environments and Exceptional Children, Experience, Structure and Adaptabilty (ed. Harvey), Springer, 1966 -- Anderson and Moore, Autotelic Folk Models, Sociological Quarterly, 1959 Thank you for these references. I will chase them down and learn as much as I can. 2. Separating out some of the programming ideas here: a. Simplest one is that the most important users of this system are the children, so it would be a better idea to make the tile scripting look as easy for them as possible. I don't agree with the rationalization in the paper about preserving the code reading skills of existing programmers. I probably need to clarify the reasoning in the paper for this point. Traditional text-based programming languages have been tweaked over decades to be easy to read -- for both small examples and large systems. It's somewhat of a heresy, but I thought it would be interesting to explore a tile-based system that *didn't* throw away the traditional text structure, and tried simply to make the structure of the traditional text easier to visualize and manipulate. So it's not really skills of existing programmers I'm interested in -- I should reword that. It's that I feel we have an existence proof that the traditional textual form of a program is easy to read, even for very complicated programs. So I'm trying to scale down the thing that works, instead of trying to invent something new which proves unwieldy at scale. b. Good idea to go all the way to the bottom with the children's language. c. Figure 2 introduces another -- at least equally important language -- in my opinion, this one should be made kid usable and programmable -- and I would try to see how it could fit with the TS language in some way. This language is JSON, which is just the object-definition subset of JavaScript. So it can in fact be expressed with TurtleScript tiles. (Although I haven't yet tackled quasiquote in TurtleScript.) d. There is another language -- AIML -- introduced for recognizing things. I would use something much nicer, easier, more readable, etc., -- like OMeta -- or more likely I would go way back to the never implemented Smalltalk-71 (which had these and some of the above features in its design and also tried to be kid usable) -- and try to make a version that worked (maybe too hard to do in general or for the scope of this project, but you can see why it would be nice to have all of the mechanisms that make your system work be couched in kid terms and looks and feels if possible). This I completely agree with. The AIML will be translated to JSON on the device itself. The use of AIML is a compromise: it exists and has well-defined semantics and does 90% of what I'd like it to do. It also has an active community who have spend a lot of time building reasonable dialog rules in AIML. At some point it will have to be extended or replaced, but I think it will get me through version 1.0 at least. I'll probably translate the AIML example to JSON in the next revision of the paper, and state the relationship of JSON to JavaScript and TurtleScript more precisely. 3. It's out of the scope of your paper and these comments to discuss getting kids to add other structures besides stories and narrative to think with. You have to start with stories, and that is enough for now. A larger scale plan (you may already have) would involve a kind of weaning process to get kids to add non-story thinking (as is done in math and science, etc.) to their skills. This is a whole curriculum of its own. I make these comments because I think your project is a good idea, on the right track, and needs to be done Thank you. I'll keep your encouragement in mind during the hard work of implementation. --scott -- ( http://cscott.net ) ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] [IAEP] Barbarians at the gate! (Project Nell)
On Wed, Mar 14, 2012 at 6:02 PM, Jameson Quinn jameson.qu...@gmail.comwrote: If you're going to base it on Javascript, at least make it Coffeescript-like. I also agree that some basic parallelism primitives would be great; it is probably possible to build these into a Coffeescript-like dialect using JS under the hood (though they'd probably optimize even better if you could implement them natively instead of in JS). I think you are underestimating the value of using a standard widely-deployed language. I love languages as much as the next guy---but our previous learning environment (Sugar) has had incredible difficulty getting local support outside the US because it is written in *Python*. Python is not a commercially viable language (not my words) and you can't even take university classes in Python in many countries (say, Uruguay) because there is no company behind it and no one who will give you a certificate for having learned it. This is very sad, but the true state of affairs. JavaScript is not perfect, but at heart it is a functional object-oriented language which is pretty darn close to Good Enough. There are huge benefits to using a language which is supported by training materials all over the web, university systems outside the US, etc, etc. I am open to *very* slight extensions to JavaScript -- OMeta/JS and quasiquote might squeeze in -- but they have to be weighed against their costs. Subsets are even more problematic -- once you start subsetting, then you are throwing away compatibility with all the wealth of JavaScript libraries out there, in addition to confusing potential contributors who are trying to type in examples they found in some book. --scott -- ( http://cscott.net ) ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
[fonc] Project Nell
Chris Ball, Michael Stone, and I have just written a short paper on Project Nell, which should be of interest to this list: http://cscott.net/Publications/OLPC/idc2012.pdf The paper mentions TurtleScript (http://cscott.net/Projects/TurtleScript/) which I've discussed on this list before. --scott -- ( http://cscott.net ) ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
[fonc] Narrative Interfaces
We're having some invited talks this Friday at One Laptop per Child's offices on Narrative Interfaces. Full talk description here: http://cananian.livejournal.com/64747.html I've been working on building a small modular growable direct system along the lines of several others discussed on this list (see http://cananian.livejournal.com/tag/turtlescript ) -- but the focus of these talks is going to be somewhat different: assume that we've built such a nice transparent system. How do we write the code walkthrough? How do we guide learners through the edifice we've built? How ought we show off corners of the architecture which they might not stumble into on their own? Put another way: the Dynabook (and/or the Primer in Neal Stephenson's The Diamond Age) isn't *just* architecture. There's some content, too -- how ought we to write that? Chalkboard's translation of Abelson and diSessa's Turtle Geometry book (http://tinlizzie.org/chalkboard/#TurtleGeometryHome) is a step toward this goal. Interactive Fiction works such as Inform School (http://www.sparkynet.com/spag/i.html#informsch) are steps toward the same goal from a different direction. The talks will be live-streamed and also available for download after the event. I hope the audience here finds the topic of interest. --scott -- ( http://cscott.net ) ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
[fonc] Improving efficiency of Worlds, in Software and Hardware
On Mon, Jun 13, 2011 at 11:17 AM, Alan Kay alan.n...@yahoo.com wrote: For example, take a look at Alex Warth's Worlds work (and paper) and see how that might be used to deal with larger problems of consistency and version control in a live system. I just read this paper for the first time. Very nice work; I think it is a nice generalization of the software transactional memory work that's been done recently. At the same time, it has some of the same drawbacks (especially in regard to managing external side effects, like from I/O). On the other hand, there's been a lot of work done on efficient implementations of transactional memory in software and hardware, and worlds can benefit from this fairly directly. For example, (to cite my own work): Unbounded Transactional Memory is a straightfoward cache modification which would make worlds scalable (http://cscott.net/Publications/HPCA05/hpca05-camera.pdf) and functional arrays provide a mechanism for decoupling the performance of the implementation from the size of the chain of worlds to allow deep undo-trees, as described in http://cscott.net/Publications/scool05.pdf and my thesis. In particular, I recommend Tyng-Ruey Chuang’s implementation of shallow binding (http://academic.research.microsoft.com/Publication/313627/a-randomized-implementation-of-multiple-functional-arrays ). --scott -- ( http://cscott.net ) ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
[fonc] Re: Improving efficiency of Worlds, in Software and Hardware
(As a minor technical note: it appears that the implementation of flattenHistory in figure 4 occurs in the wrong order. Worlds should be committed from the root to the leaves, shouldn't they?) --scott -- ( http://cscott.net ) ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] Re: Improving efficiency of Worlds, in Software and Hardware
Thanks for the explanation. I think I was confused originally because
your API is:
in world {
...
}
world.commit()
where I was expecting:
in world {
world.commit()
}
ie, in your API, even though the API occurs in the root context, it
doesn't (usually) *affect* the root world... it affects the receiver
world and its parent only. So when I saw commits from the leafs up, I
was thinking, how can you start by committing the leaf to the root
world?
I understand where I went wrong now, but on reflection it still seems
odd that the parent context isn't explicitly mentioned in the API.
Instead writing
world.parent.commit(world);
would make clear what two worlds are affected... but that's
unnecessarily verbose. So not necessarily an improvement to anything
other than my originally-confused brain.
OK, my email is too long now, too!
--scott
--
( http://cscott.net )
___
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc
Re: [fonc] Alternative Web programming models?
On Mon, Jun 13, 2011 at 4:02 PM, BGB cr88...@gmail.com wrote: Consider what it'd be like if we didn't represent code as text... and represented it maybe as series of ideograms or icons (TileScript nod). Syntax errors don't really crop up any more, do they? Given a slightly nicer User Interface than tilescript, you could still type your code, (ie use the keyboard to fast-select tokens), but the computer won't validate any input that isn't in its dictionary of known possible syntactically correct items given whatever context you're in. I think Tiles prevent syntax errors is a red herring. Sure, you can prevent stupid typos by offering only tiles with correctly spelled keywords, but that's not really a major problem in ordinary experience. The more pernicious errors aren't especially affected one way or the other by tile-based systems. (You could just as accurately say that strongly-typed systems prevent errors.) given that most non-Chinese can't read Chinese writing, despite that many of these characters do actually resemble crude line-art drawings of various things and ideas. It is a common linguistic misperception that there is some one-to-one correspondence between an ideogram and the idea it represents. The english letter A was originally a drawing of an ox-head. (http://en.wikipedia.org/wiki/A). It is as accurate to say that English letters resemble crude line-art drawings as to say that Chinese ideograms do. and meanwhile, many Asian countries either have shifted to, or are in the process of shifting to, the use of phonetic writing systems (Koreans created Hangul, Kanji gradually erodes in favor of Hiragana, ...). even in some places in China (such as Canton) the traditional writing system is degrading, with many elements of their spoken dialect being incorporated into the written language. This is also playing fast and loose with linguistics. Let's be wary of drawing analogies to fields where we are not expert. --scott -- ( http://cscott.net ) ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] Alternative Web programming models?
On Mon, Jun 13, 2011 at 11:17 PM, Julian Leviston jul...@leviston.net wrote: I think Tiles prevent syntax errors is a red herring. Sure, you can prevent stupid typos by offering only tiles with correctly spelled keywords, but that's not really a major problem in ordinary experience. The more pernicious errors aren't especially affected one way or the other by tile-based systems. (You could just as accurately say that strongly-typed systems prevent errors.) When you're about to type the next tile, you're given options... anything outside of those options is impossible, so the computer doesn't put it in, because syntactically it wouldn't make sense. There's nothing specific to tiles in what you wrote. You could do the same just as easily with a keyboard-based system. This is what I mean when I say that tiles prevent syntax errors is not accurate; it's confusing two separate things. Again: more accurately you could say, strong typing can prevent syntax errors... tiles have nothing to do with it, really. --scott -- ( http://cscott.net ) ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] why are true,false,nil pseudovariables
On Sun, Jun 12, 2011 at 1:43 AM, David Barbour dmbarb...@gmail.com wrote: Anyhow, I agree that there are plenty of optimizations available. But I don't believe we can replace a true/false/nil method invocation with a specialized bytecode in a typical open system. SELF did not have specialized bytecodes for these. See http://selflanguage.org/documentation/published/implementation.html --scott -- ( http://cscott.net ) ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] why are true,false,nil pseudovariables
On Sun, Jun 12, 2011 at 2:20 PM, David Barbour dmbarb...@gmail.com wrote: On Sun, Jun 12, 2011 at 1:07 AM, C. Scott Ananian csc...@laptop.org wrote: SELF did not have specialized bytecodes for these. See http://selflanguage.org/documentation/published/implementation.html --scott Why is this relevant? The opening question was about Squeak. The self system included a full implementation of Smalltalk. Look, this isn't really a big deal. Squeak makes some architectural choices. We're discussing alternatives. It's certainly possible for Squeak to have used a different compilation strategy for constants. You could start with the architecture of SELF, for example, and make the tradeoff that you have a lot of native methods but gain the advantage of very few specialized bytecodes. You may prefer to have more specialized bytecodes and fewer native methods, or some other point in the design space. There's no right or wrong here. I'm just puzzled why you seem to be insisting that no other alternative to Squeak's design is possible, when there are multiple existing systems which demonstrate the opposite. I've been continuing the discussion because it's been a nice opportunity to tip my hat to a lot of other people's excellent and interesting systems work, but I think it's time this thread ended now. --scott -- ( http://cscott.net ) ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] Alternative Web programming models?
On Sat, Jun 11, 2011 at 1:40 AM, BGB cr88...@gmail.com wrote: The responsiveness of exploratory programming environments (such as the Smalltalk programming environment) allows the programmer to concentrate on the task at hand rather than being distracted by long pauses caused by compilation or linking. this is also partly where dynamic script loading and eval can be nifty... say, one is using an app, and then in the console they type in a command, say: ;load(scripts/myscript.bs); and can quickly edit the file, hit the uparrow in the console to re-enter the prior command, and observe the results. or, the ability to directly type script commands into the console to observe results, ... You should spend some time playing around with the Web Inspector in Chrome or other Webkit browser. Console, live code editing, lots of other good stuff. The only big drawback is the complexity of the system: HTML+CSS+JS is quite a hairy beast. but, I was also left recently thinking some about the possible strangeness of me basically creating a vaguely Lisp-like programming environment within C. http://en.wikipedia.org/wiki/Greenspun's_Tenth_Rule --scott -- ( http://cscott.net ) ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] why are true,false,nil pseudovariables
On Sat, Jun 11, 2011 at 2:05 AM, David Barbour dmbarb...@gmail.com wrote: On Mon, Jun 6, 2011 at 11:48 AM, Ondrej Bilka nel...@seznam.cz wrote: My point is that you could just Object have methods true,false and nil Any reasonably optimalizing compiler would replace them with bytecode. As methods, you could override them. And since you don't know which subclasses override these methods, you couldn't optimize. This is a very limited way of thinking about your compiler. It hasn't been mainstream thinking since the advent of Java, which turned conventional compiler technology on its head. (Obviously, the ideas quite predate Java, but I'm just speaking of point at which the majority of papers in academic compiler conferences (say, PLDI) suddenly shifted away from purely static compilation.) --scott -- ( http://cscott.net ) ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] why are true,false,nil pseudovariables
On Sat, Jun 11, 2011 at 11:19 PM, David Barbour dmbarb...@gmail.com wrote: On Sat, Jun 11, 2011 at 6:33 PM, C. Scott Ananian csc...@laptop.org wrote: the majority of papers in academic compiler conferences (say, PLDI) suddenly shifted away from purely static compilation. True, if you use a dynamic compiler you can do quite a few more optimizations. I guess I'm used to the embedded world, where static compilation is still king. Even if you're doing pure static analysis, you should be doing open/closed class analysis and specializing/inlining any class which has no subclasses in the compilation. --scott -- ( http://cscott.net ) ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] why are true,false,nil pseudovariables
On Sun, Jun 12, 2011 at 12:13 AM, David Barbour dmbarb...@gmail.com wrote: On Sat, Jun 11, 2011 at 8:34 PM, C. Scott Ananian csc...@laptop.org wrote: Even if you're doing pure static analysis, you should be doing open/closed class analysis and specializing/inlining any class which has no subclasses in the compilation. Doesn't work with pluggable components. This is discussed in the paper(s). Closed/open types can be considered part of the type system, in which case they are perfectly compatible with plugins. They can also be considered a type of runtime optimization or method cache, in which case you just need to do a bit of extra bookkeeping when you load your component. No inherent problem. If you actually *do* redefine 'true' in your pluggable component, of course, you get the poor performance which you apparently wanted. But there's no magical reason why you can't do proper interprocedural analysis. (Call it 'link time optimization' and stick it in the dynamic loader if you want to keep it under the radar.) --scott -- ( http://cscott.net ) ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] Alternative Web programming models?
On Jun 9, 2011, at 5:58 AM, Julian Leviston jul...@leviston.net wrote: On 09/06/2011, at 7:04 PM, BGB wrote: actually, possibly a relevant question here, would be why Java applets largely fell on their face, but Flash largely took off (in all its uses from YouTube to Punch The Monkey...). My own opinion of this is the same reason that the iPad feels faster than a modern desktop operating system: it was quicker to get to the user interaction point. Julian. The slow startup time is indeed why Sun's own team felt that Java failed to get traction. Unfortunately some basic architecture choices in the standard library made it extremely difficult to fix the problem. (Broadly, how class initialization is handled and used.) The latest Java plugins contain some impressive engineering to mitigate the problem, but Java is still sluggish to start in my experience. Library design matters! --scott -- ( http://cscott.net ) ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] Alternative Web programming models?
On Fri, Jun 10, 2011 at 2:45 PM, BGB cr88...@gmail.com wrote: just had an idle thought of a JVM starting up as a prebuilt image (say, methods are pre-JIT'ed and pre-linked, static fields are pre-initialized, ...). unless of course, they already started doing this (sadly, I am not much an expert on the JVM). Yes, they do this already; but this was part of the startup-time optimizations which weren't initially present in the JVM. or, maybe it is that, within the class library, most classes are tangled up with many other classes, essentially turning the class library into some large bulk-loaded glob?... Yes, that was a large part of the initial problem. A particular culprit was the String class, which wanted to have lots of convenient hooks for different features (including locale-specific stuff like uppercase/lowercase sorting, regexs, etc) but that tangled it up with everything else. The basic JVM bytecode demanded intern'ed strings, which required String class initialization, which then required on-the-fly locale loaded based on environment variables (removing the ability to precompile and image), and things went rapidly downhill from there. a sad result of this is that using executable statements/expressions in the toplevel, it is possible to fetch 'null' from slots prior to them being initialized, creating ordering issues in some cases. Yes, this was another fundamental problem with the JVM. You needed intimate knowledge of the library implementation in order to do initial class initialization in the proper order to avoid crashes. --scott -- ( http://cscott.net ) ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: Terseness, precedence, deprogramming (was Re: [fonc] languages)
On Sun, Jun 5, 2011 at 8:13 PM, Casey Ransberger casey.obrie...@gmail.comwrote: Another approach I think is really cool is actually just using mathematical notation as one representation of what's otherwise basically an s-expr, in which case I think one is having some cake and eating it too. I've been playing with Mathematica a bit, which seems to do some of that. Kind of like flipping between the piano roll and the notation view in a music program. I also think their big algorithm library is a really lovely idea... If it doesn't necessarily separate meaning from optimization, it at least seems like it could help separate math from glue and plumbing which would just be a godsend in my work, where it often feels like I have to read-between-the-lines to find an algorithm in a piece of code I'm looking at. You would like Fortress: http://labs.oracle.com/projects/plrg/faq/NAS-CG.pdf Here is an example of runnable Fortress code: http://labs.oracle.com/projects/plrg/faq/NAS-CG.pdf (There is also an ASCII-only syntax for us luddites.) --scott -- ( http://cscott.net ) ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] Re: Electrical Actors?
I explored this idea a bit once upon a time in the context of Java: http://cscott.net/Publications/design.pdf The bibliography cites most of the related work I know about. --scott -- ( http://cscott.net ) ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] Static typing and/vs. boot strap-able, small kernel, comprehensible, user modifiable systems
On Sat, Jun 4, 2011 at 2:12 PM, John Nilsson j...@milsson.nu wrote: Is static types really an intensic property of the language? In my mind any language can be statically typed. It is just more or less hard to do. Again, please read Gilad Bracha's position paper. He concisely enumerates the ways in which a decision to make a statically typed language inherently affects the design of other parts of the language. Similarly, a dynamically-typed language will allow design decisions that rule out static typing. He does a good job giving examples of the sorts of interactions that may occur. --scott -- ( http://cscott.net ) ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] Alternative Web programming models?
On 31 May 2011 16:30, Alan Kay alan.n...@yahoo.com wrote: There are lots of egregiously wrong things in the web design. Perhaps one of the simplest is that the browser folks have lacked the perspective to see that the browser is not like an application, but like an OS. i.e. what it really needs to do is to take in and run foreign code (including low level code) safely and coordinate outputs to the screen (Google is just starting to realize this with NaCl after much prodding and beating.) The web is not *only* an OS. It also provides the backing data for a very large unstructured database. Google of course realize this, as their company rests on a search engine. The semantic web folks have tried in vain to get people to add more structure to the database. What the web OS must do is allow the efficient export of additional *unstructured and ad hoc* data. HTML+CSS web applications today are moderately good at this -- the images stored in flickr (say) are still in standard crawlable formats, and they show up in search results. Google's Native Client (as well as prior sandbox technologies, such as Java, etc) is *not* good at this (yet?). The graphics rendered in NativeClient are completely invisible to search engines -- and thus resources created in these apps are impossible to index. You can build a web app *alongside* Native Client in order to export data created in the sandboxed app -- but now you're just doubling the effort. Like it or not, the messy stew of HTML+CSS is the closest we have to a universal GUI canvas, loaded with equally-messy semantics -- but enough that I can take the source code for a (say) flickr or youtube page and extract the comment text and photos/video. No rival web application or web as OS framework (which is not itself built on HTML+CSS) can do that. --scott ps. the closest rival to HTML is RSS/Atom -- a more limited format, but it had it's own search engines and tools (see http://www.opensearch.org). A web OS which could still export its underlying data structures/files as a indexable/sharable/browsable RSS feed would be more competitive than a pure sandbox. Another possible avenue is exporting from your web OS something close to a filesystem -- ie, a list of downloadable documents, nothing more -- and letting the search engine peek inside the standard format of the documents to construct an index, as Google can currently do with PDF, XLS, and other common file formats. But this gives up the idea of the 'hyperlink' -- now I know there's a binary blob somewhere with information relevant to my search, but it comes without any code to edit/view/collaborate. (For a little more detail on the export as RSS aspect of this, you might check out The Journal, Reloaded at http://cscott.net/Publications/) -- ( http://cscott.net ) ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] Alternative Web programming models?
2011/6/3 Benoît Fleury benoit.fle...@gmail.com: I tend to agree with you. The uniform interface of the web (reduced set of HTTP verbs, links...) is what make all these applications possible. We know what to do when we have the URL to the flickr image. But we could do so much more. I agree with you there. We can certainly continue to make things better! But (as the HTML folk learned w/ the success of HTML5) the way to go forward is to *build on* the past, not throw it out and start over. If we can come up with new technologies that interoperate, that provide backward-compatibility hooks, and that provide transition paths, then they have a chance to improve the platform that everyone is using. The future has turned out to be much messier than past architects imagined. We have neither solved strong AI nor have we convinced humans to generate content which adheres to rigid semantics. Instead we have a strange new world where unstructured databases can exist, often can be searched, and most likely will generate useful results. Probabilistic models have triumphed over formal correctness. And if you think that's horrifying, you should see some of the work my former advisor is/was doing on failure-oblivious computing (http://people.csail.mit.edu/rinard/acceptability_oriented_computing/). Rather shockingly, the best thing to do is often to muddle through... But now we've drifted far off topic; all of this is rather orthogonal to the goal of making systems which people can more broadly understand, use, and modify. Having a beautiful small kernel is a good way to make an understandable system; throwing in everything but the kitchen sink is a good way to make an unobjectionable system which gets adopted easily by lots of different people with strong preexisting ideas about the way things ought to work. I would imagine the fonc project would want to steer a middle course. (Alan has previously spoken of the need for extensibility, which is one way to build a popular featureful system out of a small kernel.) --scott -- ( http://cscott.net ) ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
