3 ms·
You have a point. But then, what I remember about that software that was ported to all the different architectures was: 1. the software was an order of magnitu
by TheZenPsycho 13y ago
You have a point. But then, what I remember about that software that was ported to all the different architectures was:
1. the software was an order of magnitude or two less complex- in terms of features and platform. That is, there was maybe a dozen different kinds of (highly predictable,testable) home computers instead of a combinatorial infinity of videocards/motherboards/soundcards/operating systems/etc.., plus, the GUI/Evented model is more conceptually difficult for programmers to cope with than straightforward "I own the machine" imperative blocking code. If we want to have guis, we need languages that either abtract away events, or at least provide tools to more easily handle events than C or assembler could provide. Such languages tend to be fairly complex (in implementation)/"inefficient"/garbage collected (since events link to memory/state that must be disposed of eventually,somehow, safely,without segfaulting). Failing that, we need programmers that are smart and capable enough to just plow through the complexity of events in plain C or C++. It's a different caliber of programmer than those who could singlehandedly make simple computer games on an 8-bit home microcomputer.
2. In cases of more complex software, ports were achieved by first designing and implementing a one off virtual machine, then simply porting the virtual machine to the different platforms. See ScummVM, Z-machine, Another World, etc. Surely that threw away some notion of efficiency. You made up for it by implementing the performance sensitive routines inside the VM itself.
3. The inefficiency of software is usually a tradeoff for development speed. To make a virtual platform work consistently across the many different real platforms they must run on, the efficiency of the virtual platform becomes (roughly) a function of ( platform implementors / platform count ) * time. We're only 5 years down the road of this round of serious javascript optimisation. At the end of the day, the curve of that function isn't that different from java, or C or C++ or anything else. those other things just have a huge head start.