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

[Vimal]

Dear Haskellers,
I have been trying my best to read about Haskell from the various
tutorials available on the internet and blogs. I havent been following
YAHT properly, so its always been learning from 'bits and pieces'
scattered around.

For most languages (like C/C++/Ruby/Python), the above approach has
helped me. But for Haskell, it is failing. I like learning by
comparison with other similar languages. This approach worked for me
when I tried learning Python+Perl together. The nicer syntax and
easier object-orientedness made me leave Perl behind and pursue
Python.
I also tried it for Haskell (Lisp+OCaml+Haskell together).

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 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.

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.

--snip--

Okay, so you might be wondering as to whats the whole point of this
mail? Well, I am almost on the verge of giving up on something I
really like to learn, just because I didn't go in the right order!

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.

Meanwhile, could anyone suggest if there was anything wrong in my
approach to learning Haskell/the other languages? I agree that the
learning methodology is something personal and I have to find out what
best suits me, but I would like to hear something from you,
Haskellers, too.

I have no need to hurry anything at this point of time. But after
being introduced to the tiniest bit of Haskell, and after seeing such
a large and active community here, and #haskell, I had the plan of
conducting a Haskell Workshop, in our department (sometime in Feb next
year, the dates have not been finalized). I just hope that I should be
able to reach a substantial amount of familiarity with Haskell by that
time!

Sorry for the long mail, and pardon me if it was too boring. I just
put my thoughts on <strike>paper</strike> a mail :)

I did have a couple of ambitious projects in my mind when to help me
learn Haskell. They were:

1. An online judge system
(Like http://spoj.pl).
I had already done one for contests that were held during our
Technical festival here, using php. The ideas are laid out. All I had
to focus on was learning Haskell.

2. A solver for the Peg-Solitaire.
This was more of an academic interest. I have seen Richard Bird's
presentation on 'How to write a functional pearl, with an example' and
was quite impressed by it. But the actual modelling might be slightly
tricky here, and I am yet to start off with it.

Many thanks for your patience,
Cheers,

[Neil Mitchell]

Hi

Post by Vimal
Then, I set out to learn Monads + Category Theory from a Math
perspective.

This is where you went wrong. I know none of this stuff and am
perfectly happy with IO in Haskell. Read
http://www.haskell.org/haskellwiki/Monads_as_Containers and then read
lots of other Monad tutorials for Haskell.

Post by Vimal
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.

I'm not sure this covers IO in any great detail - it will be useful
for general Haskell though.

Post by Vimal
1. An online judge system
(Like http://spoj.pl).
I had already done one for contests that were held during our
Technical festival here, using php. The ideas are laid out. All I had
to focus on was learning Haskell.
2. A solver for the Peg-Solitaire.
This was more of an academic interest. I have seen Richard Bird's
presentation on 'How to write a functional pearl, with an example' and
was quite impressed by it. But the actual modelling might be slightly
tricky here, and I am yet to start off with it.

I would try number 2 first. IO in Haskell can be tricky, especially
while you are learning all the other bits of the language at the same
time. Network stuff is also not as well developed in terms of
libraries as something like Python - but something like HappS should
be able to do a spoj clone easily enough. A better choice for an
initial IO application might be something like "du", then moving to an
online judge system later on.

Thanks

Neil

[Vimal]

Cool! Lots of opinion. Let me consider them one by one:

========================================================================

Post by Neil Mitchell
This is where you went wrong. I know none of this stuff and am
perfectly happy with IO in Haskell. Read
http://www.haskell.org/haskellwiki/Monads_as_Containers and then read
lots of other Monad tutorials for Haskell.

I tried this too, and this made some sense to me in the beginning. But,
not enough to satisfy my curiosity! So, I tried to dig in ...

Post by Neil Mitchell

Post by Vimal
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.

I'm not sure this covers IO in any great detail - it will be useful
for general Haskell though.

IO isnt the only problem. Monads + how to define your own Monads etc.
Since Monad's arent just for IO, where else could it be used? (e.g.
Stateful functions), but is that it? Is it possible for me to come
up with an instance of a Monad to solve _my_ problem? Thats the kind
of question I would like to answer :)

Post by Neil Mitchell
I would try number 2 first. IO in Haskell can be tricky, especially
while you are learning all the other bits of the language at the same
time. Network stuff is also not as well developed in terms of
libraries as something like Python - but something like HappS should
be able to do a spoj clone easily enough. A better choice for an
initial IO application might be something like "du", then moving to an
online judge system later on.

You are probably right. Mimicking *nix tools might be great fun to start
off with :)

Post by Neil Mitchell
Thanks

Thanks :)

========================================================================

[Andrew Coppin]

Post by Vimal
IO isnt the only problem. Monads + how to define your own Monads etc.
Since Monad's arent just for IO, where else could it be used? (e.g.
Stateful functions), but is that it? Is it possible for me to come
up with an instance of a Monad to solve _my_ problem? Thats the kind
of question I would like to answer :)

I/O is a monad. Actually, there's another one called STM (for doing
"transactional" modifications). And there are various ones for doing
"stateful" stuff (e.g., incrimentally building a solution or something).

Then there's the Maybe monad (for operations which sometimes fail).
Lists are a monad (for operations that yield multiple results).

Parsers are a celebrated example of monads - although the most efficient
ones use something called "arrows". (These are like monads, but even
more abstract. If you enjoy making your head hurt...)

There is also an entire zoo of other monads out there. There's a CPS
monad (for writing unmaintainable code), many graphics libraries have a
"drawing monad"... the list goes on.

Is there any merit in you writing your own monad? Well, if it's doing
something similar to existing monads, then maybe. (Note that there are
such things as "monad transformers", which allow you to merge multiple
monads together into a giant, all-powerful monad. So, if you wanted a
stateful parser that does I/O, you could use transformers to mix those
exact features together - no coding required.)

Post by Vimal

Post by Neil Mitchell
I would try number 2 first. IO in Haskell can be tricky, especially
while you are learning all the other bits of the language at the same
time. Network stuff is also not as well developed in terms of
libraries as something like Python - but something like HappS should
be able to do a spoj clone easily enough. A better choice for an
initial IO application might be something like "du", then moving to an
online judge system later on.

You are probably right. Mimicking *nix tools might be great fun to start
off with :)

Uh... think it's been done already. ;-)

Still, you could try it yourself and see what you get - and then marvel
at how others have done it in half the code. :-}

[Felipe Lessa]

Post by Vimal
IO isnt the only problem. Monads + how to define your own Monads etc.
Since Monad's arent just for IO, where else could it be used? (e.g.
Stateful functions), but is that it? Is it possible for me to come
up with an instance of a Monad to solve _my_ problem? Thats the kind
of question I would like to answer :)

The approach I used to fully understand monads was the same as I used
to fully understand Python's metaclasses: don't try to get into its
inner until you need. I mean, don't try to find a problem to come up
with a monad. Instead, someday you will going to solving a problem and
you'll have the idea of making "instance Monad" of it. Meanwhile
you'll get used to the language and see lots of other already-built
monads. Well, worked for me.

The beautiful thing about monads and metaclasses is that they are
extremely simple after you understand them. That's also why monads are
called Warm, fuzzy things, AFAICT =). But both don't fit everywhere,
and it requires some experience to see that.

[Andrew Coppin]

Post by Vimal
I like learning by
comparison with other similar languages. This approach worked for me
when I tried learning Python+Perl together. The nicer syntax and
easier object-orientedness made me leave Perl behind and pursue
Python.
I also tried it for Haskell (Lisp+OCaml+Haskell together).

This probably works quite well for mainstream programming languages
(since they're all so similar), but is unlikely to work at all for
Haskell (since, as far as I know, no other programming language on Earth
is remotely like it - Miranda excluded). Even Lisp and Erland are
nothing like Haskell, and they're supposedly based on the same ideas.

Post by Vimal
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.

Not a bad way to learn to use a tool. You might want to stick to things
that involve simple I/O and complex processing rather than the other way
round though. ;-) (For example, I wrote a program that renders an
animation of the solutions of a simple differential equation by
numerical integration. The math is complex; the I/O just involves
dumping millions of numbers into a big text file.)

Post by Vimal
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.

For the longest time I couldn't remember whether it's "monad" or
"monand"... but anyway, yeah, it's a common problem. It's not actually
complicated ones you understand it; it's just that it's so abstract that
it's hard to explain. It's a bit like trying to explain to somebody what
a "magnet" is... it's not a complex concept, just hard to describe.

Post by Vimal
Then, I set out to learn Monads + Category Theory from a Math
perspective.

Um... yeah, that probably won't work.

As far as I know, Haskell's idea of "monad" has little to do with the
theoretical concept.

Post by Vimal
Meanwhile, could anyone suggest if there was anything wrong in my
approach to learning Haskell/the other languages? I agree that the
learning methodology is something personal and I have to find out what
best suits me, but I would like to hear something from you,
Haskellers, too.

I'm a maths nerd. To me, Haskell looks like an advanced term-rewrite
system similar to Mathematica. It was quite easy to learn the basics.
What took longer was learning to approach problems in the right way. The
way you'd do things in an object oriented language is usually NOT the
way you'd do it in Haskell. (Unless you enjoy making your life hard...)
Unfortunately, that's all practice.

[Vimal]

Post by Andrew Coppin
This probably works quite well for mainstream programming languages
(since they're all so similar), but is unlikely to work at all for
Haskell (since, as far as I know, no other programming language on Earth
is remotely like it - Miranda excluded). Even Lisp and Erland are
nothing like Haskell, and they're supposedly based on the same ideas.

I didnt know this when I _started_ :) So, thats why I am learning Haskell
in exclusion.

Post by Andrew Coppin
Not a bad way to learn to use a tool. You might want to stick to things
that involve simple I/O and complex processing rather than the other way
round though. ;-) (For example, I wrote a program that renders an
animation of the solutions of a simple differential equation by
numerical integration. The math is complex; the I/O just involves
dumping millions of numbers into a big text file.)

Yes, as someone pointed out, Haskell was meant for a lot of computation,
and IO is just a part of the story!

Post by Andrew Coppin
For the longest time I couldn't remember whether it's "monad" or
"monand"... but anyway, yeah, it's a common problem. It's not actually
complicated ones you understand it; it's just that it's so abstract that
it's hard to explain. It's a bit like trying to explain to somebody what
a "magnet" is... it's not a complex concept, just hard to describe.

But, being a computer science student, I think I need to look into it too!
I like the quote found on this site: http://patryshev.com/monad/m-intro.html
<quote>
Monads in programming seem to be the most mysterious notion of the century.
I find two reasons for this:

* lack of familiarity with category theory;
* many authors carefully bypass any mention of categories.

It's like talking about electricity without using calculus.
Good enough to replace a fuse, not good enough to design an amplifier.
</quote>

