Subj : Re: Compiler and an interpreter
To   : comp.programming
From : Gerry Quinn
Date : Fri Aug 05 2005 11:52 am

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.

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

[--]

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

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

- Gerry Quinn

.