ndeine

This is actually the same thing as regular Python scoping rules; there's not even any fancy OOP logic behind it. Here's the same thing, but using global scope and functions instead of classes and inheritance.

     >>> x = 1
     >>> def a():
    ...:     print(x)
    ...:
     >>> def b():
    ...:     x = 2
    ...:     print(x)
    ...:
     >>> def c():
    ...:     print(x)
    ...:
     >>> a(), b(), c()
    1
    2
    1
     >>> x = 3
     >>> a(), b(), c()
    3
    2
    3

I think there is an argument to be made that classes are special and "reaching upwards" into the superclass scope should not occur - a unique copy should be made - but I also think that Python's way of doing it makes enough sense that it is not confusing. The Python devs are at least consistent about having their own way of doing things.

He means immutability when he says "const-ness". There are four possibilities for mutability of a single pointer:

1. The pointer is mutable, but its contents are immutable.

2. The pointer is immutable, but its contents are mutable.

3. The pointer is immutable and the contents are immutable.

4. The pointer is mutable and its contents are mutable.

Right now for owned pointers Rust gives us (3) and (4), but no obvious way to achieve (1) and (2). Although you might argue that the borrowing semantics give us these powers, just not directly with owned pointers - which we shouldn't be using directly if we're asking for that control, we should be lending them out in a well-controlled manner.

Yes, that is his point. My interpretation:

He is saying that more people on average will respond more directly and immediately to punishment than reinforcement.

The context is that organizations' behavior influence via punishment is a short-term tactic: in the long run, we would like to believe that reinforcement poses a net gain. However cultural influence results in short-term behavior control tactics from organizations prevailing, and little heed paid to the tradeoff.

One might also argue that it is cheaper in the short term to punish than to reward, and this further perpetuates the downward cycle as a staple of organization culture.

I haven't messed around with x86 enough to know whether it is actually somehow easier than the ARM stuff, but I certainly agree with you that CPUs are damn complicated.

I loaded up the datasheet for the M3's when typing up this reply. 384 pages. Contrast that with the TI 74181 ALU datasheet from the days of old: 18 pages, most of which are just detailed diagrams of the distances between the pinouts. The logic diagrams fit on a single page. You can build a simple CPU using one of these machines in a few hours in your basement.

Hardware is only going to get more complicated. At what point does it become so complicated that no one person can reasonably understand how a computer works "under the hood", even from an abstract level?

The expression 52x/x has a restricted domain as well (x /= 0). But that's normally not what you mean when you write it. It isn't often you really care about expressions like 52x/x; they are generally just intermediate steps in getting to a real solution.

For example: I have done a lot of work on some equation that is interesting to me, and finally I have reduced it to 5+yx=52x+5. Now obviously the rules of algebra let me subtract 5 from each side and be left with yx=52x, and this subtraction also has no effect on the domains for which our variables may be defined. All is well.

But dividing out the x is what we are concerned with now. Surely y=52 is a solution to the equation - why can this not be true for all values of x?

Well, for nonzero x we have y=52 and nobody will complain. For x=0, though, solving for y is problematic. Note that if x=0, y could be 1, or 33, or any number. If there is some function f such that y=f(x), then it follows that f(x) holds a unique value y for each input of x/=0, but for x=0 we cannot know what y might be; this is what we mean by undefined. Thus we say the domain of f(x) is the set of all real numbers x, such that x is not equal to zero.

If you have been told otherwise, or even gotten away with doing algebra or calculus under the assumption that the domain of our function f may include zero, you are taking a mathematical shortcut rather than performing formal analysis. It is not calculus nor algebra that is broken by saying f is undefined for x=0, but rather your (albeit practically useful) misconception of these systems.

I'll finish with some formal rules of algebra, to hammer this in:

- [P6] Existence of a multiplicative identity: a * 1 = 1 * a = a ; 1 /= 0.

- [P7] Existence of multiplicative inverses: a * a^(-1) = a^(-1) * a = 1, for a /= 0.

These are taken from page 9 of Spivak's Calculus, 3rd edition. He goes on to build the foundations of all of calculus from rules like these. Surely he would not present this as a fundamental axiom of his system, only to immediately (and silently) reject it and build a flawed calculus instead!

Indeed, on pg. 41, when defining functions, Spivak later writes (emphasis his):

> It is usually understood that a definition such as "k(x) = (1/x) + 1/(x-1), x /= 0, 1" can be shortened to "k(x) = (1/x) + 1/(x-1)"; in other words, unless the domain is explicitly restricted further, it is understood to consist of all numbers for which the definition makes any sense at all.

I think the target userbase for Keybase is nerds who found GPG too horribly unintuitive to figure out how to use it for themselves. I know I was like that for a while.

The other target userbase is people who want to verify GPG keys that don't have a web of trust. This is useful for, say, me - I'm not part of the Debian dev team or anything, so I don't have many people around who can sign my GPG key. It's nice to be able to publish a link to Keybase on my website and have people be able to be pretty sure it's me.

He's not actually talking about saving the diff and patching within a git repo, as far as I can gather from:

> [...], apply the changes (patch) from the file and continue the work. While it is not something difficult, it can be done much easier with Git.

Since he's saying "it can be done much easier with Git", the implication is that he wasn't using Git earlier, and the workflow with `git stash` is far cleaner than that diff/patch workflow.

At least, I think that's the case. I really can't imagine someone doing that instead of just using Git and `git stash` in the first place.