Photos and numbers seem to be stolen straight from it.

Sure, single-entry bookkeeping might be easier and more normalized, but sometimes it is a good idea to just stick with the systems and abstractions that have been developed over centuries.

Just use double-entry bookkeeping unless you definitely need something else. Sure, it might be icky for the programmer inside you, but I think you'll be thankful if you ever need to get actual accountants involved to sort out a mismatch.

On a related note: does anybody know of any good resources for programmers in payments and adjacent fields? Something like an "Accounting for Programmers"?

How can you do this using print debugging? For every print statement I add, I can add a breakpoint. Even more importantly, I can see the stack frame and know which functions led to the current one. I can inspect any and all variables in scope, and even change their values if I want to pretend that the code before was fine and proceed further.

- When you sign in to Google, you sign in browser-wide. Google now gets all of your browsing data, perfect for advertising. (If you ever doubt it, go check out Google Takeout. You'll be shocked at the amount of data you see there.)

- They have special APIs and features that they get to use, and nobody else. Only because they own Chrome. [1]

- They get to move forward with enabling and pushing features that allow for more advertising: see Manifest v3, FLoC.

- Google specifically serves a worse version of Search on Firefox for Mobile. You have to get an extension to get the full experience.

This isn't an isolated attempt. You can see more of the same thing with Android.

- AOSP (the open source counterpart of Android) is now unusable. It doesn't ship with most essential apps, including a Phone app. In previous versions of Android, all of these were a part of AOSP.

- Most third party launchers/stores struggle to implement features because they are only available for Google themselves.

- The signing in with Google thing from above continues here too: you sign in to Google system-wide.

[1]: https://x.com/lcasdev/status/1810696257137959018

- You're using a dynamically typed language.

Something like Rust can eliminate most bugs that come from incorrect data types. For me, a lot of bugs used to come from types that were different from what I expect.

- It is super easy to run your program with a debugger attached.

If your code needs to run on a K8s cluster or a dedicated test machine instead of locally, logs are much easier to get hold of than a remote debug session. Some people aren't even aware that they can attach a debugger to a computer over the network, or inside a Docker container.

- Your environment.

If you don't use an IDE that supports a debugger, it's another friction point. I'm not sure if Vim has something similar to, say, PyCharm's debugger.

Similarly, if you're a junior, and you reach out to a senior and they tell you to debug using logs, you probably will never switch to using a debugger yourself.

This is one area where I believe a GUI tool is so much better: I can hover over variable names to view their values, expand and collapse parts of a nested structure, edit values easily, and follow execution in the same environment I write my code in.

Sure, it doesn't help much for some scenarios (one I've heard people mention is multithreaded code, where logs are better?), but for most people it's not that far from a superpower.

> A way to bake that in without breaking old code would be to allow function definition to put an explicit stop to the argument list, ...

Edit: Also, from the same table, it seems that only this library was ran after warming up, while others were not. https://github.com/bhavnicksm/chonkie/blob/main/benchmarks/R...

This doesn't protect you against trigger bots (shoot automatically when you put your mouse on a target), aim bots (snap to targets, ranging from obvious hacks to very minute adjustments), and others.

If you had separate paths for each language, most links would have an unnecessary /en/.