Subj : Re: Compiler and an interpreter
To   : comp.programming
From : Jon Harrop
Date : Wed Aug 03 2005 03:27 pm

Gerry Quinn wrote:
> In article <42efa9d3$0$24029$ed2619ec@ptn-nntp-reader01.plus.net>,
> usenet@jdh30.plus.com says...
>> Gerry Quinn wrote:
>> >> For example, computing the maximum of 5 and each element of a list in
>> >> OCaml:
>> >> 
>> >>   # List.map (max 5) [1;2;3;4;5;6;7;8;9];;
>> >>   - : int list = [5; 5; 5; 5; 5; 6; 7; 8; 9]
>> > 
>> > And using simple iterative methods in C++ it's just as easy.
>> 
>> 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.

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

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

> Of course, using a list as you do in Ocaml would likely be a grossly
> inefficient representation of this data compared to a vector, at least
> on typical PC architecture, since it may get scattered all over memory.
> 
>> For example, here's the OCaml code required to compute the set of
>> "n"th-nearest neighbours in a periodic graph:
> 
> [-]
> 
>> Not only is the OCaml much shorter than the C++, it is also more robust
>> thanks to static type checking, more maintainable thanks to better code
>> reuse and 100x faster thanks to functional programming.
> 
> 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 don't believe your benchmarks are valid.

These aren't benchmarks, they are real programs.

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

-- 
Dr Jon D Harrop, Flying Frog Consultancy
http://www.ffconsultancy.com

.