I agree. Firing is at least more honest (or there's a lawsuit if it isn't). Being pushed out sucks. I know because it's happening to me right now for bullshit reasons (the complaint is that my throughput is inconsistent but yet my average throughput is better than the other dev of my level on the team, and I'm involved in more above and beyond work). Being pushed out is very stressful and has negative mental and physical effects, especially if you have specific disabilities (I do).
Exactly.
I usually don't stick around when a team enters that phase, but sometimes it takes a 6-12 months to exit.
I've been on teams where management very clearly tries to do a good team/bad team split.
This looks like hiring some space cadets to build the "strategic solution" that will magically fix every problem with the existing system (despite being managed by the same senior management).
The existing team is told to just keep the lights on / the new thing is going to be so much better / just give it another year or five.
There's not a lot of upside to staying around because you either end up fired at the end if the space cadets succeed, or if the space cadets fail you end up holding the bag of rescuing them in X years post strategic platform failure. And sometimes a secret third thing - the company being run this poorly ends up having to do RIFs and you end up fired randomly anyway.
Author here. It is true that one of my goals in writing that post was to discourage people from jumping on the NeoHaskell train, but a larger goal was to educate people on what NeoHaskell actually was because there were a LOT of misconceptions floating around that led to confusion (and that confusion in turn amplified the drama because people were reading things into NeoHaskell that were not actually true).
That's actually correct versioning in Haskell. The Haskell ecosystem uses a different versioning convention from other ecosystems where the first two components of the version number signal breaking changes. For more details, see: https://pvp.haskell.org/
All of the above to some degree. I can name some specific examples of each of these occurring:
* For an example of "Drop B", at one point the haskell-lsp package was deprecated in favor of the lsp package, so all downstream packages had to drop the haskell-lsp package as a dependency and migrate to the lsp package (I personally had to do this)
* For an example of "Don't let A change", that might happen for some period of time, although not indefinitely. The most obvious example is holding back the compiler version. For example, Stackage was on GHC 8.10 for a while, even after GHC 9.2 was released, due to breakage introduced in GHC 9.0.
* For an example of "Ignored B's declared dependency constraints", this is extremely common, especially when the `base` package is upgraded (since many packages have conservative upper bounds on their `base` dependency which can often be trivially bumped without issues).
* For an example of "Take over development of B" the `aeson` package for JSON support is one example of this. More generally, this happens when abandoned packages get adopted by the Haskell organization.
And Stackage does require contactable maintainers for supported packages. There are some exceptions to this rule, though. For example, sometimes a package gets added where the maintainer is available, but a dependency for that package was not yet on Stackage. I believe you can either add that maintainer to be the contact for that dependency, too, or it can be an orphan package. There are a bunch of people who fill in the maintenance gaps in the ecosystem by fixing these packages that don't have official contacts or active maintainers.
The order in which you combine overlays can sometimes matter. In other words, overlays are monoids, but not commutative monoids. That said, most of the time overlay order does not matter
The point of the post wasn't to explain that Church encoding is a replacement for the visitor pattern. The purpose of the post was to explain that the visitor pattern is essentially the same thing as Church encoding (thus the title of the post), because I noticed a lot of people were not appreciating that connection between the two.
That's fine, but it seems like some of the confusion comes from unclear expectations? There is a vague promise at the beginning of the post that this will somehow be useful for programming:
"This post also explains how you can usefully employ the visitor pattern / Church encoding / Böhm-Berarducci encoding to expand your programming toolbox."
Thank you for the feedback. I was conscientious of that shadowing issue when writing it, but I just wasn't sure what to change on either side to differentiate them.
You're right that there is no benefit in creating another abstraction, but the point of the post is sometimes the language doesn't have support for the original abstraction (e.g. sum types), so in some cases the other abstraction (e.g. visitor pattern or Church encoding) is the only available abstraction.
Look, I never tried to be offensive or even bully. But I care about the principle of calling things by its proper names and precise language usage. I am describing things exactly how I see them.
And I have reasons to do so. Like so many others I have traveled that road, from Haskell basics up to the latest writings and courses of that self-propelled category theory expert - Bartosz, for whom I have great respect.
However, at the end of the journey I came to different conclusions, that the whole subfield is nothing but a sect (the definition is a consensus based group of eager supporters) and the whole set of nested abstractions is empty of meaning, except in producing deeper and deeper nested abstractions. I cold provide analogies with Eastern religious sects, which I have studied too, where abstract things are described in minute details, and the merit is in the knowledge of these minute details, but I won't. It will only complicate this discussion.
So I don't see any meaning, and I see socially constructed interested, identical to esoteric teachings, which is even better definition of what Bartosz and others are doing.
Author here: it's not changing the problem definition. I can confirm that the original motivation for writing the post was to show the theoretical underpinnings of the visitor pattern, not to encourage people to gratuitously use double dispatch.
