4 ms·
This is precisely the wrong solution. If anything, the CPU bytecode is one of the most stable things, so switching to some "interpretable format" is not going t
by AshamedCaptain 3y ago
This is precisely the wrong solution. If anything, the CPU bytecode is one of the most stable things, so switching to some "interpretable format" is not going to help much. It is the total carelesness of literally everyone else in the entire stack which is the problem.
If developers considered the inability to run a 30 year old game/software in the most recent release of "libwhatever" as a critical release blocker bug, then this problem would not exist.
But obviously, this is not a popular solution. And currently we rather have the opposite situation, where open source projects dump compatibility as the default (e.g. Linux sunsetting a.out support), and only preserve compatibility in the comparatively rare case that there is enough developer mass.
- TheMode 3y agoISAs aren't stable. Can you guarantee me that programs will be compiled for x86 in 20y? What instructions will they output to access the environment? Linux, Windows, MacOS? Will any of these even remain in 20y? No standard last forever, your bytecode will ultimately deprecate and this is not a "developers should stop being lazy" situation. Why do projects dump compatibility? Because this is extra work. And no project can receive indefinite support. Simple formats do not depend on maintenance.