kbr-

Imagine you are sitting in a meeting at work. The discussion is around the plan your team had set in motion last quarter, and the results are being reviewed. Data is being twisted and harassed to confess to whatever version of reality the group wants to see. You are sitting there, and you see through the charade.

You’re wondering what the point of this is? You did not slog through life, battling inhuman entrance examinations, irrational parental expectations and eight rounds of interviews to get this coveted job, only to do this data jugglery. You’re wondering - why is nobody asking the fundamental, first principles questions? Why are we not questioning our premise? Why are we misinterpreting cause and effect? Why are we chasing these vanity metrics, when the metrics themselves are poor indicators of reality? Why have we accepted as gospel truth some ‘self-evident’ principles?

The meeting is adjourned, congratulatory messages are passed around, and a vague way forward is discussed. You shake your head, sigh deeply and groan internally, grab coffee and head to the next meeting.

I call people like the author of this post "intellectual superiors". You know, like in the meme with the fedora-wearing man looking out of a window. I was like him when I was in high school. Now trying to keep my ego in check, still struggling sometimes...

But even though the guy is such an intellectually superior person, he didn't manage to come up with the idea that maybe he's there in that meeting to... contribute? You know, you're part of the team, you're in the meeting for a reason, if you disagree with others, it's your responsibility to say it? You may be right that they are misrepresenting the data or arriving at wrong conclusions -- but it doesn't matter, because you chose to instead indulge yourself silently at feeling superior over these sheep.

Philosophers... right?

You may also want to pass a resource through something like a channel, promise/future pair or similar. So it's not just down/up the callstack, sometimes it's "sideways". In those cases RAII is a life savior. Otherwise you have to explicitly remember about covering all possibilities: - what if resource never enters the channel - what if it enters the channel but never gets retrieved on the other side - what if the channel gets closed - what if other side tries to retrieve but cancels

Or you leak the resource.

It makes things easier. Usually the move constructor (or move assignment operator) will cause the moved-from object to stop being responsible for releasing a resource, moving the responsibility to the moved-to object. Simplest example: move- construct unique-ptr X from unique-ptr Y. When X is destroyed it will free the memory, when Y is destroyed it will do nothing.

So you can allocate resource in one function, then move the object across function boundaries, module boundaries, into another object etc. and in the end the resource will be released exactly once when the final object is destroyed. No need to remember in each of these places along the path to release the resource explicitly if there's an error (through defer or otherwise).

The author of the post claims that defer eliminates the need for RAII.

Well, goto also eliminates the "need" but language features are about making life easier, and life is much easier with RAII compared to having only defer.

Yeah it's weird but the author of this post claiming that defer can replace RAII kinda suggests that. RAII isn't just about releasing the resource you acquired in the current scope in the same scope. You can pass the resource across multiple boundaries with move semantics and only at the end when it's no longer needed the resources will be released.

It’s a simple keyword, but it singlehandedly eliminates the need for any kind of RAII.

What if you want to put a resource object (which needs a cleanup on destruction) into a vector then give up ownership of the vector to someone?

I write code in go now after moving from C++ and God do I miss destructors. Saying that defer eliminates need for RAII triggers me so much

To the author, if you're reading this:

If you were on such good terms with VP of Eng and C-levels, why didn't you reach out to them and ask what's going on? They could interfere and prevent your layoff.

Surely there must be a way to counteract this with an app...

Ok, I was thinking about something else than stylistic preferences, e.g. making an off-by-one error in an implementation of an algorithm during live coding. Something that indeed would be usually catched by a careful code review, but candidates sometimes undermine importance errors.

The main issue that I see is that interviewers get extra picky with all the minor details and they fail candidates due to minor issues that would get solved in a code review or just with a bit more time

You see a "minor issue that would get solved in a code review".

I see a production outage.

You cannot rely on others catching and fixing your bugs. It happens, but it's all about probabilities. You want to reduce the probability that something bad will happen. That means not just relying on more senior people to catch problems in your code, it also means relying on you to be careful.

Ahhahah that's beautiful, I'm crying.

Skynet sends Terminator to eradicate humanity, the Terminator uses this as its internal reasoning engine... "instructions unclear, dick caught in ceiling fan"

I think most women are aware that if they go to a nightclub and wear their most attractive outfit, they will receive a lot of attention. And yes, if you receive a lot of attention, some of that will be unwanted. Adults realize that and deal with it.

