Adrian May
I really don't know why somebody can't make a simple and well intentioned point without getting attacked by people who feel threatened over every little thing.
It's because we're failing to see the problem. I mean, if you can pinpoint the source of your problems we could work on a solution, and we would be happy to do that. However, it is important to keep in mind that Haskell is very active and things change a lot. This is not a problem, it's the mindset of this community. If you are turning it into a problem, feel free, but then the only suggestion I can make here is that Haskell is probably not the right choice for your particular development strategy. In other words, for Haskell it's simply wrong to assume that you can use legacy code that hasn't been maintained for many years. Regardless of whether you like it, this is the way to go. If you want to use Haskell, be prepared to maintain your code. This usually boils down to making small adjustments. When the big breaking change in the base library came I had to adjust a number of type signatures in my projects and I was done. These adjustments become necessary from time to time, and you should be ready to perform them.
I said from the start that I think Haskell is cool.
Unfortunately that doesn't really help. What you are trying to achieve is a shift in our fundamental philosophy, which is very unlikely to happen, even if the shift is small. Using Haskell is great, but does require you to keep up to date. The other option is to go with old compiler and library versions. They are all available, if you need them for your project, but this is a bad solution.
I'd just like it to pay a bit more attention to practical issues whilst making progress with its theoretical ones.
It's very difficult to combine those. Communities solve these problems differently. Most communities try to keep compatible at the expense of eliminating much of the potential for innovation. The Haskell community prefers to go the innovation route and is prepared to repair occasional breakages. They do occur, and we fix them.
Why don't you just put it in the forum rules that nobody is ever allowed to criticise anything?
Because that's wrong. I criticize things a lot, sometimes with a much stronger tone than you did. =)
At the end of the day, I'm just a typical manager who's atypical in wishing he could tell his programmers to study a bit of Haskell without making it a synch for the manager next door to knife him in the back for suggesting something that looks this unstable. This is the real deal on how Haskell looks out there in the mass market. You can lead a horse to water...
If it's your decision, you shouldn't be afraid to make it. You are the manager of your team! Don't let yourself be stabbed by another manager. Recognize that your choice can lead to higher productivity, if you don't let yourself be distracted by this pointless matter. And yes, it is pointless. If you simply move on and get to productive Haskell work, you will find that this is a non-issue. In particular, you want to make educated decisions, which means that you should probably research the current standards in the Haskell community. If you would have performed that research from the beginning, you would have come to the conclusion that WASH was a bad choice to begin with, which leads me to another very important point: I have worked in many SCRUM-based teams. While I could question the general usefulness of this paradigm, I have to say that it has taught me a number of very important things, and one thing in particular: Programmer choices should be made by programmers. You shouldn't have made the decision about the web framework in the first place. Get a team of Haskell programmers and let them choose the best tool for the job. Greets, Ertugrul -- Not to be or to be and (not to be or to be and (not to be or to be and (not to be or to be and ... that is the list monad.