There was a collection of DRM stories i read a few years ago. People (businesses, architects, professionals that should know better) calling for tech support over corrupted files was memorable (but apparently not memorable enough). I imagine there was some grim joy in informing people they were not using a legitimate copy, and thus their program was failing.
Degredation as a DRM mechanism sounds clever, and lots of developers think of it at some point (and many games have actually done it). It's actually a really bad idea, though, for a couple of reasons:
* Your support site will be flooded by pirates experiencing the degredation if it is severe enough to be noticed
* People will just assume it is a bug and your game sucks if it's subtle
* If it's very blatant it will be removed in the pirated versions. Meanwhile you run the risk of it happening to legitimate customers due to bugs in the DRM.
Why should you care that pirates think your game sucks? Well, for one, on the great democracy that is the internet, pirates' game reviews have just as much weight as legitimate purchasers. Also a pirate is not necessarily always a pirate, they may be trying before they buy, or may convert to a paying customer later in life and remember their experience with your company.
This reminds of the polymorphic viruses in MS-DOS/Windows era (very likely they still exist, but I didn't look for long time) where they would dynamically generate the decryption/encryption routines and changed their code appearances to thwart signature-based antivirus scanners. As such, maybe it would be fun to add self-modifying codes so that 1) precision is reduced 2) performance is also randomly reduced. The longer you run this baby, the slower and less precise it would be. ;)
Computers are precise but sometimes I wonder could they be made faster if we relaxed this precision requirement?
For example in game 3d graphics it might acceptable to sacrifice some precision for performance. Could be interesting to apply some thing "Entropy" to the graphics part of some existing game. Flappy Bird maybe?
Reminds me of Netflix's "Chaos Monkey". Both Entropy and the Chaos Monkey force you to deal with failure as an eventual certainty, not something to ignore and hope it doesn't happen.
AFAIK Chaos Monkey inserts random but non-permanent failures into the system, not really entropy. Entropy would be the gradual loss of their movie data, something I'm sure they work quite hard to prevent.
What is interesting about this is how it forces one to deal with a lack of precision. Computers are inherently imprecise in many situations, leading to non-commutative multiplication. I wonder if a language like this would be helpful for programming with approximate processors. They are supposed to be much faster at a cost of precision.
Pedantic aside: I guess you mean non-associative multiplication? That is, ax(bxc) versus (axb)xc. Since rounding happens at different times, they can give different results. Floating point multiplication is indeed non-commutative as well, but that has to do with NaN handling, not imprecision.
You could argue that float/int arithmetic is inherently imprecise. It is, however, fully deterministic.
Of course as you hint in your comment, at a lower level hardware is prone to failures and lack determinism: bugs in the cpu, ram corruption (ECC-ram is of course better), data corruption everywhere on storage/network/data links, etc. Ever heard a gamer bitching about Windows 7 instability? That's not Windows, but overclocking not quite under control and/or insufficient cooling...
And when all is under control a cosmic ray might still wreak your bits havoc.
It's deterministic at some level, but can be very difficult to predict when a compiler will decide to spill 80-bit float registers to 64-bit doubles in memory.
I love this idea, it's quite interesting. On the flip side, I made a change in some software at my work the other day to replace the use of a random in a unit test. The use of random was being used to populate some data. This language would make matters incredibly difficult to recreate bugs and even test software
The situation you are suggesting might require dumps of as much state as can be measured and a method for recreating the state of the application from that dump. That might be a very large set of data if every variable can be altered. Even execution paths and past variable values would need to be measured over time.
Wow, this is really appropriate for the day I've had today. Repeatedly failing to get a brand new install of Bitcoin Core to index and sync with the blockchain. I finally dusted off my Memtest86 and voila, bad RAM stick!
I suppose crypto would fare pretty badly inside this language, or has anyone thought about this kind of thing?
Well, Shannon & Moore showed [1] that you can make arbitrarily reliable circuits out of unreliable relays, so I expect you could find a redundant enough encoding for any program that would allow it to operate at high precision, even in this language. It would almost certainly be larger and slower than a more accurate equivalent though!
