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

2011-07-27 Thread BGB
On 7/26/2011 8:34 PM, David Barbour wrote: On Tue, Jul 26, 2011 at 3:28 PM, BGB cr88...@gmail.com mailto: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

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

2011-07-27 Thread David Barbour
On Tue, Jul 26, 2011 at 11:14 PM, BGB cr88...@gmail.com 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

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

2011-07-27 Thread BGB
On 7/27/2011 2:12 AM, David Barbour wrote: On Tue, Jul 26, 2011 at 11:14 PM, BGB cr88...@gmail.com mailto:cr88...@gmail.com 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

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

2011-07-27 Thread David Barbour
On Wed, Jul 27, 2011 at 3:41 AM, BGB cr88...@gmail.com 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.

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

2011-07-27 Thread David Barbour
On Wed, Jul 27, 2011 at 9:35 AM, David Barbour dmbarb...@gmail.com 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

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

2011-07-27 Thread John Zabroski
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

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

2011-07-27 Thread David Barbour
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,

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

2011-07-27 Thread BGB
On 7/27/2011 9:35 AM, David Barbour wrote: On Wed, Jul 27, 2011 at 3:41 AM, BGB cr88...@gmail.com mailto:cr88...@gmail.com 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

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

2011-07-27 Thread David Barbour
On Wed, Jul 27, 2011 at 1:30 PM, BGB cr88...@gmail.com 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

[fonc] Why Bytecode is a Bad Idea for Distribution

2011-07-26 Thread David Barbour
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

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

2011-07-26 Thread David Barbour
On Tue, Jul 26, 2011 at 8:45 PM, John Zabroski johnzabro...@gmail.comwrote: 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