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
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
