Appreciation for the importance of readability (was: Choosing Perl/Python for my particular niche)

[Fred Ma]

Michele Simionato wrote:
> 
> 1. we want to spend at most 5% of our time doing coding and 95% doing
>    science;
> 2. our group is composed by two persons and our code will never be
>    released;
> 3. if a Ph. D. student reach the group and has to study the code, we
>    will explain it to him in person;
> 4. the largest program we will ever write is a thousand lines long;
>    for the rest we will use standard routines and write as little code
>    as possible;
> 5. we don't care at all about fancy graphics: the output will be a list
>    of numbers write on a file and displayed by gnuplot;
> 6. all we care is numerical performance in floating point computations;
>    the logic of the program will be trivial.
> 
> They actually used old fashioned Fortran 77 and I think they made the perfect
> choice given their requirements; they essentially had to do numerical
> integrations and solving differential equations, tasks were Fortran is
> incredibly strong. Other persons I know doing particle Physics and doing a
> good deal of programming (good deal means something like 50% of their time
> spent on programming; spending more than 50% means that you are actually
> a programmer, and scientists don't want to do that) were using a mixture
> of Fortran and C. Here I am referring to people doing numerically
> intensive tasks; I have seen a trend to switch to C++ for large projects,
> since there is a perception than C++ scales better than Fortran. In
> any case, the core routines are still in Fortran and always will be.
> For scripting tasks, scripting languages are used; I know a few
> astronomers who were using Perl to control the telescope movement.
> Many physicists/astronomers use Python too. Specialized languages
> and tools (Mathematica, Maple, Matlab, Octave, Yorick, etc. etc.)
> have their place.


I want to start by emphasizing that I don't disagree with you.
I've spent a great deal of a previous degree in solution
methods for couple PDEs, as well as problem formulations that
come up with PDEs.  I know of the tools that you mentioned.

I would like to point out that many science problem are not
as much numerically based.  Many of them can be regarded still
as "physically" based science.  For example, physical design
phase of digital circuit design relies on optimization
algorithms, albeit applied to a specialized class of problems.
There are genetic algorithms that evolve neural nets for
various applications (many of them physically based).  These
less numerical applications use more abstraction in computational
models, so C++ has a place for these.

Of course, it is arguable that the computation models and
methods are a separate thing from the physical problems
that motivate them.  So it all depends on how each person
interprets "science".

Fred