> The most impressive one so far is making a port of a ~100 KiB Linux a.out i386 program to a native Windows PE i386 executable, despite not having access to its original source code or even decompiling it.
Quite the opposite IMHO : when your program interacts with a user, you cannot panic the program each time something unexpected happens. Here are some examples of unexpected conditions:
- "Null pointer dereference"
- "Out of memory"
- "Disk is full"
- "File does not exist"
- "File does not exist in cache"
- "File exists but is corrupt"
- "Access denied"
- "Connection reset by peer"
It's pretty obvious that all of the above is generally unwanted most of the time.
However, putting them all in the same bag labeled "error", and forcing them to be treated the same way might be counterproductive. Sometimes you might want to panic. Sometimes you might want to retry. Sometimes you might want to ignore!
Now, if your program isn't interactive (such as a compiler), halting on any error might be a choice. But you still have to provide contextualized and accurate error messages, which is easy for the case "File does not exist", and a lot less easy for the case "Out of range index".
> But as natural as causal reasoning feels to us, computers can’t do it. That’s because the syllogistic thought of the computer ALU is composed of mathematical equations, which (as the term “equation” implies) take the form of A equals Z. And unlike the connections made by our neurons, A equals Z is not a one-way route. It can be reversed without changing its meaning: A equals Z means exactly the same as Z equals A, just as 2 + 2 = 4 means precisely the same as 4 = 2 + 2.
What about Prolog ? How is it not a counter-example of this ?
> I was curious to see how the self-correcting mechanisms of science would respond [...]
> I was disappointed by the response from Southwest University. Their verdict has protected [a fraudulent researcher] and enabled him to continue publishing suspicious research at great pace.
The self-correcting mechanisms of science can only correct knowledge. Those mechanism work mainly by requiring the research works to be checkable by others. Self-correctness emerges by the accumulation of checks on the same topic, all leading to the same conclusion, and by the progressive retractation of bad research ... not by the elimination of "bad researchers".
Efficiently "correcting" people, whatever that means, is a different beast. Such a mechanism belongs to an administrative entity who can emit decisions - and, by construction, who can make errors.
It depends on how the physics engine has been integrated into your game/engine. The book "Game Coding Complete" shows how to isolate a 3rd-party physics engine so you can switch implementations.
Of course, every physics engine behaves a little differently from the others, so, if you game is physics centered (pinball, racing), switching implementation might result in a slightly different game - but having the core of your game depends on the implementation details of some 3rd-party library might not be a good idea anyway.
In general, the more you sprinkle your code with dependencies to 3rd party libraries, the less control you have over the resulting product.
Your point still stands, though, for some very low-level "utility" libraries like boost or the STL, or any standard library replacement , and more generally, libraries holding "vocabulary" types.
> You do not live in a video game. There are no pop-up warnings if you’re about to do something foolish, or if you’ve been going in the wrong direction for too long.
In the good old times most video games weren't like that.
It's a pity that those times are gone, to the point video games are now used as such a comparison point!
```
In this sense, the lock in lock-free does not refer directly to mutexes, but rather to the possibility of “locking up” the entire application in some way, whether it’s deadlock, livelock – or even due to hypothetical thread scheduling decisions made by your worst enemy. That last point sounds funny, but it’s key. Shared mutexes are ruled out trivially, because as soon as one thread obtains the mutex, your worst enemy could simply never schedule that thread again.
[...]
A final precision: Operations that are designed to block do not disqualify the algorithm. For example, a queue’s pop operation may intentionally block when the queue is empty. The remaining codepaths can still be considered lock-free.
```
I don't get it ; how could "locking a mutex" not be considered as an "operation that are designed to block" ?
Would somebody be kind enough to tell me what am I missing here? Thanks !
> Why would I want to solve puzzles with known answers that thousands of people have already solved?
For the same reasons you might engage in any entertainment activity.
Real-life still-unsolved puzzles are hard ; whereas puzzle games keep the difficulty under some control (except for the infamous boat puzzle in The Witness).
Real-life problems are hard because, often, proper domain modeling/formalization is part of the problem. Puzzle games generally don't have this 'domain modeling' part, they provide you with an extremely consistent set of rules, and you have to build a solution inside it. Sometimes this set of rules is partly implicit, and discovering it is part of the fun (e.g The Witness, Antichamber) ; but you never have to worry about the real-world and it's complexity.
There are some pretty good public game codebases (Penumbra/HPL, Quake I/II/III, Doom I/III), there are some okay ones (RedAlert), there are also pretty awful ones (Duke3D, Descent).
Note that this seems to be completely independent from whether the game is good or not!
Yes, obviously. But the message seemed to say that the constant speed of light implied that the derivative of the velocity with respect to time had to be zero.
> Also if the light wasn't moving straight that would mean it's changing direction, which is the same as an acceleration, and a beam of light traveling thru a gravitational field feels no acceleration, because it's not accelerating.
You could have both a deviation (i.e tangential acceleration) and a constant speed.
This is indeed really impressive!
(direct link: https://boricj.net/atari-jaguar-sdk/2024/01/02/part-5.html )