[Draft]

Nota Bene: This file contains many ideas to insert in the text as it is rewritten. The ideas are in no particular order (not even order of chronological appearance), having been put at random places in the file as they came, or were moved from the written text, since late january 1995 when redacting this article began.



Summary

  • Axioms:

    Current computers are all based on the von Neumann model in which a centralized unit executes step by step a large program composed of elementary operations. While this model is simple and led to the wonderful computer technology we have, laws of physics limit in power future computer technology to no more than a grand maximum factor 10000 of what is possible today on superdupercomputers.
    This may seem a lot, and it is, which leaves room for many improvement in computer technology; however, the problems computer are confronted to are not limited anyway by the laws of physics. To break this barrier, we must use another computer model, we must have many different machines that cooperate, like cells in a body, ants in a colony, neurones in a brain, people in a society.

    Machines can already communicate; but with existing "operating systems" the only working method they know is "client/server architecture", that is, everybody communicating his job to a one von Neuman machine to do all the computations, which is limited by the same technological barrier as before. The problem is current programming technology is based on coarse-grained "processes" that are much too heavy to communicate; thus each job must be done on a one computer. machine that executes Computing s all the requirement to be used as for Tunes, or design a new one if none is found.


    That is, without ADTs, and combinating ADTs, you spend most of your time manually multiplexing. Without semantic reflection (higher order), you spend most of your time manually interpreting runtime generated code or manually compiling higher order code. Without logical specification, you spend most of your time manually verifying. Without language reflection, you spend most of your time building user interfaces. Without small grain, you spend most of your time manually inlining simple objects into complex ones, or worse, simulating them with complex ones. Without persistence, you spend most of your time writing disk I/O (or worse, net I/O) routines. Without transactions, you spend most of your time locking files. Without code generation from constraints, you spend most of your time writing redundant functions that could have been deduced from the constraints.

    To conclude, there are essentially two things we fight: lack of feature and power from software, and artificial barriers that misdesign of former software build between computer objects and others, computer objects and human beings, and human beings and other human beings.

  • More than 95% of human computing time is lost about Interfaces: interfaces with the system, interfaces with the human. Actual algorithms are very few, heuristics are at the same time few and too many, because the environment makes them unreliable. Interfaces can and should be semi-automatically deduced.
  • More generally, the problem with existing systems is lack of reflectivity, and lack of consistency: you can't simply, quickly, reliably, automate any kind of programming. in a way such that system consistency be enforced.
  • Persistence is necessary for AI:

    To conclude, I'll say

  • Stress on comput*ing* systems means having a computer *Project* not only a computer *Object*.
  • Why are existing OS so lame ? For the same reason that ancient lore is completely irrelevant in nowadays' world:
    At a time when life was hard, memories very small and expensive, development cost very high, people had to invent hacker's techniques to survive; they made arbitrary decisions so survive with their few resources; They behaved dirtily, and thought for the short term.
    They had to.

    Now, technology has always evolved at an increasing pace. What was experimental truth is always becoming obsolete, and good old recipes are becoming out of date. Behaving cleanly and thinking for the long term is made possible.
    It is made compulsory.
    The problem is, most people don't think, but blindly follow traditions. They do not try to distinguish what is truth and what is falsehood in traditions, what is still true, and what no longer stands. They take it as a whole, and adore it religiously, sometimes by devotion, most commonly by lack of thinking, often by refusal to think, rarely but already too often by a hypocrit calculus. Thus, they abdicate all their critical faculties, or use it against any ethics. As a result, for the large majority of honest people, their morals are an unspeakable burden, mixing common sense, valid or obsolete experimental data, and valid, outdated, or false rules, connected and tangled in such a way that by trying to extract something valid, you come up with a mass of entangled false things that are associated, and that when extirping false things, you often destroy the few that were valid together. The roots of their opinions are not in actual facts, but in lore, hence their being only remotely relevant to anything.

    Tunes intends to rip off all these computer superstitions.


    Things below are a draft.


    III. No computer is an island, entire in itself

    1. Down to actual OSes
    2. .....


    3. Humanly characteristics of computers
    4. persistence, resilience, mobility, etc....

      response to human


      • Centralized code
      • There's been a craze lately about "client/server" architecture for computer hardware and software. What is "client/server" architecture that many corporations boast about providing ?
        .....
        conceptually, a server is a centralized implementation for a library; centralized=>coarse-grained; now, coarse grained=>evil; hence centralized=>evil. we also have centralized=>network bandwidth waste. only "advantage": the concept is simple to implement even by the dumbest programmer. Do corporations boast about their programmers being dumb ?
        .....
        A very common way to share code is to write a code "server" that will include tests for all the different cases you may need in the future and branch to the right one. Actually, this is only some particular kind of library making, but much more clumsy, as a single entry point will comprise all different behaviours needed. This method proves hard to design well, as you have to take into account all possible cases to arise, with predecided encoding, whereas a good encoding would have to take into account actual use (and thus be decided after run-time measurements). The obtained code is slow as it must test many uncommon cases; it is huge, as it must take into account many cases, most of them seldom or never actually used; it is also uneasy to use, as you must encode and decode the arguments to fit its one entry point's calling convention. It is very difficult to modify, but by adding new entries and replacing obsolete subfunctions by stubs, because it would else break existing code; it is very clumsy to grant partial access to the subfunctions, as you must filter all the calls; security semantics become very hard to define.

        Centralized code is also called "client-server architecture"; the central code is called the server, while those who use it are called clients. And we saw that a function server is definitely something that no sensible man would use directly; human users tend to write a library that will encapsulate calls to the server. But it's how most operating systems and net-aware programs are implemented, as it's the simplest implementation way. Many companies boast about providing client-server based programs, but we see there's nothing to boast about it; client-server architecture is the simplest and dumbest mechanism ever conceived; even a newbie is able to do that easy. What they could boast about would be not using client-server architecture, but truely distributed yet dependable software.

        A server is nothing more than a bogus implementation for a library, and shares all the disadvantages and limits of a library, with enhanced extensibility problem, and additional overhead. It's only advantage is to have a uniform calling convention, which can be useful in a system with centralized security, or to pass the stream of arguments through a network to allow distant client and servers to communicate. This last use is particularly important, as it's the simplest trick ever found for accessing an object's multiple services through a single communication line. Translating software interface from library to server is called multiplexing the stream of library/server access, while the reverse translation is called demultiplexing it.


      • Multiplexing: the main role of an OS
      • Putting aside our main goal, that is, to see how reuse is possible in general, let us focus on this particular multiplexing technique, and see what lessons we can learn that we may generalize later.

        Multiplexing means to split a single communication line or some other resource into multiple sub-lines or sub-resources, so that this resource can be shared between multiple uses. Demultiplexing is recreating a single line (or resources) from those multiple ones; but as dataflow is often bi-directional, this reverse step is most often unseparable from the first, and we'll only talk about multiplexing for these two things. Thus, multiplexing can be used to share a multiple functions with a single stream of calls, or convertly to have a function server be accessed by multiple clients.

        Traditional computing systems often allow multiplexing of some physical resources, thus spliting them into a first (but potentially very large) level of equivalent logical resources. For example, a disk may be shared with a file-system; CPU time can be shared by task-switching; a network interface is shared with a packet-transmission protocol. Actually, what any operating system does can be considered multiplexing. But those same traditional computing systems do not provide the same multiplexing capability for arbitrary resource, and the user will eventually end-up with having to multiplex something himself (see the term user-level program to multiplex a serial line; or the screen program to share a terminal; or window systems, etc), and as the system does not support anything about it, he won't do it the best way, and not in synergy with other efforts.

        What is wrong with those traditional systems is precisely that they only allow limited, predefined, multiplexing of physical resources into a small, predefined, number of logical resources; there they create a big difference between physical resources (that may be multiplexed), and logical ones (which cannot be multiplexed again by the system). This gap is completely arbitrary (programmed computer abstractions are never purely physical, neither are they ever purely logical); and user-implemented multiplexers must cope with the system's lacks and deficiencies.


      • Genericity
      • Then what are "intelligent" ways to produce reusable, easy to modify code? Such a method should allow reusing code without duplicating it, and without growing it in a both unefficient and uncomplete way: an algorithm should be written once and for once for all the possible applications it may have, not for a specific one. We have just found the answer to this problem: the opposite of specificity, genericity.

        So we see that system designers are ill-advised when they provide such specific multiplexing, that may or may not be useful, whereas other kind of multiplexing is always needed (a proof of which being people always boasting about writing -- with real pain -- "client/server" "applications"). What they really should provide is generic ways to automatically multiplex lines, whenever such thing is needed.

        More generally a useful operating system should provide a generic way to share resources; for that's what an operating system is all about: sharing disks, screens, keyboards, and various devices between multiple users and programs that may want to use those accross time. But genericity is not only for operating systems/sharing. Genericity is useful in any domain; for genericity is instant reuse: your code is generic -- works in all cases -- so you can use it in any circumstances where it may be needed, whereas specific code must be rewritten or readapted each new time it must be used. Specificity may be expedient; but only genericity is useful on the long run.

        Let us recall that genericity is the property of writing things in their most generic forms, and having the system specialize them when needed, instead of hard-coding specific values (which is some kind of manual evaluation).

        Now, How can genericity be achieved ?


      • features: high-level abstraction Real-time, reflective language frame, code & data persistence, distribution, higher order
      • misfeatures: low-level abstraction explicit batch processing, adhoc languages, sessions & files, networking, first order
    5. Somewhere: develop the idea of adequateness of information, and show how it relates to pertinency.
  • The Internet is a progress, in that people can publish documents. But these documents are mostly passive. Those that are not suppose highly-qualified specialists to care about;
  • More generally, in any system, for a specialized task, you may prefer dumb workers that know well their job to intelligent workers that that cost a lot more, and are not so specialized. But as the tasks you need to complete evolve, and your dumb workers don't, you'll have to throw them away or pay them to do nothing as the task they knows so well is obsolete; they may look cheap, but they can't adapt, and their overall cost is high for the little time when they are active; In a highly dynamic world, you lose at betting on dumbness, and should invest on intelligence.

  • whereas with the intelligent worker, you may have to invest in his formation, but will always have a proficient collaborator after a short adaptation period. After all, even the dumb worker had to learn one day, and an operating system was needed as a design platform for any program.

  • People tend to think statically in many ways.
  • When confronted with some proposition in TUNES, people tend to consider it separated from the rest of the TUNES ideas, and they then conclude that the idea is silly, because it contradicts something else in the traditional system design. These systems indeed have some coherency, which is why they survived and were passed by tradition. But TUNES tries to be much more coherent even,
  • At the time when the only metaprogramming tool was the human minds of specialized engineers, because memories were too small, which is very expensive and cannot deal with too much stuff at once, a run-time hardware protection was wishable to prevent bugs in existing programs from destroying data, even though th But now that computers have enough horsepower to be useful metaprogrammers, the constraints change completely.
  • Dispell the myth of "language independence", particularly about OSes. which really means "interfaces to many language implementations"; any expressive-enough language can express anything you expressed in another language in many ways.
  • And as the RISC/CISC then MISC/RISC concepts showed, the best way to achieve this is to keep the low-level things as small as possible, so as to focus on efficiency, and provide simple (yet powerful enough) semantics. The burden of combining those low-level things into useful high-level objects is then moved to compilers, that can do things much better than humans, and take advantage of the simpler low-level design.
  • Now, the description could be restated as: "project to replace existing Operating Systems, Languages, and User Interfaces by a completely rethough Computing System, based on a correctness-proof-secure higher-order reflective self-extensible fine-grained distributed persistent fault-tolerant version-aware decentralized (no-kernel) object system."
  • GC&Type checking need be in developing version, not in developed version.
  • Nobody should be forced by the system itself into proving one's program correctness with respect to any specification. Instead, everyone is enabled to write proofs, and can require proofs from others.
    Thus, you can know precisely what you have and what you don't when you run code. When the code is safe, you know you can trust it. When it ain't, you know you shouldn't trust it.
    Surely, you will object that because of this system, such man will now require you to give a proof that you can't or won't give to him, so NOW you can't deal with him anymore. But don't blame it on the system. If the man wants the proof, it means he'd expected your provided software to behave accordingly in the past, but just couldn't require a proof, which was impossible. By dealing with the man, you'd have been morally and/or legally bound to provide the things that he now asks a proof for. Hence the proofable system didn't deprive you from making any lawful thing. It just helped formalize what is lawful and what isn't.
    If the man requires so difficult proofs that he can't find any provider to that, he will have to adapt, die, or pay more.
    If the man's requirements are outrageously excessive, and no-one should morally provide him the proofs, then he obviously is a nasty fascist pig, or whatever, and it's an improvement that no-one will now deal with him.
    To sum up things, being able to write/read/provide/require proofs means being able to transmit/receive more information. This means that people can better adapt to each other, and any deal that the system will cancel was an unlawful deal, replaced by better deals. Hence this technology increases the expressivity of languages, and does not decrease it. The system won't have any statical specification, but will be a free market for people having specifications and people having matching software to safely exchange code against money, instead of being a blind racket.
  • People like that because Perl guesses usually right what you want it to do, it's a great language that allows rapid development of small programs;
    other people will object that because your programs will then depend on guesses, you can't reliably develop large programs and be confident that you don't depend on a guess that may prove wrong in certain conditions, or after you modify your program a bit.

    But why should you depend on guesses? A Good programming language would allow you

    • to control how the guesses are done, enable some tactics, disable some others, and write your own.
    • to make the guesses explicitly appear or disappear in the program by automatic semantic-preserving source-to-source transformations.
  • i saw your answer about an article in the news, so i wanna know, what is Tunes ?
  • Well, that's a tough one. Here is what I told Yahoo: "TUNES is a project to replace existing Operating Systems, Languages, and User Interfaces by a completely rethough Computing System, based on a correctness-proof-secure higher-order reflective self-extensible fine-grained distributed persistent fault-tolerant version-aware decentralized (no-kernel) object system."

    Now, there are lots of technical terms in that. Basically, TUNES is a project that strives to develop a system where computists would be much freer than they currently are: in existing systems, you must suffer the inefficiencies of

    • centralized execution [=overhead in context switching],
    • centralized management [=overhead and single-mindedness in decisions],
    • manual consistency control [=slow operation, limitation in complexity],
    • manual error-recovery [=low security],
    • manual saving and restoration of data [=overhead, loss of data],
    • explicit network access [slow, bulky, limited, unfriendly, unefficient, wasteful distribution of resource],
    • coarse-grained modularity [=lack of features, difficulty to upgrade]
    • unextensibility [=impossibility to do things oneself, people being taken hostage by software providers]
    • unreflectivity [=impossibility to write programs clean for both human and computer; no way to specify security]
    • low-level programming [=necessity to redo things again everytime one parameter changes].
    If any of these seems unclear to you, I'll try to make it clearer in
  • Note that Tunes does not have any particular technical aim per se: any particular technique intended for inclusion in the system has most certainly already been implemented or proposed by someone else already, even if we can't say where or when. Tunes does not claim any kind of technical originality. Tunes people are far from being the most proficient in any of the technical matters that they'll have to use, and hope that their code will be eventually replaced by better code written by the best specialists wherever applicable. But Tunes is not an empty project for that. Tunes does claim to bring some kind of original information, just not of a purely technical nature, but instead, as a global frame to usefully combine those various techniques as well as arbitrary future ones into a coherent system, rather than have them stay idle gadgets that can't reliably communicate with each other. We Tunes people hope that our real contribution will be the very frame in which the code from those specialists can positively combine with each other, instead of being isolated and helpless technical achievements. Even if our frame doesn't make it into a worldwide standard, we do hope that our effort will make such a standard appear sooner than it would have without us (if it ever would), and avoid the traps that we'll have uncovered.
  • unindustrialized countries: the low reliability of power feeds make resiliant persistency a must.
  • Part I:
    • (I.10 ?) utility -- correlation to static ou dynamic features [current OSes] informational basis that gives meaning to the flux of raw information; dynamical structure
    • (I.11 ?) kernel, centralism, authority
    • (I.12 ?) The ultimate source of meta(n)-information: Man

  • In this article, we have started from a general point of view of moral Utility, and by applying it to the particular field of computing, we have deduced several key requirements for computing systems to be as useful as they could be. We came to affirm concepts like dynamism, genericity, reflectivity, separation and persistency, which unhappily no available computing system fully implements.

    So to conclude, there is essentially one thing that we have to fight: the artificial informational barriers that lack of expressivity and misdesign of former software, due misknowledge, misunderstanding, and reject of the goals of computing, build between computer objects and others computer objects, computer objects and human beings, human beings and other human beings.

    ....

  • Knowledge is structured information.

  •          an open system,
             where computational information can efficiently flow
             with as little noise as possible.
    
    Open system means that people can contribute any kind of information
    they want to the available cultural background,
    without having to throw everything away and begin from scratch,
    because the kind of information they want to contribute does not
    fit the system.
       Example: I can't have lexical scopes in some
    wordprocessor spell-checker, only one "personalized dictionary"
    personalized at once (and even then, I had to hack a lot
    to have more than one dictionary,
    by swapping a unique global dictionary). So bad.
    I'll have to wait for next version of the software.
    Because so few ask for my feature, it'll be twenty years until
    it makes it to an official release. Just be patient.
    Or if I've got lots of time/money, I can rewrite the whole
    wordprocessor package to suit my needs. Wow!
       On an open system, all software components must come in small grain,
    with possibility of incremental change anywhere,
    so that you can change the dictionary-lookup code to handle
    multiple dictionaries merged by scope, instead of a unique global one,
    without having to rewrite everything.
    
       Current attempts to build an open system have not been fully successful.
    The only successful approach to offer fine-grained control on objects
    has been to let sources freely available,
    allowing independent hackers/developers to modify and recompile;
    but apart from the object grain problem,
    this doesn't solve the problems of open software.
       Other problems include the fact
    This offers no semantical control of
    seamless data conservation accross code modification;
    contributions are not really incremental in that
    the whole software must be integrally recompiled, stopped, relaunched;
    Changes that involve propagation of code among the whole program
    cannot be done incrementally with non
    because they
    
    
    because many semantical changes are to be manually propagated
    accross the whole program.
    
    "as little noise as possible": this means
    that algorithmic information can be passed
    without any syntactical or architectural constraint in it
    that would not be specifically intended;
    that people are never forced to say
    either more than they mean or less than they mean.
       Example: with low-level languages like C,
    you can't define a generic function to work on any integer,
    then instanciate to the integer implementation that fits
    the further problem.
    If you define a function to work on some limited number type,
    then it won't work on longer numbers than the limit allows,
    while being wasteful when cheaper more limited types might have been used.
    Then if some 100000 lines after, you see that after all,
    you needed longer numbers, you must rewrite everything,
    while still using the previous version for existing code.
    Then you'll have two versions to co-debug and maintain,
    unless you let them diverge inconsistently, which you'll have to document.
    So bad. This is being required to say too much.
       And of course, once the library is written,
    in a way generic enough so it can handle the biggest numbers you'll need
    (perhaps dynamically sized numbers),
    then it can't take advantage of any particular situation
    where the known constraints on numbers
    could save order of magnitudes in computations;
    of course, you could still rewrite yet another version of the library,
    adapted to that particular knowledge,
    but then you again have the same maintenance problems as above.
    This is being required to say too little.
       Any "information" that you are required to give the system
    before you know it, without your possibly knowing it,
    without your caring about it,
    with your not being able to adjust it when you further know more,
    all that is *noise*.
       Any information that you can't give the system,
    because it won't heed it, refuse it as illegal,
    implement in so inefficient a way that it's not usable,
    is *lack of expressiveness*.
       Current languages are all very noisy and inexpressive.
    Well, some are even more than others.
       The "best" available way to circumvent lack of expressiveness from
    available language is known as "literate programming",
    as developed, for example, by D.E.Knuth with his WEB and C/WEB packages.
    With those, you must still fully cope with the noise of a language like C,
    but can circumvent its lack of expressiveness,
    by documenting in informall human language
    what C can't express about the intended use for your objects.
       Only there is no way accurately verify that
    objects are actually used consistently
    with the unformal documented requirements,
    which greatly limits the (nonetheless big) interest of such techniques;
    surely you can ask humans to check the program for validity
    with respect to informal documentation,
    but his not finding a bug could be evidence
    for his unability to find a real bug,
    as well as the possible absence of bug,
    or the inconsistency of the informal documentation.
    This can't be trusted remotely as reliably as a formal proof.
       The Ariane V spacecraft software
    had been human-checked thousands of times against informal documentation,
    but still, a software error would have $10^9 disappear in fumes;
    from the spacecraft failure report,
    it can be concluded that the bug
    (due to the predictable overflow
    of an inappropriately undersized number variable)
    could have been *trivially* pin-pointed by formal methods!
    Please don't tell me that formal methods are more expensive/difficult
    to put in place than that the rubbish military-style red-tape-checking
    that was used in place.
       As a french taxpayer,
    I'm asking immediate relegation of the responsible egg-heads
    to a life-long toilet-washing job
    (their status of french "civil servants" prevents their being fired).
    Of course my voice is unheard.
       Of course, there are lots of other software catastrophes
    that more expressive languages would have avoided,
    but even this single 10 G$ crash would pay more than
    it would ever cost to develop formal methods
    and (re)write all critical software with!
    

    People are already enough efficiency-oriented so that TUNES needn't invest a lot in it, just providing a general frame for others to insert optimization into. In the case of a fine-grained dynamic reflective system, this means that hooks for dynamic partial evaluation must be provided. This is also an original idea, that hasn't been fully developed. contribution that TUNES

  • Because it ain't in the Kernel doesn't mean it ain't done. [Because the government doesn't do it doesn't mean nobody does it].
  • The Kernel is there as a warrant that voluntarily agreed contracts between objects be respected: if function F is ready to trade a golden coin from some quantity of gold powder, the kernel will see that people trading with F will actually provide the right amount of gold powder, whereas F will actually return a gold coin.

  • "Compilers can not guarantee a program won't crash." have I been told.
    Surely, given an expressive enough language, there is no compiler that can tell for an arbitrary program whether it will crash or not.
    Happily, computers are not used to run random arbitrary programs!!! Well, there's genetic programming and corewar, fair enough. When you program,
    • you know what you want, so you know what a correct program is, and more easily even what a non-crashing program is.
    • you write your program specifically so you can prove to yourself that the program is correct.
    • if programming under contract, you are expected to have done the former, even though the customer has no way to check, but perhaps having you fill red tape.
    Well, instead of all these knowledge and proofs to stay forever untold and unchecked, it is possible to use a language that can express them all! A computer language could very well express all the requirements for the program, and logically check a proof that they are fulfilled.

  • Contrarily to the socialists, who say that a state-ruled society is the End of History, the Authentic Liberals do not say that a free, fair, market is the end of history; on the contrary, they say that a free, fair, market, is the beginning of history; it is a prerequisite for information to pass well, for behaviors to adapt, for changes to operate, for history to exist. The freer, fairer the market, the more history.

  • It is amazing that researchers in Computer Science are not developing branches of a same software, but everytime rewriting it all from scratch. For instance, people experimenting with persistence, migration, partial evaluation, replication, distribution, parallelization, etc, just cannot write their part independently from the others. Their pieces of code cannot combine, and if each isolated technical point is proven possible, they are never combined, and techniques can never really be fairly compared, because they are never applicable to the same data.

    It is as if mathematicians would have to learn a completely new language, a completely new formalism, a completely new notation, for every mathematical theory! As if every book couldn't actually assume results from other books, unless they were proven again from scratch.

    It is as if manufacturers could not assemble parts unless they all came from the same factory.

    Well, such phenomena happen in other place than computer software, too. Basically, it may be conceived as a question of lack of standards. But it's much worse with computer software, because computer software is pure information. When software is buggy, or unable to communicate, it's not worth a damn; it ain't even good as firewood, as metal to melt or anything to recycle. Somehow, the physical world is a universal standard for the use of physical objects. There's no such thing in the computer world where all standards are conventional.


  • Previous: Bibliography
  • Up: Table of Contents


    To Do on this page

  • All stuff in it should be transferred to the definitive version or deleted.


    Faré -- rideau@clipper.ens.fr