> But yes, the equivalent of fnmatch should be a separate module and that could be a dependency of glob.

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.

You know what’s more fun than having a bad junior write crap code while you point out their mistakes? Writing good code yourself.

None of those listed jobs is actually unskilled labor. Driving a big truck around narrow roads is a skill most don’t have, doing it at speed and running up and down to actually move the heavy packages is a skill most don’t have. Assembling furniture is a skill most don’t have, especially with complex engineered wood products that will break if stressed wrong. Handymen is literally just a collection of skilled labor jobs rolled into one guy that can handle small home improvement projects like carpentry, masonry, plumbing, and electrical. These are specialized jobs that have wrongly been labeled “un-skilled” or “semi-skilled” as if knowledge work is the only skill of value…

Sure, but the argument is still that the smartphones aren’t the root cause. It’s the transactional nature of the thing. Can’t fail students because money would go down, so keep passing them as they get better equipped to ignore you and have reduced requirements to get a passing grade.

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 only saves you most of the time if you have a “const” all the way down the type structure. If I have a type Foo with a field that is a pointer to a mutable value, instantiating a Const Foo just means I’m always pointing at the same mutable value, not that I have an unchangeable Foo.

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.