[Haskell-cafe] a regressive view of support for imperative programming in Haskell

[Brian Hulley]

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.