Retro and the implementation chronology

[RE01 Rice Brian T. EM2]

> Ken Evitt wrote:
> >[...] It would be a royal pain in the ass
> >to implement any kind of TUNES-like system on existing systems and then
> try
> >and phase out the underlying system. With Retro, instead of phasing
> anything
> >out we can write a system from the ground up that does what we want it to
> >do.
> Hardware is constantly changing, and so are the low-level operating system
> components built upon it.  High-level components are dynamic also, as
> user's
> needs change and as new algorithms and ideas are continually being
> discovered.
> Thus, I believe you will ALWAYS find yourself "phasing out the underlying
> system."  I thought the whole idea of the HLL and kernel-less OS was to
> make
> this "phasing" task easier; Tunes can provide a high-level computing
> abstraction that allows old code modules to be dynamically and reliably
> adapted to new uses.  The goal, then, is not to build The Final OS, but to
> render OS's irrelevant.
> 
i couldn't agree more.  the point of Tunes (as a project) in my opinion is
to develop and implement those concepts that allow exploratory programming
into regions heretofore unmanageable.  the overall group experiences with
Lisp, Scheme, SmallTalk, Self, Beta, ML, Haskell, and Mercury suggest that
there are some real limits to our current programming tools that Tunes'
goals seem intent on overcoming.

> From this perspective, device drivers, filesystems, process schedulers,
> etc.
> are merely "hardware" details.  I would argue that Linux, Retro, or even
> Win32 (!) are all equally suitable foundations.  Pick whichever one has
> the
> most complete support for the hardware you use, and build from there.
> (On the other hand, maybe I'm understressing the "E" in TUNES.)  ;-)
> 
sure. just take a look at the reasons for my choosing Squeak for an
implementation platform.

what i should address soon is choosing the type of conceptual scheme for
developing an arrow environment that is most natural to it.  i'm looking at
the big conceptual hurdles of total ontological relativity combined with
expressive efficiency.  in this way, i could then state exactly how to make
abstract concepts first-order, and from their it should be simple to
describe concrete implementations of those concepts (i.e. filesystems,
run-time store management, process scheduling and distribution, ... ).

i don't consider it my business to create new concepts for computing
_implementations_; there are enough programmers in the world for that.  i'm
supposed to develop a conceptual framework into which everyone else
(including computers themselves) can link their own ideas and knowledge,
just as the internet protocols do the same for people today.