There's even a few change ringing towers dotted around parts of Africa, Australia, some of Europe. Just few and far between.
But when compared to England, where practically every town can be relied upon to have at least a 6 bell tower where change ringing can happen, it's no comparison.
My college (Sewanee: The University of the South) is one of the few places in the US with a change ringing tower. It definitely fit the Anglophilic vibe of the place. It was always lovely to hear.
Apparently, I now live in one of the other places where there is a tower (Carmel, IN), but I’ve never heard changes rung on it. It doesn’t appear from the website that it has any local players, which is too bad.
I love seeing a change ringing article on HN, especially with well labelled diagrams!
The move to a framework system where we can all ring what we like and just describe it within an agreed upon nomenclature is a great improvement rather than the legacy Decisions. Having strict rules always seemed quite dated to me - the ringing police after all do not show up if you ring a "banned" performance. But agreeing on names makes communication possible - a good role for a central body.
Jump changes are fun too, but I don't think I agree with the article that allowing them has really led to a revolution. The top performances on BellBoard are of commonly rung non-jump methods. In fact I don't think I've seen a jump method be featured at all. Philip himself doesn't seemed to have published a performance of "Jump" anything since 2013. For many I think it remains an interesting novelty.
The other reason jump changes are not a revolution and have remained just a curiosity is physics, something that's ignored by the article.
For non-ringers, in change ringing the bells rotate 360 degrees each time they strike, from mouth up to mouth up. The clapper hits the bell when the it has rotated roughly 270 degrees from mouth up and is more or less horizontal, approximately 2 seconds after it starts moving. The bells are usually in the 100kg to 1000kg range (for US folks, that's 220lb to 2200lb), although they can be up to 4000kg. The only point when the ringer can exert control on the bell via the rope is when it is near the balance and mouth upwards, and speeding it up or slowing it down any more than one "beat" is physically very difficult on heavier bells, particularly if you are doing it for a full peal, which usually takes 3+ hours.
This is good news. The dart language has been getting more complicated without corresponding quality of life improvements. A first class record object without messing around with macros would be a great start.
Because implementing them is tedious, and you can always simulate them with simpler aggregation methods, or possibly lexical closures.
When the language implementors start making larger programs, it will soon become apparent how the program organization is hampered without named, defined data structures.
I didn't add structs to TXR Lisp until August 2015, a full six years from the start of the project. I don't remember it being all that much fun, except when I changed my mind about single inheritance and went multiple. The first commit for that was in December 2019.
Another fun thing was inventing a macro system for defstruct, allowing new kinds of clauses to be written that can be used inside defstruct. Then using them to write a delegation mechanism in the form of :delegate and :mass-delegate clauses, whereby you can declare individual methods, or a swath of them, to delegate through another object.
Because it's arguably syntactic sugar and, IMHO, it's worked out better for developers for Dart to model it as a 3rd party library problem. i.e. have a JSONSerializable protocol, and enable easy code generation by libraries.
i.e. I annotate my models with @freezed, which also affords you config of the N different things people differ on with json (are fields snake case? camel case? pascal case?) and if a new N+1 became critical, I could hack it in myself in 2-4 hours.
I'm interested to see how this'd integrate with the language while affording the same functionality. Or maybe that's the point: it won't, but you can always continue using the 3rd party libraries. But now it's built into the language, so it is easier to get from 0 to 1.
If you target SDK < 31 then you’ll see reduced availability on the store. That means users with phones running Android higher than your maximum targeted version won’t be able to newly acquire it. Existing users are unaffected.
If you target SDK < 33 then you need to update to SDK 33 because you won’t be able to make releases with the old target SDK anymore. (Existing bundles are fine). If you miss the deadline it doesn’t introduce further enforcement than that but it might mean if you had an urgent update you’d need to update the target SDK at that time. So sooner is better.
At Google there’s not really such a thing as code that never changes. Your dependencies will shift beneath you, even if it’s just the compiler itself. More likely though the libraries you use have been updated, a robot or two have come through and applied automated fixes etc etc.
So if we’re using it once a year, (we do have tools like that, maybe not strictly annually but certainly rarely) then you do indeed want it to be automatically built on some kind of recurring basis so it’s ready to go when you need it. And the tooling makes it (relatively) easy to have that happen.
In the UK it seems a clear upgrade. I can be sitting on a train downloading Netflix shows between stops before we go underground. Speed tests often higher than I get at home over VDSL. Couldn't do that on 4G.
I wonder if this has the same downsides as golden and screenshot type tests, where you end up over-asserting resulting in tests that break for unrelated changes?
Obviously that’s a risk for hand written tests too but it’s easier (today… who knows what copilot like systems will offer soon!) for a human to reason about what’s relevant.
Yes, that is definitely a downside for these tests. The worst is when the text of some exception is printed and it includes line numbers. It does still require some discipline to think about what you're printing and avoid output that will be very noisy. This problem is mitigated quite a bit by the ease of accepting changes when these tests fail for obviously nonsense reasons though (just hit a couple buttons in an emacs buffer).
I lived in a house with one of these in Bermuda. Lesson learned that it’s not a good idea to use up your water pressure while the power is out as then your pump doesn’t work. Otherwise seemed to work great.
I didn’t write Java professionally before joining Google. I interviewed in Python, there’s a much wider gap between those two languages than between C# and Java. I’ve also worked with people who used to write C# since it’s kinda common in line of business finance stuff.
Forget the hundreds of hours in leetcode. If you actually want to work for one of those companies, get in touch with a recruiter and see if there’s a role that suits. Ask for prep time later if you need it.
I’ve personally appreciated people willing to talk about the topic of death and the person who died. As opposed to those seeking to provide distraction. In particular I couldn’t stand anyone seeking to give a positive spin on it to “cheer me up”. It’s a bad thing. Just marking it and being with the person is enough.
There's even a few change ringing towers dotted around parts of Africa, Australia, some of Europe. Just few and far between.
But when compared to England, where practically every town can be relied upon to have at least a 6 bell tower where change ringing can happen, it's no comparison.