Subj : Re: Compiler and an interpreter
To   : comp.programming
From : Gerry Quinn
Date : Thu Aug 04 2005 11:04 am

In article <42f0c6cb$0$91528$ed2e19e4@ptn-nntp-reader04.plus.net>, 
usenet@jdh30.plus.com says...
> Gerry Quinn wrote:

> >> Do you honestly think the 13 lines of C++ are "just as easy" as the 1
> >> line of OCaml? The gap between OCaml and C++ widens as programs get more
> >> complicated.
> > 
> > If you get 13 lines to make a copy of a list of ints with each replaced
> > by the larger of 5 and the value in the original array (which I assume
> > you are doing), you must be including curly brackets and various
> > standard includes.
> 
> Those are necessary.

But they will not increase as the problem gets more complicated.

> > The guts of it might look something like:
> > 
> > list < int > copyList;
> > for ( list< int >::iterator it = origList.begin();
> > it != origList.end(); it++ )
> > {
> > copyList.push_back( max( *it, 5 ) );
> > }
> 
> Those 4-lines are the equivalent of "List.map (max 5)", except that the
> OCaml is more general and can be reused.

Either takes seconds to write.  

> > Or are you worried about the definition of the specific list?  That can
> > often be a little clumsy in C++.  But it's hardly much of a reason to
> > choose between languages.
> 
> It is just another reason not to use language like C++.
> 
> > (Nor, indeed, is verbosity. Comprehensibility is most important.)
> 
> Are you going to say that your 4 lines of C++ are more comprehensible than
> the 16 characters of OCaml?

To many here, they will be.  I certainly had to guess from context what 
you were trying to do.  There is a certain vagueness attached as you 
introduced what seems to be a specific spelled-out list (why not a more 
efficient array, since elsewhere you talk about efficiency?) and then 
apparently modified it, which seems futile.  I asume you wanted both 
the original and a copy but that's just a guess.

> > If indeed it is 100x faster, it is because you have written unidiomatic
> > and slow C++, using libraries that are not designed for efficiency.
> 
> The STL is designed for efficiency and my code is a simple translation of
> the maths (exactly equivalent to the OCaml). The C++ implementation can be
> optimised, of course, but not without intimate knowledge of the
> implementation of set theoretic operations in the STL. Making the
> optimisations takes quite a bit of time and effort. Oh, and the OCaml
> hasn't been optimised either...

I have doubts whether set theoretic operations in STL are designed, or 
at least implemented, for efficiency.  Certainly if I wanted to write 
an efficient program in the sphere referred to, I would carefully 
consider my choice of data structures.  

In any case, C++ is a general purpose language, not one designed for 
the translation of mathematical functions.  Indeed, the tiny fraction 
of problems that consist largely of translating mathematical equations 
into programs likely constitutes a large part of the useful domain of 
functional languages.  

> > I don't believe your benchmarks are valid.
> 
> These aren't benchmarks, they are real programs.

You present them as if they are benchmarks, IMO.

> > I do accept that for the small subset of programming tasks that equate
> > to implementing complex mathematical formulae, implementations that use
> > functional languages will indeed tend to be more compact.  For what
> > that is worth.
> 
> That wasn't a "complex mathematical" formula. It was just a few set unions
> and differences. For really complicate formulae, OCaml will be relatively
> much better.

It's complex by comparison with most of the formulae used in the vast 
bulk of computer programming.

- Gerry Quinn

.