[Haskell-cafe] a regressive view of support for
imperative programming in Haskell
brianh at metamilk.com
Wed Aug 8 17:56:04 EDT 2007
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
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.
More information about the Haskell-Cafe