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

Hendrik,

Thanks for the reply.  Yes, I like that Ocaml is functional but not
exclusively functional.  It's a nice language.  I just wish there were more
books out there to support the language.  There are hundreds of books on C,
C++, Java, Python, Ruby, etc but very little good documentation to support
Ocaml.  ( There's some books out there.  I like the stuff by Whitington.  *Real
World Ocaml* is okay, but some of it is just way over my head at this point
in my development as a programmer. )

Regarding arrays, here's a question.  What do you mean by "random access"?
If an array has 100 elements in it and I want to access the element at
index #83, how is that random access?  What's random about it?  As for
inserting elements into the middle of an array, yes, I can see how that
would be very problematic.  I remember trying that in Java once.  It was a
fun exercise to do, but does require some careful planning if you want the
program to work properly.

Thanks for the feedback.  Have a great week!

Best,

Doug.


On Wed, Aug 17, 2016 at 6:17 PM, Hendrik Boom [email protected]
[ocaml_beginners] <[email protected]> wrote:

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