Post by Andrew Coppin
I'm a maths nerd. To me, Haskell looks like an advanced term-rewrite
system similar to Mathematica. It was quite easy to learn the basics.
What took longer was learning to approach problems in the right way. The
way you'd do things in an object oriented language is usually NOT the
way you'd do it in Haskell. (Unless you enjoy making your life hard...)
Unfortunately, that's all practice.

Ah, I am not familiar with the "term-rewrite" you are talking about.
I will Google it up then.
Thanks :)
========================================================================

[Andrew Coppin]

Post by Vimal
But, being a computer science student, I think I need to look into it too!
I like the quote found on this site: http://patryshev.com/monad/m-intro.html
<quote>
Monads in programming seem to be the most mysterious notion of the century.
* lack of familiarity with category theory;
* many authors carefully bypass any mention of categories.
It's like talking about electricity without using calculus.
Good enough to replace a fuse, not good enough to design an amplifier.
</quote>

Maybe *this* is why I get nowhere with designing electronic things? I
know very little about calculus. (And I can't begin to imagine what it
has to do with electricity...)

For what it's worth, a "category" is a "class" bearing some additional
structure. A "class" is exactly like a "set", except that all sets are
classes, but only some classes are also sets. There *is* a reason for
this, but nobody knows what it is. (They say it's because some classes
are "bigger" than sets - which is absurd since a set can be of any size...)

Post by Vimal
Ah, I am not familiar with the "term-rewrite" you are talking about.
I will Google it up then.
Thanks :)

A term-rewrite system is just a system that replaces ("rewrites")
certain terms with other terms. For example, a package like Mathematica
would have a term rewrite rule that says that all occurrances of "x - x"
should be rewritten as "0". Haskell can't do anything quite *that*
sophisticated, but what it *can* do is things like

linear a b x = a*x + b

which causes all terms involving "linear" to be rewritten into the thing
on the RHS. You can actually draw the "reduction" sequence as an
expression is transformed step by step into the final result:

sum [1,2,3]
foldr1 (+) [1,2,3]
foldr (+) 1 [2,3]
foldr (+) (1+2) [3]
foldr (+) (1+2+3) []
1+2+3
3+3
6

Each line is derrived from the previous one by some program rule. (The
last three being hard-coded into the language itself.)

If you're pathologically curiose, look up "lambda calculus" for a
programming language like Haskell where the last few steps above are
*definable* from first principles. >:-D

[j***@info.unicaen.fr]

I will be impolite.

Post by Andrew Coppin
For what it's worth, a "category" is a "class" bearing some additional
structure. A "class" is exactly like a "set", except that all sets are
classes, but only some classes are also sets. There *is* a reason for
this, but nobody knows what it is. (They say it's because some classes are
"bigger" than sets - which is absurd since a set can be of any size...)

If this were the first posting of A.C., I would suspect that he is pulling
my leg, that his brilliant sense of humour surpasses my comprehension, so
I should be filled-up with deep respect for such a wonderful mind. But
enough is enough. Now, would it be really too much asking that - at least
from time to time - Andrew Coppin think twice before saying things he -
apparently - knows NOTHING about?

Haskell café, is, well, café... even no tobacco restrictions. But, since
we
have here people who want to learn something structured and based on some
real competence, saying e.g. that "CPS monad is for making unmaintainable
code", or "I know very little about calculus. (And I can't begin to imagine
what it has to do with electricity...)", is becoming a nuisance.

I skipped the postings of A.C., as most of people on this forum I happen to
know, and there was no personal reason to react. But A.C. engages
in a dialogue with newbies, and this is, from the pedagogical point of view,

Post by Andrew Coppin
foldr (+) 1 [2,3]
foldr (+) (1+2) [3]
foldr (+) (1+2+3) []
1+2+3
3+3
6

This "derivation" is pure rubbish. Read the definition of foldr, please,
would it be the first time in your life??? The functional foldr is NOT
tail recursive! And, actually, as EVERYBODY knows, Haskell is not a
rewriting system.

So, a good advice for J. Vimal: do whatever you wish, but avoid this fellow
A. Coppin, since he leads you nowhere.

Jerzy Karczmarczuk

[Andrew Coppin]

Post by j***@info.unicaen.fr
I will be impolite.
If this were the first posting of A.C., I would suspect that he is pulling
my leg, that his brilliant sense of humour surpasses my comprehension, so
I should be filled-up with deep respect for such a wonderful mind. But
enough is enough. Now, would it be really too much asking that - at least
from time to time - Andrew Coppin think twice before saying things he -
apparently - knows NOTHING about?

OK. I get the message. I'm unsubscribing now...

[How ironic the subject line suddenly seems.]

[Roberto Zunino]

Post by j***@info.unicaen.fr
I will be impolite.

There was no need to.

Post by j***@info.unicaen.fr
OK. I get the message. I'm unsubscribing now...

There was no need to.

Please, let's keep haskell-cafe a friendly place, as it's always been.

When someone posts inaccurate (or even wrong) facts:
"Attack ideas. Do not attack people."

(Please!)

Regards,
Zun.

[j***@info.unicaen.fr]

..

Post by Roberto Zunino

Post by Andrew Coppin
OK. I get the message. I'm unsubscribing now...

There was no need to.
Please, let's keep haskell-cafe a friendly place, as it's always been.

Yes.
I would add, friendly and USEFUL, as it's always been. It was not my
intention of "throwing away", anybody, and I didn't. I had no right to do
such thing either. I just asked A. Coppin to think twice before submitting
dubious statements, didn't I? I believe that it would be useful for the
list if he stayed, and *asked questions*. My impoliteness was quite
restrained...

But, when J. Vimal "threateneds us" to throw away Haskell, complained about
monads, and most people confirmed that the underlying theory is difficult,
ugly, and useless, I began to read those postings with attention, since
I disagree with spreading such atmosphere. And A.C. additionally wrote that
all this theory has nothing to do with Haskell, and submitted three more
postings, one more dubious than the other, I found that a warning seems
suitable, not for him, but for his readers!

Mathematics is beautiful and useful. The commutativity of some categorical
diagrams can be translated into the optimization of Haskell constructs,
say, showing that there is a canonical isomorphism between

(map f) . (map g) and: map (f . g)

etc. So, why dump the theory away, which suggests additionally that the
conceptors of Haskell are irresponsible dreamers, living on some crystal
mountain?... The language is not trivial to learn, that's it. If somebody
feels discouraged, my own students often are, then the recipe is simple:
ask CONCRETE questions, get CONCRETE answer. THEN generalize.

But if some people offer general answers, they must be based on a real
competence and experience, otherwise they easily become harmful.

==============

"David48" points out that if a list returns the reader to the docs which
he has already seen, and which is poor, then it doesn't work at all. OK,
then, once more, don't say "I cannot understand monads", or rewriting, or
whatever, but say plainly: "I read XYZ in the ABC tutorial, and the example
PQR remains too difficult." And say WHAT doesn't work.

Go ahead, criticize *concrete* documentation, don't say that docs are lousy!
Almost all Haskell documentation has been written by people who *beg*
constantly for comments, for criticism; let's help them instead of
shouting at them.

Of course, the repeated, ever and ever again questions mean that one day
it will be absolutely necessary to make a true FABQ, proposed a few times,
and still in statu nascendi...



Jerzy Karczmarczuk

[Emre Sahin]

[...]

jerzy> But, when J. Vimal "threateneds us" to throw away Haskell,
jerzy> complained about monads, and most people confirmed that the
jerzy> underlying theory is difficult, ugly, and useless, I began
jerzy> to read those postings with attention, since I disagree
jerzy> with spreading such atmosphere. And A.C. additionally wrote
jerzy> that all this theory has nothing to do with Haskell, and
jerzy> submitted three more postings, one more dubious than the
jerzy> other, I found that a warning seems suitable, not for him,
jerzy> but for his readers!


I'm an (almost) complete newbie to FP and for a beginner I don't see some
"right" in myself to criticize "theory" being hard. I'm a CS guy
without any background in Category Theory and related ideas, but when
I see something elegant, I think I recognize it, and monads seem to be
much elegant way of doing things than "usual" I/O. (And because of
this elegance I couldn't persuade myself to learn OCam'l etc. first)

Currently I can't say I understand monads, but as Von Neumann put it,
"Young man, in mathematics you don't understand things. You just get
used to them." ;)


jerzy> Mathematics is beautiful and useful. The commutativity of
jerzy> some categorical diagrams can be translated into the
jerzy> optimization of Haskell constructs, say, showing that there
jerzy> is a canonical isomorphism between

jerzy> (map f) . (map g) and: map (f . g)

jerzy> etc. So, why dump the theory away, which suggests
jerzy> additionally that the conceptors of Haskell are
jerzy> irresponsible dreamers, living on some crystal
jerzy> mountain?... The language is not trivial to learn, that's
jerzy> it. If somebody feels discouraged, my own students often
jerzy> are, then the recipe is simple: ask CONCRETE questions, get
jerzy> CONCRETE answer. THEN generalize.

I asked Paul Hudak a few days ago about an exercise in his Haskell SOE
book and I got more than I expected. (Prior to that, I asked in
#haskell and also got more than I expected, though not understood all
of them ;))


jerzy> But if some people offer general answers, they must be
jerzy> based on a real competence and experience, otherwise they
jerzy> easily become harmful.

Being friendly is one thing, but being sensitive about the information
is much more valuable IMO. I thank you for deciding to post this "disclaimer"
instead of overlooking, which is perhaps the easier way.

jerzy> ==============

jerzy> "David48" points out that if a list returns the reader to
jerzy> the docs which he has already seen, and which is poor, then
jerzy> it doesn't work at all. OK, then, once more, don't say "I
jerzy> cannot understand monads", or rewriting, or whatever, but
jerzy> say plainly: "I read XYZ in the ABC tutorial, and the
jerzy> example PQR remains too difficult." And say WHAT doesn't
jerzy> work.

jerzy> Go ahead, criticize *concrete* documentation, don't say
jerzy> that docs are lousy! Almost all Haskell documentation has
jerzy> been written by people who *beg* constantly for comments,
jerzy> for criticism; let's help them instead of shouting at them.

jerzy> Of course, the repeated, ever and ever again questions mean
jerzy> that one day it will be absolutely necessary to make a true
jerzy> FABQ, proposed a few times, and still in statu nascendi...


I'm 27 years old and somehow programming for ~12 years in almost all
major imperative languages. (I have some Scheme & Lisp experience
also.) As another poster mentioned, this language gave me long
forgotten excitement of programming again. Though I feel myself too
lazy to cope with problems (and obstacles in learning and changing
mindset) sometimes, and I usually don't understand topics in this
mailing list most of the time, I don't attribute these to difficulty
of the language. This is my laziness, not Haskell's.

