Re: [ba-ohs-talk] What are we trying to accomplish?
Mei Lin Fung wrote:
> [Lost of good stuff snipped]
> People who have been in Doug's orbit sometimes feel they understand
> fully the problem and what needs to be done. Often that seems to involve
> putting Doug on the shelf so that he stops making these troublesome
> remarks that people can't understand.
>
> This is to do him a disservice, that's my opinion. He is not at a place
> in his life where he wants to debate his ideas and plans, they have been
> the product of 51 years of thinking. He just wants to do it and to work
> with people that want to do it. What he wants to do has been outlined
> in the OHS Launch Plan for the hyperscope, BI2120.
> http://www.bootstrap.org/augment/BI/2120.html (01)
[Trying to catch up a tiny bit...] (02)
Mei Lin- (03)
One major issue here is a fundamental contradiction between implementing
the perfect OHS on the first pass, versus bootstrapping a population of
tools capable of evolution. (04)
I don't think anyone here disrespects Doug's technical accomplishments
or his social ones of getting creative people together. I don't think
anyone here disrespects his vision for something good for humankind by
enabling high performance teams capable of further bootstrapping (until
transcendence?). It would be wonderful to see Doug's current vision for
an OHS implemented as it is a distillation of years of experience and
pondering, whether or not the current design is perfect. If you want to
help him implement exactly that specification, and recruit others to do
so, more power to you. (05)
Still, doing so would take considerable effort, and the question is who
will make that investment and for what reasons -- given an estimate of
the project's chances of success (in various ways) against how useful it
will be and what is already out there. Much of the value of this list
has been in seeing all the other things people have been doing, both for
ideas and to avoid reinventing wheels (or at least, for me, to avoid
reinventing other free wheels). (06)
I'm not ready to make that investment myself, in part (beyond licensing)
because I have specific design issues with aspects of OHS design, which
were raised quite a while back. (And frankly, I'm not up on all the
latest discussion, so some of these issues may have been better
addressed since then, either by Doug or various other contributors.) (07)
The most serious issue is in the notion of "Document" which I think
needs further contemplation. For example, where do document boundaries
end? How are documents composed of other components? How do documents
change through time along with the system itself? How are documents
merged? How are they split? Is the notion of "Document" really a
valuable idea as opposed to say nested versioned hierarchies (e.g. OTI's
Envy for Smalltalk) or networks with paragraphs at the base?) (These are
related to some issues William Kent raises in "Data & Reality"). (08)
The second major design issue revolves around the notion of a link.
While I think it makes sense to be able to use a system to move from a
viewed concept to related items, it isn't clear what the best way to do
that is, given the power of search engines (which can find all pages
containing a text string) and that the link an author originally creates
(say for a definition) may not reflect the current needs of the reader.
Also, related to transcending links is the issue of distributed
non-locational content. (09)
Design issues can be thrashed through and both of the above issues could
probably be resolved in some form in a process that involves
bootstrapping Doug's design (if license issues & permisison to use were
resolved yada yada). (010)
Doug seems to have a gift for defining requirements, and the documents I
look at seem more like requirements documents than architecture to me.
To elaborate on how what is spelled out are requirements, one could say
the system should be capable of helping people deal with things some
people call documents -- even if documents don't exist in the system as
such. Similarly, the system should support the author's intent in
defining useful links -- but that does not mean that is necessarily the
only sort of link or navigation the system might handle, or that
internally the system will represent links as they are conventionally
described these days in HTML syntax. (011)
This fundamental contradiction between implementing a perfect system in
one pass versus bootstrapping a self-reflective one (is perhaps one
reason people (including me) set off in entirely different directions
rather than implement the OHS or Hyperscope spec. I, for one, remain
respectfully always informed by Doug's vision, but perhaps not always
movign things along in a way exactly as he planned. (012)
Also, such systems may tend to be perhaps nearly from scratch in various
ways but using existing tools. This fundamental contradiction might
also end up being reflected in the tools used and the tradeoffs (speed
vs. storage vs. flexibility etc.) in and Bootstrappable architecture.
It's a difficult set of challenges -- and there are schools of
programming thought like "extreme programming" that argue to never put
in any flexibility in the system because there are infinite ways you can
do that so most of that effort will be wasted. I don't completely agree
with that; I think every once in a while you see an elegant way to stay
flexible. (013)
Frankly, it isn't clear to me from the OHS or Hyperscope specifications
I have looked at, such as linked above, how evolving the system code
itself in a bootstrapping way is easily doable (as opposed to evolving
the textual content). I'm not saying it is impossible, just that the
focus seems more on a great system to evolve populations of textual
content, as opposed to a great framework for the evolution of
populations of code. Granted, that is the need most people have for an
OHS and what atttracts most peopel to the concept. There is a lot of
content out there to deal with, not the least of which is this mailing
list. (014)
That self-reflective aspect of the system isn't emphasized, such as it
is with, say, Squeak Smalltalk (for all its other issues) or, say, Forth
(the premier Bootstrapping computer language in some ways). Naturally,
evolving code versus evolving content don't have to be in opposition
(since code is content). What I am talking about here is more just an
issue of focus and what aspects and levels of the system architecture
one is talking most about. (015)
Still, I think the fundamental contradiction would ideally be addressed
to lower the risk of any specific implementation approach. (016)
Just to give one tiny example in this direction (and to break my own
rule about not posting code here until licensing is resolved...) (017)
==================== (018)
[The following lines of code disclaimed to the public domain in an
effort to be useful and to limit liability, and come with NO WARRANTY:] (019)
import org.python.util.*;
import org.python.core.*; (020)
... (021)
void OnRunPython()
{
PythonInterpreter interp = new PythonInterpreter();
String program = this.textEditor.getText();
interp.exec(program);
} (022)
==================== (023)
This the essence of a crystallized Java program that can bootstrap
itself using Jython (Python in Java), even to the point of launching new
windows, communicating over the internet, retrieving versions of its
source from a database, and so on. (024)
There are other approaches, say by bootstrapping IBM's Eclipse Java
development environment (or Sun's Netbeans, or GCC & Emacs, etc.). (025)
In any case, this is a code example related to resolving the
contradiction... (026)
-Paul Fernhout
== The Pointrel Foundation
== Helping people understand nature, technology, and society
== by developing networks of free digital libraries
== and free software and free content to put in them.
== http://www.pointrel.org (027)