On Mon, Jun 13, 2011 at 4:50 AM, BGB <[email protected]> wrote: > > however, unlike full image-based development, the app will generally > "forget" everything that was going on once it is exited and restarted. >
I think this is one of the most annoying "features" of our current computer systems. If I have a project (or 10 or 20 projects) spread out on my workbench, and I leave to have something to eat, or go to sleep, when I return everything is still (more or less) in the state I left it. > > by analogy, it is like running programs in Windows: > one can open/close/run programs, edit things, ... in Windows, and so long as > it is running, it will remember all this; > but, if/when Windows is rebooted, it will forget, and one starts again with > a "clean slate" of sorts (an empty desktop with only their icons and > start-up programs to greet them...). > > but, the merit of rebooting Windows is that it keeps the system "clean", as > running Windows continuously is prone to cause it to degrade over time, and > without an occasional reboot will begin to manifest lots of buggy behavior > and eventually crash (IME, much worse in Vista and Win7 than in XP...). > Long-running stability and continuous upgrading (WITHOUT "rebooting") should be the norm. There should be no such thing as a "boot" process. A system should remain stable (and running) throughout a lifetime of gradual evolution/mutation. Of course, we also need a way to branch/fork/clone/version and even start-from-embryo, to build new systems. The next step is to consider how the "system" (or parts of it) can migrate, or become mobile, among hosts. > >> and essentially, that's what text-file coding (ie editing "offline" code) >> does for us... because things are in files, it's easy to "include" a file as >> one packaged unit, or a group of file, or a "package"... and then that >> "package" can be referred to... separately, and even maintained by someone >> else, and it's not a COPY of the package, it's a reference to it... you >> know? This is incredibly powerful. > > yep. > > I am generally mostly in favor of using files. > Naming is certainly important, as is contextual reference, but I'm not convinced that "files" are a necessary part of providing that mechanism. Consider, as a possible alternative, the idea of parametrizing a module with its dependencies. This is just the principle of applying abstractions to allow local naming (aliasing) of "externally" provided objects. my_module(something_i_need, ...) = ... module specification using something_i_need ... create my_module(provider_of_service, ...) _______________________________________________ fonc mailing list [email protected] http://vpri.org/mailman/listinfo/fonc
