There is also the theoretical issue of "full abstraction" of the byte code language with respect to the source language. In this sense, byte code is redundant other than to provide a different representation, which can still be useful! But arguably, the byte code should be defined by proving equivalence of representations. That's not so easy. But looked at another way, byte code is really just a formally verified IR step! So the problem today is that we define byte code and the language separately, and somehow expect things to work.
On Tue, Jul 26, 2011 at 11:34 PM, David Barbour <dmbarb...@gmail.com> wrote: > On Tue, Jul 26, 2011 at 3:28 PM, BGB <cr88...@gmail.com> wrote: > >> why do we need an HLL distribution language, rather than, say, a low-level >> distribution language, such as bytecode or a VM-level ASM-like format, or >> something resembling Forth or PostScript?... >> > > Because: > > (1) Code will often adapt to relatively 'static' conditions indicated by > the host (such as user-agent, screen size, or access to a 'tilt' sensor). In > these cases, higher-level code is often much easier to specialize and > garbage-collect than an opaque block of bytecode. > > (2) Unnecessarily powerful languages, such as Forth or Postscript, are > difficult to reason about, difficult to audit. We are forced to stick them > in 'sandboxes', and the extra memory barriers and copying overheads slow > them down, and consume more resources. If we design our HLL for secure > composition and provable (or semantically controllable) resource > consumption, we can optimize it in-place, as though it were a native part of > our application. One valid fear from code distribution - even secure code - > is that it will consume too many resources (CPU, memory, bandwidth). We can > accommodate that concern in the sandbox with a low-level language, but not > *gracefully* - i.e. if we want graceful failures, we need semantics that > support it, such as clear disruption semantics. > > (3) Most interesting code is not 'algorithmic'. Dataflow models can be > optimized considerably with some access to the relevant local structure; > decisions on caching, propagation, and parallelism, for example, should wait > until the code is in place. Thus, libraries and modules for dataflow > languages must provide a higher-level structure to the compiler, and > compilation should happen *after* linking. In open systems, linking is > dynamic, and so must be compilation. > > (4) The web model today is *extremely* constrained: code distribution is > single-origin, server-to-client. We want to scale deeper, wider. These > things will happen: Clients will compose code from multiple services. > Services will receive agents and ambassadors from clients. Services will > broker clients, who will then speak directly. Services, themselves, are > clients to their dependencies and will thus repeat all these processes. HLL > code offers two critical features: (a) secure composition, and (b) the > ability to agglomerate resulting compositions, identify relationships > between dependencies, then shatter and distribute shards closer to the > appropriate resources. Static decisions about code can easily introduce > orders of magnitude in bandwidth and latency inefficiency. > > (5) Higher level code is much more accessible to humans. For developers, it > is easier to debug at the site where the problem occurred (no painful > shipping 'stack dumps' around). It is easier to extend or transform the > code, e.g. using GreaseMonkey scripts or Chrome extensions. It is easier to > learn to code. Children can peek behind the curtain - begin to understand > and manipulate the sea of computation in which they live. > > From every viewpoint I subscribe to - performance, security, scalability, > flexibility, user rights - <b>bytecode is a BAD idea</b> as a distribution > language. Other low-level languages are similarly bad. > > Any good distribution language *will be* high level, though not *because* it's > high level. There are quite a few desiderata for a web language. > > > _______________________________________________ > fonc mailing list > fonc@vpri.org > http://vpri.org/mailman/listinfo/fonc > >
_______________________________________________ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
