If I've got a "page" that displays an image, how is the code to display that image specified? In lisp terminology, does that reference involve a relatively opaque gensym that is bound (by the page) to the code to interpret it? Or does the page instead include a well-known semantically meaningful unbound symbol, which is then interpreted by my software stack as referencing code that is administered by my package manager?
There's certainly a continuum between the two, but everything in the OP strikes me as arguing for the opaque and locally bound symbol, at the expense of control by the end-user.
Here's a quick-and-dirty outline of how it could work. The webclient has a local map of file associations from a given file type to a generic-runtime display program for files of that type, specified by a URL (or maybe a URI). When the webclient has to determine the default display program for a particular file it is loading, it first looks up the local table. (Obviously the default action for a file which is itself a generic-runtime executable is to run it directly.) If there's no local mapping for the file's filetype then, for that loading sequence only, the webclient takes as the default the display program suggested (again using a URL/URI) by the file's webserver in the response header.
Of course display programs can be cached locally. There's also no assumption that the default display program will always be the one used - on any given occasion that a file is loaded, the user (or a default-runtime program which is XHRing the file) can specify a non-default display program, in order to get a different UI or a non-standard view or just a different display-program implementation. (And a program doing an XHR could just take the file itself if it desires.) Finally, the process can chain, so a particular file might be given to a display program which is a Ruby script which would in turn be given to a generic-runtime interpreter for the appropriate version of Ruby.
> There's certainly a continuum between the two, but everything in the OP strikes me as arguing for the opaque and locally bound symbol, at the expense of control by the end-user.
Yes, the OP is basically advocating Alan Kay's floor-wax over TBL's dessert topping. But talking about a continuum implies that I'm hawking some horrible compromise substance made by mixing floor-wax and dessert topping in a bucket in whatever ratio. In fact, I'm offering a delicious synthesis product which really is a perfect specimen of both things at the same time! ;) http://en.wikipedia.org/wiki/List_of_Saturday_Night_Live_com...
http://web.archive.org/web/20050414203105/http://ce.et.tudel...
If one was to flesh this idea out and create a "universal bitstream" -> specific FPGA "compiler", at what layer do we stop and declare that we have reached the proper primitive abstractions? What happens when technology moves on from those primitives, and more performance is demanded by the majority of the applications? An older CPU can go about its business a bit slower while an older FPGA trying to run new code won't even fit the design.
The primary feature of declarative protocols/formats/languages is to convey a common meaning of data without specifying how it should be interpreted. Try to pull meaning out of imperative code and you'll run up against the halting problem. We could just be happy with our binary blobs, but moving beyond take-it-or-leave-it single-purpose content is exactly what as allowed "the web" the flourish.
Programmable logic as a standard PC feature would be great, but there would still be video ASICs for low power decoding or high-quality realtime encoding. also how would you propose to set a standard format for FPGA bitstreams when the balance of topology/block capability/timing is ever-changing. Once again we'd need a common declarative format as a base, and software tailored for the different nodes.