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

[Brian Hurt]

On Sun, 14 Oct 2007, Andrew Coppin wrote:

> Vimal wrote:
>> 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