Re: [fonc] Why Bytecode is a Bad Idea for Distribution

On Wed, Jul 27, 2011 at 1:30 PM, BGB wrote: > one does need recursion/... for many things to work. > Even if we do have recursion, it does not imply being Turing-powerful. Primitive recursion and total recursion both terminate. But we don't need recursive functions. We only need a convenient an

Re: [fonc] Why Bytecode is a Bad Idea for Distribution

On 7/27/2011 9:35 AM, David Barbour wrote: On Wed, Jul 27, 2011 at 3:41 AM, BGB > wrote: a non-turing-complete IL is too limited to do much of anything useful with WRT developing "actual" software... You aren't alone in holding this uninformed, reactionary o

Re: [fonc] Why Bytecode is a Bad Idea for Distribution

I wasn't able to find your link. But I must say: splitting a complex image into a thousand parts for rendering and stitching them back together in real-time, is the sort of problem that quickly becomes painful and tedious even if you have a good approach to it. Regards, Dave On Wed, Jul 27, 201

Re: [fonc] Why Bytecode is a Bad Idea for Distribution

There is way too much back in forth about various things. I just want to comment on one of the many. PostScript is indeed over-specified, and was a mistake carried through to perfection by powering James Gosling's NeWS windowing server. I have links somewhere on my blog that talk about various a

Re: [fonc] Why Bytecode is a Bad Idea for Distribution

On Wed, Jul 27, 2011 at 9:35 AM, David Barbour wrote: > >> unnecessary or drastic change may often be seen as evil. >> >> hence, the status quo is king... >> > > A despotic king, perhaps. > Apologies. The status quo, as it exists, allows for its own change. We should not place the status quo on

Re: [fonc] Why Bytecode is a Bad Idea for Distribution

On Wed, Jul 27, 2011 at 3:41 AM, BGB wrote: > a non-turing-complete IL is too limited to do much of anything useful with > WRT developing "actual" software... > You aren't alone in holding this uninformed, reactionary opinion. Consider: Do we need Turing power for 3D apps? No. Because we want *

Re: [fonc] Why Bytecode is a Bad Idea for Distribution

On 7/27/2011 2:12 AM, David Barbour wrote: On Tue, Jul 26, 2011 at 11:14 PM, BGB > wrote: one can support ifdef blocks in the IL, no real problem there. Those seem like a problem all by themselves. Definitions are inflexible, lacking in domain of language types a

Re: [fonc] Why Bytecode is a Bad Idea for Distribution

On Tue, Jul 26, 2011 at 11:14 PM, BGB wrote: > one can support ifdef blocks in the IL, no real problem there. > Those seem like a problem all by themselves. Definitions are inflexible, lacking in domain of language types and lack effective support for complex ad-hoc decisions that would normally

Re: [fonc] Why Bytecode is a Bad Idea for Distribution

On 7/26/2011 8:34 PM, David Barbour wrote: On Tue, Jul 26, 2011 at 3:28 PM, BGB > 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

Re: [fonc] Why Bytecode is a Bad Idea for Distribution

On Tue, Jul 26, 2011 at 8:45 PM, John Zabroski wrote: > 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!

Re: [fonc] Why Bytecode is a Bad Idea for Distribution

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 equi

[fonc] Why Bytecode is a Bad Idea for Distribution

On Tue, Jul 26, 2011 at 3:28 PM, BGB 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