Paul Hudak wrote:
All of the recent talk of support for imperative programming in Haskell makes me really nervous....
... if we give imperative programmers the tools to do all the things they are used to doing in C++, then we will be depriving them of the joys of programming in the Functional Way. How many times have we seen responses to newbie posts along the lines of, "That's how you'd do it in C++, but in Haskell here's a better way...". Perhaps I may have sounded unappreciative of all the hard work that's been done trying to find solutions to the problem of GUI programming in a pure functional style. I think the problem is that for the purposes of research, it is sufficient to show that a concept can be implemented but the speed of the resulting program is not that important compared to the essential ideas.
Thus the concept of a GUI as a time varying continuous function of events and response pictures (represented as functions:: Vector3 Float -> RGB) is tremendously appealing, and will surely become the standard way when machines get fast enough, but for the moment this nice pure functional way just doesn't seem directly applicable (;-)). I see the problem you're pointing to though - that the language could become caught in the middle trying to serve two rather different purposes namely a pure ground for research and a fast general purpose platform for creating programs now. As for me, the issue is just that after spending almost 2 years with Haskell trying to find/discover a purely functional solution to this problem that will be suitable for a practical high speed graphics application on standard hardware, being unsuccessful, and not having any funding to pursue this research further, my only option is to either use the imperative monadic style of Haskell programming or to use OCaml or C++, because I need to get something written right now that I can put on my website to sell... Personally I don't find the existing do notation all that burdensome - I've got used to it, and even though each action must be explicitly written, the ease with which higher order functions can be introduced to factor out commonality means that the do blocks are often shorter than the corresponding C++ code from my previous GUI. Furthermore, even though I'm using the imperative style, the use of Haskell has led me to surprisingly neat solutions to several problems that I didn't discover when I implemented the previous versions in C++ and C#, so I think there are still great benefits to be had from using Haskell or languages inspired by it. Best regards, Brian.