mmcclimon

Cold ketchup on hot french fries is one of life's great joys, though.

> You can invoke git-who as git who by setting up an alias in your global Git config

This works even without the alias, by the way: by default `git whatever` will search your path for `git-whatever` and execute it.

Field size for American football is definitely standardized: 100 yards between goal lines and 160 feet wide. Lots of Americans will have an intuitive sense for how long something like "three football fields" is.

Man with PhD in subject is pedantic about that subject on Hacker News, film at 11. ;)

There are, of course, stylistic norms, and a lot of those norms are shared across lots of kinds of Western music. The thing I'm pushing back against is a misconception I see a lot that people who teach music theory are arbiters of quality in music, and that music that doesn't "follow Bach's rules" is somehow less good than music that does. (That misconception is probably well deserved, because that is how music theory was presented for a long time. I think that has changed, though, and that you'd be hard-pressed to find someone in the field that holds that position these days.)

What I mean when I say that music theory is a descriptive enterprise is quite literal: the research that professional music theorists do is designing theories to describe music we see and hear in the real world. So yes, composers (now and in the past) do learn music theory, and do write music with stylistic norms in mind, as well as adding their own spin on things. That work, in my reading, is not music theory, it's composition! The act of "inventing music theory" is something done by music theorists (writ large), not by people writing music.

To use your analogy: composers are inventing music in the same way that normal speakers invent language. I don't think I'd describe new variations on language as "inventing linguistics," though, as linguistics is the in-depth study of language (and as such, "inventing linguistics" is something done by linguists, not by language speakers). But language is not linguistics, in the same way that music is not music theory.

Oh boy. Music theory, as such, has no "rules," and so of course Bach did not invent them. Music theory is a descriptive enterprise, which aims to make sense of music as composed/performed/enacted by humans. (I have a PhD in music theory.)

Bach's chorales were functional music for the Lutheran church, and to the extent that they form any sort of "rules" in music theory, it comes from the fact that they have been used to teach harmony for a long time (since at least the 1940s, as evidenced by this article). The reason for that isn't so much that they're prime examples of Western common-practice harmony, but rather that they have a homogeneous texture that's easy to use in classrooms, because they're easy for one person to play at the piano or for students to sing.

Recent music theory pedagogy has largely been moving away from the reliance on Bach chorales to teach harmony, especially as music theory has taken a broader perspective on what music we should be studying anyway. Studying the Bach chorales is just fine if you want to know about how Bach used harmony, but there's a whole lot of music in the world, and there's no meaningful sense in which Bach's music intrinsically defines a set of rules any more than Mozart's or Clara Schumann's or AC/DC's or Meredith Monk's defines a set of rules.

While acknowledging that git's CLI is often unintuitive: `git tag` lists tags, `git branch` lists branches, and `git remote` lists remotes, so I don't think I understand this particular objection.

The current version of perl is 5.36 (it's a really good perl). The language formerly known as Perl 6 is now called Raku. The "Perl 7 initiative" referred to in the grandparent is the idea that at some point, the 5.x series (i.e., the language you know as Perl) will accrue enough features and deprecate enough very old behavior that it'll get rebadged as Perl 7.

There's not a timeline for that right now, nor clear consensus on what exactly will be worth a version bump or how much backcompat between 5.x and 7.x there will be going forward. It's being actively discussed, though; the Perl Steering Committee (formed a couple of years ago) meets weekly, and discussion on p5p (the language development mailing list) is still fairly active, though admittedly much less so than in years gone by.

Very little of git as used by most people is Perl these days; almost everything has been rewritten in C by now. A few things remain, but they're pretty niche: git-send-email, the git-cvs tools (!), git-svn, and git-fast-import (maintained in the contrib/ tree) look to be the only top-level perl things left, at a glance.

Perl may or may not be relevant in 2022 (it's certainly relevant to me), but this article does not do a great job at explaining Perl's merits. The example code, in particular, is certainly not what I'd expect to see in a modern Perl shop. They don't use warnings or strict, which the author cites as a benefit of Perl over Python, and which is the bare minimum for maintainable perl these days. The examples also use CGI.pm, which was removed from the core Perl distribution as of perl 5.22, which was released in June 2015! (Nowadays you'd use a framework for that; there are lots to choose from.)

Many of the things the author cites are good about Perl are, in fact, good about Perl. But if you're writing new software in 2022, you should probably pick a language with a future, and that language is probably not Perl.