Adrian May
[...] If you'd rather see more using Haskell, I strongly suggest you get a grip on what real companies actually have to worry about. It ain't mathematical rigour. Backward compatibility is a big chunk of it.
I'm not saying that you are wrong, but you may be looking at it from the wrong angle: Unmaintained projects depending on one of the major web frameworks still compile today. The strong version constraints used by packages and taught by the package versioning policy makes this possible. When you install it, it does the right thing. WASH on the other hand is really a legacy from the stone age of real world development in Haskell. As said, I'm surprised that you could even compile it today. I consider it a proof of concept that web application development is very possible with Haskell and the community has moved on to implement real web frameworks made for production use. This happens for all languages, not only Haskell. You may find that one or the other C/C++ package breaks with GCC 4 when it compiled just fine with GCC 2. This is why we have the major/minor/patch-level split in the first place. You can't expect that nothing will break when you update from GCC 3 to GCC 4. The same holds for GHC and even for strongly keep-being-retarded language implementations like PHP. At some (quite recent) point in time the whole language was revised and is called Haskell 2010 now. You can still compile with Haskell 98 and many old packages should still work, unless they are broken by the new base library. With the new language it's simply that the type system has changed in an incompatible way. It's not that features have been removed, but simply that you have to express them differently now. This is most noticable for local bindings, but you will also find that the base library has undergone some breaking changes. This was the most legacy-breaking change I can remember, but it was necessary. We all suffered from bad decisions made in the old days. This is also likely the change that broke WASH. Other than this the Haskell ecosystem is actually comparatively stable. It is so stable that actually we run into another problem, which we refer to as the Cabal Dependency Hell. Semisolutions like cabal-dev are available, but we really need to do some work here. This is probably the weakest part of the Haskell ecosystem right now. However, it's also actually a very hard problem. Other languages have the same problem, but they fix it by ignoring it. Programmers in those languages just pretend that it's impossible to install multiple versions of the same package, but if operating systems like NixOS gain more popularity they will have to reconsider their philosophy when they face sudden segfaults. Haskell's Cabal would have warned them. They don't have such a tool. In other words, you are likely suffering from the one big breaking change made in Haskell's modern history (i.e. post 1998). Don't be discouraged by that and enjoy the improved language and base library. Enjoy an ecosystem that acknowledges the existence of problems and the tools you get to find a solution that fits you. You are going into the right direction now. =) 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.