I believe that the root problems are programs having direct access to environment, being compiled down to hardware instructions, and these instructions not being easily interpretable (without having access to an already made interpreter)
These problems cause software to depend on highly specific platforms [1] that prevent any hardware from being standalone-ly sustainable.
* Environment access creates the opportunity for security risks, and dependencies that cannot be fulfilled on different platforms (e.g. asking for touch input on a desktop device)
* Being compiled to hardware specific instructions obviously prevent the same software to run on different hardware, rendering them obsolete sooner than otherwise necessary
* These instructions being hard to implement prevent individual users from creating their own interpreter, therefore creating the need for a centralized entity to provide it.
In other word, my suggestion would be to create a new target platform that compile down to a very understandable instruction set ("understandable" referring to the amount of time it would take for a new developer to fully implement it) and leave environment access out of the spec (How the software convert an input request to your mouse position remains platform specific).
This way, all software becomes permanently available without depending on any external entity, but new devices would still be free to improve the process
> In other word, my suggestion would be to create a new target platform that compile down to a very understandable instruction set and leave environment access out of the spec
This is already the case. The vast complexity of modern software and hardware comes from the ever more complex environment they interact with.
If you take a nice small instruction set - leaving environment access out of the spec, and then attach device specific cameras, modems, displays, sensors, accelerators, etc. and then build an OS with a web browser and apps that interact with all the extra hardware. What you've invented is the modern smart phone. It runs on ARM - an easily interpretable instruction set.
Discord not running on older phones is entirely due to them depending on newer operating system APIs. It's not the instructions that changed, the environment did.
> The vast complexity of modern software and hardware comes from the ever more complex environment they interact with.
100% agree, hence my suggestion to completely remove environment access from the instruction set. No syscall.
> It runs on ARM - an easily interpretable instruction set.
I give you 2 hours to write a brand new fully spec compliant ARMv8 interpreter, 3 hours to write an android VM to run on my windows laptop.
> Discord not running on older phones is entirely due to them depending on newer operating system APIs. It's not the instructions that changed, the environment did.
The instructions allowed them to depend on platform specific features, which is what I want to prevent.
Instead of calling some random android `external_is_switch_gesture` syscall the app should request a boolean/bit given a string "Has there been a switch gesture?" and expect the result of that syscall to be what they asked for.
Then, it would be up to the OS to decide how to interpret that request, maybe that the string is part of some standardized way to retrieve a gesture input in which way automate it, but if it is not you could simply prompt the user to chose what to give the application given a list of all the possible environment access.
> I give you 2 hours to write a brand new fully spec compliant ARMv8 interpreter, 3 hours to write an android VM to run on my windows laptop.
2 hours is pushing it for pretty much anything. I am pretty confident I can make a 64bit risc-v interpreter that'll boot Linux in a few days. Wouldn't be fast and wouldn't have IO, but neither of those have any baring on how easy the instructions are to interpret. The spec is fairly easy to understand.
> The instructions allowed them to depend on platform specific features, which is what I want to prevent.
> Instead of calling some random android `external_is_switch_gesture` syscall the app should request a boolean/bit given a string "Has there been a switch gesture?" and expect the result of that syscall to be what they asked for.
Ok so in order to make it fast we're not going to use strings, instead integers that we only ever increment for new syscalls (no conflicts, ever). 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.
Lets use your hypothetical: I'm writing a game that makes heavy use of switch geatures. I make my game call the "Has there been a switch gesture?" syscall, 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.
This is the status quo. Nothing you've suggested is a fundamental change to how software/hardware works. As long as new things are being invented/written you can never have full backwards compatibility.
> but if it is not you could simply prompt the user to chose what to give the application given a list of all the possible environment access.
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.
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.
> 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.
> Good luck turning those into silicon with any kind of performance.
It doesn't have to be the hardware ISA, nothing would prevent the hardware manufacturer from including a compiler.
> Because string comparisons are slow. Non-standardized hints are not a basis upon which software can be built.
The comparison will only happen once, I do not think that we should argue about 2-3 string comparisons heating our CPUs. And you can definitely build software this way, you just need to work on the way the user map its hardware to the software.
> I can write a library that implements all the APIs needed to run discord on older versions of Android
But the hardware is there, the problem is that the mapping must be done through low level code.
> Your OS can't design a GUI for you, unless you're assuming the OS is also an artificial general intelligence.
I am not speaking about AI, but I do believe that our OSs could help us draw an interface from data. There are many UI creation tool, but they aren't meant to be real-time.
> GUI apps are complex to make because their behavior is complex.
They are complex to write, but very simple to describe (if you accept to give up on some details). I could describe my HN page layout to you way faster using english than html/css. GUI apps are complex because we are trying to map them to weird standards. Good luck implementing a CSS parser.
> You can totally port discord to an arduino! Get it to boot linux, run a web browser and open discordapp.com.
You can theoretically do it yes, in the same way developers could in theory port their apps to every single platform current and future. But in practice it isn't the case, and my calculator app will likely stop working in 5 years because of some weird API change.
> 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 believe otherwise, instead of fighting against new platforms by exposing restrictive standards, I want to embrace the different platforms by allowing developers to write what they app should do instead of how. If your apps want to draw pixels, they should just draw pixel. How the windows must open is completely irrelevant and the OS/user should be able to figure that out.
Which I guess is better, but they are not tackling the root of the problem.