Subj : Re: Compiler and an interpreter
To   : comp.programming
From : Rob Thorpe
Date : Thu Aug 04 2005 06:47 am

Gerry Quinn wrote:
> 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.

Brace lines are a corner case.  The ones that just close braces don't
get any more complex as you write more of them, they're of little
trouble.  The problem though is that in C++ and C they're generally put
on separate lines for clarity, so you still have to read through them
to maintain the code.  Overall, I'd allow say 0.25 of a "normalised
line of code" per brace.

Theres a useful script called clines for C programs, it lists for a
program
# of lines
# of "code" lines
# of comment lines
# of blank lines
# of paren lines
# of preprocessor lines

I estimate complexity to be proportional to:

codes + preprocessors + 0.5 * (blanks + parens + comments)

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

But on a larger scale writing more of the OCaml is quicker.  It may
take you 30 seconds to write the above, but it may take Jon 10 seconds
to write his.  It all adds up.

Also, what Jon has written is something of a cliche.  In lisp you would
write something like:

(mapcar #'(lambda (x) (max x 5)) list)

This improves understanding, because the programmer can recognise this
cliche and recall what it means without having to read all the code.
The mapcar idion above is frequent in lisp.

I'm pretty sure you can do this in C++ anyway, with "transform".

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

I'd agree about that.  There are two reasons:-
1 Because C++ is a more well known language.
2 Because the C++ involves iteration you can see

2. is really a sub-problem of 1, programmers of other langauges are
used iterations they can't see.

1. Is the crux of the problem.  I would use functional languages if any
sizable number of other programmers knew them, but they don't.  So
there are far fewer people able to maintain or improve my code.

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

I have doubts if the STL was designed.
I'm also not sure about "set".

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

Most functional languages have been designed to be general purpose,
they target the same tasks as C++.  OCaml -of which Jon is so fond-
certainly was.

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

For stuff like that shown above, either it's critical and has to be
fast, or it isn't and it doesn't and might as well be as clear as
possible.

So, what would be really interesting to know is:
* Could one write a more concise C++ version, regardless of efficiency
* Could one write a faster C++ version, regardless of conciseness
* Could both be done

It would also be interesting to see a comparison between versions that
have enough commentary in them to be readable.  Most of my code is ~1/2
comments (and even that often isn't enough).

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

It's not that complex, though it's certainly more complex than average.
 Perhaps one function in a twenty a programmer would have to write
would be that complex, I'd guess.

.