Still worth being careful, but it can be useful when you have a set of common fields that everything of a certain group will have (such as a response object with basic status, debug info, etc. and then additional data based on the particular struct). I don't know why they let you embed multiple layers and multiple objects though. I've never gotten value out of anything but a "here's a single set of common fields struct embedding".

Characters in Chinese can be combined to make more words, and you need around 9k words in English to read a novel and 2k characters in Chinese to read a novel.

Interesting, lets look at fnmatch: https://pubs.opengroup.org/onlinepubs/9699919799/functions/f...

Well, fnmatch really does two things, it parses the pattern and then applies that to a string, so really, there should be a "ptnparse" library that handles the pattern matching that fnmatch has a dependency.

Though, thinking it through, the "ptnparse" library is responsible for patterns matching single characters and multiple characters. We should split that up into "singleptn" and "multiptn" libraries that ptnparse can take as dependencies.

Oh, and those flags that fnmatch takes makes fnmatch work in several different ways, let's decompose those into three libraries so that we only have to pull in the matcher we care about: pthmatch, nscmatch, and prdmatch. Then we can compose those libraries based on what we want in fnmatch.

This is perfect, now if we don't care about part of the fnmatch functionality, we don't have to include it!

/s

This decomposition is how we wind up with the notorious leftpad situation. Knowing when to stop decomposing is important. fnmatch is a single function that does less than most syscalls. We can probably bundle that with a few more string functions without actually costing us a ton. Glob matching at a string level probably belongs with all the other string manipulation functions in the average "strings" library.

Importantly, my suggestion that fnmatch belongs in a "strings" library does align with your suggestion that fnmatch shouldn't be locked into a "glob" library that also includes the filesystem traversal components.

The thing that’s changed is how much the transactional nature favors the lazy students, not the smartphones specifically.

The reason the argument is so bad that “it’s the smartphones” is because that implies an easy solution that is external to the academic system, when the root cause is internal to the system.

Const support in languages never makes all modifications to data accessed through the variable locked out, just the top level, which makes it much more difficult to ensure that the assumptions about immutability hold without constantly doing deep copies or having to double and triple check that your Const definitions are correct.

Const often leads to a false sense of security.

That’s the most likely bet they are making, similar to Apple/Android or Safari/Chrome. Spending a minor fraction of your revenue to avoid anti-trust probably makes sense for them.

There are some incredible programmers in both big tech and game dev, but big tech has vastly more developers with less pressure to have top-tier talent.

Median developer at both probably represents the same skill because of normal distributions.

However, he’s stated many times that he will release his language compiler and modules openly when they are ready and that he believes he’ll have to open-source it at some point if he wants broad adoption.

JSON is already strictly worse than XML though as it doesn’t support comments and multi-line strings in a sane way.

It feels very much like the "read" in the "read-after-write consistency" is usually forgotten, hand-waved away with "eventual consistency", or is actually just a single node handling the coordination somewhere, leading us to not having nearly as scalable a system as we are promised by the database.

https://youtube.com/watch?v=s7tWHJfhiyo