New TUNESer!

[Tril]

> >> Brian
> >David
> Brian

> i see the computer project of TUNES as a prelude to a greater and much
> more meaningful project (for me): the next generation of consciousness
> for people. this project, i believe, will be enabled by the one
> concerned with computers (or rather, the one concerned with solving the
> problems we now have today due to the phenomena associated with
> electronic devices).

The problems we have are social detachment, information overload,
obsessive immersion, and technocracy.

Social detachment- computers must mold to people's society at a micro and
macro level so as not to interfere with normal socialization.  If
computers cannot be made people-friendly, they should be eliminated.

Information overload- computer software must be scalable into worldwide
distributed databases indexed by meaning, and therefore easily useable by
people.

Obsessive immersion- I think if collaborative terminals are made where two
or more people can use a computerized blackboard, while in the same room,
they will tend to speak to one another instead of ignoring each others'
presence.  When computers force a single-user interface there isn't much
other choice than to sit in your room by yourself.  But there's surely
other ways than this.

Technocracy- This is important.  Technology shouldn't be in the hands of
specially-trained workers.  The most immediate way we can help with this
is to have the system be a meta-lexicon, or translate between technospeak
and layman's terms.  For example, I write a module and attach
documentation in both highly technical terms, for those who know them, and
in everyday language.  Then, if someone wants to learn technical terms,
they have a jumping point, and can just tell the system to change their
'difficulty level' for reading documentation.

The other way is to make the system inherently easy to understand, by
being abstract.  (see below)

> >> 	first, when new hardware standards or products are introduced, new
> >> semantics-based descriptions must be written to take advantage of this.
> >> how this will be accomplished will vary on the support from the Linux
> >> kernel-hacking crowd and eventually hardware vendors themselves (or an
> >> extended VHDL standard is adopted) as a possibility. the possibility of
> >> profit becoming involved eventually does not seem too bad a thing in
> >> itself, but i maintain Linus Torvalds' stance: source code must remain
> >> free.
> >
> >What meaning of 'free' do you use here?  The GNU sense (libre'), or the
> >no-cost sense (gratis)?
> well, i don't think that i can force hardware vendors to support the
> system, so this development will take effort. the effort itself will
> eventually be worth money, but information, once generated, should
> indeed be as free as possible.
> no one can claim any information as their own, and i intend to convince
> people of this in a system where all information is mathematical
> (meta-mathematical?), and hence completely generic.

OK, we agree completely on basics.  Except I think you underestimate the
ability of the free software community to quickly adapt this system.
Maybe you should read more about how excited people are about Linux.  If
they got their hands on a completely-redesigned system, it would probably
get all the necessary drivers written overnight, and I mean that quite
literally.

> >> 	second, the nature of the software (at the core level) requires a
> >> certain kind of mathematical purity that i don't foresee many
> >> programmers adhering to, at least in the beginning, when the interfaces
> >> will be quite 'ad hoc'. at that point, the development will be entirely
> >> derived from within the original group, or at least all inputs would
> >> have to be channeled through the group. 
> >
> >My goal is for everyone to have their own OS.  In order for that to
> >happen, there have to be many different distributions, and no single one
> >official.  I'm not even sure the original developers will be able to
> >decide on one version to emphasize.  But there's nothing wrong with that
> >at all.
> 
> the OS is as much separate from the project as is some library of
> algorithms (like a QuickDraw-like set of API's), for example. i believe
> that each distribution should contain many OS specifications and
> supported hardware platforms.

Yet the OS is a very important part of the reflective mathematical system
because without it the abstractions could not be automated.  Without the
OS, TUNES is just a theoretical model on paper.  Yes, the OS is
conceptually only a derivation of the abstract architecture.  But it's
necessary background because every time anyone uses the abstract
architecture on their computer, the OS will be involved.

The way I have become involved in the project is first trying to develop
an operating system, and realizing we needed more powerful abstraction
tools (languages), then designing those in order to write the OS.  Of
course, the abstraction tools BECOME the OS, but it would be clearer if we
said: 

OSes are designed to treat software components unequally; our system
replaces OSes by introducing a unified system where all software
components are treated equally; and therefore our system is not an OS. 

> >> the issue here is performance
> >> only, i assure you, due to the inherent complexity of the work at that
> >> point. 
> 
> >What do you mean by 'performance'?
> >I agree that the initial work on this system has 'inherent complexity'.
> >But how does it follow that it requires centralized control of
> >development?
> 
> my point is that the encoding of the descriptions has to be easily
> interfaced to the logical engine, so that the complex (NP-complete,
> among other things) analysis of things like memory-management,
> code-generation, and problem-solving will induce as little system
> overhead as possible. in other words, i am saying that without proper
> care, this system will be SLOW. Very Slow. it will crawl on a high-end
> system released 5 years from now. so slow as to drive away most users
> from the system while it is still small. of course, since computing
> power increases quite dramatically over time, this performance lag
> should disappear. however, i intend to have the system quite intelligent
> and fast from the beginning, to help attract attention. i mean, of
> course, blindingly fast at non-reflective/linearly-dynamic actions
> (performance that makes the BeOS pale in comparison), with absolutely no
> blubber associated with reflective actions (i.e. highly streamlined).

Be very certain that performance is only a secondary issue to all the
other design requirements.  We should first make the system, then add
efficiency features.  The mistake of previous systems was that features
(like security, scalability, reuse, expressibility) were sacrificed for
efficiency!

> >> once the system becomes 'self-sustaining' in terms of allowing
> >> 'easy-to-use' interfaces to be used while maintaining the efficiency
> >> required (i.e. it becomes 'infinitely' extensible) (e.g. speed
> >> performance per software environment 'size' ratio < O(sqrt()) ?? ), the
> >> standard of acceptance could be shifted to the interface, allowing the
> >> general programmer to release their work to the public without
> >> interference. at that point, some good proof-generators should have been
> >> built, as well, in support of those second-generation interfaces. i
> >> don't foresee profit becoming more of an issue than it is for today's
> >> shareware-writers beyond that point. i would, however, like to be one of
> >> those shareware applications writers. ;) there will always be people who
> >> don't have enough time to put together a nice package for total
> >> PDA-management or who need someone to manage a software system's
> >> migration to a new platform (say, for a database-management system or
> >> engineering mathematics applications that depend on the processing of
> >> experimental data), and people with the knowledge or time would be there
> >> to help, and probably expect compensation.
> >
> >Easy-to-use-interfaces are what Microsoft wants, not what TUNES wants.  We
> >want a built-in language of a very high level of abstraction, so that it
> >is inherently easy to understand.  No 'interface' to the base system is
> >required.  You can 'use' it directly.
> 
> my apologies for using a buzzword. i didn't mean it that way. i meant it
> to distinguish the new interfaces from today's idiotic interfaces (or
> in-your-face interfaces) which force a particular mentality on the
> person, and therefore only make the person easy-to-use.

