Xp System

Some thoughts on XP by MikeStump.

I have an idea for a new project. Actually, it is an old idea of mine, and one that I see from time to time in various forms. What would the world be like, if you took all code that one can get via FTP, and applied AutomatedRefactoring and then maybe topped it off with RefactorMercilessly. What if you through in a decompiler, and included demoware, warez site software and just for grins and you chucked in all the software you could get your hands on? What if then you threw out all the fringe software (software near the edges) and distilled the lot into an elegant library of commonly used stuff.

What if the refactoring operations were contributed back the code authors/maintainers in the form of software libraries and refactoring operations? Would this advance software in general, or hurt it?

For real OnceAndOnlyOnce programming, I think the world needs a programming environment (singular). This would have to be unlike any system I know. First, you have to be able to refactor across all software in the world. You'd have to be able to change all interfaces and all implementations. The idea of CppUnit, DelphiUnit, OcUnit, PerlUnit and so on, seems to violate OnceAndOnlyOnce to me. If you don't buy that, take a look at WikiWikiClone, maybe that will convince you we're doing something wrong. The grand idea is that you need one language and that language has to be as flexible as WikiWikiWeb is to work. What is there today, so to speak, is the best idea of what should be there, and if someone discovers a new need, they implement it, refactor and life continues.To manage offline development, once fixates the various interfaces, and sometime later, applies all the various refactoring operations that have been queued since the last sync point.

I checked around found WikiWithProgrammableContent, not quite right. First, no security, in the WikiWiki sense. Security would be a flaw. Also, one has to be able to _change_ the language translator underneath such a tool. Think, add a MetaLevel. SoftWiki is also kinda close, but you can't change the TCL interpreter underneath. It would need a wiki language underneath to work. Also, one has to be able to have it span into new systems easily, and span into the processor and disk easily, for a real system.

There was a comment that you can't change a CPU, well, I have news for you. There things called FPGAs, they are chips that are wired to let you rewire them on the fly. Taken to its logical conclusion, this project would of course be able to handle both the synthesis of FPGAs and even chip design and layout. This is a longer term goal, which is why I didn't list it initially on this page. But make no mistake, that is one of the directions I would like to see the software evolve. When you get down to it, the raw element is a NAND gate with the property of delay and a wire. Everything else is a man made invention on top of it. You can see my digital slant here. An analog person would of course have a different view I am sure. In the fullness of time (read, real long term), this project would also bridge this gap.

They're still just TuringMachines. Whether you're synthesizing gates or generating TCL is a performance detail.

No, FpgasAreNonTuring.

See also: SoftWiki (for something that starts to come close)

You can't change the Tcl interpreter under SoftWiki, but you can't change the instruction set in your CPU either. Ultimately, both a C++ compiler and the Tcl interpreter translate or interpret your code terms of a binary code understood by your CPU, and the CPU interprets that binary code in terms of tiny patterns of logic etched into silicon. Those patterns might be very orthogonal (as in the case of an FPGA) but they're still etched. In both cases, you implement new languages using the fixed languages you have.

I suspect that no language will ever really be able to scale in a meaningful way (meaningful for humans, that is) all the way up to interactive 3-D video and down to gate arrays on silicon (or any other material for that matter). NAND gates can't do garbage collection, nor can one NAND gate interpret a string of Unicode characters to figure out which other NAND gates it should be talking to. With sci-fi tech like generalized asynchronous CPU technology (CPU-sized FPGAs are sci-fi tech too, for that matter), software could be defined in terms of rearranging CPU logic on the fly--then you'd need a new language that could express just that, elegantly. Just try translating a non-trivial program to each of Lisp, Perl, Tcl, Python, Java, C, and C++--without changing its semantics or performance characteristics for either speed or storage by more than one order of magnitude.

This would seem to imply that there would have to be several XpSystem languages, each evolving at different rates to serve different needs. So the "XpSystem language" would be a group of languages each maintained as part of the XpSystem.