If I would like to program in "more understandable" ways, I know there
are lots and lots of other languages that I can use, but trying to
come up with a solution and seeing how succint it can be amazes me in
this language and I don't know if I can be a successful Haskell
programmer (and write those haikus you write here and there), but at
least I'll try to be and if I can't, this will be my laziness, not
Haskell's.

Thanks and best regards,

E.

[Richard A. O'Keefe]

Post by j***@info.unicaen.fr
But, when J. Vimal "threateneds us" to throw away Haskell,
complained about
monads, and most people confirmed that the underlying theory is difficult,
ugly, and useless, I began to read those postings with attention, since
I disagree with spreading such atmosphere. And A.C. additionally wrote that
all this theory has nothing to do with Haskell, and submitted three more
postings, one more dubious than the other, I found that a warning seems
suitable, not for him, but for his readers!

I hope we can agree on several things here:

(1) The mathematical background of Haskell is one of the things that
makes Haskell a beautiful and useful programming language. It
may even be one of the most important factors.

(2) The mathematical background of Haskell is extremely important
for implementations. Some important data structures and
techniques are practical in large part because of the kinds of
optimisations that are only straightforward in a language that
has such foundations.

(3) Beginners do not need to understand all the mathematics behind
Haskell to use it.

I really really hope we can agree on the next two points:

(4) It is not unfair to describe "Category Theory" as "The mathematical
study of sound analogies between mathematical structures"; it leads
to concepts of great generality and power, and encourages a
consistent
use of terminology which makes it easier to transfer ideas and
techniques from one area of mathematics to another. It's about
*consistently* pushing generality rather hard.

(5) Precisely because it seeks generality, category theory seems
difficult to "concrete thinkers". And books on category theory
tend to be extremely fast-paced, so ideas which are not in
themselves
particularly esoteric (which may in fact be eminently practical)
tend to be presented in a way which people trying to study by
themselves have trouble with. So people can be scared off by
what _ought_ to be a big help to them.

[Brandon S. Allbery KF8NH]

Post by Richard A. O'Keefe
(5) Precisely because it seeks generality, category theory seems
difficult to "concrete thinkers". And books on category theory
tend to be extremely fast-paced, so ideas which are not in
themselves
particularly esoteric (which may in fact be eminently practical)
tend to be presented in a way which people trying to study by
themselves have trouble with. So people can be scared off by
what _ought_ to be a big help to them.

I would really like to see "category theory for the working
*non*mathematician". I have essentially zero formal programming/CS-
theory or mathematical training, and while sucking knowledge up like
a sponge is often a good thing (especially for me as a practicing
sysadmin), it does leave me at a bit of a disadvantage when you start
maximally generalizing everything in sight at me, especially when you
do so in esoteric mathematical language that leaves me going "buh?"

[a***@spamcop.net]

G'day all.

Post by Brandon S. Allbery KF8NH
I would really like to see "category theory for the working
*non*mathematician".

It's pricey, but your local university library probably has it:

http://www.cambridge.org/catalogue/catalogue.asp?isbn=9780521478175

Cheers,
Andrew Bromage

[a***@spamcop.net]

G'day all.

Post by Richard A. O'Keefe
(5) Precisely because it seeks generality, category theory seems
difficult to "concrete thinkers". And books on category theory
tend to be extremely fast-paced, so ideas which are not in themselves
particularly esoteric (which may in fact be eminently practical)
tend to be presented in a way which people trying to study by
themselves have trouble with. So people can be scared off by
what _ought_ to be a big help to them.

I agree, but I don't think it needs to be this way.

Books on category theory tend to be written for mathematicians or
computer scientists who already grok the things that need generalising,
even understand in a general sense how they're similar, and really just
need to learn the language to express what they already know.

In one respect, this makes sense (you learn the concrete, then you learn
how to abstract away the details), but it also raises the barrier to the
point where in learning mathematics, you're really learning history.

Mathematics isn't immune from this, of course. Many scientists in
disparate fields have complained that textbooks for their fields are
really history books in disguise, and the material is more confused and
tedious than it needs to be as a result.

Example complaints:

http://insti.physics.sunysb.edu/~siegel/history.html
http://jchemed.chem.wisc.edu/journal/issues/1998/jul/abs817.html

Cheers,
Andrew Bromage

[Brandon S. Allbery KF8NH]

But I think we are still at the stage where a programmer
who wants practical results is better off starting out
by learning how to use monads in practice, not by
delving into category theory.

No argument from a Haskell standpoint. Still, when people here or on
#haskell start tossing CT around, it'd be nice to have more than a
very vague and probably incorrect notion of what they're saying. :)

[j***@info.unicaen.fr]

Post by Richard A. O'Keefe
(2) The mathematical background of Haskell is extremely important
for implementations. Some important data structures and
techniques are practical in large part because of the kinds of
optimisations that are only straightforward in a language that
has such foundations.
(3) Beginners do not need to understand all the mathematics behind
Haskell to use it.
(5) Precisely because it seeks generality, category theory seems
difficult to "concrete thinkers". And books on category theory
tend to be extremely fast-paced, so ideas which are not in themselves
particularly esoteric (which may in fact be eminently practical)
tend to be presented in a way which people trying to study by
themselves have trouble with. So people can be scared off by
what _ought_ to be a big help to them.

Yes.
Yes.
And when *additionally* people whose experience/competence is rather weak,
spread the fear, hatred and carelessness, I have the impression that this
is something similar to a guy in primary school (and this list *is* a kind
of school) who bothers the pupils with such discoveries as "the differential
calculus is a swearword, just to annoy you, you will =never= need that, I
live happily without".

There IS a problem. The fast pace of Category theory is a bit incomplete
diagnosis. For me, what was most annoying was an awful trap. Everything
began slowly, and nicely. And authors are kind, helpful, and understanding.
And they promise that it is *for me*. Or for Brandon S. Allbery KF8NH...

(BTW, Why Andrew Bromage says that the book of Lawvere is pricey? Cambridge
Univ. Press sells the "Conceptual Mathematics" for 33 pounds. This is not
so much...)

Check some other titles, *free*, please:

*Categories for =working comp. sci'ists=, Asperti&Lungo.
*Categorical Primer by Chris Hillman (he - apparently - still revises the
next version...)
*Gentle introduction to Cat. Th., a calculational approach by Fokkinga.
*Basic Cat., by Jaap Van Osten, a course for undergraduates, which begins
by saying that for the Author the basic experience counts more than
theory.

(And, of course, Barr and Wells...)

Now, you start reading, it goes smoothly, you understand functors, natural
transformations, retracts, initial objects, etc. And then the slope
begins to increase exponentially, you hit a wall...
It seems that people who finally decided to write books, tutorials, etc.
are so conditioned, that they cannot put themselves into a skin of a true
profan, even people so perfect, so didactically skilled as Barr and Wells.

But as says the quotation from a science-fiction story /Born among the
dead/: "you must elevate yourself to their level, since you cannot force
them to descend to yours..."

Still, monads, Kleisli triples, etc. belong to the *EASY* part!!
===
So, if some people really *want* to learn something, some time devote they
shall. But, there are some shortcuts as well, although nothing complete.

http://en.wikibooks.org/wiki/Haskell/Category_theory
is a nice introduction!

The paper on "Bananas, lenses and barbed wire" (Meijer, Fokkinga, Paterson)
is almost a compulsory reference.

The craziness of generalization/universality is very well exposed in the
compilation of Fritz Ruehr, which can be read by *ANYBODY*. There is no
"hard science" inside, just examples!
http://www.willamette.edu/~fruehr/haskell/evolution.html

Once upon a time, Eric Meijer and Luc Duponcheel wrote a paper entitled
"On the expressive power of constructor classes", where they proposed
a new "categorical prelude" for Gofer. It is an extremely inspiring paper!
(Citeseer shall have it.)

Some of ideas therein, in a different setting, can be easily read in the
Varmo Vene thesis on coinduction, and other "horrible stuff".

And, of course, there is a paper by Conor McBride and Ross Paterson on
applicative programming with effects, with an interesting discussion
*around* monads.

http://www.soi.city.ac.uk/~ross/papers/Applicative.pdf

..
Ugh. I am afraid I began an infinite, corecursive strem. Perhaps it is
time to break it.

Jerzy Karczmarczuk

[Lennart Augustsson]

You don't need to unsubscribe. Just avoid posting things that are totally
wrong (at least without a warning).

-- Lennart

Post by Andrew Coppin

Post by j***@info.unicaen.fr
I will be impolite.
If this were the first posting of A.C., I would suspect that he is pulling
my leg, that his brilliant sense of humour surpasses my comprehension,

so

Post by j***@info.unicaen.fr
I should be filled-up with deep respect for such a wonderful mind. But
enough is enough. Now, would it be really too much asking that - at

least

Post by j***@info.unicaen.fr
from time to time - Andrew Coppin think twice before saying things he -
apparently - knows NOTHING about?

OK. I get the message. I'm unsubscribing now...
[How ironic the subject line suddenly seems.]
_______________________________________________
Haskell-Cafe mailing list
http://www.haskell.org/mailman/listinfo/haskell-cafe

[david48]

Post by Lennart Augustsson
You don't need to unsubscribe. Just avoid posting things that are totally
wrong (at least without a warning).

How would he know they're "totally wrong" ?

[Tim Chevalier]

Post by david48

Post by Lennart Augustsson
You don't need to unsubscribe. Just avoid posting things that are totally
wrong (at least without a warning).

How would he know they're "totally wrong" ?

Thinking before hitting the Send button might be a good first step, as
well as refraining from giving the impression of certainty when one
isn't actually sure. A little knowledge can be a dangerous thing, and
it can be hard for newbies to evaluate the credibility of an answer.

Cheers,
Tim

[Hugh Perkins]

You're picking on Andrew Coppin? That's insane. He's got a sense of
humour, and he's a lay (non-phd) person.

Honestly, in one thread you've got "Haskell is misunderstood! Its the
greatest language in the world! Why does no-one use it????" and in
another you're insulting one of the few non-phds who's interested in
the language.

[Peter Verswyvelen]

Correction, I'm also very interested in Haskell, and I even don't have a
bachelor degree :-) I'm a completely self-educated kind-a-guy...

Anyway, IMHO Haskell rocks! A year ago I kind of started to hate writing
code, and that after 25 years of coding in imperative and
object-oriented languages. But thanks to Haskell, I found the vibes again!

Cheers,
Peter Verswyvelen

Post by Hugh Perkins
You're picking on Andrew Coppin? That's insane. He's got a sense of
humour, and he's a lay (non-phd) person.
Honestly, in one thread you've got "Haskell is misunderstood! Its the
greatest language in the world! Why does no-one use it????" and in
another you're insulting one of the few non-phds who's interested in
the language.
_______________________________________________
Haskell-Cafe mailing list
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Hugh Perkins]

Post by Peter Verswyvelen
Correction, I'm also very interested in Haskell, and I even don't have a

bachelor degree :-) I'm a completely self-educated kind-a-guy...

