It’s not missing it. I’ve published two books “Functional Design and Architecture” dedicated to this topic exactly. Seems haskellers prefer to ignore its existence for some reason.
7 Likes
Oh yeah, it’s out there, but not really near the “entrance” of the Haskell world. It’s not as ubiquitous as the design pattern material for OOP that you straight up get in uni classes in the first or second year.
From a quick glance your books look interesting, though I can imagine there are dissenting opinions for the specific choices you made on what to explain. There’s a million ways of doing things in Haskell, and very strong opinions in all directions as to what way is the right way. Specifically mtl versus free monads versus effect systems is fiercely debated.
This is also something I’ve noticed in discussions about Serokell’s certification program: questions like “why these choices for subjects?”. I think with any book, there are going to be a lot of people saying “you should have gone for Y instead of X”.
That said, thanks for writing these books. I think that the questions “what makes a good functional architecture”, and “what are the high level dos and don’ts” are extremely valuable to explore.
4 Likes
Side note: My personal backup program uses GHC2021 and effectful. I don’t recognize these issues. Do you have the latest versions of everything?
1 Like
I find Haskell actually really easy to maintain. The “if it compiles it works” is especially true when refactoring allowing to rewrite confidently bits of code which got overly complex.
5 Likes
I compare maintenance of Haskell programs to gardening:
-
When you do it daily, the results are beautiful and the effort is low. Each incremental step is nice and pleasant. -
If you forgot about your Haskell package for several years, it might be easier to burn the entire thing to the ground instead of trying to bring it up-to-date.
17 Likes
Hopefully this is not too off-topic, but I’m sad to see Kowainik’s packages like summoner, policeman, and stan wither. I’ve opened a pull request for summoner to update it to support GHC 9.4, but that has seen no response for over a month. Do you need help? I can’t promise anything, but maybe I could help with minimal maintenance like that pull request now and then.
2 Likes
agreed with this 
Tsoding was undoubtedly aware of the tendency of GHC upgrades to break older programs. Unlike many other compilers, GHC is one of the rare exceptions that not only accepts but also embraces breaking changes. Whenever an issue arises, it is promptly addressed and fixed, rather than leaving older bugs as permanent features to endure.
1 Like
I think it’s slightly off-topic but I haven’t been maintaining any of the Kowainik packages for more than a year and I don’t have plans to return to their maintenance. You should contact current maintainers if you want to offer support and maintenance help.
On a non-off-topic subject, since almost all Haskell packages are maintained by volunteers in their free time for free, it’s unfortunately quite common when people completely stop maintaining Haskell packages with no one to step in. Besides, often it’s impossible to use an older package if it hasn’t been maintained for a while.
Some people stop maintaining Haskell packages party because maintenance requires too much churn (myself included).
6 Likes
IIRC, I was trying to create a new Effect similar to IxMonadState (docs here). I think the effects you create in your app aren’t type constructors, hence
-- this compiles
data MyADT :: Effect where
...
-- this doesn't
data MyADT s :: Effect where
...
Yet another reason to use StandaloneKindSignatures (which is in GHC2021):
type MyADT :: Type -> Effect
data MyADT s where
...
1 Like
My experience is completely the opposite on this one. Haskell is the only language I’ve ever used where I’ve been able to come back to code years later and still be able to understand it.
5 Likes
It’s also quite unfortunate when other people volunteer their time for free yet their contributions are ignored.
I appreciate you are no longer a maintainer @ChShersh, so this isn’t directed at you, but I thought I’d mention it whilst we were “on the off-topic”. Do you have any suggestions about what I should do in this case?
3 Likes
In my experience, Haskell is rock solid when it comes to long term maintenance.
I am working on a web application with about 20 thousand lines of Haskell code and about 400 packages of Haskell dependencies needed for compilation. It was written, according to git, with Stackage lts-5.1. Looking up, this means base 4.8.2.0 and GHC 7.10.3. This was back in 2016. We are now at GHC 9.2, shipping new features every once in a while. The «hardest» thing to overcome, as far as maintenance goes, was when Amazon pulled a rug from under our feet and we had to roll out a patch to our dependency mime-mail — and I am saying «hardest» in quotes because that was a routine, clearly bounded change. We depend on all the same libraries all these years — a few times a small patch was needed, a «version bump». I have no tales to tell because nothing worth talking about ever happens.
I am hugely thankful to the people that made Hackage, Cabal and Stack. There are obviously cultural differences and disagreements. But the hard, principled position of Haskell’s packaging’s thought leaders made Haskell easy to rely on. They get all the flak and no praise; so let me praise.
I see the person in the video is from Novosibirsk, Russia. I know some people from there. As I see it, they are a rough about the edges kind of people. They like themselves a lyrical hyperbole and unafraid to be sincere both in the good and in the bad. I should be taking whatever he is saying with a grain of salt.
12 Likes
Just to notice, I’m also from Novosibirsk, Russia (don’t live in Russia though). I don’t think it’s valid to use ad-hominem arguments here.
6 Likes
Thanks everyone for all the thoughtful responses! I’m possibly starting a green-field project in my company, and have been a little on the fence about if I should use Haskell or not. In my gut, Haskell is what I want to use, but public opinion (from friends and internet) was causing me a little bit of doubt. But seeing experienced practitioners chiming in with a lot of positives helps me to feel a lot more confident in my decision. I really appreciate everyone taking the time!
7 Likes
My glualint hobby project is also close to a decade old (it’s from 2014/2015 IIRC), and still quite nice to maintain. It’s rock solid software that I manage to compile for Windows, Macos and two architectures of Linux. I still love maintaining it.
In recent years I’ve been refactoring some things. I originally wrote it while I was doing my master’s, and let’s just say it’s code I wouldn’t write that way today. I recently switched it over from “IO everywhere lol” to a proper effects system. I found a bunch of bugs in the process, and only accidentally introduced backwards incompatibilities. Otherwise, it was a great experience to refractor.
It runs on 9.4, and is only one broken dependency away from working on 9.6. Definitely a success story imo.
6 Likes
Just want to point out that theres survivorship bias here since everyone here likes haskell one form or another.
1 Like
Well, I mean, its a necessary evil I think lol. Only people who have stuck it out long enough to maintain a Haskell project in the long term can actually comment on how easy or hard it is to maintain.
But we still do learn something useful here, even with the bias: The survivors and enthusiasts find Haskell code easy to maintain. If even the enthusiasts were to concede “It’s not as easy as you might believe”, or “It’s about the same as other languages”, then I might be worried!
I’m of the impression that those enthusiasts have already left for rust…
1 Like
Tbh I hope that Haskell Foundation steps in and offers more protection for the Haskell ecosystem. It is very nice that we have all these libraries available for use, but often they bitrot or the maintainer vanishes.
Moreover, from the reports I’ve heard from various package maintainers, it often seems a bad idea to solo maintain a Haskell package and having a team or an organization in support to help keep packages current might be necessary, especially with important libraries.