Tcl seems to require less syntax (fewer words, less punctuation) for short programs that do mostly string-manipulation operations, which seems to combine an important part of the WikiEssence--being quick and short--with an important goal of SoftWiki--being a sandbox for a huge pile of quick and short CGI programs. SoftWiki is application-specific, after all: it's a Wiki, first and foremost, and not a final solution for all software problems. --ZygoBlaxell

Microsoft Research has IntentionalProgramming. Description text here moved to IntentionalProgramming

Assuming IP is everything it claims to be, it's the ultimate solution for OnceAndOnlyOnce as outlined above.

There is a page here (somewhere) which describes 'Code in the Database'. IIRC it was a link to a collection of potential student projects, one being the idea of storing code (well, a model of the code) in a database, so you could do more intelligent things with it, like refactoring, emacs+ctags-style jumping to the location of a piece of code from its caller, UML diagramming and so on. The description was very like IP but I think it was only being applied to Java - C-like languages can be so abused with macros, for instance, that the meaning can be very hard to reverse-engineer. Can anyone remember where this page was? and replace my rambling description with a See Also? Thanks!

Open Source software (Linux, FreeBSD, et. al) certainly seems to be an experiment in this programming model. Changes need to be propagated manually or with minimal automation, but they do get propagated. It seems to be an advancement of some kind, especially considering the tiny resources they work with.

Debian and FreeBSD (including the "ports" collection) are very large collaborative Open Source software projects where any contributor can modify any part of the project, including the infrastructure used to build it. Users of the system must take explicit action to have updates from the shared infrastructure propagated to their machines (so that a fatal error introduced into the shared infrastructure doesn't automatically destroy any machine based on that infrastructure), but once you the action is initiated, the process of integrating the update into your machine is mostly automatic. The software project contains a complete Unix-like operating system (Linux), the toolchain used to develop, compile, debug, and use it, and a thousand or two user-level applications that run inside it.

Contributors to Debian or FreeBSD have to be registered, but beyond that there is no distinction between one contributor and another--in that sense, it has some WikiEssence--and the limitation of write privilege outside the community is typically not a problem because the peer review implied in preparing and submitting changes as a difference set to existing member of the community (and probably someone experienced with the code in question) seems to be a benefit in itself.

These projects also come with a culture, a set of rules for the participants that tells them where and when it's appropriate to exercise their power to make changes. It's like a WikiWiki with pages that contain strict community-enforced rules about modifying certain other pages.

Two observations from these projects relevant to this page: One, people don't like it when you RefactorMercilessly code that currently exists and is working, unless you also provide evidence that the old code was non-existent or broken. Two, and this is particularly noticeable in Debian, is that OnceAndOnlyOnce is not necessarily desirable, or at least has a cost that has to be considered against its benefit. Debian features at least one text editor written in every major user interface toolkit, from line-oriented non-interactive all the way up to themable GNOME with integration into other applications--definitely not OnceAndOnlyOnce. --ZygoBlaxell

The OS/2 filesystem, was completely object oriented, and thus a link or short cut was a reference to the ObjectByID. So, if you change the name of the object, that didn't matter, all the references were updated automatically.

This behavior suggests something to me. Software is really just a bunch of references to some underlying implemenation details. Either language symantics, or collections of language semantics. In this discussion, it appears that if every reference to a collection of semantics (a method invocation or function call) was by signature, and included the version of the object referenced and the instance of the method, then when the API changed, the method call could be invalidated, the execution stopped, and the user prompted to fix the problem. If you wanted to do this at compile time, you could as well. As the software was typed in, the IDE would create the correct reference information in the source file so that a compiler would be able to validate the reference, and instruct the user or compilation system what the problem is.

Thus, an API that had

void a(String b)
int a(String b, int v)

but required an additional parameter be added so that we get

void a(String b, int x)
int a(String b, int v, int x)

would be able to detect which method applied and tell you that a new parameter was required to continue to use the correct method, instead of giving you a ReturnTypeMismatch? error...

We are still relying on textual representations of software, and that in and of itself creates problems...

GreggWonderly