That's true, and actually you and Andrew are two of the people whose
opinions I respect the most. Well, I'll add SPJ to that list I guess.

Post by Peter Verswyvelen
Anyway, IMHO Haskell rocks! A year ago I kind of started to hate writing

code, and that after 25 years of coding in imperative and
object-oriented languages. But thanks to Haskell, I found the vibes again!

Oh, I wont deny Haskell is fun; wouldnt be here otherwise. Useful?
Different question ;-)

[Andrew Coppin]

Post by Hugh Perkins
You're picking on Andrew Coppin? That's insane. He's got a sense of
humour, and he's a lay (non-phd) person.
Honestly, in one thread you've got "Haskell is misunderstood! Its the
greatest language in the world! Why does no-one use it????" and in
another you're insulting one of the few non-phds who's interested in
the language.

Um... well... thanks for the unsolicited defence.

Well anyway, as you can see, I'm back. Mainly because I have questions
that I need answers for...

For what it's worth, I think Haskell is the most fantastic programming
language ever invented. I spend all my time thinking about it and using
it. And it frustrates the hell out of me that 100% of the human
population consider Haskell to be an irrelevant joke language. So I
basically have this uncontrollably awsome thing in front of me that I
spend all my time and energy interacting with... and nobody to talk to
about it. This mailing list is the only place I know of that is
inhabited by people who actually think Haskell is something worth
persuing. However, apparently even here my enthusiasm is misplaced.

I'm getting rather tired of being repeatedly flamed. So, in the
interests of preventing any further incidents, I will limit myself to
only asking specific questions that solicit a specific answer, and I
will attempt to refrain from stating any opinion of any kind. Hopefully
that way at least I'll get something useful from this list, and the
other people reading it won't have to listen to me being flamed again...

[Let the lurking begin...]

[Brent Yorgey]

Well anyway, as you can see, I'm back. Mainly because I have questions

Post by Andrew Coppin
that I need answers for...

glad you're back. =)

This mailing list is the only place I know of that is

Post by Andrew Coppin
inhabited by people who actually think Haskell is something worth
persuing.

don't forget about the IRC channel!

-Brent

[Andrew Coppin]

Post by Andrew Coppin
Well anyway, as you can see, I'm back. Mainly because I have questions
that I need answers for...
glad you're back. =)
This mailing list is the only place I know of that is
inhabited by people who actually think Haskell is something worth
persuing.
don't forget about the IRC channel!

That have talking on IRC now?

..damn it. That was an opinion... OK, I'll try harder in future.

[Felipe Lessa]

Post by Andrew Coppin
it. And it frustrates the hell out of me that 100% of the human
population consider Haskell to be an irrelevant joke language. So I
basically have this uncontrollably awsome thing in front of me that I
spend all my time and energy interacting with... and nobody to talk to
about it. This mailing list is the only place I know of that is
inhabited by people who actually think Haskell is something worth
persuing. However, apparently even here my enthusiasm is misplaced.

I feel this way as well, specially because one of the teachers here
tell all students that Haskell is the slowest thing ever by comparing
Fibonacci sequence implementations between C and Haskell *using Hugs*.
Unfortunately he doesn't want to now GHC or anything else that changes
his mind.

But it's easy to impress your friends. One of these days I used Parsec
to solve in 5 minutes a problem most people had spent at least a
couple of hours. And besides having one tenth of SLOC, it gave nice
error messages. They're getting interested, and some of them already
said that they'll learn it on the next summer (we're on the Southern
Hemisphere =). Someday we'll be using "monads" on e-mails.

Maybe this is not the best way to present a language, but in a
university where most people think that Java is the answer for every
question, it's the way I found to motivate them.

Oh, and I'm an undergraduate. Do I get free lambdas? :)

PS: Does anybody have slides for teaching imperative programmers how
to start feeling Haskell? I would like to give them a sort of
minicourse for getting started.

[j***@info.unicaen.fr]

Post by Felipe Lessa

... And it frustrates the hell out of me that 100% of the human
population consider Haskell to be an irrelevant joke language. ...

I feel this way as well, specially because one of the teachers here
tell all students that Haskell is the slowest thing ever by comparing
Fibonacci sequence implementations between C and Haskell *using Hugs*.

We shall thus understand that a teacher who likes Fibonacci, is a
representant of of the 100% of the human population.

On the other hand, Microsoft Research who pays some developers of Haskell
(whose names I have forgotten) doesn't count at all. Very interesting.


Jerzy Karczmarczuk

[Felipe Lessa]

Post by j***@info.unicaen.fr
We shall thus understand that a teacher who likes Fibonacci, is a
representant of of the 100% of the human population.

Sorry if I didn't understand very well the tone of your message or if
I wasn't clear enough, however what I was trying to say is that he
makes up the mind of most of his students with the idea that Haskell
is a toy language with poor performance and strange limitations. IOW,
that it's difficult to breath Haskell there.

Let's try not to start another meaningless discussion here, please =).

Cheers,

[j***@info.unicaen.fr]

Post by Felipe Lessa

Post by j***@info.unicaen.fr
We shall thus understand that a teacher who likes Fibonacci, is a
representant of of the 100% of the human population.

Sorry if I didn't understand very well the tone of your message or if
I wasn't clear enough, however what I was trying to say is that he
makes up the mind of most of his students with the idea that Haskell
is a toy language with poor performance and strange limitations.

My tone was obviously sarcastic, and the reason is that for ANY niche
of human activity you may find lousy teachers. And - in my eyes - you
shouldn't have agreed on such a pathological example that 100% of the
human population consider Haskell a toy. Haskell is being taught in
hundreds of places. That's all. We shouldn't advertize bad teachers.

BTW., almost 100% of humanity don't care at all about the General Theory
of Relativity. And *never did*. It didn't prevent Einstein from sleeping.
Of course, this example is as silly as it is, but not more.

J.K.

[Dipankar Ray]

i fear that, at this point, this thread is a test: if I post a reply, it
shows that I am a fool. ah well.

JK, of course there are foolish teachers out there. I don't think Felipe
was suggesting that this teacher had the right idea, nor that he himself
was going to stop haskelling anytime soon. But when people in relative
power say wrong things, it makes it harder for junior colleagues (or
students) to establish credibility, with other colleagues and students.

You may be of the opinion that such colleagues and students are fools, or
beyond help. But I think none of us made it to the promised land of
haskell in a vacuum - most were introduced by a friend or teacher. Seems
to me that Felipe feels a little thwarted in his desire to pass on the
favor to others.

Your tone suggests that it's some kind of moral weakness to want others to
get what we're talking about, what I'd call the "what do you care what
other people think?" philosophy. Of course, such a mindset can be very
valuable, and we should all cultivate self-confidence.

Nevertheless, I think there's no shame in wanting other people to share in
our joy - many of us are on this email list because we are
mini-evangelists as well as lovers of haskell. on the whole, I think we
evangelists can be a good thing for haskell, though of course we must be
responsible scholars ourselves.

It's not clear to me that Einstein slept so well (for myriad reasons), and
one can easily point to people who were geniuses and visionaries, who were
miserable for much of their life (Cantor, Godel, Turing, etc). Aren't we
all, to some degree, interested in creating a world where our ideas get
more support? You mention MS Research supporting the Simons - well, MSR
does so in part because both of them (and their colleagues at MSR
Cambridge) are tireless evangelists, who are fantastically generous with
their time, ideas, and code.

One way to go might be to code haskell in self-confident semi-secrecy, and
demonstrate the wonderfulness of our ideas by the results it produces.
This would be great. Another way to go is to teach others what is
*already* known. I think we can all agree that today there is a vast gulf
between what is considered "good", "professional" programming, and what is
the state of the art in CS (and specifically PL theory) today. Hence I
suspect that the good fight can be fought on many fronts at the same time.

Post by j***@info.unicaen.fr

Post by Felipe Lessa

Post by j***@info.unicaen.fr
We shall thus understand that a teacher who likes Fibonacci, is a
representant of of the 100% of the human population.

Sorry if I didn't understand very well the tone of your message or if
I wasn't clear enough, however what I was trying to say is that he
makes up the mind of most of his students with the idea that Haskell
is a toy language with poor performance and strange limitations.

My tone was obviously sarcastic, and the reason is that for ANY niche
of human activity you may find lousy teachers. And - in my eyes - you
shouldn't have agreed on such a pathological example that 100% of the
human population consider Haskell a toy. Haskell is being taught in
hundreds of places. That's all. We shouldn't advertize bad teachers.
BTW., almost 100% of humanity don't care at all about the General Theory
of Relativity. And *never did*. It didn't prevent Einstein from sleeping.
Of course, this example is as silly as it is, but not more.
J.K.
_______________________________________________
Haskell-Cafe mailing list
http://www.haskell.org/mailman/listinfo/haskell-cafe

[j***@info.unicaen.fr]

Dipankar Ray decided to invest himself after my last grumbling concerning
the uselessnes of recalling that Haskell may be presented in schools in
a very bad way.

Post by Dipankar Ray
JK, of course there are foolish teachers out there. I don't think Felipe
was suggesting that this teacher had the right idea, nor that he himself
was going to stop haskelling anytime soon. But when people in relative
power say wrong things, it makes it harder for junior colleagues (or
students) to establish credibility, with other colleagues and students.

I *never* implied that. I suggested only that - after the statement of
A. Coppin that 100% of the world ignores/despises Haskell - coroborating
such a statement by a clearly inadequate example is not serious.

Post by Dipankar Ray
You may be of the opinion that such colleagues and students are fools, or
beyond help.

I would *NEVER* say that, and I never did. On the contrary, my philosophy
addressed to young was always: be *proud* that you began to learn sthing,
since you *progress*. Potentially, you are more valuable that old guys
who know everything they think they need... (*) If I blessed Felipe, I am
terribly sorry. But I will fight with all arms against our
auto-flagellation, and the "victimization" atmosphere! This is a road to
hell.

Post by Dipankar Ray
... and we should all cultivate self-confidence.

Yes, absolutely. Without exaggeration... Perhaps the Feynman's wife phrase
which became the book title "What Do You Care What Other People Think" is
not the way of selling Haskell, but - please - there is a well known
personage in the Great Literature, somebody really nice, but *absolutely*
bad example to follow: Eyore, the Winnie the Pooh friend...

Post by Dipankar Ray
You mention MS Research supporting the Simons - well, MSR
does so in part because both of them (and their colleagues at MSR
Cambridge) are tireless evangelists, who are fantastically generous with
their time, ideas, and code.

Not only that, of course, there are plenty of tireless evangelists who
got no support. I wanted to point out that there are people/institutions
who dispose of non-negligeable resources, and who decided to *invest* in
people who do - apparently - an ever unpopular branch of programming theory
and practice.

++

(*) OK, an absolutely irrelevant anecdote.

