Program Translation - Nov. 14, 2013

[Roy Smith]

In article <xMydnRjrQ45fSBXPnZ2dnUVZ8mGdnZ2d at giganews.com>,
 Henry Law <news at lawshouse.org> wrote:

> On 17/11/13 14:37, E.D.G. wrote:
> > All of my own important programs are written using Perl.  I am starting
> > to run into calculation speed limitations with one of the programs.
> 
> Your Perl code is, er, sub-optimal.  There is absolutely no point in 
> doing benchmarks until you've improved the code.

Having spent many years in science (molecular biology), I disagree with 
this sentiment.

Scientists view computer programs as tools, no different from any other 
piece of lab equipment or instrumentation they use.  When picking a tool 
to use, it's perfectly reasonable to evaluate what performance you can 
get out of that without having to be an expert in its use.  If I'm using 
a spectrophotometer, there may be many things that instrument is capable 
of doing, but as long as I'm getting the data I need from it, it's 
serving my purpose.  My goal is to do science, not to be an expert on 
optics, or electronics, or data processing.

The same goes for programming languages.  Most programs I've seen 
written by scientists are horrible from a computer science point of 
view, but they serve their purpose.  A language which makes is easy for 
a non-(computer)-expert to write decent programs is a good tool.

To get back to the original point, let's say I (as a computer expert) am 
comparing two programming languages, L1 and L2.  If I write a fully 
optimized program in L1 and a piece of crap in L2, then try to say, "L1 
is better than L2", that's a poor comparison.  Until I've optimized my 
L2 code, it is, as Henry says, pointless to try to compare them.

But, for a non-expert, it may be that while L2 is capable of computing a 
solution in less time than L1, it takes a lot of expert knowledge to get 
the L2 program to that state.  For the limited amount of programming 
expertise and time available, L1 may actually be better for this use 
case.