

Let me get this straight. We have an emulator for 1985 hardware that was written in a pretty new language (Go), ported to a language that isn't even 1.0 (Nim), compiled to C, then compiled to JavaScript? And the damn thing actually works? That's kind of amazing.

The amazing thing about computer software, relative to every other human endeavour: once you've got one component right, it's right; you can treat it like a simple little node in an even more complex design, and scale it up 1,000,000x, and it'll keep working every single time.

Once you've built a C-to-JS compiler, and a Nim-to-C compiler, you've got a perfectly-functioning Nim-to-JS compiler. There's no game of telephone gradually confusing things; the fidelity is perfect no matter how deep the pipeline goes.

(This is also what's amazing about layered packet-switched networks, come to think of it. The core switch transferring data from your phone to AWS doesn't need to speak 4G or Xen SDN; it's just coupled to them, eventually, by gateways somewhere else, and it all just keeps working, one quadrillion times per second, all over the world.)

It's so funny that you say that, because you are describing the way that I wish the world works, but I have found that in practice it rarely does.

For example, here are a list of ways in which the C-to-JS compiler is far less than "perfect": http://kripken.github.io/emscripten-site/docs/porting/guidel...

That's what I was really trying to get across—the difference between "imperfect" in other engineering, and "imperfect" in software. In other engineering, "imperfect" means "will randomly fail 0.00000001% of the time."

In software, though, "imperfect" means "will work perfectly, 100% of the time, even after a quadrillion tests, within a well-specified subset of all possible inputs; will fail in arbitrary unknown ways outside of that subset."

It's a difference to being "within tolerance"—even within tolerance of a physical system, stresses are still going on. Physical systems have a lifetime, and repair procedures, for a reason.

But in software, you don't have to worry about "stress within tolerance." In fact, even if someone else builds an "imperfect" software system that accepts inputs with undefined results, you can just wrap it with an input validator, and suddenly it's a well-defined-100%-of-the-time system!

(Of course, in implementation, software has to run on hardware, which is the other kind of imperfect system. But, surprisingly, you can write software to compensate even for that, with failover and quorum-agreement &c.)

> you can treat it like a simple little node in an even more complex design

Unix Philosphy right there (right?)

More like engineering philosophy

What's that obligatory talk link where he describes that everything will be compiled to JavaScript and run in the browser over the next 50 years?

Perfect, thanks!

You're part of the post now!

Old hardware is not necessarily hard to emulate. Often it's the opposite.

I agree it's not the hardest part, it just makes the overall picture more delightful to imagine.

Applications are open for YC Winter 2019
