[Haskell-cafe] On the verge of ... giving up!

[David Stigant]

I just started working in Haskell about 2-3 months ago, and I'm loving it. 
I've programmed a lot in Scheme which I learned my freshman year in college, 
so that helped a lot with the difference between functional and oop 
languages, but as Andrew Coppin mentioned, Haskell is quite different even 
from Lisp/Scheme etc.  By way of an annecdote, the other day, I was working 
on a problem in Haskell and having some problems getting types (I believe it 
was a problem of converting between different types of numbers) to match up 
correctly.  Darnit, if I was doing this in Scheme, I thought, the types 
would just work themselves out, so I booted up DrScheme and started 
translating the code.  It took me three times as long because of all the 
list comprehensions and laziness that I had started to use so automatically 
in Haskell.  Anyway... let me get to some of your questions.


> So, I requested my institute to buy Dr. Graham Hutton's book. I would
> be getting hold of that quite soon, and am willing to start from the
> beginning.

So when I first started with Haskell, I started with the online tutorials, 
but got stuck with the Monad stuff.  So I actually ordered this same book 
and read it cover to cover, and it helped a quite a bit, but I still needed 
some practical experience.  I think the examples which compare parsing 
strings to doing IO are especially instructive with respect to understanding 
Monads.  However, what I'm really missing at this point is how to write my 
own monads.  (As a side note, I'm not entirely convinced that you need to 
write a lot of your own monads, but I'd still like to understand that)

 > The next step I usually take in learning a language is, not to go by
> the topics found in textbooks, but by taking real world examples and
> then blindly try to solve it using that language as a tool. For e.g,
> I tried writing a terminal GTalk client for Python when I was learning
> it, and learnt so many features that way. I used to call this
> 'learning by need', and it worked, to the extent that I never knew how
> to take 'input' from the user, but knew how to write Objects in
> Python! (Since I never used input in that example :)

I also agree about this, so I started looking for small projects on which to 
cut my teeth and really learn the basic concepts in Haskell well.  Then I 
stumbled onto Project Euler (projecteuler.net).  Its a whole bunch of 
math-related problems where you usually need to write a program to do some 
sort of search for numbers with specific properties or to find the number of 
combinations for some bizarre situation etc.  It may or may not be your cup 
of tea in the sense that the problems themselves are a bit esoteric and 
you'll never use these programs again.  However, I (have) found that:
1.  These smaller exercises have really helped me learn some of the weirder 
syntax better (ex: list comprehensions are now a piece of cake)
2.  A number of the exercises require you to come up with more than just a 
brute force search (or your program will take too long to produce an 
answer), so I've had to learn about various topics (ex: how to use arrays in 
a functional (non-imperitive) way to accomplish dynamic programming type 
tasks)
3.  Haskell is ideally suited to doing mathy type problems.  For example, 
the laziness feature of the language (something else that is entirely 
different from most main stream languages, and which I needed more practice 
with) allows me to implement (potentially) infinite searches in the same way 
as I implement finite searches.

>
> I didnt want to repeat that mistake, so I made sure I would learn IO
> in Haskell, which initially turned out to be a disaster, due to the
> 'Moands' which sounded like 'Go Mads' to me.

A couple of my solutions to project euler required me to use hashtables 
(before I figured out how to use arrays functionally) so I've picked up a 
little of the IO stuff.  Its... less than intuitive, and I avoid it at all 
costs... some of the problems have large input files.  I parse them by hand 
into Haskell syntax to avoid making my program have to do IO.  But you can 
definitly learn more about IO by doing it the "sane/intended" way.  Haskell 
programs tend to be structured to restrict IO to the surface level of the 
program, and use purely functional ideas to solve the meat of the problem. 
This seems to be one of the major design features of the language.  However, 
most widely-used programs (ex: web browsers, word processors, email 
programs, data bases, IDEs) tend to be 90% IO and 10% (or less) computation. 
This can make Haskell quite unweildy for solving these types of problems. 
On the otherhand, writing something like a compiler (which requires a small 
amount of IO - read a file(s), write results to a file - and a large amount 
of "unseen" computation - generating and optimizing code) is right up 
Haskell's alley.

>
> Then, I set out to learn Monads + Category Theory from a Math
> perspective. And since I haven't been introduced to abstract math
> (like Groups, etc.), I found this a little difficult. However I tried
> my best to understand the tiniest bit and waited for the tiniest spark
> that would enlighten me. It didn't work out.

Yeah, I have a math background as well, and I'd even heard of Monads and 
Category Theory back when I was taking algebraic topology, so I thought I'd 
dive into that... didn't work for me either.

-Dave Stigant