From: Jon Harrop <jon@jdh30.plus.com>
To: caml-list@inria.fr
Subject: Re: [Caml-list] C++ STL and template features compared with OCaml parametric polymorphism and OO features
Date: Sun, 26 Sep 2004 14:05:37 +0100 [thread overview]
Message-ID: <200409261405.37558.jon@jdh30.plus.com> (raw)
In-Reply-To: <7f8e92aa04092522313d47820d@mail.gmail.com>
On Sunday 26 September 2004 06:31, Radu Grigore wrote:
> The resulting C++ code is still uglyer than its OCaml counterpart. And
> longer. But you should notice that the same accumulate function is
> used for three different containers, while in OCaml you use one
> function for each container type.
My "sum" function was used for all container types. Indeed, that was the
point... :-)
If you don't want to supply the container-specific fold at compile-time (e.g.
with "sum List.fold_left ...") then you can use some form of RTTI, most
obviously objects:
let sum c = c#fold_left ( +. ) 0. c
But, essentially, this is a problem of factoring code. We wish to factor the
commonality of operations over different types of container. Iterators are
only one way to do this and this approach is only suitable in the absence of
HOFs (IMHO) and in the presence of imperative style. If you have HOFs, you
just write my "sum" function and get on with something more interesting.
> OTOH, something that is maybe less
> obvious in the code above, I do use conainer specific functions in
> C++: namely begin and end.
Also, note that the C++ version uses "accumulate" which is effectively
equivalent to "folding with addition". In OCaml, you can fold using any
function you want, or write a higher-order function which folds over a given
function. This is possible but, IMHO, not practicable in C++.
> So, in short: In OCaml you don't have iterators so the fold method is
> container specific. In C++ you have iterators that allow a
> container-independent "fold-like" function to be implemented. The C++
> program is more verbose.
My example is also borderline. Virtually anything more complicated that this
will widen the gap between C++ and OCaml. Consider computing the variance of
a given container of integers using rational arithmetic, or computing the
"n"th nearest neighbours in a graph, or writing a function minimisation
algorithm, the maximum entropy method...
> Using C++'s <functional> header (or Boost.Lambda for that matter) is
> sure to give you a headache after programming a bit in a functional
> language like OCaml. But the same can be said about writting
> imperative code in OCaml.
I'd contest that. I use mutables for things like testing that some operation
was done at least once by an otherwise functional function. I haven't had any
headaches...
> I have recently compared two implementations of the same small program
> in C++ and OCaml, both written by me. The OCaml one was 45% the size
> of the C++ one (byte count). After compression (with bzip2) it was
> 67%. And it was kind of imperative job so C++ should have been in
> advantage there. And I know C++ much better than OCaml, so this should
> have been another advantage..
I'm finding that OCaml code is much more concise than that. My
imperative-style vector graphics engine in about 1/4 the size than the C++
version and includes much more functionality. My other work simply cannot
feasibly be written in C/C++ due to the incidental complexity of lexing,
parsing and interpreting in such languages.
Also, for any >1 month programming tasks, my OCaml code is _always_ faster
than my C++ equivalents were.
Cheers,
Jon.
-------------------
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
next prev parent reply other threads:[~2004-09-26 13:10 UTC|newest]
Thread overview: 42+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-09-25 21:12 Vasili Galchin
2004-09-25 21:38 ` Nicolas Cannasse
2004-09-25 22:15 ` Vasili Galchin
2004-09-25 22:52 ` Vasili Galchin
2004-09-26 1:34 ` Jon Harrop
2004-09-26 5:31 ` Radu Grigore
2004-09-26 9:47 ` sejourne_kevin
2004-09-26 13:05 ` Jon Harrop [this message]
2004-09-26 14:36 ` skaller
2004-09-26 15:08 ` sejourne_kevin
2004-09-26 15:27 ` skaller
2004-09-26 18:51 ` Jon Harrop
2004-09-26 20:14 ` Radu Grigore
2004-09-27 1:59 ` Jon Harrop
2004-09-27 4:48 ` skaller
2004-09-27 9:40 ` Jacques GARRIGUE
2004-09-27 10:50 ` Radu Grigore
2004-09-27 12:14 ` skaller
2004-09-27 13:11 ` Jon Harrop
2004-09-27 13:31 ` Radu Grigore
2004-09-27 16:54 ` Jon Harrop
2004-09-29 18:59 ` Radu Grigore
2004-09-27 13:32 ` Radu Grigore
2004-09-27 14:04 ` Brian Hurt
2004-09-27 14:58 ` skaller
2004-09-27 15:30 ` Brian Hurt
2004-09-27 16:38 ` skaller
2004-09-27 17:01 ` Brian Hurt
2004-09-28 1:21 ` skaller
2004-09-27 16:41 ` brogoff
2004-09-28 0:26 ` skaller
2004-09-29 15:32 ` Florian Hars
2004-09-29 16:49 ` [Caml-list] Factoring HOFs [was Re: C++ STL...] Jon Harrop
2004-09-30 9:19 ` Radu Grigore
2004-09-30 10:13 ` Keith Wansbrough
2004-09-30 10:31 ` Keith Wansbrough
2004-09-30 13:21 ` skaller
2004-09-30 23:17 ` [Caml-list] Factoring HOFs Jacques Garrigue
2004-10-01 8:46 ` Keith Wansbrough
2004-10-01 17:35 ` brogoff
2004-09-26 20:43 ` [Caml-list] C++ STL and template features compared with OCaml parametric polymorphism and OO features skaller
2004-09-26 14:19 ` skaller
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=200409261405.37558.jon@jdh30.plus.com \
--to=jon@jdh30.plus.com \
--cc=caml-list@inria.fr \
/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