Learning Haskell and FP

[Benjamin L. Russell]

On Fri, 5 Jan 2001 10:26:19 -0500 (EST)
 Patrick M Doane <patrick@watson.org> 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
russell@brainlink.com
benjamin.russell.es.94@aya.yale.edu
"Furuike ya!  Kawazu tobikomu mizu no oto."  --Matsuo Basho