caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
From: Brian Hurt <brian.hurt@qlogic.com>
To: Sergey Goldgaber <sgoldgaber@yahoo.com>
Cc: Caml-list <caml-list@inria.fr>,
	Graham Guttocks <graham_guttocks@yahoo.co.nz>
Subject: Re: [Caml-list] poll - need for a good introductory OCaml book (LONG)
Date: Fri, 14 Mar 2003 11:24:48 -0600 (CST)	[thread overview]
Message-ID: <Pine.LNX.4.33.0303141022400.2164-100000@eagle.ancor.com> (raw)
In-Reply-To: <20030314081208.86223.qmail@web11004.mail.yahoo.com>

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.

Heh.

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

Brian


-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners


  parent reply	other threads:[~2003-03-14 17:14 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-03-14  8:12 Sergey Goldgaber
2003-03-14  9:51 ` Noel Welsh
2003-03-14 10:36   ` Sergey Goldgaber
2003-03-14 10:47     ` Noel Welsh
2003-03-14 11:13       ` Sergey Goldgaber
2003-03-14 11:47         ` Noel Welsh
2003-03-14 12:59         ` Geoff Wozniak
2003-03-14 11:20     ` William Lovas
2003-03-14 11:38       ` MikhailFedotov
2003-03-14 12:16       ` Sergey Goldgaber
2003-03-14 18:57         ` Richard W.M. Jones
2003-03-14 14:17       ` Guido Kollerie
2003-03-14 14:52 ` Fred Yankowski
2003-03-14 17:24 ` Brian Hurt [this message]
2003-03-16  0:44 isaac gouy
     [not found] <20030318093223.I30420@latour.inria.fr>
2003-03-18  9:47 ` Sergey Goldgaber

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=Pine.LNX.4.33.0303141022400.2164-100000@eagle.ancor.com \
    --to=brian.hurt@qlogic.com \
    --cc=caml-list@inria.fr \
    --cc=graham_guttocks@yahoo.co.nz \
    --cc=sgoldgaber@yahoo.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).