I see several people sharing the Stanford bithacks link, so I'll throw in a slightly-less well-known resource that I found particularly instructive. Basically, a collection of the lemmata we can prove about fixed-length sequences of bits and the fun algorithms that can be built atop those results.

https://www.jjj.de/fxt/

And for the non-pdf-phobic: https://www.jjj.de/fxt/fxtbook.pdf

> Long verbose names don't cost anything

They absolutely do have a cost. The question is whether the benefit they bring in implicit documentation is worth their cost.

> Even beyond the DX of readable names, it also acts like a type-checker. By reading the code, you can verify at least the semantics make sense.

I would strongly prefer that the actual type system do this job instead. As a toy example, if a function is only meant to operate on "lengths" (i.e., non-negative scalar values) then that should be modeled in the types of its arguments, not in its name.

Modelling in the type system has a cost too. You have to digest a lot of text (wrapping & unwrapping, etc.) just to understand that you're passing a length. Comparatively some extra characters in an identifier are basically free and can tossed in anywhere.

That may be a fair criticism in some cases.

For my toy example I don't think it is because it's generally easy (in the languages I work in) to overload arithmetic operators on types that are basically constrained scalars so there's no explicit wrapping/unwrapping to do when you want to operate on them as if they were plain scalars.

Maybe you could give me an example of the kind of pathological situation you're alluding to?

> I would strongly prefer that the actual type system do this job instead. As a toy example, if a function is only meant to operate on "lengths" (i.e., non-negative scalar values) then that should be modeled in the types of its arguments, not in its name.

Have you never worked in a dynamically typed language?

I have. I prefer statically typed languages.

Python is only palatable with strict type checking everywhere. I don't see how unchecked dynamic typing can bring anything else than chaos in a large project.

What's the cost?

Readability. In particular, an increase in the rate at which long, verbose names which are mostly the same are confused with one another.

>They absolutely do have a cost.

what cost? aesthetics?

Long, verbose variables are hard too read (it literally takes more time to read more characters), cause excessive line breaks, are harder to remember, and in general hurt readability more than they help.

Cognitive overload. Storing 3-4 succinct variable names in your head takes the same energy as storing 1-2 verbose variable names in your head.

I think there's some nuance though. If I'm the one writing the code, sure I can keep 3-4+ succint names of things I came up with in my head.

But then somebody else needs to look at this code in the future, and they're scratching their head as to what these names represent. Or somebody didn't really put enough thought into what the variables are, or gave them a name that only half represents what they actually mean.

I basically threw away all care for how long a variable name is long ago and have never had a problem. I just name it with enough words it needs to describe what it represents and don't fuss with making it smaller. With a decent IDE you don't even have to remember the whole name for things half the time, only parts of it.

Cognitive overload.. Perhaps it'd be best to provide and example of a "verbose" variable name as compared to a "succinct"

Personally I'm thinking more along the lines of

Succinct ->KEY

Verbose -> MAIL_SERVICE_API_KEY

> the semantics it learns sometimes have significant artifacts resulting from associations that are common in news coverage

I think this is largely the point. The game is significantly easier (for me at least) when I limit myself to thinking about what words would have high co-occurrence in English print journalism.

| It tests my anxiety levels at least 5x more than my skillset.

I'm not so convinced that these are two distinct things. I want coworkers who can maintain their level of skill under extremely hostile, stressful conditions. I'm not going impose those conditions on them, but I can't necessarily control the myriad third parties or circumstances that might.

Would you have been willing to hire this person without them graduating?

They've paid many tens+ of thousands of dollars for graduate school... they likely place some value on graduating!

Exactly one of the characters in that story can weather disasters.

Why would an individual have to defend themselves against disasters when they are so simple to mitigate against collectively?

First, I claim there exist disasters that are not simple to mitigate against collectively. Civil unrest (the full spectrum, from vigorous protest to outright governmental collapse) being the big one I have in mind.

Second, I claim that the wealthy character in the story above has significantly greater ability than the non-wealthy character to: (1) have accurate situational awareness about disasters (e.g., can distinguish shit actually hitting the fan from shit narrowly missing the fan (possibly via superior sensing apparati, more likely, just by delegating the task)); and (2) have well-equipped (read: expensive) bug-in/out plans in place. Thus, even in cases where disasters are mitigated against collectively as you claim is possible, the wealthy character will be in a better position to maintain their pre-disaster quality of life than the non-wealthy character.

That said, this is all a little too removed from a concrete comparison for my liking. Maybe you have one in mind? Ideally, an example where collective efforts at disaster mitigation basically made outcomes for individuals insensitive to the wealth of those individuals.

IME, when people say this, they mean that the difference between two quantities varies exponentially with time.

> Yeah, there are reasons to use dynamic linking, but I'm still not sure why dynamic linking gives you better profiling and tracing.

It's not so much that the tracing becomes better, but that it becomes feasible at all. Two specific situations come to mind, both MPI-adjacent. (1) Running a PMPI-based tool on code you can't recompile yourself (e.g., you need a Q clearance to see the source, but not to actually execute it--weird I know, but not that uncommon in the DOE labs.); and (2) running multiple PMPI-based tools simultaneously which are composed at runtime via PnMPI.

Exactly, but even if you can rebuild it, you don't want to under most circumstances. In principle with static binaries you can use dyninst, for instance, but in practice you may not be able to for various reasons. Then as a system manager you'd like to have global profiling of what runs -- for various reasons, including putting the result for a program in front of a user. If it's all dynamically linked, you can hook in and do that by default, and with various levels of insistence, depending on the hooks.

I addressed these arguments. I think that if you don't have access to the source, it's a security problem.

That includes not having access to the source because of security clearances. As far as I am concerned, your superiors in the DOE are adversaries to you and your machine.

Other people will have different viewpoints on that, and that's fine.

I want free software, and I'm aghast at what some people run, but this is not the real world. How many examples do you want? If you talk security, what's the threat model? What I run on a decently managed (with the aid of dynamically linked libraries) compute cluster should only put my data at risk.

As I understood it, there actually has been a push for free software solutions on CORAL systems, but I don't remember where that came from.

Suppose all of those mitigations in your second paragraph are true. If phytoplankton die off in meaningful amounts, where will we get our oxygen?

We have thousands of years of oxygen banked in the atmosphere so it's not an issue on the same time scale as co2

Thanks! Since this was not obvious to me (and maybe isn't to others) here's a summary that cleared things up for me: https://blogs.nicholas.duke.edu/citizenscientist/oxygen-in-t...

Landau's "Foundations of Analysis"