1. 40
  1.  

  2. 19

    I find this piece pretty frustrating.

    I think the thesis is fundamentally interesting and worth exploring: the idea that adopting Haskell means that you’ve spent your “novelty budget” and need to dial things back rings true to me. However I feel like going from there into a bunch of very specific technical recommendations is dissatisfying and doesn’t lead to much insight into how to manage Haskell effectively if you’re trying to minimize novelty, because it doesn’t take individual teams’ needs or specific goals into account. And one of Haskell’s primary strengths is exactly the fact that you can dip into the massive collection of extensions, libraries, and conceptual approaches to tailor something very specifically to your domain and reduce boilerplate, when you need to. Of course you don’t want to turn everything on and go nuts, but we should be able to think more generally about how to approach limiting novelty than just checking things off of a list.

    Let me state up front that I dislike the whole “Simple Haskell” notion that folks are latching on to lately, simply because I don’t see us ever coming to consensus on what that means; what’s simple for some may be challenging, confusing, or pointless for others, and fundamentally it makes no sense to me to close the door on features when they could solve a problem you’re having, simply because you’ve arbitrarily put them on that side of the “Simple Haskell” line.

    And that’s also why I find this piece so frustrating: extensions like FunctionalDependencies and MultiParamTypeClasses seem pretty basic to me, and I don’t buy the “gateway” argument just like I don’t buy it with drugs; saying you should e.g. avoid MonadReader but exhorting people to use mtl seems kinda weird; generics are stupidly powerful and great at reducing boilerplate and under-leveraged and should be used more IMHO, as long as you can justify it; and as someone said in the Haskell subreddit, if you think Nix is confusing then ask more questions, but don’t start spreading FUD about it! Others are using it to solve problems meaningfully and have done the math to determine that the learning curve and complexity are worth it for what they’re trying to do. I get that it’s novel and not appropriate in all situations, but…same for Haskell right?

    I realize the author was talking about a first project for a team, but they also clearly assert that having an experienced Haskell programmer on the team is a necessity–so shouldn’t they also have the flexibility to introduce whatever Haskell features are necessary as long as they can balance the complexity and learning curve with the needs of the team?

    And sorry, this is just wrong, or at least, hyperbolic to the point of absurdity:

    Haskell makes it really easy to refactor code. Too easy. It’s a bug, not a feature.

    In the end these are choices the author’s team made to try to balance the trade-offs involved in choosing such a novel stack. They may not work or be appropriate for every team. I really do think there’s an interesting discussion to be had about balancing novelty, but I don’t think a laundry list of “do this, not this” is the way to go about it. It’s dogma; I want general principles other than “No Fancy Types” to help guide me.

    EDIT: 100% agreed on the Graham Hutton recommendation over the other two, btw. Also don’t mean to suggest there isn’t a lot of useful advice in here, I think re-reading my comment it may seem like I’m throwing the baby out with the bathwater: this is obviously written by an experienced Haskell programmer and I think a lot of the specific recommendations are absolutely valuable and worth considering. I just wish it had been framed differently and there had more discussion on general principles vs. specific technical suggestions.

    1. 7

      the whole “Simple Haskell” notion

      If anybody is interested in reading more about this, I’ve collected links to some background and discussions here.

      1. 5

        Thanks, this is great.

        In particular I find Snoyman’s Boring Haskell a lot more palatable as it’s framed as, “here are a set of specific choices that we’ve made and encoded into a library/alternate prelude.” I think the framing works for me better because you can also simply drop the library in, read about the approach, and go, and figure out relatively quickly (hopefully) if it works for you.

      2. 5

        So what exactly is the benefit of the additional things you want to include in the first year (and the author doesn’t) – and what else would you remove in exchange?

        E. g. you think people should learn Haskell and Nix at the same time – what else would you remove, considering that you agree with the basic argument

        the idea that adopting Haskell means that you’ve spent your “novelty budget” and need to dial things back rings true to me

        1. 3

          So what exactly is the benefit of the additional things you want to include in the first year (and the author doesn’t) – and what else would you remove in exchange?

          E. g. you think people should learn Haskell and Nix at the same time – what else would you remove, considering that you agree with the basic argument

          Great questions!

          So using the nix example, I can definitely see a world where a more experienced Haskell programmer who finds nix to be a great solution to a lot of problems sets up some nix infrastructure to manage dependencies, and/or builds out some kind of deployment infrastructure with that, and then provides guidance to the rest of the team for using it. Maybe day-to-day, less experienced programmers would never have to touch their *.nix files, but it could solve a bunch of problems that the org has. This is predicated upon having a team-member who is willing to own that and who has the relevant experience and maturity to introduce this kind of novel tech without burdening the rest of the team, as a given.

          I think there’s another aspect to this which is important to call out, which is that you want to be guiding those developers who are less experienced with Haskell (and the ecology around it) so that they can begin to make some good decisions themselves. That being the case I think that, rather than hiding certain features from people to try to prevent them from getting frustrated or confused, it’s important to give them a reasonable surface area to start with, in terms of complexity they need to wrangle day-to-day, and slowly introduce new features as they become relevant. This is entirely orthogonal to any discussion about “Simple Haskell,” which I fundamentally find to be more confusing itself than it’s worth.

          I’ll reiterate again that I think a lot of the specific points made in the piece are useful and great advice though–I just think a collection of points like those in the article should be part of a set of internal standards and conventions resulting from a thoughtful process you and your team have gone through together, not a list of things to confirm as you start in on your new Haskell infrastructure goals.

          (Interestingly (to me at least), I’m finding myself thinking about the same point that comes to mind whenever I’m discussing “Agile” vs. agile programming: trying to make vague, but useful guidelines into rigid practices is a good way to find yourself locked-in to a dogmatic and inefficient approach. Maybe we should be talking about simple Haskell vs. “Simple Haskell,” if anyone knows what I mean?)

          EDIT: sorry soc it probably seems like I didn’t answer your question in a straightforward way (“what else would you remove in exchange…”), but I hope it’s clear that I was trying to suggest a different way of thinking about it. That said if you think I’ve evaded the question let me know and I’ll try to respond more directly.

          1. 3

            If someone at my job tried to sell me Haskell for a service, I might consider it. If I was sold Haskell and Nix, I would not approve the project. That’s a lot of new programming languages and tools! Add one new programming language at a time. You can settle for Docker and stack or Docker and cabal. If Haskell doesn’t work out, then all the Nix infra is wasted effort. Do the simplest thing that could possibly work and grow when you feel the need.

            1. 1

              Do the simplest thing that could possibly work and grow when you feel the need.

              I’m not disagreeing with this. I’m stating that the simplest thing that could possibly work may not be the specific set of things that the original article claims, or that you are claiming. I can imagine many ways to use Haskell and Nix together and introduce them at the same time that doesn’t “bust the novelty budget,” and I tried to explain one way in the post you responded to. Fundamentally I don’t agree with the a priori reasoning that simply introducing these two tools together is too much, or furthermore, that there’s any specific subset of Haskell that one can point to as “the simplest thing.” This is always going to be contextual.

            2. 2

              Maybe we should be talking about simple Haskell vs. “Simple Haskell,

              YES! This is why I always put scare quotes around “Simple Haskell”… after all simple isn’t easy.

              I find the “simple haskell” vs “fancy haskell” debate mirrors “worse is better” vs “better is better”. As a result I’ve recently been reading up on that debate.

              If we revisit https://www.jwz.org/doc/worse-is-better.html then we see:

              worse is better: Simplicity-the design must be simple, both in implementation and interface. It is more important for the implementation to be simple than the interface. Simplicity is the most important consideration in a design.

              better is better Simplicity-the design must be simple, both in implementation and interface. It is more important for the interface to be simple than the implementation.

              “Simple Haskell” advocates seem to advocate for things that result in simple implementations at the cost of the interface. They might disagree with my characterization here, so one example is whether or not to use something like deriving-aeson[0] or writing manual instances for aeson.

              I think that simplicity of interface is ultimately what will make Haskell more approachable, but that requires sanding down all the rough edges of bad type errors.

              0: https://hackage.haskell.org/package/deriving-aeson

              1. 1

                I never responded to this but I’ve been thinking about it a lot since you posted it. It never occurred to me to connect this to worse-/better-is-better. I’m still not sure where I land but it’s very interesting to me, especially the bit about prioritizing interface vs. implementation simplicity and how that plays out in the whole “Simple Haskell” debate. Maybe I’ll even have something meaningful to say about it at some point…haha.

          2. 4

            Do note that this is aimed squarely at a less experienced non-established Haskell crew getting a product done successfully. You seem to be arguing against a point that the article doesn’t even try to make.

            Some other points:

            • yes nix works, but also very much yes it’s complicated and hard to learn and deducts massively from your novelty budget
            • the important part (to me) with Simple Haskell (and this article) is less about coming up with a concrete selection of things to use or not to use (though those are quite helpful as a basis for discussion), and more about acknowledging that all the things that could be cut out have significant costs, and it’s worthwhile (imperative, even?) to aim for simplicity
            1. 1

              Do note that this is aimed squarely at a less experienced non-established Haskell crew getting a product done successfully. You seem to be arguing against a point that the article doesn’t even try to make.

              I don’t feel like I am. My arguments were specifically about how a team trying to introduce Haskell to their org. should think about structuring their Haskell app when they have at least one reasonably experienced Haskell programmer on the team, which as far as I understood the article, was how the author was framing things.

              As far as your other points, I don’t disagree with either of them (or at least, regarding the latter point: assuming that is what “Simple Haskell” means I don’t disagree), but I don’t think they are arguments the author was making, which is what I was trying to argue against.

              1. 1

                worthwhile (imperative, even?) to aim for simplicity

                It trades simplicity of initial implementation for complexity of interface/usage later though. It takes away the choice of using more complex pieces even when they are unquestionably the right choice by making fitting those things into your current codebase exorbitantly difficult.

            2. 8

              Every sentence of this article is hard-won wisdom. While I think some language features and extensions can be used safely by anyone I think the author’s advice should be taken very seriously.

              Haskell features can have this tendency where one fancy type feature forces you to need another until you are using all these cutting-edge extensions just to catch a subset of the errors you might make in that code.

              1. 5

                From what I have seen, this article has not been received well in the Haskell community. :-/

                1. 8

                  I’ve been a professional Haskell user for almost 7 years. I agree with pretty much everything in this article. There might be some noise on reddit or twitter or whatever, but I can assure you that the thesis in this article is extremely sound.

                  There may be a silent majority in industry who think this way.

                  1. 4

                    I’ve been a professional Haskell user for almost 7 years. I agree with pretty much everything in this article. There might be some noise on reddit or twitter or whatever

                    Hi, noise here… I disagree and I’ve been doing professional Haskell for roughly the same amount of time.

                    1. 2

                      I’m sorry for my poor choice of words.

                  2. 7

                    I don’t think most communities take well to being told that their core beliefs are failing them, even if those statements are backed up by facts, (though what we have here is anecdata. From the sounds of it, pretty good anecdata, though).

                    1. 8

                      their core beliefs are failing them

                      That’s kind of a hyperbolic framing of the point this article is trying to make, isn’t it?

                      I think rather a lot of folks are disagreeing with specific technical points or the overall way it’s being discussed. Furthermore, the notion of “Simple Haskell” has been contentious from the first time I saw folks discussing it when it started getting some steam; that’s just something the community hasn’t found consensus on. Finally, a lot of Haskell programmers also agree with a lot of points this article is making even if they don’t agree with the overall approach (which is where I stand).

                      1. 4

                        Have you read responses by the Haskell community? Or are you just dismissing them based on the idea that they’re probably too biased to critique this article in any way worth reading?

                        1. 6

                          Yea, it is a shame that parent commenter made a generality based quick assessment without having any idea about the facts of the matter involved on this topic.

                          Discussion about this article at the Haskell community if anybody is curious: https://www.reddit.com/r/haskell/comments/j9g9rk/delivering_with_haskell/

                          And here are the past discussions on the topic itself:

                          1. 3

                            I will admit that I’m not an insider in the Haskell community, and that I’ve not read their responses outside of this thread. So, what you’ve gotten from me is an impression that a non-Haskeller has about Haskell, and it’s community. Take it with a grain of salt, but perhaps as a bit of PR intelligence?

                            I didn’t mean to dismiss them, so much as point out that when you’re cutting against the grain of a community, there is likely to be resistance from that community. I overstated my point, for sure, but I also do not consider the Haskell community unique in this regard. Go has had a lot of examples of this, for example, relating to generics and package versioning and so on. Ruby/Rails (rather than Ruby in general) has had DHH pushing back against certain architechtures. I should have expanded on things more, and probably waited until later in the day to post.

                            My impression of Haskell has been that a lot of people try to push the language as far as they can, and that they believe doing so brings them a lot of benefit. So seeing someone say “Heeey, lets put the brakes on a bit” seems like it’d naturally cut against that grain. I think this is the first I’ve heard about Simple Haskell, for example. Granted, I don’t follow Haskell circles much, other than what pops up here and on the orange site.

                            I’ll try to be a bit more considered about Haskell going forward.

                            1. 3

                              My point is: ‘people are biased against things that don’t align with their beliefs, i.e. their existing biases’ isn’t news. Saying that in response to people disagreeing before actually becoming familiar with their disagreement just poisons the well.

                              By definition, that statement is in and of itself revealing of a bias against the Haskell community’s criticisms. We can’t take bias as a reason to dismiss something (i.e. prejudge before reading), because that in and of itself is bias, which means the dismissal can just be dismissed under the same rules; it’s self-defeating.

                              1. 1

                                Fair enough then. I will try to avoid poisoning the well in the future.

                                As someone who is a Haskell outsider, however, after looking over the reddit thread, and realizing that the article has been more controversial (rather than universally shot down), I’m now tempted personally dismiss the noise as inside baseball. Not to say the conversion is not an important one, but that it is one that I ok missing the majority of, since I don’t have a major horse in the race, other than generally preferring simple things. I don’t know Haskell well enough to add to it meaningfully, and learning it is not on list of priorities at the moment, especially if a “simple” version of it is such a controversial topic.

                                1. 3

                                  The controversy isn’t that, all else being equal, simpler is better. If that were the position being advanced, it’s not hard to agree.

                                  The controversy arises for a few reasons, but here’s a snippet of a comment higher in the thread I agree with:

                                  Let me state up front that I dislike the whole “Simple Haskell” notion that folks are latching on to lately, simply because I don’t see us ever coming to consensus on what that means; what’s simple for some may be challenging, confusing, or pointless for others,

                                  but especially:

                                  fundamentally it makes no sense to me to close the door on features when they could solve a problem you’re having, simply because you’ve arbitrarily put them on that side of the “Simple Haskell” line.

                                  Rails is full of tricky metaprogramming, a “fancy” feature of Ruby that’s easy to create a mess with, but is powerful in the right hands. Beginners learn Rails in bootcamps around the world with little trouble, even though it works very differently from stock Ruby due to its magic.

                                  At the end of the day, you can’t dish out rules of thumb like, ‘keep it simple’ as rigid lists of what constitutes simple and what doesn’t. Judicious use of the right “fancy” features can turn a confusing complex mess into a simple easy to follow snippet. But use it in the wrong time and place and you’ve turned a slightly ugly snippet with lots of churn that does the job into an inscrutable use of a fancy feature only one person on the team is familiar with, as elegant as it might even be.

                                  The idea of limiting extensions and deciding based on what the team knows, etc., none of that is bad. But it becomes dogmatic when you have a pretty rigid list, especially when that list includes extensions to avoid simply for being “gateway drugs” to more fancy extensions and includes popular and widely-used extensions to avoid that aren’t even that fancy.

                        2. 4

                          That’s really a shame since I think the advice is sound. I’ve used Haskell for nearly a decade. Those fancy features have their place but I wish they were used more judiciously.

                          Also the idea that you can actually have a better time if you use less of Haskell’s features isn’t even that new of an opinion http://www.haskellforall.com/2012/05/scrap-your-type-classes.html

                      2. 3

                        Do not use Nix. Nobody understands Nix unless they have time to burn, Nix barely ever works, the guy who uses NixOS can never get anything to work, Nix will kill your project. Let the NixOS guy keep the nix files up to date for his own benefit, if he really must, but never make it sound like a requirement.

                        I’m surprised more people are not upset about that. I’ve never had good luck with nix personally but I feel like it’s advocates are many.

                        1. 5

                          I’m a nix user and I feel like mandating nix to anyone in your team is a disaster. Once your program depends on Nix to work then I feel like you have already done something wrong.

                          I do think Nix is decent for deployments.

                          1. 2

                            Heh. Yeah, I mean, I switched to Nix in large part because I felt like I needed more tedium and uncertainty in my life so I would appreciate nice things more. (Sincerely.) I agree that it’s pretty fair for people to not want to use it because it’s going to be more work.

                            1. 2

                              My apologies for inadvertently using the sysop hat on this comment. It is not an official comment. I had been going back and forth in another discussion for several days and I guess I got in the habit.

                            2. 2

                              I use NixOS for all of my personal projects. It is great, but it is so different, and therefore often incompatible, with a lot of the software world. Doing “simple” things like running a quick python or node script that has some package requirements can turn into a multi-day slog of reading documentation and testing third party Nix helpers. And then after you get your environment mostly set up you realize that one of the dependancies won’t work automatically with Nix, so it is back to to documentation.

                              I Nix is like Vim. I love it and use it often, but I never recommend it for others when simpler tools will work.

                            3. 1

                              This post is full of red flags for me.

                              Make sure to document how to setup a text editor and build tool in your README for all the platforms used at your work so that nobody can claim that they don’t know where to begin.

                              It’s always the users’ fault, not the fault of poor documentation. This is pure CYA.

                              “Everybody hates on Haskell but it’s awesome” - proceeds to hate on Nix.

                              Trying to start a project in a language with inexperienced and / or reluctant team members (heckling every time something doesn’t work) is guaranteed to fail, no matter what language you choose.

                              It’s not heckling if it’s a valid complaint.