Kogasa

Code is easy in a vacuum. 50 moving parts all with their own quirks and insufficient testing is how you get stuff like this to happen.

No, they’re not sure. You’re correct.

Definitely not.

All people. 320kbps mp3 is completely audibly transparent under all normal listening conditions. It’s a low-tier audiophile meme to claim otherwise but they will never pass a double-blind test.

It means they admit they were wrong and you were correct. As in, “I have been corrected.”

The argument describes an algorithm that can be translated into code.

1/(1-x)^(2) at 0 is 1

(1/(1-x)^(2) - 1)/x = (1 - 1 + 2x - x^(2))/x = 2 - x at 0 is 2

(1/(1-x)^(2) - 1 - 2x)/x^(2) = ((1 - 1 + 2x - x^(2) - 2x + 4x^(2) - 2x^(3))/x(2) = 3 - 2x at 0 is 3

and so on

Let f(x) = 1/((x-1)^(2)). Given an integer n, compute the nth derivative of f as f^((n))(x) = (-1)^{(n)(n+1)!/((x-1)}(n+2)), which lets us write f as the Taylor series about x=0 whose nth coefficient is f^((n))(0)/n! = (-1)^(-2)(n+1)!/n! = n+1. We now compute the nth coefficient with a simple recursion. To show this process works, we make an inductive argument: the 0th coefficient is f(0) = 1, and the nth coefficient is (f(x) - (1 + 2x + 3x^(2) + … + nx^(n-1)))/x(n) evaluated at x=0. Note that each coefficient appearing in the previous expression is an integer between 0 and n, so by inductive hypothesis we can represent it by incrementing 0 repeatedly. Unfortunately, the expression we’ve written isn’t well-defined at x=0 since we can’t divide by 0, but as we’d expect, the limit as x->0 is defined and equal to n+1 (exercise: prove this). To compute the limit, we can evaluate at a sufficiently small value of x and argue by monotonicity or squeezing that n+1 is the nearest integer. (exercise: determine an upper bound for |x| that makes this argument work and fill in the details). Finally, evaluate our expression at the appropriate value of x for each k from 1 to n, using each result to compute the next, until we are able to write each coefficient. Evaluate one more time and conclude by rounding to the value of n+1. This increments n.

Start with the goal to create something, be it a console app, website, web api, or game. It’s hard to just study a language abstractly and learn it. Use the Microsoft Learn documentation as reference, and look for open source .NET projects on GitHub to get different perspectives on how to build things with .NET. There is a free course on freecodecamp that will get you started by building an app, and I believe it was done in partnership with Microsoft

SQLite is one of the best tested codebases in existence. Having only so many variables per line means nothing

Web of trust

Well yeah but that’s not the problem. You can evidently encode sophisticated models and logic in those billions of parameters. It’s just that determining and modifying what has been encoded is impossible.

foo terminal

foot

But something has to be written on the birth certificate and social security card, and that’s what everything else will expect you to use. I think just due to technical limitations (e.g. of the printer/template for those things) it wouldn’t be allowed, but I dunno about legally

Status 200 for errors is common for non-REST HTTP APIs. An application error isn’t an HTTP error, the request and response were both handled successfully.

There may be a need for additional information, there just isn’t any in these responses. Using a basic JSON schema like the Problem Details RFC provides a standard way to add that information if necessary. Error codes are also often too general to have an application specific meaning. For example, is a “400 bad request” response caused by a malformed payload, a syntactically valid but semantically invalid payload, or what? Hence you put some data in the response body.

This should be done with font ligatures, not replacing character combinations with other characters that can’t be typed normally

No, it isn’t

You’re making assumptions about the control flow in a hypothetical piece of code…

What you’re saying is “descriptive method names aren’t a substitute for knowing how the code works.” That’s once again just a basic fact. It’s not “hiding,” it’s “organization.” Organization makes it easier to take a high level view of the code, it doesn’t preclude you from digging in at a lower level.

No, your argument is equally applicable to all methods. The idea that a method hides implementation details is not a real criticism, it’s just a basic fact.