Ugh; there's a reason why I'm switching my architecture course to MIPS32.
474 karma · joined August 20, 2013
Ugh; there's a reason why I'm switching my architecture course to MIPS32.
In JK you are never asked explicitly, "Do you want to do a Good Thing or a Bad Thing?". After a boss fight, you can choose to kill your opponent, or not. Those civilians running around sometimes drop health packs or ammo when they die, so maybe you kill them, or you don't. Dark side force powers are awesome, and don't require ammo to work, so maybe you put a few points into them. Then, at about 3/4 through the game, it doesn't ask if you want to be a light or dark Jedi, it tells you what kind of Jedi you were all along. You get to the point where you might expect the game to offer you a Big Choice, but instead, it points out that you already made your choice when you weren't paying attention.
The problem with Git is the same kind of problem Excel has: everyone can (correctly) claim to only use 20% of its features, thus everyone can say "Git is too complex!". But the problem is that everyone uses a different 20% of Git; Git is the union of the solutions to lots of different problems.
for(var i = 0; i < arr.length; ++i)
...
then the array's length is not read once at the beginning of the loop; it is read every loop iteration. So if the code inside the loop (or inside the getter for `length` itself) modifies the length of the array, then it will be caught when the condition is evaluated. The problem is that the C++ code makes assumptions about JS (reading the length of an array cannot change the array's length) that don't hold. But it's an easy mistake to make.Yep, instead of "you definitely get out of prison after X years have passed" you instead get "you get out of prison in 21 years! (or never, depending on how we feel)".
Although in a very different content, I have seen "dereferencing" a null pointer in C++ not crash immediately, if you dereference it to call a nonvirtual class member function, e.g,
t->foo();
Depending on how this gets compiled and the implementation of `foo()`, the segfault may not come at the line above, where technically `t` is being dereferenced. It may come inside `foo`, or somewhere further down the call chain. The resulting crash may not even manifest as a segfault.Why would that be true? When you write a library, you are writing code to cover all possible uses; everything within the scope of your library should at least be considered, even if you personally have no need of that particular bit of functionality. But when you write a program it only has to do one thing, so of course it's going to be simpler. To me, it seems obvious that (good) library code will be very different from (good) application code.
(I've used libraries that were written like applications, but they were bad libraries; I was constantly fighting the fact that the library author wrote only for their own use-case, and didn't consider any other.)