Ok.  I have more ambitious plans than you, then, because I want the system
to be easy to use at every level, not just the user interface.

> >There won't be any need to have a team of people, centrally controlling
> >the definition of 'interfaces' in the system.  Any low-level
> >(byte-order-dependent) protocol will be dynamically controlled by the
> >system.  High-level protocols will have ambiguity induced purposefully to
> >allow generic use (and indefinite extension).  Therefore no defined
> >interface is necessary at any level.
> 
> what i'm saying requires you to understand how i intend to make the
> system work in order to avoid a misunderstanding.
> it's like this: i'm trying to make the system's reflective language be a
> type of intensional logic itself. that means no variables. no creation
> of objects. nothing. just a description of mathematical objects required
> for the definition of the language (e.g. possibilities include number
> theory, function theory, ZF set theory, category theory, linear algebra,
> abstract language theory, combinatorial topology). just one big graph to
> describe everything. this original interface WOULD be its own abstract
> VM. interfaces would be reified out of this 'original' interface.
> explaining this to too many people at the project's outset will take
> more time than it will after interfaces have been designed to cover all
> of the possible desired interpretations of how this system will work.
> the internals WILL be accessible to all, it's just that no one would
> WANT to deal with this origin interface in its raw form. this interface
> wouldn't even be explicitly coded in software on most implementations,
> but perhaps a description of it would be necessary (i haven't yet found
> a satisfactory answer to this question, yet).

Here we differ; the original interface in its raw form should be already
abstract, generic, fine-grain, and therefore it will be just as easy to
use as any other part of the system.

The definitions of mathematical objects, and intensional logic, must be
defined reflectively (in terms of themselves).  But the system has uniform
treatment of everything, so these definitions must use objects, even
though they are used to build objects.

You may have a different idea of how to bootstrap the system than I do. 
Actually, Fare and I are working on two different ways to boostrap,
because we don't have any clue which one will work.  You are welcome to
try a third way (with your idea of definitions and intensional logic), and
I encourage you to, frankly because if our methods fail we can adopt
yours.

David Manifold <dem@tunes.org>