[Haskell-cafe] Draft chapters of "Real World Haskell" now publicly
bf3 at telenet.be
Wed Jan 23 04:53:08 EST 2008
Wolfgang Jeltsch wrote:
> Covering reactive programming would indeed be interesting.
> I want to add that there is no single way for doing reactive programming in
> Haskell. There is Conal’s stuff, there is Yampa and there is “my” stuff
> (Grapefruit ) whereby the pros and cons of these approaches differ. (And
> there is plenty of other stuff which doesn’t seem to be actively developed,
> like, for example, FranTk.)
Doesn't that count for everything? I've been doing imperative & OO
programming for more than 2 decades, and every technique has its pros
and cons, it's what makes the job hard, picking the right choices, which
is (in my case) often more a matter of taste and "it worked before" than
It would be nice to just briefly introduce the reactive topic and
available solutions, and let the user know what the advantages and
disadvantages are of each approach, so he does not reinvent the wheel.
It is a very interesting domain.
Gtk2HS can hardly be called pure functional programming can it? It is IO
and monads everywhere. Not that I have something against that (it
works!), but IMHO it does not offer the same "combinatorial" (?) and
declarative advantages of the reactive approach, does it? And isn't the
fact that some of these reactive approaches "blow up" (space/time leaks)
just a general consequence of Haskell's laziness? You get it more often
with approaches like FRP, it works a bit better in AFRP (but you still
have to be careful for leaks). So in imperative languages you get buffer
overruns, null pointers, dangling pointers, overly eager evaluation,
side effects depending on evaluation order, etc... In Haskell you can
get space/time leaks caused by hard to track mutually recursive
dependencies and unevaluated thunks (I guess). I had it with the former,
so I'm happy to try the latter and see where it brings me... The more
people get introduced to this reactive proggy, the better?
> Also note that reactive programming in Haskell is not as mature as, for
> instance, GUI programming with Gtk2Hs. So it might not be wise to add a
> chapter on it now. Maybe in the second version of the book. :-)
Yes but it's not yet robust either. When I made some programs with
Gtk2HS, I encountered a couple of bugs that I reported (bugs in the GTK
code on Windows, so nothing to do with Haskell), so what is "mature"?
I haven't looked at Grapefruit yet (actually I don't like fruit, but I
like vegetables, so lucky me ;-). I will certainly do so. Any
More information about the Haskell-Cafe