Subj : Re: Compiler and an interpreter
To   : comp.programming
From : Rob Thorpe
Date : Fri Aug 05 2005 07:10 am

Gerry Quinn wrote:
> In article <1123159636.278503.19720@g43g2000cwa.googlegroups.com>,
> robert.thorpe@antenova.com says...
> > Gerry Quinn wrote:
>
> > > 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.
>
> Given that in either case one could write thousands of LOC in a day if
> this were the bottleneck, I don't think it's a real issue.

This is an example of only a small piece of code though.  For a large
piece of code I would expect the difference in time be fairly similar.
(see Vesa Karvonen's post)

> > 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".
>
> What I wrote is a C++ cliche that will be equally recognisable.

Yes, it is, but it's a rather more general one.  Once you see something
like "for (..) {... pushback}" you know something fairly simple is
being done in a loop.  Reading the stuff in the brackets of the "for"
and you see that it is applied to the whole loop.  Then it's obvious
what it does.  The mapcar idiom above though is slightly more concise
because the programmer knows upon seeing the "mapcar" form that the
entire list is being manipulated.

This is a small advantage in this case, in other cases having more
idioms to hand is useful.

> > 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
>
> My guess is that the second could probably be done, but not the first.
> C++ is designed so you can go as low-level as C to please the hardware,
> so it should be feasible to write a very fast program.  Functional
> languages, on the other hand, are probably hard to beat for conciseness
> in mapping mathematical functions.

Yeah, I'd expect the same.

> > 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.
>
> I doubt that, unless he really hates short functions!

Do you mean the nth_nn function Jon has written.  I would have thought
that to be a medium-sized function.  In C++ code I've had to deal with
in the past most of the functions have been that length or longer.
(And I wished they weren't)

> Maybe we could
> say that writing such functions, even if they are one in a hundred,
> might well take a significant fraction of the programmer's time, if the
> task is math-intensive.

It probably depends on what the program the programmer is maintaining
does.

.