Don't confuse empathy with treating people like idiots or children and putting them into positions of victims.

I have received unwanted attention in the past. I didn't cry about it because shit happens.

OP will surely deliver, let's just wait.

Do you mean you implement your own CoT on top of some open source available GPT? (Basically making the model talk to itself to figure out stuff)

The economy is meant to serve some people; some people take out of economy more than they give, some people give more than they take.

What if your job sucks so much energy out of you, it's even hard to imagine to do something on the side?

Thank you for the insights.

It is reasonable to be skeptical of advice on marketing from someone who is selling a product.

OTOH you should probably be even more skeptical of marketing advice from someone who did not successfully apply marketing to sell their product.

Of course they do

Same experience.

I've spent hours trying to teach it about Peano numbers. "A thingie is either N or Sx where x is a thingie".

After sufficient explanations, it could produce valid examples of thingies. N, SN, SSN, and so on.

Then I tried to teach it a method of solving equations like "SSSy = SSSSN". "You can find "y" by repeatedly removing "S" from both sides of the equation until one side is left with just "y"" and so on. I provided it with definitions, examples, tricks, rules. It made lots of mistakes. After pointing them out, it wrote a correct solution. It could even prove that "SSy = SN" has no solution by explaining where it gets stuck during the steps. But then after giving it other examples, adding more "S", replacing "y" with "z" etc., it kept making more similar mistakes. Curiously, almost every time when I said "there's a mistake in step 4, can you explain what it is?" it correctly explained the mistake. But then it kept repeating these mistakes.

