FWIW, the latest stable release is 7.0.12, released a week or so ago: https://www.mongodb.com/docs/upcoming/release-notes/7.0/. (I'm not sure why the URL has /upcoming/ in it, actually: 7.0 is definitely the stable release.)
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.)
I'm not sure what your dissent is, so I'm not sure how to respond to it. I think you're saying that you had a good experience in your music theory classes, which used Bach chorales, and you wouldn't want to discard that experience in favor of a shallower, broader curriculum.
If so: that's not really what I'm saying at all! Even in courses that focus primarily on, say, Western common-practice harmony (as many basic undergrad theory courses do), you're likely to find a much broader variety of music being taught than just the Bach chorales. That's partly because the field as a whole has been moving away from strict adherence to the traditional canon, but also more basically it's just good pedagogy. That is: most music that students play isn't going to be four-part homophony, and so learning to do harmonic analysis of string quintets or saxophone quartets or lead sheets provides a much stronger grounding about how harmony works in real music -- even if you circumscribe harmony quite strictly as "harmony as deployed in Western common-practice music betwen 1700 and 1850."
Disclaimer: I left the field and have been employed full-time as a software developer for more than 5 years, and pedagogy isn't an area of the field I follow closely. A good recent example is the open-access textbook Open Music Theory (https://viva.pressbooks.pub/openmusictheory/); perusing the examples there I think will be a good demonstration of the breadth of both styles and composers that's pretty representative of current pedagogy, even without radically altering the aims of the undergraduate music theory curriculum (which is also happening).
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.
Fair point; that's partly my own bias (I know basically nothing about non-Western musics), and partly because of the article I'm responding to ("Bach doesn't tell us anything about gamelan music" isn't an interesting observation).
But also: the majority of academic music theory at the moment does focus broadly on the Western tradition. That's changing, I think, but a quick scan of recent articles in Music Theory Online (https://www.mtosmt.org/issues/issues.php) reveals quite a broad spectrum of music, most (not all!) of it is from the Western tradition.
We know quite a lot about Greek music theory (Thomas Mathiesen's Apollo's Lyre: Greek Music and Music Theory in Antiquity in the Middle Ages is the go-to source here: https://archive.org/details/mathiesen-1999-apollos-lyre/page...). Of course we don't have recordings, but we do have a solid understanding of the theory, and some very good guesses as to the scales and intervals.
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.
Yeah, `git log --format=%ae | sed s/.*@//` will get you most of the way there, and then it’s down to how you want to deal with the domains themselves, as you say!
The rule we have is that anything that is not idempotent and not run as a matter of daily routine must dry-run by default, and not take action unless you pass --really. This has saved my bacon many times!
Hmm! You're right that I hadn't looked it a while, so I checked before making the comment above. I'm still seeing the same thing I always have, which is "No response data available for this request". Possibly something is slightly wrong somewhere (though Chrome dev tools seem fine on the same), but you've given me something to look into, thanks!
SSEs are one of the standard push mechanisms in JMAP [1], and they're part of what make the Fastmail UI so fast. They're straightforward to implement, for both server and client, and the only thing I don't like about them is that Firefox dev tools make them totally impossible to debug.