Okay, let’s skip the formal logic talk then and go straight to linguistics.

The question “Good to merge?” does not contain a grammatical error. It is perfectly well-formed by the grammar that native English speakers actually follow in everyday communication. A grammar that fails to parse “Good to merge?” in context cannot parse native English speakers’ actual output.

Schoolbook English is not native English, because it’s not how native English speakers actually speak. Schoolbook English contains rules that directly contradict native English speakers’ everyday usage.

(Standard examples include the rule against split infinitives and the rule against ending a sentence with a preposition. These are not grammatical rules of English as it is spoken by native speakers. To boldly assert them is silliness up with which I will not put.)

The guideline (as applied) contains a contradiction, so the principle of explosion applies.

Specifically, there is a contradiction between “native-sounding English” and “no grammatical errors”, when the latter phrase is interpreted in the manner seen here. Native speakers quite often use sentence fragments and in other ways do not follow schoolbook “proper grammar”. In fact, second-language learners often use schoolbook grammar where a native speaker would use a more relaxed register.

Since the guideline contains a contradiction, it is either impossible to follow (i.e. forbids all communication whatsoever) or impossible to violate (i.e. forbids no communication).

But if someone creates a file called HEAD, should it overwrite a file called head?

That shouldn’t matter to the “nontechnical” end-user at all. To the nontechnical user, even the abstraction of “creating a file” has largely gone away. You create a document, and changes you make to it are automatically persisted to storage, either local or cloud.

Only the technical command-line user cares about whether /usr/bin/HEAD and /usr/bin/head are the same path. And only in a specific circumstance — such as the early days of Mac OS X, where the Macintosh and Unix cultures collided — could the bug that I described emerge.

I recall a case-insensitivity bug from the early days of Mac OS X.

There are three command-line utilities that are distributed as part of the Perl HTTP library: GET, HEAD, and POST. These are for performing the HTTP operations of those names from the command line.

But there’s also a POSIX-standard utility for extracting the first few lines of a text file. It’s called head.

I think you see where I’m going with this. HEAD and head are the same name in a case-insensitive filesystem such as the classic Mac filesystem. They are different names on a Unix-style filesystem.

Installing /usr/bin/HEAD from libwww-perl onto a Mac with the classic filesystem overwrote /usr/bin/head and broke various things.

I recommend picking up Graham Hutton’s short text Programming in Haskell, Second Edition. Even if you don’t end up using Haskell in “real work” (and you might!) it will teach you a remarkable number of things about how functional programming works.

The term “open source software” was coined specifically to refer to software licensing that recognizes a particular set of freedoms. It is not a generic term for source-available software, and never was.

One of the freedoms of open source is “no discrimination against fields of endeavor.”

Calling the Hippocratic license family “open source” is inaccurate, since its entire goal is to discriminate against certain fields of endeavor.

It’s better described as a sort of source-available license.

In other words, the new technologies (like insect farming or mycoprotein harvesting) have not caught up with the old ones (like composting or feeding food scraps to a pig or goat).

• The compiler hates you
• The compiler sees nothing wrong with your code and is just giving error messages to look busy
• The compiler was written by a maniac with a semicolon fixation
• The compiler could optimize your code, but it’s just not feeling it today
• The compiler wonders why you can’t match braces right like your brother does
• The compiler had a torrid affair with a Perl interpreter in 2006
• The compiler likes big butts and cannot lie
• The compiler wants to grow up to be an IDE but hasn’t told its parents they need to send it to GUI school yet
• The compiler reads Nazis on Twitter but only to make fun of them
• The compiler works for the Servants of Cthulhu

Jury nullification is a real thing, but it is often misunderstood … mostly because right-wing libertarians and sovereign-citizen kooks have spent decades pushing conspiracy theory about it.

It isn’t an affirmative right of individual citizens to get onto juries and individually block the enforcement of the law. An individual juror cannot nullify. Rather, jury nullification is a logical consequence of two important rules in our legal system:

1. Double jeopardy: if a defendant gets a “not-guilty” verdict from a jury, that defendant cannot be retried for that same crime.
2. Juror independence: the judge cannot order the jury to return a particular verdict, nor punish them for the verdict they return.

Double jeopardy is in the US Constitution. Juror independence is inherited from English common law, where it was established in 1670 in an infamous case where a judge imprisoned and tortured jurors for not returning the verdict the judge wanted.

Because of these two principles, if a jury returns a “not-guilty” verdict, the defendant goes free; even if the verdict seems blatantly contrary to the facts and the law. Even if the jury is blatantly wrong, nobody in the system has any authority to do anything about it — not the judge, not the prosecutor, not the cops.

If you are summoned to be on a jury and you make it clear that you do not intend to judge the case on the facts and the law, you will be dismissed from the jury in voir dire. If you preach nullification to your fellow jurors, you might cause a mistrial: the defendant will not be freed; the court will just get a new jury, and the defendant will go back to jail in the meantime.

A mistrial does not free the defendant. A hung jury (refusing to come to a consensus) does not free the defendant. Only a not-guilty verdict frees the defendant.

That’s a fake.

