One of the many questions that usually wanders through my consciousness while I'm noding is this: what other things might
the E2 engine be good for? We all know how effective (or not, depending on your
POV) it is at maintaining a distributed knowledge/database. What else might it be good for?
There are the usual data collection and organization roles - intranet, knowledge base for a project or organization, collaboration tool for writers, researchers, etc. However, these are all mostly passive roles - they serve as a platform on which the human users of E2 can interact with information, but these interactions are usually limited to reading and writing. While we may debate whether E2 has a 'soul' or a consciousness (which it might, if you susbscribe to the connectivist hypothesis that associational links or connections make up intelligence), there are other possibilities!
My favorite so far arose from a conversation with Crankbear, who had proposed the title Node your Code. When I asked if he meant in a 'code snippet repository' manner, he replied that no, that was what Perlmonks was doing, and well. In an attempt to decide what, in fact, the title *did* mean, here's what we came up with.
E2 could make a bitching OO Integrated Dev Environment.
Please note: while crankbear is in fact a coder, I am not; I am a systems guy who hacks and scripts. However, in my Object Oriented defense, I have used C++, I have hacked around in LISP for an AI course, and I was fervently in love with NewtonScript, God Rest its Soul. Any errors or ludicrous ideas in here are my fault, not his.
Think of it this way - one of the biggest problems (at least, of the ones I have when coding) in an OO environment is maintaining the OO structure in your head. You have to, if you're going to code as opposed to script, because your code will exist, at the base level, as text on a page, where (according to Hiro Protagonist) real hackers live. Coding a sequence of objects is one of the best reasons to rationalize a really really big monitor, or even a Matrox 4xx multi-head card on your Linux box, with the neighbor's 19-inch on your desk when he or she isn't lookin'.
There are tens to hundreds of screebly little text files that you need to keep track of, to say nothing of their inheritance, overloading, location, methods, data structures, yadda, yadda. Some IDEs handle this by allowing you to use two-dimensional representations (the most popular being the flowchart or 2-D tree structure) to manage your codebase. This suffers from various problems. For example, when compiling/debugging/packaging, you may find yourself with around fifty open windows just to help yourself keep track of stuff.
Enter E2.
What if someone implemented an OO interpreter/compiler that was smart enough to traverse a nodespace? Then you could use nodes for objects! Writeups might indicate uses of the objects in different projects. The compiler would be given a base node with the project description and code 'start', and would traverse the nodespace] as indicated by the object relationships in the code.
Whenever an object is invoked, it might declare its inheritance through a hardlink back to its parent. The compiler would b e smart enough to traverse the link and read in the non-superseded code.
Data could be easily stored and switched in and out of the app simply by changing hardlinks. A nodelet could be used for program tracing; another might be used to display variable contents during an interpreted run of the code. Multiple versions of code could be maintained by switching hardlinks. Entire languages or modules might be shifted in and out this way.
There would be a massive speed hit for the compilation/linking phases from using DB references for everything; however, the improvements in organization and code resuse would (IMHO) make this well worth it.
I await any corrections, ideas, challenges with great interest.