Re: Introduction to Functional Programming in OCaml at Paris Diderot (MOOC)

On Wed, Aug 17, 2016 at 04:10:43PM -0500, Douglas Lewit [email protected] [ocaml_beginners] wrote:
> I'm replying here to an older message, but what the hell.  Anyhow, the
> course looks great.  I wish it started sooner than September 26th.  By
> "Informatics" I'm assuming they mean "analysis of data" or the combination
> of statistics and computer programming.  Or is there another definition for
> Informatics?
> 
> I'm kind of proud of the following functions that I created while playing
> around with the language.  I was wondering how I could reverse a list
> without resorting to the @ operator.  Well I think I found a way to do it.
> 
> So....  ( Copied from memory, so forgive typos, mistakes, etc. )
> 
> *exception Empty_List of string ;;*
> 
> *(* Here I am borrowing the names of pre-defined functions in Haskell. *)*
> 
> *let rec last = function *
> *                      |[ ] -> raise ( Empty_List "An empty list does not
> have a last element!" )*
> *                      |head :: tail -> if tail = [ ] then head else last
> tail ;;*
> 
> *let rec init = function*
> *                     |[ ] -> raise ( Empty_List "The init function only
> applies to non-empty lists." )*
> *                     |head :: tail -> if tail <> [ ] then head :: init
> tail else [ ] ;;*
> 
> *let rec reverse = function *
> *                             |[ ] -> [ ]*
> *                             |lst -> ( last lst ) :: reverse ( init lst )
> ;;*
> 
> *I'm pretty happy with these functions, especially since the cons operator
> or :: is supposed to be more efficient or faster than the append operator
> or @.*
> 
> Of course I have to wonder why recursing over lists is better than
> iterating over arrays.  In traditional imperative programming all these
> things are done through iteration and array manipulation.  But in Ocaml and
> Haskell these things are done by recursing over lists or linked lists
> rather than arrays.  ( Although I realize that Ocaml does offer the array
> data structure.  I'm not really sure if Haskell has arrays.  I don't know
> that much about Haskell. )  So then this begs the questions: 1) Why is
> recursion superior to iteration?, and 2) Why are lists better than arrays?
> I know I'm playing the Devil's Advocate here, but it might be good to
> reflect on why functional programming is the way to go rather than studying
> a more "traditional" language such as C or C++ or Java.

The traditional languages force you to pay too much attention on the 
details of data representation.  What's more, C and C++ are not 
type-safe.  It is very easy to overwrite random pieces of storage with 
junk and not experience the consequences for a very long time, making 
debugging difficult.

> I also recently
> read some blog post where the author said something like, "We need mutable
> data when modeling phenomena in the real world!"  He was casting some doubt
> on the legitimacy of the practice of allowing only immutable data types in
> a programming language.  He basically said that you have to assign,
> reassign and update variables in order to successfully model real world
> data.  Is that really true?

It is possible to do this functionally.  But it my not be a convenient 
way to model such phenomena.  At some point you are likely to want to 
perform actions on the world, and that is an effect on the world.

> Any thoughts?  I appreciate the feedback.
> Have a wonderful day.

I've found the notation and semantics of functional programming to be 
wonderfully compact and clear for most purposes.

But I'd never be happy with a language that did not have imperative 
features.  It would be like programming with one hand tied behind my 
back.  Figuring out how to get the effect of simple imperative actions 
in a language that has none is a major research project.
 
Which is why I use OCaml, and not Haskell.

As for arrays, they are efficient when you have a fixed-size bunch of 
values of uniform type, and you don't want to do things like 
inserting one in the middle and shoving the others over, adding new 
elements anywhere, and the like, but you do want to index into tham 
more or less at random (Let me see element 83 now.).

Lists are better for for these dynamic patterns of usage if you are 
*not* interested in indexing into them at random.

By the way, the ancient programming language APL had a lot of 
operations that accomplished functional manipulation of arrays.
But it wasn't a functional language by any means.  Its array handling 
was an interesting and elegant functional outpost in an otherwise ugly 
procedural language.

-- hendrik