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.

To be clear, I mean people who praise Hitler, get swastika tattoos, blame everything on a Jewish Conspiracy, etc.

You know, Nazis.

Not really. Nazis are scum and deserve to be kicked out.

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.

The big thing you can do from the command line is script it.

Until you know a few very different languages, you don’t know what a good language is, so just relax on having opinions about which languages are better. You don’t need those opinions. They just get in your way.

Don’t even worry about what your first language is. The CS snobs used to say BASIC causes brain damage and that us '80s microcomputer kids were permanently ruined … but that was wrong. JavaScript is fine, C# is fine … as long as you don’t stop there.

(One of my first programming languages after BASIC was ZZT-OOP, the scripting language for Tim Sweeney’s first published game, back when Epic Games was called Potomac Computer Systems. It doesn’t have numbers. If you want to count something, you can move objects around on the game board to count it. If ZZT-OOP doesn’t cause brain damage, no language will.)

Please don’t say the new language you’re being asked to learn is “unintuitive”. That’s just a rude word for “not yet familiar to me”. So what if the first language you used required curly braces, and the next one you learn doesn’t? So what if type inference means that you don’t have to write int on your ints? You’ll get used to it.

You learned how to use curly braces, and you’ll learn how to use something else too. You’re smart. You can cope with indentation rules or significant capitalization or funny punctuation. The idea that some features are “unintuitive” rather than merely temporarily unfamiliar is just getting in your way.