JRFC 27 - Hyper Modular Programming System

Over the last six months I've crossed that dark threshold where the desire of building a programming language has become an appealing idea. Terrifyingly, I _might_ actually build this some day. Well, not a language, a programming _system_. The arguments behind its design are long and will be written up some day, but for now I'll just dump the central tenet and core ideas here.
## > Hyper Modularity - write symbols once
### An Illustration

You open your editor and begin to write a function. The first thing you do is write the ([mandatory](https://code.google.com/p/go-wiki/wiki/CodeReviewComments#Doc_Comments)) [doc comment](http://golang.org/doc/effective_go.html#commentary) describing what it does, and the type signature (yes, static typing). As you write, [your editor suggests](http://npmsearch.com/?q=factorial) lists of functions [published to the web](npmjs.org) (public or private) that match what you're typing. One appears promising, you inspect it. The editor loads the code. If it is exactly what you were going to write. You select it, and you're done.

If no result fits what you want, you continue to write the function implementation. You decompose the problem as much as possible, each time attempting to reuse existing functions. When done, you save it. The editor/compiler/system parses the text, analyzes + compresses the resulting ASG to try to find "the one way" (or good enough) to write the function. This representation is then content addressed, and a module consisting of the compresses representation, the source, and function metadata (doc string, author, version, etc) is published to the [(permanent) web](http://ipfs.io/), for everyone else to use.
### Important Ideas
- exporting a symbol (functions, classes, constants, ...) is the unit of modularity (node)
- system centered around writing _functions_ and writing them once (node)
- stress interfaces, decomposition, abstraction, types (haskell)
- use doc string + function signatures to suggest already published implementations (node, Go)
- content address functions based on compressed representations
- track version history of functions + dependents (in case there are bug fixes, etc). (node)
- if a function has a bug, can crawl the code importing it and notify dependents of bugfix. (node, Go)
- use static analysis to [infer version numbers](https://github.com/jbenet/random-ideas/issues/22): `.` (semver inspired)
- when importing, you always bind to a version, but can choose to bind to `/` or just ``
- e.g. `factorial = import QmZGhvJiYdp9Q/QmZGhvJiYdp9Q` (though editors can soften the ugly hashes) (node + ipfs)
- all modules (functions) are written and published to the (permanent) web (public or private)
- when importing a function, you import using its content address, and bind it to an explicit local name (`foo = import ` type of thing)
- the registry of all functions is [mounted locally](https://github.com/jbenet/random-ideas/issues/19) and accessible in the filesystem (ipfs style)
- _hyper modular_ means both to "very modular" and "modules are linked and on the web"

Note: this system is not about the language, it is about the machinery and process around producing, publishing, finding, reusing, running, testing, maintaining, auditing, bugfixing, republishing, and understanding code. (It's more about _the process of programming_, than _expressing programs_). This means that the system only expresses constraints on language properties, and might work with modified versions of existing languages.