Quite a time ago, far east of Poland (now Ukraine). An old Jew enters a
train in a small station at his shtetl, enter the compartment, and - shock:
he sees therein two well known Rebbis, wise men, very famous in the region.

Oh, my! thinks he, what a chance. Now I will learn something, since they
will probably engage in an extremely profound and enlightening discussion.

But hours pass, the train is slow, nothing happens...
After three hours, our hero is worried. He dares to open his mouth:
"Excuse me, Rebbe. I apologize for interrupting your meditation, but aren't
you the well know Rabbi from Pinsk?"
- Yes, indeed.
"And other gentelman..., I know you as well! You are the most well known
thinkers of the region. Now, please, tell me, why do you remain silent,
having such an opportunity to exchange some ideas, points of view, etc.
I really hoped I would profit from your presence, it would be a godly gift
for me!"

- "Well" - the Rabbi smiles. "You are right, we are wise men.
My neighbour is really very, very wise. He knows everything.
Actually, I know many, many things myself as well.
Why should we waste time on discussions? We won't learn more...

=====================

Jerzy Karczmarczuk

[Dipankar Ray]

Post by j***@info.unicaen.fr
Dipankar Ray decided to invest himself after my last grumbling concerning
the uselessnes of recalling that Haskell may be presented in schools in
a very bad way.

sadly, I'm neither the rabbi from minsk nor the one from pinsk. I just
happened to be on the train... an innocent bystander, I swear! ;-)

[Philippa Cowderoy]

Post by j***@info.unicaen.fr

Post by Felipe Lessa

... And it frustrates the hell out of me that 100% of the human
population consider Haskell to be an irrelevant joke language. ...

I feel this way as well, specially because one of the teachers here
tell all students that Haskell is the slowest thing ever by comparing
Fibonacci sequence implementations between C and Haskell *using Hugs*.

We shall thus understand that a teacher who likes Fibonacci, is a
representant of of the 100% of the human population.

Uh, Jerzy? You might want to consider this a variant of the idiomatic
"nobody cares", which also isn't quite meant literally.

[Gour]

On Wed, 17 Oct 2007 21:59:41 +0100

Post by Andrew Coppin
Well anyway, as you can see, I'm back. Mainly because I have
questions that I need answers for...

Welcome back ;)

Post by Andrew Coppin
This mailing list is the only place I know of that is inhabited by
people who actually think Haskell is something worth persuing.

Huh, the above is grievous offence to #haskell :-)


Sincerely,
Gour

[Andrew Coppin]

FWIW, other people feel about Haskell the way you feel about calculus
and the continuation monad, and your opinions of these other powerful,
but difficult, tools is what got you into this mess.

On the contrary, other people's misinterpretation of my opinions on
these matters is what got me into this mess.

I could go into a lengthy explanation, but I'll probably just be
misunderstood again. So let's leave it here.

academics don't like hearing that their life's work is useless.

Being positively surrounded by people who think Haskell is pointless, I
certainly have I fair idea how that feels...

[Don Stewart]

Post by Andrew Coppin

Post by Hugh Perkins
You're picking on Andrew Coppin? That's insane. He's got a sense of
humour, and he's a lay (non-phd) person.
Honestly, in one thread you've got "Haskell is misunderstood! Its the
greatest language in the world! Why does no-one use it????" and in
another you're insulting one of the few non-phds who's interested in
the language.

Um... well... thanks for the unsolicited defence.
Well anyway, as you can see, I'm back. Mainly because I have questions
that I need answers for...
For what it's worth, I think Haskell is the most fantastic programming
language ever invented. I spend all my time thinking about it and using
it. And it frustrates the hell out of me that 100% of the human
population consider Haskell to be an irrelevant joke language. So I
basically have this uncontrollably awsome thing in front of me that I
spend all my time and energy interacting with... and nobody to talk to
about it. This mailing list is the only place I know of that is
inhabited by people who actually think Haskell is something worth
persuing. However, apparently even here my enthusiasm is misplaced.

Please drop by the irc channel! enthusiasm is always welcome there, and
we're pretty much all obsessed too!

-- Don

[Valery V. Vorotyntsev]

Post by Don Stewart
Please drop by the irc channel! enthusiasm is always welcome there, and
we're pretty much all obsessed too!

Maybe that's not The Right Thing(TM) to ask, but anyway. :)

My access the world outside the office's LAN is limited to ports 80 and 443.
And chat.freenode.net lives on 6667.

Once upon a time I could access #haskell via IRC gateway @ irc.e.jabber.ru,
but not know, for the reasons unknown.

Do you know of any 443:server, forwarding connections to chat.freenode.net:6667?

Thanks a lot.

--
vvv

[Johan Tibell]

Post by Valery V. Vorotyntsev

Post by Don Stewart
Please drop by the irc channel! enthusiasm is always welcome there, and
we're pretty much all obsessed too!

Maybe that's not The Right Thing(TM) to ask, but anyway. :)
My access the world outside the office's LAN is limited to ports 80 and 443.
And chat.freenode.net lives on 6667.
but not know, for the reasons unknown.
Do you know of any 443:server, forwarding connections to chat.freenode.net:6667?
Thanks a lot.

If you have a web server somewhere you can use CGIIRC. That's what I
did in a similar situation.

http://cgiirc.org/

-- Johan

[Valery V. Vorotyntsev]

Post by Johan Tibell
If you have a web server somewhere you can use CGIIRC. That's what I
did in a similar situation.
http://cgiirc.org/

Thanks, Johan!

[Valery V. Vorotyntsev]

Post by Valery V. Vorotyntsev

Post by Johan Tibell
If you have a web server somewhere you can use CGIIRC. That's what I
did in a similar situation.
http://cgiirc.org/

Thanks, Johan!

There is one at http://ircatwork.com/
And now I'm in. Thank you very much. :)

--
vvv

[a***@spamcop.net]

G'day all.

Post by Vimal
Monads in programming seem to be the most mysterious notion of the century.

I agree with the "hair shirt" talk on this. I found understanding monads
no harder than understanding objects, starting from a comparable level of
ignorance.

I think the only difference is that "object" is a more accessible name
than "monad".

instance WarmFuzzyThing IO where ...

Cheers,
Andrew Bromage

[Richard A. O'Keefe]

Post by Vimal
I like the quote found on this site: http://patryshev.com/monad/m-
intro.html
<quote>
Monads in programming seem to be the most mysterious notion of the century.
* lack of familiarity with category theory;
* many authors carefully bypass any mention of categories.
It's like talking about electricity without using calculus.
Good enough to replace a fuse, not good enough to design an amplifier.
</quote>

It is true that Haskell Monads are inspired by category theory.
It is also true that all the operations you need for something to
be a category theoretic monad are available for Haskell Monads.
HOWEVER

You don't need to know that. Many Haskell programmers not only
don't understand anything much about categories, they will never
understand anything much about categories, and it doesn't matter.
(After years of study, I can now get *to* chapter 3 in the typical
"introduction to category theory* book, but not *through* it.)

The really amazing thing about the IO Monad in Haskell is that
there *isn't* any magic going on. An level of understanding
adequate for using the I/O and State monads stuff (that is,
adequate for practically anything analogous to what you might
do in another language) goes like this:

A type constructor that belongs to the Monad class can be used
to sequence actions over some kind of hidden state. Each of these
actions has an effect and a value. For example, getChar has the
effect of reading a character from standard input, and the character
it read as its value. For example, putChar x has the effect of
writing a character to standard output, and () as its value because
there isn't anything else useful to return. All monad instances
must provide

fail msg msg is an error message; this reports
an error.

return value an action with value as its value and
no effect

act1 >> act2 the effect of (act1 then act2) and the
value of act. THIS IS JUST LIKE SEMICOLON
IN TRADITIONAL LANGUAGES.

act1 >>= actf2 the effect of (act1 then (act2f x))
with the value of act2f x, where x is
the value of act1.

Each monad also typically comes with a function that takes an action and
an initial state and performs the action and returns its value. That
function's name usually starts with "run". For the IO monad, the hidden
state is "the state of the world, including I/O devices", and the "run"
step is done just outside your 'main' function. In order to have an
I/O action performed you should ensure that it is chained into the
sequence actions starting from main and linked by >> and >>= .

That's really all you have to know. The I/O actions in Haskell look
uncommonly like C, and if you can do I/O in C you *can* do I/O in
Haskell without even knowing how to spell 'Category Theory'.

[Brandon S. Allbery KF8NH]

Post by Richard A. O'Keefe
The really amazing thing about the IO Monad in Haskell is that
there *isn't* any magic going on. An level of understanding
adequate for using the I/O and State monads stuff (that is,
adequate for practically anything analogous to what you might

(...)

I like an explanation dons gave once the best: A Monad is a
programmable semicolon.

That pretty much sums it up, nice and simple. Everything else is
just scaffolding.

[Vimal]

Post by Richard A. O'Keefe
The really amazing thing about the IO Monad in Haskell is that
there *isn't* any magic going on. An level of understanding
adequate for using the I/O and State monads stuff (that is,
adequate for practically anything analogous to what you might
do in another language) goes like this:[...]

Yes, I am at the stage where I can understand most of whats going on,
as you described it in your email.

I was wondering if understanding Category Theory would help me model
situations better. Thats all :)

But for now, I guess I will stick with this. Assuming that its a black
box and it does what its supposed to do.

[Brian Hurt]

Post by Vimal
I like learning by
comparison with other similar languages. This approach worked for me
when I tried learning Python+Perl together. The nicer syntax and
easier object-orientedness made me leave Perl behind and pursue
Python.
I also tried it for Haskell (Lisp+OCaml+Haskell together).

This probably works quite well for mainstream programming languages (since
they're all so similar), but is unlikely to work at all for Haskell (since,
as far as I know, no other programming language on Earth is remotely like it
- Miranda excluded). Even Lisp and Erland are nothing like Haskell, and
they're supposedly based on the same ideas.

I'm going to offer an opinion here that's likely to be controversial (in
this forum): people new to functional programming shouldn't learn Haskell
first. They should start with either Ocaml or SML first. If it makes it
easier to accept this argument, you can consider Ocaml and SML as "Haskell
with training wheels". And that the original poster, rather than giving
up on Haskell, should instead put Haskell on the backburner and instead
learn Ocaml (which is likely to be hard enough). Then, in a year or two,
start taking another swing at Haskell.

The problem is that Haskell has a lot of big ideas that all come at you
pretty much immediately. Learning a new language in a new paradigm is a
lot harder than learning in a new language in a paradigm you already know.
If you know Java or C#, it's not that hard to learn Python or Ruby,
because you already know how to think in objects. The problem with going
from a C/Java/Ruby paradigm to Haskell is that Haskell isn't just one
paradigm shift, it's several all rolled into one:
- Purely functional
- Lazy
- Monadic
- Strongly typed

Each one of these has a huge impact in how you think about problems and
design programs- I'd argue about as large an impact as Objects have.
These are all good things (well, I'd admit to not being 100% sure about
pure laziness), and knowing how to think in these paradigms is definately
a good thing.

And the situation is worse with pure functional languages. When you move
from, say C/Pascal/Fortran to Java/Ruby/Python, you don't have to learn
new data structures and new algorithms. A doubly linked list is still
just a doubly linked list, still has the same properties, and still has
more or less the same implementation. In addition to learning Haskell,
you also need to relearn basic computer science. You need to learn what a
realtime lazy catenable dequeue is, how to implement it, and why you need
one, all the while struggling with the syntax, type errors, and all the
other problems trying to learning a new language.

I mean, contemplate this trivial exercise for a moment: write a program
that reads from stdin a series of numbers (one number per line), and
writes out the sum of the last n numbers. This is a trivial problem, and
I have no doubt that someone who knows Haskell better than I will reply to
this email with a single line of code that does it. But just think for a
moment the number of different paradigm shifts that you need to make to
write this program in Haskell.

I'm not saying that it's impossible to go directly to Haskell, I'm saying
that it's just very very hard.

Ocaml, meanwhile, is in many ways the C++ of the functional world. C++
was needed for object orientation to take off, because it allowed you to
continue to program in plain old procedural C when you needed to get
something done, and to play with OO concepts and ideas as you have the
time/inclination/need. Then, once people became comfortable with objects
and OO thinking, they were ready for the real OO languages.

In a similiar fasion, Ocaml allows you to write old fasioned impertive
code when you need to just get something working. And as you have the
time/inclination/need to, you can start playing with more advanced
functional concepts, like purely applicative data structures, lazy
evaluation, and even monads.

Brian

[j***@info.unicaen.fr]

Post by Brian Hurt
I'm going to offer an opinion here that's likely to be controversial (in
this forum): people new to functional programming shouldn't learn Haskell
first.

Great! So, there are at least two of us!

Post by Brian Hurt
They should start with either Ocaml or SML first.

Or Scheme.
Or *any* decent language, with functional tools. It is *exactly* what we
tried to do with Python. Paying tribute to our pedagogical constraints,
and teaching a language with a strong imperative taste, but using
functional constructions as frequently as possible. Recursion,
comprehensions, map/filter business (despite strong intentions of Guido
V.R. of killing them...), etc.
Also, higher-order functions, not so bad in Python, although sometimes
curiously inefficient. But, anyway, splitting between the language and
the basic techniques may be not so stupid.
Hm. An Anglosaxon shouldn't say "techniques may not be so stupid"?...

Post by Brian Hurt
In a similiar fasion, Ocaml allows you to write old fasioned impertive
code when you need to just get something working. And as you have the
time/inclination/need to, you can start playing with more advanced
functional concepts, like purely applicative data structures, lazy
evaluation, and even monads.

As far as the lazy evaluation is concerned, I would suggest then to jump
to Haskell or to Clean, after just a few simple-minded exercices in other
languages (the cons-stream, etc. in Scheme. Or, the generators in Python,
which are in a sense "lazy objects").
Otherwise you will *never* get a taste of laziness. It is useful only if
it is comfortable.

Jerzy Karczmarczuk

[apfelmus]

Post by Brian Hurt
I mean, contemplate this trivial exercise for a moment: write a program
that reads from stdin a series of numbers (one number per line), and
writes out the sum of the last n numbers. This is a trivial problem,
and I have no doubt that someone who knows Haskell better than I will
reply to this email with a single line of code that does it.

Sorry, I can't resist :)

main n = print . sum . map read . take n . reverse . lines =<<
getContents

Post by Brian Hurt
I'm not saying that it's impossible to go directly to Haskell, I'm
saying that it's just very very hard.
[&]
I'm going to offer an opinion here that's likely to be controversial
(in this forum): people new to functional programming shouldn't
learn Haskell first. They should start with either Ocaml or SML first.
If it makes it easier to accept this argument, you can consider
Ocaml and SML as "Haskell with training wheels".

I don't agree. At least, it was different for myself.

Looking at the line of code above, I can't help it, but I perceive
Haskell as being the _simplest_ programming language in the whole world.
I had no trouble learning it (step by step from a book), maybe because
I've happily thrown away everything I (thought I) knew (about
programming). The reward was worth it.

Why do people want side effects? Purity is soo much simpler.


Regards,
apfelmus

[Peter Verswyvelen]

Post by apfelmus
main n = print . sum . map read . take n . reverse . lines =<<
getContents

Amazing. And so easy to read and understand...

This reminds me of a student how asked me to convert a simple formula to
approximate PI from C++ to Haskell. Even although I have over a decade
of C++ experience, I could not immediately do it (okay, I also just gave
a 3 hours non-stop lecture, so my brain was completely empty ;). But
when he gave me the math formula, converting it to Haskell was just a
matter of translating the math to Haskell, almost one-to-one....

And that's one of the reasons I want to stick to Haskell for a few more
years (at least) :-)

Peter

[Prabhakar Ragde]

Post by Brian Hurt
I mean, contemplate this trivial exercise for a moment: write a program

Post by Brian Hurt
that reads from stdin a series of numbers (one number per line), and
writes out the sum of the last n numbers. This is a trivial problem,
and I have no doubt that someone who knows Haskell better than I will
reply to this email with a single line of code that does it.

Sorry, I can't resist :)
main n = print . sum . map read . take n . reverse . lines =<< getContents

Could someone describe succinctly how to compute the space complexity of
this program, if there are m lines of input and m >> n? Many thanks. --PR

[Felipe Lessa]

Post by Prabhakar Ragde

main n = print . sum . map read . take n . reverse . lines =<< getContents

Could someone describe succinctly how to compute the space complexity of
this program, if there are m lines of input and m >> n? Many thanks. --PR

'reverse' needs to go to the end of the list to start outputting, so
it has to keep all elements in memory somewhere at least in one moment
of time. That means that the program has space complexity of O(m) --
the other functions are all O(1) in terms of line count.

You may try this version instead:

main n = print . sum . map read . head . dropWhile (not . null . drop
n) . tails . lines =<< getContents

where I changed (take n . reverse) to (head . dropWhile (not . null .
drop n) . tails). Yes, I cheated, I'm using Data.List =). With this
version you keep only n lines in memory at any moment, so it has space
complexity of O(n).

Please anybody correct me if I'm wrong.

Cheers,

[apfelmus]

Post by Prabhakar Ragde

main n = print . sum . map read . take n . reverse . lines =<< getContents

Could someone describe succinctly how to compute the space complexity of
this program, if there are m lines of input and m >> n? Many thanks. --PR

Good point :)

Post by Prabhakar Ragde
main n = print . sum . map read . head . dropWhile (not . null . drop
n) . tails . lines =<< getContents
where I changed (take n . reverse) to (head . dropWhile (not . null .
drop n) . tails). Yes, I cheated, I'm using Data.List =). With this
version you keep only n lines in memory at any moment, so it has space
complexity of O(n).

Yes, this has O(n) space complexity since dropWhile can discard the
dropped elements. Unfortunately, we now have O(m*n) time complexity
since drop n is executed for every list element.

Of course, the solution is to first drop n elements and then take
tails instead of dropping n elements every time.

map (drop n) . tails = tails . drop n

O(m*n) O(m)

With this, we can write a function that returns the last n elements of
a list in O(m) time and O(n) space as

lasts :: Int -> [a] -> [a]
lasts n xs = head $ [x | (x,[]) <- zip (tails xs) (tails $ drop n xs)]

and use it as a drop-in replacement

main n = print . sum . map read . lasts n . lines =<< getContents

Regards,
apfelmus


PS: The implementation of lasts n in my original version would be

lasts n = reverse . take n . reverse

But thanks to

map f . reverse = reverse . map f
sum . reverse = sum

we can leave out one reverse.

[Felipe Lessa]

Post by apfelmus
Of course, the solution is to first drop n elements and then take
tails instead of dropping n elements every time.
map (drop n) . tails = tails . drop n
O(m*n) O(m)

Nice identity. I'll remember this one.

Post by apfelmus
With this, we can write a function that returns the last n elements of
a list in O(m) time and O(n) space as
lasts :: Int -> [a] -> [a]
lasts n xs = head $ [x | (x,[]) <- zip (tails xs) (tails $ drop n xs)]
and use it as a drop-in replacement
main n = print . sum . map read . lasts n . lines =<< getContents

But that's a a two-liner now heh =).

Thanks for your great postings, apfelmus.

Cheers,

[Daniil Elovkov]

Post by Felipe Lessa

Post by apfelmus
Of course, the solution is to first drop n elements and then take
tails instead of dropping n elements every time.
map (drop n) . tails = tails . drop n
O(m*n) O(m)

Nice identity. I'll remember this one.

Post by apfelmus
With this, we can write a function that returns the last n elements of
a list in O(m) time and O(n) space as
lasts :: Int -> [a] -> [a]
lasts n xs = head $ [x | (x,[]) <- zip (tails xs) (tails $ drop n xs)]
and use it as a drop-in replacement
main n = print . sum . map read . lasts n . lines =<< getContents

But that's a a two-liner now heh =).

If we're talking about (more than one)-liners, isn't this simpler to
read? Or is it just me

lasts n xs = let (_,remn) = splitAt n xs in go xs remn

go lag [] = lag
go [] _ = error "shouldn't happen"
go (l:ls) (x:xs) = go ls xs

[apfelmus]

Post by Felipe Lessa

Post by apfelmus
Of course, the solution is to first drop n elements and then take
tails instead of dropping n elements every time.
map (drop n) . tails = tails . drop n
O(m*n) O(m)

Nice identity. I'll remember this one.

Oops, please don't because it's wrong :)

Data.List> let xs = [1..3]
Data.List> map (drop 2) . tails $ xs
[[3],[],[],[]]
Data.List> tails . drop 2 $ xs
[[3],[]]

The first one produces some extra empty lists at the end. In other
words, the left hand side and the right hand side have different lengths

length . map (drop n) . tails = (+1) . length

but

length . tails . drop n = (\k -> 1 + max 0 (k-n)) . length

But the wrong version looks much nicer :)

Post by Felipe Lessa
Thanks for your great postings, apfelmus.

λ(^_^)λ

Regards,
apfelmus

[Brandon S. Allbery KF8NH]

Post by Felipe Lessa

Post by apfelmus
lasts :: Int -> [a] -> [a]
lasts n xs = head $ [x | (x,[]) <- zip (tails xs) (tails $ drop n xs)]

(...)

Post by Felipe Lessa

Post by apfelmus
main n = print . sum . map read . lasts n . lines =<< getContents

But that's a a two-liner now heh =).

oO { if you want Perl, you know where to find it... }

[Neil Mitchell]

Hi

Post by Prabhakar Ragde

main n = print . sum . map read . take n . reverse . lines =<< getContents