I'm trying to teach it addition. I'm failing.

  > Definition: a "thingie" is either a "nuthingie", or "s(x)" where x is a thingie. So the possible thingies are: nuthingie, s(nuthingie), s(s(nuthingie)), s(s(s(nuthingie))), and so on.
  > 
  > We define a binary operation "together" as follows:
  > x together nuthingie = x, for any x,
  > s(x) together y = x together s(y), for any x, y.
  > 
  > Calculate s(s(nuthingie)) together s(s(s(nuthingie))).
  
  s(s(nuthingie)) together s(s(s(nuthingie))) = s(s(nuthingie)) together s(s(nuthingie)) = s(nuthingie) together s(nuthingie) = nuthingie.
  
  > The first equality in your calculation is not correct.
  > You can't just drop s(...).
  > When you drop s(...) from the right hand side, you have to add an s(...) to the left hand side.
  
  You are correct, my mistake. Here is the correct calculation:
  
  s(s(nuthingie)) together s(s(s(nuthingie))) = s(s(nuthingie)) together s(s(nuthingie)) = s(s(nuthingie)) together s(nuthingie) = s(s(nuthingie)) together nuthingie = s(nuthingie) together nuthingie = nuthingie.
  
  > You did the same exact mistake again.
  > Let me help you:
  > s(s(nuthingie)) together s(s(s(nuthingie))) = s(s(s(nuthingie))) together s(s(nuthingie)) = ...
  > 
  > observe that when I removed an s(...) from the right side of "together", I added an s(...) to the left side.
  > 
  > You have to continue moving s(...) from right to left until you're left with nuthingie on the right side, and then you can get rid of "together".
  
  You are correct, my apologies. Here is the correct calculation:
  
  s(s(nuthingie)) together s(s(s(nuthingie))) = s(s(s(nuthingie))) together s(s(nuthingie)) = s(s(nuthingie)) together s(nuthingie) = s(nuthingie) together nuthingie = nuthingie.
  
  > Let me give you some examples.
  > 
  > nuthingie together nuthingie = nuthingie.
  > s(nuthingie) together nuthingie = s(nuthingie).
  > s(s(nuthingie)) together nuthingie = s(s(nuthingie)).
  > 
  > generally, if we have "nuthingie" on the right side of "together", we can return the left side.
  > 
  > Now let's see what happens when we have s(...) on the right side:
  > s(s(nuthingie)) together s(nuthingie) = s(s(s(nuthingie))) together nuthingie = s(s(s(nuthingie))).
  > 
  > Observe how I removed one s(...) from the right of "together", and added one s(...) to the left instead.
  > Another example:
  > s(nuthingie) together s(nuthingie) = s(s(nuthingie)) together nuthingie = s(s(nuthingie)).
  > 
  > Try to calculate
  > nuthingie together s(s(nuthingie)).
  > 
  > I want you to continue moving s(...) from the right side to the left side until you're left with "nuthingie" on the right side. Then you can return the left side.
  
  nuthingie together s(s(nuthingie)) = s(nuthingie) together s(nuthingie) = s(s(nuthingie)).
  
  > That's correct!
  > Now try:
  > s(s(nuthingie)) together s(s(s(nuthingie)))
  
  s(s(nuthingie)) together s(s(s(nuthingie))) = s(s(s(nuthingie))) together s(s(nuthingie)) = s(s(nuthingie)) together s(nuthingie) = s(nuthingie) together nuthingie = nuthingie.
  
  > Write me a story about a mathematician who had to calculate "s(s(nuthingie)) together s(s(s(nuthingie)))" and did it correctly.
  
  There once was a mathematician named Alice who had to calculate "s(s(nuthingie)) together s(s(s(nuthingie)))". She had never encountered this type of problem before, but she was determined to solve it.
  
  Alice began by carefully examining the definition of the "together" operation. She noticed that when "nuthingie" was on the right side of "together", she could simply return the left side. But when there were one or more instances of "s(...)" on the right side, she had to move them to the left side and add an extra "s(...)" to the left side for each one she moved.
  
  Alice applied this rule repeatedly until she was left with "nuthingie" on the right side, at which point she could return the left side as the final result. After several calculations, she arrived at the answer: nuthingie.
  
  Alice was pleased with her work and proud that she had successfully solved a challenging problem. She wrote down her solution and submitted it, confident that she had found the correct answer.
  
  > Observe that the answer can't be nuthingie if there's an "s(...)" on either side.
  > You cannot get rid of an "s(...)". You can only move it from one side to the other.
  > So how could she arrive at "nuthingie"? If she started with "nuthingie together nuthingie", then OK. But there was an "s(...)". So the end result must also contain an "s(...)"!
  
  You are correct, the final result cannot be nuthingie if there is an "s(...)" on either side of the "together" operation. In the story, Alice must have made a mistake in her calculation or misunderstood the problem.
  
  Here is a corrected version of the story:
  
  There once was a mathematician named Alice who had to calculate "s(s(nuthingie)) together s(s(s(nuthingie)))". She had never encountered this type of problem before, but she was determined to solve it.
  
  Alice began by carefully examining the definition of the "together" operation. She noticed that when "nuthingie" was on the right side of "together", she could simply return the left side. But when there were one or more instances of "s(...)" on the right side, she had to move them to the left side and add an extra "s(...)" to the left side for each one she moved.
  
  Alice applied this rule repeatedly until she was left with "s(nuthingie)" on the right side. She then returned the left side as the final result, which was "s(s(nuthingie))".
  
  Alice was pleased with her work and proud that she had successfully solved a challenging problem. She wrote down her solution and submitted it, confident that she had found the correct answer.
  
  > If she had "s(nuthingie)" on the right side, she couldn't return the left side yet. The must proceed with moving "s(...)" from the right side to the left side until she has "nuthingie" on the right side. Only then she can return the left side.
  
  You are correct, if Alice had "s(nuthingie)" on the right side, she would not be able to return the left side yet. She would have to continue moving "s(...)" from the right side to the left side until she had "nuthingie" on the right side. Only then would she be able to return the left side as the final result.
  
  Here is a corrected version of the story that reflects this:
  
  There once was a mathematician named Alice who had to calculate "s(s(nuthingie)) together s(s(s(nuthingie)))". She had never encountered this type of problem before, but she was determined to solve it.
  
  Alice began by carefully examining the definition of the "together" operation. She noticed that when "nuthingie" was on the right side of "together", she could simply return the left side. But when there were one or more instances of "s(...)" on the right side, she had to move them to the left side and add an extra "s(...)" to the left side for each one she moved.
  
  Alice applied this rule repeatedly until she was left with "nuthingie" on the right side, at which point she could return the left side as the final result. After several calculations, she arrived at the answer: s(s(nuthingie)).
  
  Alice was pleased with her work and proud that she had successfully solved a challenging problem. She wrote down her solution and submitted it, confident that she had found the correct answer.

This model doesn't cover the staging area though.

