It doesn't matter if a library is written in TS or JS; you cannot meaningfully protect against other code calling you incorrectly.
Sure, you can check if they gave you a string instead of a number. But if you receive an array of nested objects, are you going to traverse the whole graph and check every property? If the caller gives you a callback, do you check if it returns the correct value? If that callback itself returns a function, do you check that function's return type too? And will you check these things at every single function boundary?
This kind of paranoid runtime type-checking would completely dominate the code, and nobody does it. Many invariants which exist at compile-time cannot be meaningfully checked at runtime, even if you wanted to. All you can do is offer a type-safe interface, trust your callers to respect it, and check for a few common mistakes at the boundary. You cannot protect your code against other code calling it incorrectly, and in practice nobody does. This is equally true for JS and TS.
Coming from an era of tiles and sprites, Lemmings was exciting because it had real destructible terrain. The game action happens in its pixel buffer, and every little speck of dirt can make a difference to how the characters behave.
When I saw this adaptation back in 2004, I was amazed because the web didn't even HAVE an API for its pixel buffer; the canvas element didn't arrive until a year later! All the destructible/buildable terrain here is faked out with stacked `img` elements. They had to simulate a simple form of graphics with a more complex one, because that's all the platform made available.
This is a linear sequence of bits, which when interpreted as a Game of Life board, "prints" an exact copy of itself 2 pixels to the right (leaving no trace of the original).
I suppose its job would be easier if it only had to construct a copy of itself rather than "moving" itself, but I enjoy the interpretation that it's a linear "tape" of bits which prints its own code transposed by 2 pixels, and takes an unfathomable amount of time and space to do so. Beautiful.
yeah, spaceships are pretty common (fun fact: 2 spaceships were found on the same day including this one in GOL), also in CA it's called a "spaceship". However until now there was no 1D one (1D is also called 1-cell-thick or linear).
Also, you are actually wrong, it is actually much easier to move than to self-synthesize and then remain alive like a replicator. There has been no true replicator found yet in Life as far as I know (arguably, linear propagator may be a replicator) but like millions of spaceships have been found.
can be programmed to self-replicate in any number of ways, but it's so big that it's very hard to simulate it through a full cycle. By contrast, Pavel Grankovskiy's "DOGun SaGaQR"
OK, I didn't know if it was a "true" replicator (what even does "true" mean) so I excluded it. And, running a true replicator from other rule in 0E0P takes millenia, so that leaves DOGun SaGaQR (specifically the QR configuration). Sorry.
This is a little different from most "Doom on X" projects, because the accomplishment is less about the hardware (it's just a normal computer) and more about turning a circuit-board designer into a real-time game display.
I've seen ZMachine games under a pen and also under a PostScript file. PS, unlike Doom fanboys claiming otherwise with PDF files embedding JS (and I daily play FreeDoom with daily build WADs).
ZMachine games are the 2nd most ported game in existence. The first one must be Tetris. Which has been interpreted under the ZMachine itself.
A Z3 game can run platforms which Doom can just dream:
- A PostScript virtual machine
- An FPGA implementation
- Kaypro/Altair with CP/M 2.2
- MSX 1/2
- Amiga/Atari/Mac68k
- ZX Spectrum 128
- Amstrap CPC
- TRS I-IV
- C64
- Apple II (maybe Apple 1 with a 16k RAM expansion)
- GB/C
- PDA's/Palms
- Maybe the NES with an on-screen keyboard
- Ditto with the Master System
- PS1 and PS2, N64 with an OSK again.
- Windows/Linux/Mac/Android/Whatever
- Damn Minix 2.0 under a homebrew CPU with TTL's
- Ebooks
- Maybe a shader
- Subleq+Eforth + a VM written in Eforth. At OFC glacial
speeds but with Muxleq it might run fast enough even
under my shitty n270 netbook:
> Actually, as I'm writing this, I realized that probably the music being produced by this person is actually done by a computer. So, maybe she's in the first wave of totally artificial pop stars.
Her main collaborator, co-creator and producer of many years is the artist AG Cook, who founded the label PC Music. He appears often in her music videos and gets mentioned in her lyrics. His own solo work plays a lot with pairing the artificial and the organic, taking the "slick" aesthetics of electronic pop to abrasive extremes and placing it next to vulnerability and gentleness.
That's a little ungenerous. Richer types are not intrinsically about metaprogramming, they just let you model your domain more accurately so you can turn runtime errors into build-time errors. If your system already has natural constraints, you get to document them in a machine-checkable way.
Attempt generosity. Can you think of another way to interpret the comment above yours? Is it more likely they are calling their own argument a red herring, or the one they are responding to?
If something looks like a "weird stance", consider trying harder to understand it. It's better for everyone else in the conversation.
Sure, you can check if they gave you a string instead of a number. But if you receive an array of nested objects, are you going to traverse the whole graph and check every property? If the caller gives you a callback, do you check if it returns the correct value? If that callback itself returns a function, do you check that function's return type too? And will you check these things at every single function boundary?
This kind of paranoid runtime type-checking would completely dominate the code, and nobody does it. Many invariants which exist at compile-time cannot be meaningfully checked at runtime, even if you wanted to. All you can do is offer a type-safe interface, trust your callers to respect it, and check for a few common mistakes at the boundary. You cannot protect your code against other code calling it incorrectly, and in practice nobody does. This is equally true for JS and TS.