John,
Where did you see me mentioning Richard? All I did was saying that in both cases,
B4J/
Java and
LBB/
BB4W, the idea is ill conceptually for the following reasons:
- Do you remember us re-writing LISP-in-BASIC in Script BASIC and FBSL BASIC? We did prove that QB45 code was easily reproducible in both dialects, and that's just what it was. We were sensible enough to stop in time and not let the results spread around as a product, because writing an interpretative engine in another interpreter is nothing but profanation, speed-wise, and therefore evil, and can be justified only as an in-house experiment. On the other hand, TinyScheme, NanoScheme and OxyScheme are more or less finished, albeit simplistic, distinct products because all the three are ultimately resolved to uncompromized native machine code via 64-bit MS VC, 32-bit Dynamic ANSI C, and 32-bit assembler, respectively.
- LB Booster is written in BBC BASIC for Windows. It is only the unbearable slowliness of LibertyBasic, that piece of sh*tcode SW that's been foisted upon people for their own money for decades, that has allowed LBB to be a bit faster than the original LB but still lagging far behind a ton of other BASICs inclusive of BB4W itself in terms of usability and throughput. So LBB is profanation doubled i) in terms of item 1 above, and ii) as a means, purposeful or naive, to indirectly support and promote LB out of well-deserved oblivion.
- Now take B4J/B4A/B4I. Java is a bytecode interpreter and it is only in some special cases and using some special extensions that its bytecoded classes get partially JIT recompiled to machine code. Another such example is originally purely interpretative Lua and its indie extension LuaJIT that generates a mixture of interpreted bytecode and native machine code. So, B4A/B4I/B4J are translators of BASIC-like syntax to a subset of Java syntax on respective platforms. All the three are feature-limited, albeit quote beautiful unquote, BASIC-like back-end IDE simplifications of originally far better developed Java interpretative VM -- a BB4W written in an LBB, if you'd prefer such an analogy to my original one.
I repeat once again, I'm scrutinizing language implementations and their design concepts, not people, from my own perspective and experience as a language developer. Aurel's scrutiny ends exactly where his knowledge of English does.