Was FORTRAN buggy 4346

Right. But you can get almost all the way there with a good emulator, and the better the emulator is, the more you can automate.

It is a different problem because it means that there are two bugs: one in the virtual machine and one in the code. When you fix the bug in the emulator, it reduces to the earlier problem.

You're coming from a world where the only way to know what the hardware does is to play with it. I'm coming from a world where the hardware is so complex and sophisticated that it's designed and tested virtually before it even exists physically, and the authoritative description of the hardware is that software description.

Yes, because that's the only way to manage the levels of complexity in current computers. You build a black box to a certain specification, and you trust that the black box will behave according to that specification. You maintain that black box even if you're responsible for both what's inside the box and what's outside it, because when the hardware changes, what's inside the black box changes; if you have a well-defined interface in and out of the black box, when the hardware changes, you just change the inside of the black box to match, and the rest of the code outside the black box doesn't change.

I can write code that compiles and runs identically on the machine I'm running Gnus and Emacs on, which is some flavor of x86 running OpenBSD; the machine I'm actually typing this on, which is a MacBookPro (x86) running OS X; the Mac mini back at home (PowerPC) running OS X; and the SPARC in the server room here running Solaris. If I visited a few of the right yard sales, I could get the same code to run on DECstations running Ultrix, Alphas running OSF-1 or Tru64 Unix, SGI machines running Irix.

And the reason I can do that is that atbreastude: it's black boxes all the way down, and each layer can trust the layer below to behave according to its spec.

Charlton