For the most part, these are ideas which need to exist.
Ideas are generally a dime a dozen.
Between ideas and reality is a lot of hard work and skill. If someone else would like to supply the hard work and skill, I'll gleefully reap the benefits and move on to something else. ;^)
I started sketching down possible pattern names after Protospiel 2002. Even this simple list started giving me some insight by noting that some of the best games are almost pure patterns. I've since learned that a pattern language is a lot more than a list of good ideas, and I've also learned that Christoper Alexander is working on generative sequences now, a potentially more usefull development.
(Well, sub my standards. I've certainly seen worse things published ;^)
Offhand; the drafts are in my other OS at the moment
This is what got me started with Debian, in emulation of LiveJournal. My thoughts have since been significantly distracted by the next project.
I had been doing a lot of reading on historical subjects, but it seemed hard to make connections between events. I thought that it would be cool if I could set things on a big interactive timeline, so I could see what context events were occuring in. This raised two issues: First, entering all that data myself would be a royal pain. Second, it wouldn't do anybody else any good. Solution(?): Put it up on the internet and let everyone add events, with a backend database process creating a default consensus of time.
I've since ran across the Wiki community, which makes an interesting counterpoint to the consensual reality model. I'm still pretty scared of time vandals though...
You can program a computer in a lot of ways: C, C++, C#, Java, Smalltalk, Haskell, ML, OCAML, Python, Perl, and probably a few dozen others that I could name with a few moments thought. But if somebody had developed the perfect language, we'd all be using it, right? Some languages will give you fibinocci sequence in one line of code, but if I'm writting a video driver, it is a lot easier and faster if I don't have to jump through hoops to write to a bunch of memory mapped registers. Differnent things are easier to write in different programming paradigms. Sometimes you can link two langauages with a bunch of boreing and error prone 'glue logic,' sometimes you just can't (unless maybe you want to do some high concept compiler modifications yourself.)
Ultimately a language specifies some peice of logic being encoded for a computer, which will be translated into the low level machine instructions of one (or more) particular computers for execution.
What is needed then is the ability to specify that logic in whatever language is most appropriate for the problem at hand. Refactoring the logic into another language may even provide intsights into yet better ways of encoding it.
And when you think about it, the machine code is just another language for the logic, albeit a particularly non-intuitive one for most people.
What we need then is a logic representation in a variation of the "abstract syntax trees" familar to compiler writers. This format is a favorite of compiler writers because it is a lot easier to have the computer perform transformations on the AST than on most other represnations of the logic.
The goal is Model + Transformations. Major transformations will include input/output filters for various langauges. Once a transformation pool is established, it should be a matter of specifiying a subset and adding a few more to support a new langauge; but these transformations can then be used to enable yet more languages. Some of the languages will be machine languages; 'compiling' is just another output filter. Reverse engineering is just the same filter in reverse, which is going to scare a lot of people.
Transformations also need to exist at the highest levels. To choose a simple example, once a transformation exists for "insertion sort," the system should be able to identify insertion sorts and store the operations as only a single element in the model, regenerating the steps in a langauge-appropriate manner every time they are needed. Better, have the concept of "sort," with the particular implementation chosen varying with the target settings in force at the time: clarity, size, speed, and so on.
These ideas are not really new. In particular see [Swaine2001] for universal filters, [PeytonJones1996] for using model + transformations in a haskell compiler, [Tilkov] for some primitive model based programming, and [Ecplise] for a current attempt at a universal IDE; the langauges are still separate however. Some of the eclipse subprojcts are also beginning to scratch the surface of some of the issues that concern me.
Just ran across [PTorg] looking up the other references. Have to look this over some time soon...
It's not that the ideas arn't out there, it's just that I haven't found anyone who has put them together yet. I guess that leaves it to me.