Agreed. UTs certainly seem to straighten out my IO grumpiness, but they aren’t a panacea. Monads are still necessary but can be restricted in their application. See here:

http://lambda-the-ultimate.org/node/1180

However, uniqueness typing really kicks the IO monad’s butt IMHO, while also being useful for destructive updates. See http://en.wikipedia.org/wiki/Uniqueness_type

I wish uniqueness typing would enter a language that feels more presently alive than Clean.

Regarding Clojure, it seems to me that it does not really matter if it handles multi-cores well if it is 10 times (often more) slower than C. Haskell is nice that way.

You mention that there are “a number of successful libraries for Haskell that are derivative of those in other languages.” Do you have some examples? Looking through them myself, the “ported libraries” that have a very similar interface to the original tend to have interfaces that are either fairly trivial (zlib) or don’t feel very Haskell-ish (various POSIX library ports). The ones that do feel Haskellish tend to have fairly major changes to the interface to make them so (eprocess, regex-base).

It doesn’t really make sense, by the way, to ask if your adaptation of Rails was or was not to my liking, since the source material is so much not to my liking. I think that Rails goes about a lot of things in a very wrong way. What little I’ve seen of Django, for example, seemed a lot nicer. I’d love to show you QWeb, but unfortunately it’s proprietary and I no longer own the product.

I think we’re in agreement about the use of IO if you no longer feel you’re always “doing something wrong” when it gets used heavily. As I mentioned, I’ve got areas of my program a thousand lines in size that are all in IO, though you’d hardly know it to look at it, and it certainly doesn’t feel like you’re working in IO.

As for feeling more productive in Ruby, as I do for certain things as well, I suspect that there are two things that bring this about. The first is that there are some areas where Haskell doesn’t yet have the comfortable syntax and libraries needed for certain types of things, mainly in string matching and manipulation and system areas (think of things like the Dir[...] construct in Ruby). Those will probably come if someone sits down to work on them seriously. The other is that, especially due to the lack of refactoring tools, Haskell isn’t well suited to certain types of prototyping (or prototyping-like programming) where so long as the program is 20% correct, you’re happy to ignore all the broken parts. Haskell really tends to push you to handle all cases rather than just the common one, and especially if you’re writing something like a one-off script this can be far more work than necessary. Still, this isn’t always the case; one example I can think of involved a filter to colour the text passing through it based on certain rules, where after a couple of hours of struggling with it in Ruby I switch to Haskell and had a much more correct version running in about 30 minutes.

For stuff that really does need to handle all possible cases correctly, though, Haskell is a godsend. I wouldn’t even want to contemplate trying to write my current trading system in a non-ML-based language.

I’m a little confused. Reading through my previous message, I don’t really see myself as saying anything you suggest I said…

I didn’t say that porting Rails is a standard exercise. I said that it’s a standard exercise to bring favored practices from other languages to new languages. There are a number of successful libraries for Haskell that are derivative of those in other languages. Naturally, the exercise includes adapting the material to the new environment and I assume what you’re saying is that my adaptation was not to your liking.

I’m not dogmatic about IO and I don’t consider IO to be offensive. In Haskell, IO is treated very specially, so I felt as though I was doing something wrong when I was special-casing all of my functions for IO. In nearly every other language, IO is not distinguished from non-IO so everyone does it blindly.

Productivity: again, I’m not sure where I said anything about the productivity of the code. I said that I was more productive in Ruby than in Haskell. It bums me to admit that, but it is what it is. I can build fairly robust systems quickly and easily in Ruby or Rails; I struggle with relatively basic stuff in Haskell (and comments here suggest that others do, too).

I also didn’t say that I’d “never been bitten by sloppy IO”; I’m sure that I have been. I said that I couldn’t remember a time when I’d been bitten. To me, that suggests that I’m working on problems which don’t have the issue that Haskell solves…

MVC: agreed. The term is used very loosely in the web world… but, just as frustratingly as Ruby, the structure seems to make me fairly productive… I’ve definitely seen Rails projects abuse it and produce an incomprehensible app.

QWeb: I’ve been thinking more about how to solve this C-V impedance match issue. Would love to see how you did it with QWeb.

That said, if you want to do it, it’s not as hard as you make it out to be. Rather than using all those separate data types in your environment, just create a big dictionary mapping String names to a type that’s an enumeration of all your different kinds of values, and your type “problems” will disappear just the way they do in Ruby. It’s even easy to do automated conversions in your accessors, e. g., given “data Value = StringValue String | IntValue Int”, the getInt function can return the Int in the IntValue case, or read the String to an Int in the Str ingValue case.

If you consider this offensive, you have to ask yourself why it’s not offensive when you do what is morally the same thing in Ruby.