Could someone describe succinctly how to compute the space complexity of
this program, if there are m lines of input and m >> n? Many thanks. --PR

The space complexity is the size of the file - i.e. of size m. reverse
will buffer up all the lines before it gives any back, which is a well
known property of reverse. You could rewrite (take n . reverse) as a
function that only requires n lines of buffer.

Thanks

Neil

[Conal Elliott]

More neatly, we can fully separate IO from computation:

h n = interact $ show . sum . map read . take n . reverse . lines

Better yet go a small step further and make *composable* combinations of IO
& pure computation, as in TV (http://haskell.org/haskellwiki/TV).

Cheers, - Conal

Post by apfelmus

Post by Brian Hurt
I mean, contemplate this trivial exercise for a moment: write a program
that reads from stdin a series of numbers (one number per line), and
writes out the sum of the last n numbers. This is a trivial problem,
and I have no doubt that someone who knows Haskell better than I will
reply to this email with a single line of code that does it.

Sorry, I can't resist :)
main n = print . sum . map read . take n . reverse . lines =<<
getContents

Post by Brian Hurt
I'm not saying that it's impossible to go directly to Haskell, I'm
saying that it's just very very hard.
[&]
I'm going to offer an opinion here that's likely to be controversial
(in this forum): people new to functional programming shouldn't
learn Haskell first. They should start with either Ocaml or SML first.
If it makes it easier to accept this argument, you can consider
Ocaml and SML as "Haskell with training wheels".

I don't agree. At least, it was different for myself.
Looking at the line of code above, I can't help it, but I perceive
Haskell as being the _simplest_ programming language in the whole world.
I had no trouble learning it (step by step from a book), maybe because
I've happily thrown away everything I (thought I) knew (about
programming). The reward was worth it.
Why do people want side effects? Purity is soo much simpler.
Regards,
apfelmus
_______________________________________________
Haskell-Cafe mailing list
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Peter Verswyvelen]

Or F#, if you know C#, which is the "OCaml for the .NET world".

Now I immediately went from C/C++/C# to Haskell, and yes, that was (is)
hard. For me, the book Haskell School of Expression did it... All you
need is a good book and lots of patience...

Post by Brian Hurt

Post by Andrew Coppin

Post by Vimal
I like learning by
comparison with other similar languages. This approach worked for me
when I tried learning Python+Perl together. The nicer syntax and
easier object-orientedness made me leave Perl behind and pursue
Python.
I also tried it for Haskell (Lisp+OCaml+Haskell together).

This probably works quite well for mainstream programming languages
(since they're all so similar), but is unlikely to work at all for
Haskell (since, as far as I know, no other programming language on
Earth is remotely like it - Miranda excluded). Even Lisp and Erland
are nothing like Haskell, and they're supposedly based on the same
ideas.

I'm going to offer an opinion here that's likely to be controversial
(in this forum): people new to functional programming shouldn't learn
Haskell first. They should start with either Ocaml or SML first. If
it makes it easier to accept this argument, you can consider Ocaml and
SML as "Haskell with training wheels". And that the original poster,
rather than giving up on Haskell, should instead put Haskell on the
backburner and instead learn Ocaml (which is likely to be hard
enough). Then, in a year or two, start taking another swing at Haskell.
The problem is that Haskell has a lot of big ideas that all come at
you pretty much immediately. Learning a new language in a new
paradigm is a lot harder than learning in a new language in a paradigm
you already know. If you know Java or C#, it's not that hard to learn
Python or Ruby, because you already know how to think in objects. The
problem with going from a C/Java/Ruby paradigm to Haskell is that
- Purely functional
- Lazy
- Monadic
- Strongly typed
Each one of these has a huge impact in how you think about problems
and design programs- I'd argue about as large an impact as Objects
have. These are all good things (well, I'd admit to not being 100%
sure about pure laziness), and knowing how to think in these paradigms
is definately a good thing.
And the situation is worse with pure functional languages. When you
move from, say C/Pascal/Fortran to Java/Ruby/Python, you don't have to
learn new data structures and new algorithms. A doubly linked list is
still just a doubly linked list, still has the same properties, and
still has more or less the same implementation. In addition to
learning Haskell, you also need to relearn basic computer science.
You need to learn what a realtime lazy catenable dequeue is, how to
implement it, and why you need one, all the while struggling with the
syntax, type errors, and all the other problems trying to learning a
new language.
I mean, contemplate this trivial exercise for a moment: write a
program that reads from stdin a series of numbers (one number per
line), and writes out the sum of the last n numbers. This is a
trivial problem, and I have no doubt that someone who knows Haskell
better than I will reply to this email with a single line of code that
does it. But just think for a moment the number of different paradigm
shifts that you need to make to write this program in Haskell.
I'm not saying that it's impossible to go directly to Haskell, I'm
saying that it's just very very hard.
Ocaml, meanwhile, is in many ways the C++ of the functional world.
C++ was needed for object orientation to take off, because it allowed
you to continue to program in plain old procedural C when you needed
to get something done, and to play with OO concepts and ideas as you
have the time/inclination/need. Then, once people became comfortable
with objects and OO thinking, they were ready for the real OO languages.
In a similiar fasion, Ocaml allows you to write old fasioned impertive
code when you need to just get something working. And as you have the
time/inclination/need to, you can start playing with more advanced
functional concepts, like purely applicative data structures, lazy
evaluation, and even monads.
Brian
_______________________________________________
Haskell-Cafe mailing list
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Sterling Clover]

Or you could just use Data.Sequence and brows the code at your later
leisure, right? Better yet, you could forget about optimal
datastructures until you learned how to do toy problems with just
plain lists.

--S

Post by Brian Hurt
And the situation is worse with pure functional languages. When
you move from, say C/Pascal/Fortran to Java/Ruby/Python, you don't
have to learn new data structures and new algorithms. A doubly
linked list is still just a doubly linked list, still has the same
properties, and still has more or less the same implementation. In
addition to learning Haskell, you also need to relearn basic
computer science. You need to learn what a realtime lazy catenable
dequeue is, how to implement it, and why you need one, all the
while struggling with the syntax, type errors, and all the other
problems trying to learning a new language.

[namekuseijin]

Post by Andrew Coppin

Post by Vimal
I like learning by
comparison with other similar languages.

This probably works quite well for mainstream programming languages
(since they're all so similar),

very true. Python, Java, C++ are just different syntaxes for
essentially the same imperative paradigm. You may program in a
functional style in them, just as you can program in a OO-style in C.

Post by Andrew Coppin
but is unlikely to work at all for
Haskell (since, as far as I know, no other programming language on Earth
is remotely like it - Miranda excluded). Even Lisp and Erland are
nothing like Haskell, and they're supposedly based on the same ideas.

Now you're exaggerating. Lisp and Erlang are very close to Haskell,
except for the lazyness and the type-system. I know it because, as a
Scheme programmer, I didn't find it too difficult to dig Haskell
concepts...
Funny you don't mention ML-family languages, though... they're even
closer.

I personally find ML, Miranda and Haskell to be legitimate Lisp
derivatives (or deviates :).

Post by Andrew Coppin

Post by Vimal
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.

Not a bad way to learn to use a tool. You might want to stick to things
that involve simple I/O and complex processing rather than the other way
round though. ;-)

yes, the problem of that approach is that you can't bring common
mainstream expertise,
the way to do things as all others do, to languages like Haskell. You
should find the
Haskell way to do the same thing instead.

[apfelmus]

Post by Vimal
I have been trying my best to read about Haskell from the various
tutorials available on the internet and blogs.
[...]
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.

IMHO, the best way to learn Haskell is to learn it from a textbook.
That's basically all there is to it :)

I mean, the same goes for Theoretical Computer Science, Mathematics,
Physics etc. I think that the key properties of a textbook are
1) printed on paper
2) well-written
Of course, if a book doesn't have property 2), use another one. An
online book satisfying 2) can be made satisfy 1) by printing it out. In
other words, anything goes that fulfills 1) and 2).

And since reading two textbooks (in parallel) is even better than
reading only one, I'd additionally recommend Bird's "Introduction to
Functional Programming using Haskell". For other books, see also

http://haskell.org/haskellwiki/Books_and_tutorials#Textbooks

Regards,
apfelmus

[Mads Lindstrøm]

Hi Vimal

Post by Vimal
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.
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.

In my opinion (other may think differently) it is not a good idea to
learn IO by starting with trying to grasp the theoretical foundation for
monads. In the beginning you should just view the IO monad as Haskell's
way of doing imperative IO stuff. When you feel comfortable with Haskell
IO, then try to learn a couple of other monads. Then maybe this article
http://sigfpe.blogspot.com/2006/05/grok-haskell-monad-transformers.html
about monad transformers. It is good because it do not try to explain
the implementation details of monad transformers - just how you use
them. When you have done all that, then you should be ready for all the
details.

Post by Vimal
--snip--
Okay, so you might be wondering as to whats the whole point of this
mail? Well, I am almost on the verge of giving up on something I
really like to learn, just because I didn't go in the right order!
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.
Meanwhile, could anyone suggest if there was anything wrong in my
approach to learning Haskell/the other languages? I agree that the
learning methodology is something personal and I have to find out what
best suits me, but I would like to hear something from you,
Haskellers, too.

As I wrote above, I think you are trying to understand too many details
at once. Also a textbook can sometimes be helpful. But you also have a
learning by doing approach, which I personally find very productive.

And do not give up yet. Haskell has a lot to offer and I think it is
well worth the steep learning curve.


Cheers,

Mads Lindstrøm

[Vimal]

Post by Mads Lindstrøm
In my opinion (other may think differently) it is not a good idea to
learn IO by starting with trying to grasp the theoretical foundation for
monads. In the beginning you should just view the IO monad as Haskell's
way of doing imperative IO stuff. When you feel comfortable with Haskell
IO, then try to learn a couple of other monads. Then maybe this article
http://sigfpe.blogspot.com/2006/05/grok-haskell-monad-transformers.html
about monad transformers. It is good because it do not try to explain
the implementation details of monad transformers - just how you use
them. When you have done all that, then you should be ready for all the
details.

Alright, this post seems interesting. Will try it out soon!

Post by Mads Lindstrøm
As I wrote above, I think you are trying to understand too many details
at once. Also a textbook can sometimes be helpful. But you also have a
learning by doing approach, which I personally find very productive.

