4 ms·
I understand your point, but by similar logic I can argue any language is interpreted because nothing compiles down to microcode. The point is you don't need j
by terminalbraid 1y ago
I understand your point, but by similar logic I can argue any language is interpreted because nothing compiles down to microcode. The point is you don't need janet-specific external dependencies in the environment. I don't differentiate between this and an inefficient compiler.
- xigoi 1y agoThe distinction matters because the resulting executable is not (significantly) faster than running the program as a script.
- massung 1y agoI think the distinction (from the OP’s perspective) is that it’s “just an app” to the end user. When I download the Slack desktop app, I might know it’s running on electron because I’m a programmer. But I didn’t have to download and install nodejs or anything else. As far as I’m concerned it’s a completely self contained application. The end user needn’t download and install Janet or even know that Janet exists. That can obviously be done with any interpreted language, but Janet makes it really simple out of the box.
- packetlost 1y ago> I can argue any language is interpreted because nothing compiles down to microcode Not every processor architecture uses microcode, so this doesn't hold up. > The point is you don't need janet-specific external dependencies in the environment Sure. > I don't differentiate between this and an inefficient compiler A compiler is the general term here, but the target is not. Targeting the native architecture for a CPU vs targeting a bytecode VM are quite different and have pretty important implications for performance, portability, memory usage, etc.