There should be one-- and preferably only one --obvious way to do it.

- t-strings

- f-strings

- %-operator

- +-operator

- str.format()

https://en.m.wikipedia.org/wiki/Operation_Paperclip

I am fairly certain that 15% increase was the automatic recommendation by RealPage.

Given the number of preprocessor hacks used in the kernel, and the amount of GCC-specific behavior that the codebase depends on, it seems like they are already halfway there.

Need some window function like LAG() or LEAD()? Too bad, I hope you like writing Python "for i in range(...):" loops. My notebook is littered with ".reset_index()" calls, ".replace(np.nan, None)", "axis='columns'", "foo.assign(bar=lambda df: df.apply(lambda row: ...))". groupby is especially confusing to me, as a Pandas GroupBy is difficult to compose with a normal DataFrame until you call .reset_index(). Compare this to SQL, where a subquery is a subquery, whether or not it has a GROUP BY clause.

The Pandas documentation also leaves a lot to be desired. Take the documentation of pandas.NaT[1] for example. "pandas.NaT: alias of NaT". Ok? That still doesn't tell me what NaT is, nor does it link to the thing that it aliases. The groupby documentation[2] also caused me some headaches, as it covers only the simplest aggregation use-cases.

Pandas is clearly better for some use-cases, but mostly for simple operations that are well-supported by the API (perhaps numeric operations that are implemented with native numpy routines). But if I'm doing some interactive OLAP stuff, I'll reach for SQL. Perhaps the problem is I'm trying to use Pandas like it's SQL, when it's not. But for manipulating data, I'd rather use a language than a library.

[1] https://pandas.pydata.org/docs/reference/api/pandas.NaT.html [2] https://pandas.pydata.org/docs/user_guide/groupby.html

edit: half a sentence

https://www.youtube.com/playlist?list=PL6e8wfdmIuLEDpO3rd5jO...

https://www.youtube.com/playlist?list=PLNNHQbT3rbzXwLY0E_-o9...

However, I do think it's a bad idea to enforce the content of compressed archives to be deterministic. tar has never specified an ordering of its contents. Compression algorithms are parameterized for time and space, so their output should not be deterministic either. Both of these principles apply to zip as well. But we now have a situation where we are depending on both the archive format and the compression algorithm to produce a deterministic output. If we expect archives to behave this way in general, we set a bad precedent for all sorts of systems, not just git and GitHub.

The only time the accelerometer reads something other than 0 is when something pushes it away from an inertial reference frame. This is true when you're on the ground: spacetime is curved, and "flows" towards the center of the Earth. The ground pushes you against the flow of spacetime, and the difference between these two frames of reference is 1g. Note that this 1g is not "caused" by gravity, it's caused by the electromagnetic force. Forces push matter away from an inertial reference frame. Gravity is different. It decides where an inertial reference frame goes by curving spacetime - it is not a force.

Hypothetically, if you were are the center of the Earth, the accelerometer would read 0g. There would be nothing pushing you in any particular direction - you would be in an inertial reference frame (ignoring the minor detail of being crushed by all of the Earth's mass).

Again, I'm trying to show the subtle difference between accelerating compared to a fixed coordinate system, and accelerating compared to an inertial reference frame. The fixed coordinate system does not take into account the curvature of spacetime. If it did, the coordinates would be "accelerating" towards the center of the Earth at 1g - congratulations, you've defined an inertial reference frame.

I hope that makes sense. It blew my mind when this idea clicked: that space and time are not two distinct things, they are two parts of the same thing.

Consider this: if you hold an accelerometer while stationary on the ground, it will read 1g (accelerating). If you read an accelerometer while in free-fall, it will read 0g (ignoring wind resistance). In the first scenario, you are accelerating compared to your rest frame, even if you are standing still.

This is not an arbitrary distinction either. The 1g of acceleration while stationary on the ground produces measurable relativistic effects.

This Veritasium video gives an intuitive explanation: https://youtu.be/XRr1kaXKBsU

  // UserID and PostID are distinct types
  type UserID int
  
  type PostID int