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
