On Fri, 5 Jan 2001 10:26:19 -0500 (EST)
Patrick M Doane <[EMAIL PROTECTED]> wrote:
>
> [snip]
>
> I think a really good beginner's tutorial on I/O could be
> started from this
> paper:
>
> - Start immediately with using the 'do expression' and
> don't
> worry about the history that led to its development.
Actually, the history, especially from a comparative programming languages standpoint,
can sometimes be useful for motivation.
For example, many Java textbooks motivated study of the language by explaining the
need for a C-style language without explicit memory allocation or explicit pointer
casting. Similarly, an on-line document for C# motivated it by explaining the history
of how it grew out of a need for a language similar to C and C++ (the document somehow
left out the Java comparison :-( ), but that allowed programmers to develop more
efficiently in it.
Even for a "Haskell in a Nutshell"-style textbook, a couple of paragraphs comparing
Haskell to other languages from a historical viewpoint and describing the advantages
and disadvantages of Haskell in particular could prove quite useful.
> [snip]
>
> Many people are also annoyed by an author using new
> vocabulary even
> if it is well defined. It's better to get them
> comfortable with the
> system first.
That depends on which new vocabulary is being mentioned, though. That may true for
unnecessary new vocabulary, such as "monads" for the first chapter. However, e.g. in
the following example (borrowed from Chapter 3 of _A Gentle Introduction to Haskell,
Version 98,_ by Paul Hudak):
add :: Integer -> Integer -> Integer
add x y = x + y
it is hard not to introduce such vocabulary as "has type," "arrow" (or "mapping"), and
maybe even "currying."
> [snip]
>
> - Conclude with explaining the difference between
> executing an action
> and building a value to execute the action. There is
> no need to
> point out that this is a requirement of being a lazy
> language.
> Instead point out the benefits such a system
> provides to back up
> the claim that Haskell truly is "the world's finest
> imperative programming language."
Forgive me if I am ignorant, but who claimed that Haskell was an "imperative" language?
Also, in order to take full advantage of Haskell, it would seem necessary to get used
to functional programming style (the Haskell school of expression, in particular). It
seems that using Haskell as an "imperative" language is a bit like thinking in C when
programming in C++; only worse, since the imperative habits are being brought into the
functional, rather than the OO, realm.
--Ben
--
Benjamin L. Russell
[EMAIL PROTECTED]
[EMAIL PROTECTED]
"Furuike ya! Kawazu tobikomu mizu no oto." --Matsuo Basho
_______________________________________________
Haskell-Cafe mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell-cafe
