On Wed, 2005-12-21 at 13:10 +0100, Udo Stenzel wrote:
. . .
> tutorial. Before that, IO should be restricted to the EVA principle
> ("Eingabe, Verarbeitung, Ausgabe" == "Input, Processing, Output"). It
> was a good principle in the 60s, and it still is. Unless you want to
> teach people to program as they would do in Basic, that is.
Don't forget that the pioneers of IPO (Input,Process,Output) quickly
went to HIPO (Hierarchical IPO). My natural design style is top-down,
functional decomposition, separation of concerns, all the good things.
Many problems involve relatively complex mixtures of IO and processing,
which I can capture fairly naturally with programs whose IO is
distributed over various nodes low in a functional decomposition tree.
It often feels like I'm turning a program inside-out to have the IO
monad at the top with pure functional snippets called at various points
in a "do" sequence. And if the only way to express my decomposition
tree is with a tree of "imperative" code inside the IO monad, then I
start to ask, "Why am I here? I can write this in Scheme or Ocaml".
Since I'm a Haskell novice, I'm well aware that I may totally
misunderstand the situation. However, I hadn't seen anything in
tutorials that would lead me to think so. That said, one of the great
effects of these recent threads is that they've alerted me to the fact
that apparently the available tutorial information has expanded and been
improved since last I looked. So I think I shall now go do some deep
browsing; thanks for the links.
-- Bill Wood
PS: While looking over my post it occurred to me that the issue is at
least as much methodological as it is linguistic. So I ask: Does
Haskell stand far enough apart from other programming languages to
warrant adapting standard methodological principles to it? Is there an
identifiable "Haskell Way"?
-- bw