With IO, it’s the same. I seem to hear you saying that “f s = putStrLn s :: IO ()” is offensive, but “def f(s); puts(s); end” is not. What about “f s = putStrLn s”, without the type signature, then? All three of those have the same type sig nature. How is the Ruby one “more productive” than either of the Haskell ones?

I think here you’ve just got the handle on the wrong end. Haskell is no more str ict about the use of IO than any other languge: it’s only more strict about dec laring the use of IO. You’re perfectly free to put every function you write int o the IO monad, if you like, just as you always do in any other language.

Further, when you say you’ve “never been bitten by sloppy IO,” you’ve missed the whole point, unless you really meant that a variable (often a global) being set to a different value than you expected was “sloppy IO”. All this monad stuff is really all about control of access to state. That’s why program designs that re ly on lots of global state being accessable everywhere (such as Rails assumes, if you really analyze it) hurt to build in Haskell.

As to your controller and view type safety issue: yes, you’re absolutely correct there. In fact, what you’ve stumbled on is an indication of the true problem, which is that the MVC design is not a good match to HTTP’s request/response design. (Consider, for example, how in Rails you’d implement a “view” without a “controller.” You can’t.) “Controllers” and “views” are actually inextricably linked in systems like Rails, and artifically separated for no good reason. (I’m reckoning that someone thought MVC sounded like a cool idea and wanted to apply it somewhere.)

Rails “solves” the problem by sweeping it under the rug. Haskell, uncomfortably enough, forces you to admit that the problem is there. The solution, of course, is to dump the MVC model, avoid the impedence mismatch, and use the command/response model that matches the way HTTP works.

I’ve in fact tested this approach in Ruby, and the QWeb framework I designed tur ned out to produce servlets rather less complex than those in Rails; a simple He llo World servlet that returns the result of a database query for example is a h alf-dozen lines of code in a single file, including all “routing” information, whereas in Rails that’s spread across three different files and possibly has thin gs encoded in the source file names and locations themselves. (Determining just what URLs a large Rails application responds to is a nightmare.)

Fantastic comment. Taking it bits at a time:

Rails: I like it; you don’t. Fair enough.

Porting Rails to Haskell: it’s a fairly standard exercise to bring favored practices from other languages/disciplines into new languages, so, while I agree with the “square peg – round hole” assessment of the project, it’s not unreasonable to undertake the project. Especially when the project looks like an opportunity to web together a number of libraries into a more useful framework… except when the project then founders because its requirements and the libraries’ construction/monads all conflict.

IO: I really like Haskell’s explicit usage of IO and I buy that not being careful with IO can get me into trouble… but I don’t think that I’m deluding myself if I choose to move to a language that is less strict about the usage of IO. In fact, I’m acting rationally: I’m more productive across a range of problems and I can’t really think of a time when I’ve been bitten by sloppy IO. (At which point someone will claim that I don’t know Haskell well enough or haven’t worked on large enough projects or something…)

Rails makes maintaining type-safety hard/impossible: amen, sister! This is more than a problem for just Rails, though. See ViewState in ASP.NET MVC. I’m really interested in this problem. The MVC-ish pattern used in Rails and in ASP.NET seems to force type-UNsafety at the transition from Controller to View. I hate it, but I’m not sure how to fix it especially given that the MVC-ish structure seems to force type-UNsafety at the Controller-View intersection. I held my nose and duplicated ASP.NET MVC’s ViewState.

Also, I’m sold on creating a number of different environment types. Multiple types would make the program more clear in return for minimally increased complexity. ServerEnvironment, WorkerEnvironment, RequestEnvironment

Monads: Agreed. If I recall correctly, the problem I got into with Monads was that various libraries had their own monads and composing them together rarely worked, so I wound up incrementally backing down to just IO and then got everything working. But I didn’t like that solution and was frustrated by having to do so.

First, trying to model your system Rails is a bad idea. Not only is Rails more complex than it needs to be, but the overall design is really unsuited for a system with any sort of type discipline. With Rails, pretty much everything is accessible and can be changed anywhere.

Second, yes, you really did want to split Environment into a few entirely separate types. Right now you’ve got a system where, for example, a function that loads static configuration information (such as your CodeStore) is typed as taking a Maybe Request, and something that operates on a Request is not only typed as taking a Mabybe Request but is also typed as being able to modify your CodeStore. Even starting with the Java Servlet API would have cleaned up a lot of this; you’ll note that Java API is fairly clear about what can and can’t be modified as a ServletRequest and ServletResponse go through the processing chain, though both those classes have parts that can be modified.

