> 2 hours is pushing it for pretty much anything.
bf could, lambda calculus as well, or potentially cellular automata. Also implementing IO is still important, as the apps depend on it. What I am saying in my case is that the hardware manufacturer should expose the basic hardware features as functions (so immutable, there is nothing to update here) and you would then be able to implement whatever your app is written in and reuse the primitive hardware functions.
> Ok so in order to make it fast we're not going to use strings,
Why would strings be slower? These would be part of the static binary. These calls being hint and not necessarily standardized is an important part. Standards are the same as environments, they always evolve.
> Applications want to know whether the system has support for a syscall, so we return an error if they don't exist. This is how Linux syscalls work.
You may want to do something with the call even if the guaranteed syscall isn't there. I am meaning the string as a hint, not as an api
> but whoops switch gestures were added in version 6 but this customer is using version 5. The absense of this syscall is fundamentally incompatible with my game, so I guess I'll put "requires version 6" on the website.
Switch gestures cannot be linked to a software version. It is hardware. As long as you can listen to touch input and optionally multi-touch you have physical support for all gestures. It being limited to version 6 or above is an arbitrary limitation, and indeed will cause the software to delimit what's supported. Whereas if your software only exposed a "has there been a switch gesture" visible to the users, they could decide that actually a button press should be considered as a switch, or they could use a separate library that convert touch inputs into a yes/no switch, or perhaps that their devices already come with some hardware accelerated switch gesture control that they can plug into it.
> As long as new things are being invented/written you can never have full backwards compatibility.
The problem is that when making software you are forced to reinvent the whole chain. I simply cannot make a calculator app with the guarantee that it will be able to run decades from now, I need to include the binary that open the window, get the OpenGL context, write the boilerplate so I can draw individual pixels, etc.
But what if my compiled program only contained basic flow logic and an input and output? Essentially a function. And when users run it, how that function behaves with the environment is device specific and as the calculator developer I couldn't care any less.
Obviously, if you make a VR game it will be pretty hard to emulate it on a gameboy, but there is nothing justifying that I cannot make my own discord port on an arduino (except speed, but this is a convenience)
> Just to be thorough this is fully possible right now - intercepting unknown syscalls and showing a prompt - but there's simply way too many and their behavior too complex for it to be of any use. Especially non-experts would have exactly zero chance.
I agree, that's because we do not assign proper meaning to these syscalls. Users wouldnt know what to do, I am not saying that we need to expose raw file descriptors or make the user handle async i/o. I however believe that we should make this option more viable, for example by allowing applications to transform whatever they want into an environment request so they become more straightforward. And the less syscall you do, the easier it will be for users to make their ports.