On the one hand, this is a change whose software engineering benefit is very small. (There is a small performance advantage, but it's not significant.) It has a large aesthetic benefit, though, in that it makes the standard library have one less ugly wart. But that wart wasn't really doing anything except being ugly. Some community members have a point of view that "ugly" shouldn't matter, and that in particular, the bar for breaking changes should be very high, and far higher than wart removal.
On the other hand, this particular change should affect extremely little actual code, because defining (/=) explicitly is dumb. When it does affect code, the solution is just to delete the lines of code that are doing the dumb thing. They don't even need to be replaced, because the only reasonable behavior is already provided by the default. Just deleting the dumb code is enough.
On the OTHER other hand, even a small amount of code change can add up to a lot of dependency management work. If just one library somewhere at the leaf of a dependency tree needs it's explicit (/=) deleted, then version bounds need to be added for all upstream bodies of code to ensure that they don't try to build against the old now-broken. Changing all those version bounds across perhaps dozens of packages is far, far more work than just deleting those few lines of code. You can look at this as a broken process, but I don't think anyone has a great answer to dependency management.
So I think it's in the end kind of a coin flip between (a) it's infuriating to some people not that this specific change is being made, but that it indicates the community values aesthetics above backward compatibility, and the absence of almost any practical software engineering benefit makes this a compelling test case upon which to direct their fury, and (b) despite the tiny amount of actual code change, it's quite possible it could lead to a non-trivial amount of coordination work between libraries, and THAT is a real (and not very fun) job.
One of the most important lessons learned by the Haskell community is that we shouldn't worry about whether complete type inference is possible. We should worry about whether type inference can be maintained in the easy cases, while falling back to explicit annotation for the hard cases. All of rank-n types, GADTs, type families, even basic type classes, break complete type inference. The solution has always been to document the limitations, draw as clear a line in the sand as possible, and then go on and introduce those features. This doesn't affect the usability of the language.
What does affect the usability of the language is when (a) the line in the sand isn't very clear from an end-user point of view [see simplified subsumption in GHC 9, for example], or (b) the line is on the wrong side of simple features [see monomorphic local bindings, for example].
I guess what I'm saying is that Idris having minimal type inference is kind of terrible, and the excuse that it's not decidable for dependent types is a flimsy one.
Yeah, I'd say that Haskell has done a phenomenal job for most of its history of maintaining a balance between the interests of researchers, commercial programmers, educators, and enthusiasts/hobbyists. At different times, each of these communities has been inconvenienced by decisions made by the Haskell community, but the community has nevertheless been for the most part welcoming to all of them. On the other hand, some of the darkest chapters of the community have involved power plays where one of these groups feels entitled to sideline the others and decides it should be in charge.
By contrast, a typical mainstream programming language might, say, completely neglect one or more of these communities in favor of whatever is best for commercial programmers. Particularly when, like most mainstream languages, it's mainly funded by those interests.
Fair enough. For my part, I didn't include that comment as just an obligatory remark, though. I did so because it occurs to me that, for instance, the only tech community I'm involved in where I have regularly met people who identify as non-binary gender is Haskell. I don't think that's entirely a coincidence, and I do think it's related to the strong role played by non-industry Haskell programmers in the community. So I said so.
As the author of the article, I hope it's clear that we're talking about the community that has formed around the programming language. Racial diversity isn't, to the best of my knowledge, mentioned at all in the Haskell Report or the source code to the GHC compiler. But when I'm talking about the community, that is all about the people in that community. Some of the people in that community have very different backgrounds from myself, and I think that's a valuable thing to celebrate and acknowledge.
That said, it wasn't the point of the article. It's fast becoming the point of this comment thread, though, which is unfortunate.
Thanks for the question. I'm the author of the article, and I can talk about why I included that paragraph. It's not because everything has to be about racial diversity. Rather, it's because I was already writing about some kinds of diversity, and when I reflected on people I know in the Haskell community, I realized that we've got some pretty interesting characters, and that this is due to communities like Tidal Cycles. Tidal Cycles is a great example of why something that's not at all important to corporate sponsors is nevertheless a cornerstone of the language community. I've had the chance to meet some really interesting people with interesting stories who I wouldn't have met if Haskell were just a language for writing web services.
To be clear, the algorithm is proposer-optimal only when compared to other stable matchings. It is still possible that there exists some other matching that would make all proposers happier. It just won't be stable: there will be some pair of proposer and proposee that could switch to immediately increase their happiness, BUT it would set off a chain reaction of further swaps that leave everyone less happy in the end. This was a bit surprising to me.
There's a variant where you run the deferred acceptance algorithm, but then only the proposees who never rejected anyone finalize their decision. All other proposees and their matched proposers split up, and the whole algorithm is run again with the unmatched participants. This time, you end up with a Pareto-optimal matching for the proposers, with respect to their stated preferences. That is, there's no possible way to make anyone happier without making someone else less happy. But it's not stable, and the algorithm is no longer strategy-proof. (In fact, one can prove that no strategy-proof algorithm can guarantee a Pareto-optimal matching!)
If the result of the election is the choice of two finalists, then as long as there are more than two candidates, there are more than two possible outcomes. For example, if the candidates are A, B, and C, then the possible outcomes are: (A and B), (A and C), or (B and C), so 3 in all. In general, for n candidates, there are n * (n - 1) / 2 outcomes. By Gibbard's Theorem, then, either there is a dictator, or there is strategy.
Another way to see this: the entire process of choosing two finalists and then having a runoff to choose an ultimate winner counts as a collective decision-making process. That there are two separate votes doesn't actually matter. By Gibbard's theorem, then, if there isn't a dictator, then the entire process is strategic. Since the chance to use strategy doesn't occur in the simple-majority final runoff, by process of elimination, it must occur in choosing the candidates who qualify for the runoff.
Author here. No, it doesn't mean that. If the election is held to determine who wins, then the outcome is who wins, and everyone has opinions about that same outcome.
Contrast this to the matching problem, where the outcome is where ALL the candidates are assigned. You're allowed to have an opinion about where you are assigned. I'm allowed to have an opinion about where I am assigned. These opinions might conflict indirectly because of limited spots, but they don't conflict directly. This is very different from the election case, where if you and I have different opinions about who we want to win, those opinions are always contradictory.
Keep in mind that this article was written by a reporter who was unable to talk to the district, and got all their information from a lawyer representing the kid who was suspended. The district itself is prohibited from releasing any information about the case by privacy laws, no matter what the family says or how accurate it is. The same evidence was presented to the school board in an appeal hearing, and they (granted, probably not technical people) did not find it convincing. That doesn't mean the family's lawyer is wrong, but it is worth keeping in mind as you evaluate this. We don't have the whole story here.
Something's weird with that. Gwinnett County schools are out for the summer starting late next week. Most of the "three months" will be when school isn't in session, unless he was planning to attend summer school.
Mathematicians use words differently. What you're talking about is what the article calls a generalized continued fraction. Generalized continued fractions are not unique, and there are actually many of them for pi, which have different rates of convergence. The article here contains a (different) nice generalized continued fraction for pi, and an algorithm for converting from generalized continued fractions to standard ones, thereby computing the exact standard continued fraction for pi as a result.
(These were later edits to the article, so if you read it early on, you may not have read those parts.)
It's actually worse than that. Even knowing the very first term of the continued fraction result would already tell you that the number is at least 2. So the computation will hang without ever producing even a single term.
This is a fundamental problem shared by any form of exact real arithmetic with unique representations; you can always then be forced to make a choice, before emitting any information, that depends on infinite amounts of information about the operands. To solve this problem, you would need to choose a representation with redundancy. (With redundancy, equality comparison becomes harder, and it can still diverge, but you can still get approximations of the answer.)