As a (stripped down) example of what you did and should have done, rather than having something like an “Environment (Maybe CodeStore) (Maybe MimeTypes) (Maybe (HTTP.Request String))” you really wanted an “Environment CodeStore MimeTypes”, “Request Environment (HTTP.Request String)”, and “typedef Servelet = Request -> Response -> Response” to indicate that a request cannot exist without a CodeStore etc., a response can be built up through stages, and neither the envirionment nor the original request can be modified by any Servlet (or whatever you care to call your service functions).

Request Environment (HTTP.Request String)”. That would show that a Request can’t be handled without a CodeStore and a MimeTypes, nor can it modify the CodeStore and MimeTypes

Third, it appears that you were designing a system, like Rails, where a a request handler (or Servlet, or whatever) can do pretty much anything on the system that any arbitrary program running as the web server user can do. If you really want to go that way, as you saw, the request handling code has to run in the IO monad. For programs of this nature you just need to accept that, rather than getting all uptight about it; even with that you can still end up with a fair amount of pure code, and have fairly good isolation of functions that do impure stuff. Looking at your list of Things You Could Do Without:

Regarding your subclassing complaint, how one fixes any particular situation is heavily dependent on the exact details of the situation itself, so I can’t provide much advice here, except to say that usually a fairly clean design can be found. Type classes and composition are your basic tools here. I gave a small example of one direction you might take things above, but no doubt it’s wrong in the details for the particular idea of how you want your web server to work.

Regarding monads, I love them myself, but you do have to find some way to really learn to understand them, both from the inside (writing your own) and the outside (good ways to use the interfaces they can present). You’re right that monad transformers can get clunky quickly, which is why I don’t use them all that much: when they do start to get clunky, I find that to be an indication that you should be writing your own custom monad rather than using a transformer stack. The key thing about monads is that they provide a powerful way of dividing up the total state of your program into discrete chunks, and knowing what functions modify what state. I think many Haskell programmers working on real-world applications concentrate too much on trying to make everything pure, and not enough on using state all over the place because it’s convenient, but typing things so that, while you’ve got lots of functions that deal with state, most of them deal with a very limited amount of state. STM is a good example of this sort of use: you know exactly what functions do and don’t touch TVars and so on, and atomically is what drags a composition of these into the world of IO.

Regarding IO, as I mentioned above, some sorts of programs just want to have a lot of functions in IO because they do a lot of “real-world” work. If you can’t figure out how to bring more stuff out of IO, don’t get too unhappy becuse you’re still ahead of the game. Remember that switching away from Haskell means putting every function into IO; if that doesn’t make you even more unhappy, you’re just deluding yourself.

I’m not clear from your example on what the issue with simpleFunction is. If you write it as “otherFunction s >>= putStrLn” it feels fairly functional to me when I remember that this is basically sugar where we’re just passing a World state between the functions in a clever way. Playing a bit with the State monad and expanding the “do” syntactic sugar and then doing some by-hand evaluation of what’s really going on may make this more clear.

Let me give you one example of something where, even though IO is involved, things end up looking pretty clean. I’ve got a custom monad within my trading system called OrderGen which handles state for one particular loop of the order (as in orders I send to the exchange) generator. It’s typed as “newtype OrderGen a = OrderGen { run :: State -> IO (a,State) }”, and so you can see that anything running in that monad can do IO. However, it’s quite clear to me when exactly I’m doing something in IO because I need to do an explicit liftIO to do that. As it turns out, in something just over a thousand lines of code in that part of the system, I call liftIO exactly nine times in only six out of well over a hundred functions. It’s quite easy for me to find and review all of these cases and convince myself that this whole subsystem is only reading from and updating a very limited set of MVars and Channels, and also in one case doing a threadDelay. Try that with a thousand lines of code in any other language!

cjs@cynic.net

I still think that Turbinado is a great bit of code (down!, ego, down!), but it is very much a port of Rails to Haskell and doesn’t really feel like functional programming. I’m not entirely happy with some of the design decisions, but I’m very happy with the simplicity of developing web apps in Turbinado.

Yeah, it could be, but, unfortunately, I never really tried it, hoping to see some more docs.

I’m also sad that nobody jumped in to help fixing design which finally brought you to the end.

The various Haskell web libraries have always struck me as a bit complicated, more like PHP web libraries than web frameworks.

I confess that I still do not understand Yesod, but, at least, it has prospects to get proper back-end, to run on non-VPS (FCGI,SCGI etc.). Happs is also too complicated and non-practical for my use-case.

It would be great to get one common & decent web-framework for Haskell. (I just posted to web-devel list about it. You’re are free to join. )

Sincerely, Gour

I’d say the problem is not that it’s difficult to do but that you wish to do it. This is just not how I believe Haskell should be used, generally. It’s much nicer to work with small, composable parts which are simply not aware of each other. A design of this kind tend to avoid monstrosities like heterogeneous collections.