h a l f b a k e r yBusiness Failure Incubator
add, search, annotate, link, view, overview, recent, by name, random
news, help, about, links, report a problem
browse anonymously,
or get an account
and write.
register,
|
|
|
Most computer systems and programming languages are based on the notion of "programs" or "functions" which, when run, accept input and produce output. If the input changes, you have to run the program again. If you want it to respond automatically to input changes, you need to build a domain-specific
"notification" or "polling" system that automatically re-runs the appropriate routines and updates the output accordingly.
Because this is difficult, all too often the user must manage this process themselves. If you update a service configuration file, you have to restart the service (or even reboot the machine). If you change a Web page, you have to hit "reload" to see the changes. If you edit source code, you have to recompile. If one user changes a document, another user has to re-open the file to see the changes.
Spreadsheets represent a notable exception to this paradigm. With spreadsheet software, the user can construct fairly complex programs, but the spreadsheet application takes care of all the dependency management. If the inputs change, the outputs are recalculated automatically; sophisticated algorithms determine what needs to be recomputed and what doesn't. This happens in real time as you're writing the program and editing its input; you almost never have to "compile" or "run" or "refresh" anything... it's just *there*.
So, I propose constructing an operating system around this paradigm. Ignore the silly row/column grid, I'm talking about the automatic dependency part. The basic programming language would be fully dynamic; if you say "int x = y + z;", and the value of "y" changes, "x" would change as well.
Because the system would be managing and optimizing dependency updates at a low level, everything would be automatically and robustly updated. The moment you commit a change to a configuration file, all affected services change their behavior. If one user edits a file, another user sees the changes immediately reflected in their editor. If you write some code, you see the output of the code dynamically change as you edit the program.
(There are lots of implementation details. You'd probably need some low-level components written in the "traditional" fashion for performance. Some algorithms are simply not suitable for incremental update, and the "refresh rate" would need to be controlled appropriately; we might not be able to get away from manual triggers altogether. Since half-baked code and data would be "executed" all the time as people made changes, there would need to be a good isolation system and a "commit" strategy to prevent too much damage. You don't *want* the recipient of your e-mail to see it until you're done!)
[sorry this is so long... and sorry all my ideas are nerdy.]
Virtual Memory
http://www.microsof...ctOview/ntarc_7.asp
Point out differences between what you're calling for and linked OS hosts. [reensure, Oct 18 2000]
Vapour
http://vapour.sourceforge.net/
The Vapour Operating System Project [dnm, Oct 18 2000, last modified Oct 17 2004]
Ralf Moller's Symbolics Museum
http://kogs-www.inf...info/symbolics.html
Information, pictures, and papers about Symbolics Lisp Machines, Symbolics Genera, et alia. [dnm, Oct 18 2000, last modified Oct 17 2004]
Adaptive Functional Programming
http://www-2.cs.cmu...pers/afp/popl02.pdf
[egnor, May 30 2002, last modified Oct 17 2004]
[link]
|
| |
As you say - there are many situations where you wouldnt want change to be dynamic |
|
| |
Also I suspect there are processing time implications. It usually takes several seconds to compile a small program so your machine would be busy while it did this every so often |
|
| |
Having the ability to control dynamic update (suspending it when appropriate, using sandboxed testing environments, applying version control) would be far superior to never having it available, whether you want it or not. |
|
| |
It takes several seconds to compile a small program, but perhaps that's simply because compilers are not designed to be incremental. Most of that time is spent starting and stopping the compiler, reading in a lot of header files (which never change), etc.. |
|
| |
(That said, languages like C aren't really amenable to incremental compilation, hacks like "ups" notwithstanding. I imagine incremental execution would be more appropriate for the "scripting language" that holds this system together, or perhaps even for the system programming language used to build the thing.) |
|
| |
I put this at the operating system level because I want these concepts (incremental execution, dynamic update) to automatically appear everywhere without every application author having to explicitly build them in (as they do now). That way, the application doesn't even have a chance to "get it wrong". It's actually fairly hard to do right, and I'd rather see it done right once and reused everywhere else. |
|
| |
Note that it doesn't need to be *literally* in the OS kernel (though it would be nice if it could take advantage of protection facilities). Perhaps "environment" is a better word. If I were to start working on it today, I'd build it on top of something like Linux. |
|
| |
If you want to sample what you are asking for, try MathCad. You will soon find that if is very single-solution oriented and leads you away from modularity. (Don't get me wrong, I really like the product!) But this does not lead to a generalized processing system. Two other problems come to mind, are we not just doing away with the power of algebra? And... this is tougher to extend to symbolic (language) problems...
Still, fun halfbaked thought. |
|
| |
I've never used MathCad, but I see no reason modularity must be sacrificed. It's true that spreadsheets aren't very good at modularity, but the concept of a reusable high-level concepts should be perfectly safe. Just as "int x = y + z" can be updated dynamically when "y" and "z" change, so can "int x = foo(z)", even if "x" and "z" are complex objects and "foo" is an entire subsystem worth of processing. |
|
| |
I have no idea what you mean by "doing away with the power of algebra", nor do I see how this fails to extend to "symbolic (language) problems". |
|
| |
*Whew* I just wasted the last double wondering, "Does egnor think I'm a moron?" Glad to know I just a tad thick. I'm puzzling over the requirements to build what you're calling for and don't have all the facts. Maybe some light will come on if I go for a walk?! BTW, I thought the evaluation version of MathCAD was super -- a sort of development pad and scribble sheet that rolled on and on like an endless stack of computational layers. I never viewed it as harnessing frames or scripting. |
|
| |
I think that this sort of OS would be similar to one of my
favorites, Symbolics Genera. Written in Lisp down to the
customized hardware in Symbolics Lisp Machines, and
later down to a custom "Lisp on a chip" Macintosh
expansion card, and later still to a software-only emulator
running on Compaq Alphas and under Tru64 Unix (and
previous DEC incarnations), it was truly a modern marvel. I
actually have a Symbolics XL1200 LispM and use it daily at
work, though it is a bit of an eccentric hardware fetish. |
|
| |
In any event, the principles of the OS were constructed
very much around leveraging the full power of Lisp, which
included such things as dynamic typing and type
inferencing compilers. Writing "x = y + z" and changing the
value of y is not a problem (assuming the program is
written correctly). Just try to avoid the chaos caused by
InterLisp's DWIM. |
|
| |
I'm working on something somewhat novel and similar to
Genera, an upstart OS called Vapour. |
|
| |
Genera, and the LISP machine
architecture in general, are
interesting, but I don't see any
direct application of this
concept. Certainly it's entirely
possible to write reactive
programs in LISP (as with any
language), the environment may
have been designed to be
relatively incremental and
interactive, and the OS may
provide some amount of
standardized scaffolding for
reacting to changes automatically,
but that's a far cry from what I'm
talking about. |
|
| |
Specifically, Genera is based on
LISP, and LISP is all about
*invoking* functions, passing them
parameters, and getting results.
That's not what I'm talking about.| — | egnor,
Feb 24 2001, last modified Feb 25 2001 |
|
|
| |
There are many circumstances when I'd rather not have my computer perform an expensive update, like re-compiling my project. For example, I might be in the middle of making a lot of changes, so waiting until I'm done would be the right thing to do. Also, I might be testing something, and want to compile a new copy but leave the old one in place. |
|
| |
It would be nice if my system *noticed* that my binaries were out of date (being a hypothetically clueless or forgetful user) and asked if it should re-compile now, not recompile now, wait 5 minutes, or never ask again. |
|
| |
As for configuration file updates, I think gconf is supposed to solve that problem for Gnome. It seems to me the CORBA framework of message passing between instantiated modules would be a good one to implement the kind of general change-awareness you are talking about. (Forgive me if I've confused levels of abstraction; I'm only mildly familiar with the technologies involved.) |
|
| |
I'm not sure if that satisfies your criteria of not having the author worry about updates. |
|
| |
I mean, it makes sense for there to be some service in the operating system that provides notices that a given file has changed. It seems that coping with changes is, in fact, a domain-specific behavior. There may be a small number of common solutions that would be useful utilities (much like UDP and TCP are good solutions for many applications' needs for coping with an unreliable data transmission medium) but some applications might want to implement their own solutions. Sometimes, the right thing to do if an input variable has changed is to re-execute the function, and pass the new output to the same place the old output went. Other times (like for non-idempotent operations), the right thing is to do something completely different, like filing a tax return amendment form vs. a second, slightly different one. |
|
| |
I guess most of what I've said is just a rehash of what's already here, but I'd just like to underscore the point that authors *should* have to worry about change awareness, that there's probably not a good universal default. This is not to say that providing an easy interface to small set of solutions that are the right thing 80% of the time isn't a spectacularly useful idea. |
|
| |
A good analogy is probably to error-condition awareness. There are standard mechanisms both in the operationg system and in higher-level environments (like Gnome) for passing around error notifications. But the actions that are to be taken in response to any given error are function-specific (though there many times the response fits a paradigm that is reducible to a function call - tell the user, keel over and die, try again, etc.) |
|
| |
Mac OS X machines have a similar thing to this idea, though
only in relation to the filesystem. the computer keeps track of
which programs have opened which files (the program doesn't
have to be changing the file, simply opening it registers the file
as 'In Use', and each process has a list of open files associated
with it, which can be looked at via Activity Monitor)
when a program opens and changes a file , the filesystem driver
notifies all other processes using the file that it has been
changed. Most processes ignore this, however, many text
editors for the mac will pop up a dialog notifying you that the
file was changed by another program, and ask if you want to
reload from disk, or continue as you are |
|
| |
things are slowly going this way, but it is difficult, which is why we don't have it. But incremental builds, continuous integration, webapps, etc. etc. are all pointing in that direction as concerns apps development.
It might take people a while to get used to the notion though... |
|
| |
I think Google Apps are pretty sophisticated in this respect and allow multiple users to edit the same document, locking spreadsheets down to the cell level and text documents down to the paragraph level. |
|
| |
I like the idea of this and I would add as well as sounding like a spreadsheet, it also sounds very much like a Relational Database Engine has to work in multi-user environments. |
|
| |
For that reason - I think you would have to be very careful about the 'deadly embrace' problem here - it might get very complicated to design something to avoid this (on multi-user system at least): you could end up locking up the machine pretty badly if two or more people are changing co-dependent resources (maybe down a 'chain' of dependencies, which would be difficult to predict at design-time). |
|
| |
Or perhaps that type of problem this is just the same for standard OS's - I'm not sure... |
|
| |