3 ms·

> The extent of how each bytecode was used doesn't invalidate their existence. It does, because uptake is the proof of suitability to purpose. There's no credi

> The extent of how each bytecode was used doesn't invalidate their existence. It does, because uptake is the proof of suitability to purpose. There's no credit to just being first to think of an idea, only in being first to implement it well enough that everyone wants to use it. > Any bytecode can be embedded, it is a matter of implementation. Empty sophistry is a poor substitute for thought. Are you going to post any evidence of your earlier claim, or just let it waft around like a fart in an elevator? In particular, your reference to ANDF is absurd and makes me think you're having this discussion in bad faith. I remember ANDF, and TenDRA -- I lost a lot of hours fighting the TenDRA C compiler. Nobody with any familiarity with ANDF would put it in the same category as WebAssembly, or for that matter any other reasonable bytecode. For anyone who's reading this thread, check out the patent (https://patents.google.com/patent/EP0464526A2/en https://patents.google.com/patent/EP0464526A2/en) and you'll understand quickly that ANDF is closer to a blend of LLVM IR and Haskell's Cmm. It's designed to be used as part of a multi-stage compiler, where part of the compiler frontend runs on the developer system (emitting ANDF) and the rest of the frontend + the whole backend + the linker runs on the target system. No relationship to WebAssembly, JVM bytecode, or any other form of bytecode designed to be executed as-is with predictable platform-independent semantics. > More than 20 programming tools vendors offer some 26 programming languages > — including C++, Perl, Python, Java, COBOL, RPG and Haskell — on .NET. I want to see you explain why you think the CLR pre-dates the JVM. Or explain why you think C++/CLI is the same as compiling actual standard C/C++ to WebAssembly. > Naturally one can always advocate that since 60 years of history have not > provided that very special feature XYZ, we should now celebrate WebAssembly > as the be all end all of bytecode, as startups with VC money repurpose old > ideas newly wrapped. Yes, it is in fact normal to celebrate when advances in compiler implementation, security research and hardware performance enable a new technology that solves many problems without any of the downsides that affected previous attempts in the same topic. If you reflexively dislike any technology that is adopted by startups, and then start confabulating nonsense to justify your position despite all evidence, then the technology isn't the problem.

pjmlp 2y ago
> It does, because uptake is the proof of suitability to purpose. There's no credit to just being first to think of an idea, only in being first to implement it well enough that everyone wants to use it. Depends on how the sales pitch of those selling the new stack goes. > Empty sophistry is a poor substitute for thought. Are you going to post any evidence of your earlier claim, or just let it waft around like a fart in an elevator? Creative writing, some USENET flavour, loving it. > In particular, your reference to ANDF is absurd and makes me think you're having this discussion in bad faith. I remember ANDF, and TenDRA -- I lost a lot of hours fighting the TenDRA C compiler. Nobody with any familiarity with ANDF would put it in the same category as WebAssembly, or for that matter any other reasonable bytecode. It is a matter of prior art, not what they achieved in practice. > I want to see you explain why you think the CLR pre-dates the JVM. Or explain why you think C++/CLI is the same as compiling actual standard C/C++ to WebAssembly. I never written that the CLR predates the JVM, where is that can you please point us out? C++/CLI is as standard C and C++, as using emscripten clang extensions for WebAssembly integration with JavaScript. But I tend to forget at the eyes of FOSS folks, clang and GCC language extensions are considered regular C and C++, as if defined by ISO themselves. > Yes, it is in fact normal to celebrate when advances in compiler implementation, security research and hardware performance enable a new technology that solves many problems without any of the downsides that affected previous attempts in the same topic. Naturally, when folks are honest about the actual capabilities and the past they build upon. I love WebAssembly Kubernetes clusters reinventing application servers, by the way, what a cool idea!

pjmlp 2y ago

> It does, because uptake is the proof of suitability to purpose. There's no credit to just being first to think of an idea, only in being first to implement it well enough that everyone wants to use it. Depends on how the sales pitch of those selling the new stack goes. > Empty sophistry is a poor substitute for thought. Are you going to post any evidence of your earlier claim, or just let it waft around like a fart in an elevator? Creative writing, some USENET flavour, loving it. > In particular, your reference to ANDF is absurd and makes me think you're having this discussion in bad faith. I remember ANDF, and TenDRA -- I lost a lot of hours fighting the TenDRA C compiler. Nobody with any familiarity with ANDF would put it in the same category as WebAssembly, or for that matter any other reasonable bytecode. It is a matter of prior art, not what they achieved in practice. > I want to see you explain why you think the CLR pre-dates the JVM. Or explain why you think C++/CLI is the same as compiling actual standard C/C++ to WebAssembly. I never written that the CLR predates the JVM, where is that can you please point us out? C++/CLI is as standard C and C++, as using emscripten clang extensions for WebAssembly integration with JavaScript. But I tend to forget at the eyes of FOSS folks, clang and GCC language extensions are considered regular C and C++, as if defined by ISO themselves. > Yes, it is in fact normal to celebrate when advances in compiler implementation, security research and hardware performance enable a new technology that solves many problems without any of the downsides that affected previous attempts in the same topic. Naturally, when folks are honest about the actual capabilities and the past they build upon. I love WebAssembly Kubernetes clusters reinventing application servers, by the way, what a cool idea!