Many Republicans are sponsored and bribed by fascist powers such as Putin’s Russia. They are under orders to take actions intended to weaken American industry, government, and society. This includes, for instance, sabotaging infrastructure projects, blocking disaster preparedness and relief, and fomenting political violence. The long-range goal is to make America incapable of projecting force to protect its international allies, global trade, etc.; a medium-range goal is to restore a regime broadly supportive of the international fascist movement.

(Just consider: Why does Putin support Trump? Putin doesn’t want to make America great; he wants to make America incapable — especially, incapable of defending Ukraine and, ultimately, other European allies. Putin predicts that Trump/Vance will accomplish that goal.)

A feast for worms.

I’m confused. To me, “building a tree” and “parsing” are the same thing. If you end up with a tree representation of the structure of your document, the thing you did to get there is parsing.

Rust does memory-safety in the most manual way possible, by requiring the programmer prove to the compiler that the code is memory-safe. This allows memory-safety with no runtime overhead, but makes the language comparatively difficult to learn and use.

Garbage-collected compiled languages — including Java, Go, Kotlin, Haskell, or Common Lisp — can provide memory-safety while putting the extra work on the runtime rather than on the programmer. This can impose a small performance penalty but typically makes for a language that’s much easier on the programmer.

And, of course, in many cases the raw performance of a native-code compiled language is not necessary, and a bytecode interpreter like Python is just fine.

The best code editor is the one that works well with your other tools, including your compiler and your keyboard.

Corollary: If you use an unusual compiler or an unusual keyboard, this may change what the best editor for you is.

Some other ways:

Cultivate bitterness.

Find the pessimists in your organization, and disappoint them.

Make mean cynicism a part of your workplace culture. Do this by example: Promote mean cynics and put them in charge of things. But do it also by conversion: Behave in a way that makes mean cynics’ view of the world correct.

Reward bad personal habits to create internal conflicts between work and health.

If someone skips sleep to finish a project, give them a bonus. This gives them an internal conflict between approval and health, and teaches them that they can sacrifice their health to receive a reward.

Encourage a hard-drinking culture in teams that have stressful roles that demand team cohesion, like SRE or Ops teams with on-call requirements. This gives them an internal conflict between their support network and health.

If someone is sick, injured, bereaved, or otherwise suffering: Make it clear how much their condition is inconvenient to their coworkers, and how much their projects are impacted by their absence. Assure them that all will be well once they can conclude their personal problems and commit to the team. Do not, however, offer them any specific help; if they express specific needs for accommodation, disregard them as idle and unrealistic wishes.

If DNS is transiently down, the most common mail domains are still in local resolver cache. And if you’re parsing live user requests, that means the IP network itself is not in transient failure at the moment. So it takes a pretty narrow kind of failure to trigger a problem… And the outcome is the app tells the user to recheck their email address, they do, and they retry and it works.

If DNS is having a worse problem, it’s probably down for your mail server too, which means an email would at least sit in the outbound mail spool for a bit until DNS comes back. Meanwhile the user is wondering where their confirmation email is, because people expect email delivery in seconds these days.

So yeah … yay, tradeoffs!

(Confirmation emails are still important for closed-loop opt-in, to make sure the user isn’t signing someone else up for your marketing department’s spam, though.)

The only way to correctly validate an email address is to send a message to it, and verify that it arrived.

If you’re accepting email addresses as user input (e.g. from a web form), it might be nice to check that what’s to the right of the rightmost @ sign is a domain name with an MX or A record. That way, if a user enters a typo’d address, you have some chance of telling them that instead of handing an email to user#example.net or user@gmailc.om to your MTA.

But the validity of the local-part (left of the rightmost @) is up to the receiving server.

Any time you’re turning a string of input into something else, what you are doing is parsing.

Even if the word “parser” never appears in your code, the act of interpreting a string as structured data is parsing, and the code that does parsing is a parser.

Programmers write parsers quite a lot, and many of the parsers they write are ad-hoc, ill-specified, bug-ridden, and can’t tell you why your input didn’t parse right.

Writing a parser without realizing you’re writing a parser, usually leads to writing a bad parser. Bad parsers do things like accepting malformed input that causes security holes. When bad parsers do reject malformed input, they rarely emit useful error messages about why it’s malformed. Bad parsers are often written using regex and duct tape.

Try not to write bad parsers. If you need to parse something, consider writing a grammar and using a parser library. (If you’re very ambitious, try a parser combinator library.) But at least try to recall something about parsers you learned once way back in a CS class, before throwing regex at the problem and calling it a day.

(And now the word “parser” no longer makes sense, because of semantic satiation.)

By the way, please don’t write regex to try to validate email addresses. Seriously. There are libraries for that; some of them are even good. When people write their own regex to match email addresses, they do things like forget that the hyphen is a valid character in domain names.

It’s safe to look things up!

Looking up the name of a crime does not mean that you’re doing that crime.

If you look up “bank robbery” that doesn’t make you guilty of bank robbery. It doesn’t even mean you’re trying to rob a bank, or even want to rob a bank. You could want to know how bank robbers work. You could be interested in being a bank guard or security engineer. You could be thinking of writing a heist story. You could want to know how safe your money is in a bank: do they get robbed all the time, or not?

Please, folks, don’t be afraid to look up words. That’s how you learn stuff.