Yeah, this has always been a problem with me. Its like browsing
Wikipedia. Open an article, and you branch out like anything.
Curiosity does kill the cat :(

Post by Mads Lindstrøm
And do not give up yet. Haskell has a lot to offer and I think it is
well worth the steep learning curve.

Nope. I enjoy learning it, just waiting to hit the peak!
Someone creative enough should draw the learning curve for Haskell :D.
I remember some funny ones for text editors!
(emacs had a spiral...)

[Andrew Coppin]

Post by Vimal
Wikipedia. Open an article, and you branch out like anything.
Curiosity does kill the cat :(
Yeah, this has always been a problem with me. Its like browsing

Whenever I do this, I usually end up reading about something utterly
unrelated. (Actually, I usually end up reading about things which are
toxic, explosive, flammable or corrosive... hmm, That's Not Good...)

I tried to use Wikipedia to learn about how to build digital filters...
this was a disaster. There is almost no useful information there! :-(

[a***@spamcop.net]

G'day all.

Post by Andrew Coppin
I tried to use Wikipedia to learn about how to build digital filters...
this was a disaster. There is almost no useful information there! :-(

That's not my experience. I didn't really understand Kalman filters
until I read the Wikipedia page. It's better than most of the tutorials
out there.

(I think you have to luck out with the right topic.)

Cheers,
Andrew Bromage

[Chung-chieh Shan]

Post by a***@spamcop.net
That's not my experience. I didn't really understand Kalman filters
until I read the Wikipedia page. It's better than most of the tutorials
out there.

While we're off topic, here's a nice introduction to Kalman filters:
http://www.cs.unc.edu/~welch/kalman/maybeck.html

[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.

Post by Vimal
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)

Post by Vimal
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.

Post by Vimal
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.

Post by Vimal
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

[Andrew Coppin]

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.

Yep, that's the idea. :-D

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.

Au contrare... ;-)

Let us examine "web browser" for a moment. Yes, it does some input
(typically fetching resources by HTTP), and some output (mainly
displaying stuff on your screen). But wait a moment there... For a
typical web page, you might well have to perform all of the following
operations:

- Parse an XHTML file into a document tree. (That's pretty algorithmic.)
- Parse multiple CSS style sheets, and apply them to the document. (This
involves processing possibly-complex element selectors, observing
inheritance relationships, and merging the properties from several
sources into a single result set. That's A LOT of algorithm!)
- Parse some JavaScript and execute it. (That's an entire programming
language, remember.) Watch in horror is it uses the DOM to *modify* the
XHTML data you just parsed and applied CSS to...
- Load several JPEG files. (You might think that "load a JPEG file" is
I/O, but really, getting the data into memory is just the beginning.
You've got a file to parse, you've got an arithmetic code to decompress,
and then you've got an inverse Discrete Cosine Transform to do. Again,
LOTS of algorithm.)
- Let us hope to God the page doesn't contain any SVG... (Think of the
massacre!)
- Perform final layout (frames, tables, justification, backgrounds,
transparency...) and rendering to incorporate all this data into one
huge bitmap that can be dumped into the framebuffer.

OK, so if you wrote this program today, the JPEG part would probably be
an external library. And SVG, if you supported it. But you get the
point; there is A LOT of heavily algorithmic stuff happening there that
has little or nothing to do with I/O. The browser is sucking in XHTML,
CSS, JavaScript, JPEG, SVG and God only knows what else (XSLT, anyone?),
doing a mountain of processing with it, and only then showing the final
result on your computer screen. There's a lot more I/O than your typical
compiler, but don't go thinking there's nothing algorithmic happening
here. ;-)

Similarly, any good "word processor" is going to have layout algorithms
(would you like that left-justified or right-justified? what happens if
you have several typeface sizes in the same block of text? how does text
flow round images?), and possibly cross-referencing. Email programs need
to efficiently store and retrieve user's mail, and often have search
facilities (and even Baysian filters for eliding spam). Even a humble
IDE usually has syntax recognition...

So you see, they may not spend quite as much *time* on computation as a
compiler does, but there's still plenty of *complexity* there. ;-)

[Vimal]

I think you have got a very good point in your mail that I overlooked
all along ... "Why was Haskell created?" is a question that I havent
tried looking for a answer :)

Post by David Stigant
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

Ah, yes, Project Euler. I did start doing this sometime back, but then
gave up on it. Perhaps its time to start again :)

Thanks, that was an eyeopener.

[Andrew Coppin]

Post by Vimal
I think you have got a very good point in your mail that I overlooked
all along ... "Why was Haskell created?" is a question that I havent
tried looking for a answer :)

To avoid success at all costs?

(No, seriously. The basic idea was that there used to be about two-dozen
languages like Haskell, but all developed by different people and all
with different syntax and so on. So they wanted to create a single
language suitable for teaching to students. You could say it's the
Pascal of the functional world... Hey, maybe that explains the lack of
success?)

[Derek Elkins]

Post by Andrew Coppin

Post by Vimal
I think you have got a very good point in your mail that I overlooked
all along ... "Why was Haskell created?" is a question that I havent
tried looking for a answer :)

To avoid success at all costs?
(No, seriously. The basic idea was that there used to be about two-dozen
languages like Haskell, but all developed by different people and all
with different syntax and so on. So they wanted to create a single
language suitable for teaching to students. You could say it's the
Pascal of the functional world... Hey, maybe that explains the lack of
success?)

The first goal listed in the Haskell 1.0 Report is:

"It should be suitable for teaching, research, and applications,
including building large systems."

Haskell was never intended to be solely a teaching or research language.
(You didn't necessarily say that, but it is a widely held and propagated
misconception.)

[a***@spamcop.net]

G'day all.

Post by Derek Elkins
"It should be suitable for teaching, research, and applications,
including building large systems."
Haskell was never intended to be solely a teaching or research language.
(You didn't necessarily say that, but it is a widely held and propagated
misconception.)

I'd argue that you're kind of both right.

The purpose of Haskell (i.e. "Haskell 89") was to unify all of those
Miranda-like systems into a single language that everyone could share.

However, arguably the biggest imperatives for Haskell 98 was to remove
features that would confuse undergraduates. Even though we may not like
to admit it, H98 really is primarily a teaching/research language.

If we were doing H98 today, I don't think that would happen. The
"research" part is bigger and better than ever, but we seem to weight
"applications, including building large systems" more highly than
"teaching" now.

Having said that, in retrospect, the clean break was probably for the
best. H98 gave us a simpler core on which to add the glasgow-exts.
There's some stuff from Haskell 1.3 that I miss, and I hope it will
come back, but there's also stuff that we're better off without.

Cheers,
Andrew Bromage

[j***@info.unicaen.fr]

Post by a***@spamcop.net
There's some stuff from Haskell 1.3 that I miss, and I hope it will
come back, but there's also stuff that we're better off without.

I have heard that a few times, not recently. This is really interesting,
WHAT do you actually miss?

For me, from the ancient times, what I regret, but just a tiny bit, is
that (:) is not an operator as any other, but a "syntactic construct".
(Well, who cares, unless you try to make your own lists, with different
precedence, etc...)

Also, monadic comprehensions, which disappeared in order to remove too
much of ambiguity... Anything else worth mentioning? What *negative* has
been suppressed?

Frankly, I regret the times when Mark Jones made his revolutions within
Gofer, proposing constructor classes, etc. At that time we knew that
Haskell was for the brave, not for people making money... Almost everybody
was a newbie.

Jerzy Karczmarczuk

[a***@spamcop.net]

G'day all.

Post by j***@info.unicaen.fr
I have heard that a few times, not recently. This is really interesting,
WHAT do you actually miss?

Off the top of my head, from H1.4, I miss:

- MonadZero (a lot)
- Some of the monad/functor-overloaded functions (quite a bit)
- Record punning (slightly)

Post by j***@info.unicaen.fr
For me, from the ancient times, what I
regret, but just a tiny bit, is
that (:) is not an operator as any other, but a "syntactic construct".

I agree with that in principle; it's unfortunate that lists are
"built in" as much as they are. But I can't say I really miss this.

Post by j***@info.unicaen.fr
Also, monadic comprehensions, which disappeared in order to remove too
much of ambiguity...

Five years ago, I would have agreed. I'm over that now, and do-notation
is more useful.

Post by j***@info.unicaen.fr
Anything else worth mentioning? What *negative* has
been suppressed?

I mentioned the un-generalising of "map" above. That probably needs some
justification. I think that the best evidence of why this was a mistake
is the fact that many modules implement a namespace-overloaded "map".
Data.Map.map springs to mind, but there are others.

People want to write "map" instead of "fmap". We could have come up
with an alternative name for the list-version of "map" and not showed
"map" to newbies.

(Having said that, some of the un-overloading was good. I'm happy,
for example, to reserve "concat" for lists and use "join" for monads.)

Cheers,
Andrew Bromage

[apfelmus]

Post by a***@spamcop.net
However, arguably the biggest imperatives for Haskell 98 was to remove
features that would confuse undergraduates.
[...]
People want to write "map" instead of "fmap". We could have come up
with an alternative name for the list-version of "map" and not showed
"map" to newbies.

Couldn't the "too much overloading for undergrads" issue be solved by
providing a LearningPrelude and a RealHackersPrelude? :) The condition
is that the former exports the same or less functions with the same or
less general types than the latter, so that function names are the same
and there's no infantilizing.

A stronger condition would be that every valid LearningPrelude program
should be a valid RealHackersPrelude program. This is probably
preferred, but may be tricky due to overloading ambiguities.

Regards,
apfelmus

[Claus Reinke]

Post by David Stigant
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.

hey, compilers do nothing but IO! they read sources, print error
messages or write object files and executables. there is really no
need to do any "unseen" computation at all! unless there is some
visible effect on the file system or programmer console, any such
"unseen" computation is wasted, and should be optimised away.

. just kidding, of course?-)

if compilers seem more suitable for haskell, it may be because
they have been studied for a long time, and while throughput is
important, noone is likely to argue that the core of compilation
is about reading or writing files. the focus in writing compilers
is on designing, implementing and manipulating the internal
representations of the source and object code represented
externally as strings of chars and bytes.

applying the same reasoning to your "most widely-used programs",
we could say that their theory hasn't reached the same level as
that of compilers (and so i'd remove data bases from your list,
and editors are also reasonably well-understood). once their
internal representations are better understood, programming
again focusses on working with these internal representations
(often called models), while IO reduces to a straightforward
mapping from and to those internal representations that are
closest to the external ones.

claus

[Philippa Cowderoy]

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.

No, they don't. They look it, but there's always a fair amount of
computation going on to decide things like what IO to do. For example, in
a web browser the IO is in reading user input, rendering the display and
interacting with the network - but page layout is computation, as is
dispatching input.

[Hugh Perkins]

Post by Vimal
Dear Haskellers,
I have been trying my best to read about Haskell from the various
tutorials available on the internet and blogs. I havent been following
YAHT properly, so its always been learning from 'bits and pieces'
scattered around.

You might try Erlang. It's easy like Python. It's designed for
rock-solid enterprise applications. Threading and rpc are insanely
easy.

[Bulat Ziganshin]

Hello Vimal,

Post by Vimal
Dear Haskellers,
I have been trying my best to read about Haskell from the various

first time when i tried to learn haskell i give up and returned only a
year later :) about IO: you may try to read
http://haskell.org/haskellwiki/IO_inside