> bf could, lambda calculus as well, or potentially cellular automata Good luck turning those into silicon with any kind of performance. > Why would strings b

> bf could, lambda calculus as well, or potentially cellular automata Good luck turning those into silicon with any kind of performance. > 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. Because string comparisons are slow. Non-standardized hints are not a basis upon which software can be built. What you've described are APIs with loose coupling, which is the current status quo. > 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. This is again the status quo. I can write a library that implements all the APIs needed to run discord on older versions of Android. It's simply a non-trivial amount of work for little benefit and thus hasn't happened. > 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. Your OS can't design a GUI for you, unless you're assuming the OS is also an artificial general intelligence. So really what you're asking for already exists: the CLI. GUI apps are complex to make because their behavior is complex. Take your simple input and output, make the input include all window events and the output the file system/display/etc. and you end up doing all the same things. > 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) You can totally port discord to an arduino! Get it to boot linux, run a web browser and open discordapp.com. You'll run out of RAM long before you get there, but just hook up an SSD for swap. Performance is just a convenience after all. > 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. All this is essentially doing is turning libraries into syscalls. It's a loosely coupled external dependency and has all the same problems that entails regardless of what form its in. I think the core issue you're trying to address is fragmentation. Unfortunately it's a natural result of people interacting with one another, not something you can fix with good design or software. It ends up leading to a lot of wasted work, but it's also a massive drive to innovate. I'm going to sign off here. Thanks for discussing this, I honestly do find your idea interesting.