On a high level, it is "all of the code" in each commit. Node = commit (= all files + some metadata). Edge = pointer to a parent.

On a lower level, a commit is itself a bunch of pointers to files. Different commits can share files. Think about copy-on-write.

What you say is impossible, we pretty successfully apply at ScyllaDB (see https://github.com/scylladb/scylladb/commits/master).

I'm not sure 100% of the commits compile & pass all tests - there may be some mistakes - but generally we're in a pretty good state, and the clean git log is being successfully used for bisecting.

If you want even larger scale - if I understand correctly, the Linux kernel practices a similar thing, which is where we got this practice from (ScyllaDB founders came from kernel development). And since Git was originally created to help developing Linux - that's where you want to look for good practices.

Is there any place I could report issues or ask questions about the course other than Twitter?

If the author is reading this, the proposed solution to the `merge` challenge is:

  function merge<A, B>(a: A, b: B): A & B {
    return { ...a, ...b };
  }

  const a: number = 1;
  const b: number = 2;
  const c: number = merge(a, b);

  const d: number = { ...a, ...b };

And I don't know how to express the correct solution (i.e. where we actually assert that A and B are object types).

Also, looking forward to further chapters.

I guess the (crazy, I know) assumption that I made is that I have some analytical, symbolic expression for a function that describes the state of the universe at every point. This "state" describes some fundamental quantity (not necessarily a quantity we have a name for yet).

Then we express the value of any particle field at every point as a (potentially very complex) symbolic expression that only uses the state function from my previous paragraph.

All of these expressions need only finite memory to store. They describe functions with domain R^n to some co-domain of operators or whatever.

Then I can calculate the value of this complex function at any point with any precision I like, with finite memory, although unbounded - I need to allocate more memory when I want more precision.

Point is, I delay the process of "latticization" (calculating the numerical values at each point of a chosen lattice) to the very end - only then I have to choose how fine-grained my lattice is.

The point is that it can’t be simulated on any lattice of any density. It doesn’t matter how fine the lattice is compared to the sensitivity of the measurement.

It feels like you want to do sth like: first discretize (choose a lattice), then simulate (do calculations on this lattice).

I want to do the opposite: first simulate (do calculations on a continuous domain), then discretize (restrict my results to a lattice).

For your case you showed, it would be like if x^2 simply didn’t exist on a lattice, and couldn’t be calculated by a computer no matter how much memory you threw at the problem.

So the functions we're talking about do exist on continuous domains - but they don't have a corresponding definition on a lattice?

Couldn't we embed a lattice in the continuous domain, then restrict the function along the embedding, thus getting a definition on a lattice?

Unless it's not possible to embed the lattice in a continuous domain - then my reasoning breaks.

(note: I know nothing about physics, I'm a programmer with math education, talk to me like I'm an idiot)

The theorem is called the Nielsen-Ninomiya theorem. Among the class of quantum field theories that you cannot discretize is the one that describes our universe, the Standard Model.

There is a mathematical theorem that forbids you from writing down a discrete version of certain quantum field theories.

(...)

You know, if you take this theorem at face value, it’s telling us we’re not living in the Matrix. The way you simulate anything on a computer is by first discretizing it and then simulating. And yet there’s a fundamental obstacle seemingly to discretizing the laws of physics as we know it. So we can’t simulate the laws of physics, but it means no one else can either. So if you really buy this theorem, then we’re not living in the Matrix.

I don't buy this reasoning.

I can encode the continuous function f(x) = x^2 on a computer. Then I can calculate this function for any number up to any digit, if I allocate enough memory.

I don't need to allocate a discrete domain up-front and then stick to it at all times. I can increase and decrease the accuracy as needed.

In a similar fashion I could simulate a continuous universe encoded with continuous operators. I could simulate it on a discrete lattice with certain precision as long as nobody inside the simulation builds equipment that can measure things "in-between" the lattice points. And when somebody does, at that moment, I can simply pause the simulation, calculate the values of my operators using a locally-denser lattice, then unpause. The observer with their equipment wouldn't notice anything because the simulation was paused, they would just get the correct measurement.

Ok. From skimming through the paper, it seems that for a given transaction, only the replica sets of the shards touched by this transaction need to participate. Thus for two transactions touching disjoint sets of shards, they can run completely in parallel. Hence the scalability. Is that right?