[SciPy-user] python (against java) advocacy for scientific projects

[Matthieu Brucher]

>> Code maintainability works by using clearly defined idioms.
>
> That's really only part of the story. Code maintainability also
> requires the idioms to be well shared and understood by the community
> - which C++ makes really hard to ensure because it is such a complex
> beast. C++ is unmaintainable without a strong set of coding rules,
> which only really works in companies, or when you have an already
> strong framework (in open source, it is quite striking that C++ is
> seldom used, except for complex GUI programs).
>
> I have no reason to doubt your experience that template leads to
> maintainable code - but it is exactly the contrary in my experience,
> and often for code which is supposed to be state of the art (boost).

It leads to maintainable code. It's as for C and Fortran, as for any
language, there must be rules (the higher-level, the more the rules).
There may be more rules than for C and Fortran 90, but both of them
can lead to horrible code. And in the research domain, it's more
horrible than good code.

>> First, Fortran, as I pointed out above, is generally worthless for a lot of
>> computation-intensive problems that don't map to its native data types.
>>
>> Second, Fortran is not magic; it simply uses optimized libraries underneath
>> and the speed of Fortran compiled code depends upon the libraries
>
> Part of the fortran speed comes from the fact that fortran does not
> have pointer.

You're wrong. Pointers are there since the begining. It's Fortran
nasis. Fortran 77 code is full of pointers when using dynamic
allocation. Fortran is simpler than C and C++, but mainly they do not
state the same things, leading to different optimization strategies.
For instance, Fortran forbids arguments aliases, C and C++ allow them.
This enables Fortran to achieve more optimizations.

>> Third, computation speed now on CotS processors depends more on cache & memory
>> access optimization than anything else, which compilers can do with C/C++ just
>> as well as with Fortran;
>
> No, they can't. At least in standard C++, you can't provide enough
> informations about pointers. But even then, it is often only 2 or 3
> times slower - which rarely matters for scientific programming, except
> for the biggest simulations. That's something that many C++ developers
> don't seem to understand for some reason; I remember that one eigen
> developer asked me once whether I would prefer coding in 3 days
> something which runs in 3 hours or running in 3 days something which
> took 3 hours to program - we both had an obvious answer to this
> question, and you can guess it was not the same for both of us.

Fortran can optimize better than C++ only in some circumstances.
Usually, it can't.

>> You could object that writing
>> such a C++ library is difficult, but the point is that Eigen or MTL needs to
>> be written only once (just as you would write only once the Fortran compiler
>> where this knowledge is embedded for Fortran).
>
> But the point is that it is difficult for no reason but a dreadful
> syntax. Something like eigen could be done in a higher level language.
> To everyone his own interet, I guess, but I don't understand the joy
> of spending time coding and debugging template code. It is just awful
> - the compiler often cannot tell you even the line which has a syntax
> error.

It's worse for C or Fortran macros.
>From my point of view, template errors can not that hard to debug.

> Something like fftw, wich a code generator written in a high level
> language is a much better example of meta programming IMHO. It is
> readable, flexible, and portable, at least in comparison to anything
> C++ has to offer today.

I don't think so. You get the generated code, and you have to find out
what generated the code that didn't compile. It's like for C++
templates: if you don't know the language, you can't understand. And
you need 2 languages. With C++, it's only one.

Matthieu
-- 
Information System Engineer, Ph.D.
Website: http://matthieu-brucher.developpez.com/
Blogs: http://matt.eifelle.com and http://blog.developpez.com/?blog=92
LinkedIn: http://www.linkedin.com/in/matthieubrucher