Version française
Home     About     Download     Resources     Contact us    

This site is updated infrequently. For up-to-date information, please visit the new OCaml website at

Browse thread
Re: [Caml-list] poll - need for a good introductory OCaml book (LONG)
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: 2003-03-14 (17:14)
From: Brian Hurt <brian.hurt@q...>
Subject: Re: [Caml-list] poll - need for a good introductory OCaml book (LONG)
On Fri, 14 Mar 2003, Sergey Goldgaber wrote:
> I have been struggling to learn OCaml for over a month now.  It
> is, without a doubt, the hardest language I have ever tried to
> learn, and in some ways makes assembly language look simple and
> intuitive by comparison.


> Now, I am not a novice at programming.  I have used computers
> since 1980, I know: C, Perl, Assembly, Pascal, Visual Basic, shell
> scripting, Logo, REXX, SQL, HTML.  Picking up most any of those
> (except for assembly) was a breeze.  But learning OCaml, as it is
> my first functional language, is painful (until I have an "aha"
> moment, when I glimpse its elegance and power, and all the pain
> seems worth it).

I note that none of the languages you list are Object Oriented either.  
You're learning a new paradigm.  Which is hard.  I actually got functional
programming *easier* than I got OO programming.  Not the least of which
was because I realized that it was a paradigm shift, and knew what that
meant (having gone through it once before, with OO).  I'd bet that 
learning Java or Smalltalk would be just as hard.

> Coming from a purely imperative background I found the following
> concepts the biggest stumbling blocks in my attempts at learning
> OCaml: functional style, recursion, type inference

I don't view type inference as 'core' to functional programming.  You can 
do type inference on C, just most people don't.  It's easier to do it on 
functional programs than on imperitive programs, but you could quite 
easily write a functional program without type inference.

Functions as first class objects, partial evaluation, and recursion are 
central to functional programming, much like inheritance, virtual 
functions, and overloading are central to object oriented programming.

Let me shift the argument over a bit- from functional to object oriented
programming.  I've often heard the argument (from those who don't know OO,
and don't want to learn it) to the effect "why should I learn OO?  I can
do all this stuff in C if I want to.  I just generally don't want to."  
In a sense, they are correct- you *can* do everything Java does in C.  
It's just inconvient and error prone.  Java makes them easy, safe and
natural to use, and encourages you to use them.  At which point you
discover that using them a lot more is usefull.

A similiar argument applies to functional programming.  You can do 
functions as first-class values (function pointers), recursion, etc in an 
imperitive language as well.  It's just not as convient and safe.  

Here's the problem: in imperitive (and OO) languages, recursion is a hard 
concept.  Because it's not a natural concept in the model of computation 
that is implicitly being used.  You need to understand about stacks, stack 
frames, local variables being on stack frames, how side effects propogate, 
etc.  My high school Comp Sci AP class taught us the basics of Pascal in 
two weeks- and then we spent a solid month on recursion.  In imperitive 
languages, recursion isn't a trivial concept.

But if you change your model of computation, from turing-machine 
imperitive to lambda-calculus functional, most of these concepts become 
easy, even trivial.

Also, another thing I'd like to see- functional patterns.  Even language 
has design patterns.  Yes, the concept was pioneered by the OO people, but 
there are imperitive patterns, and functional patterns as well.


To unsubscribe, mail Archives:
Bug reports: FAQ:
Beginner's list: