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

[David Cournapeau]

On Wed, Jan 21, 2009 at 6:15 AM, Ravi <lists_ravi at lavabit.com> wrote:
> On Tuesday 20 January 2009 13:13:27 David Cournapeau wrote:
>> On Tue, Jan 20, 2009 at 11:27 PM, Ravi <lists_ravi at lavabit.com> wrote:
>> > Really? Try writing just a fixed-point radix-8 FFT
> [snip]
>> The FFT reference is FFTW. It uses neither C++ or fortran. It does not
>> have rounding /clipping strategies that I know of, but is certainly as
>> flexible as you can make in C++.
>
> Please notice that I specifically mentioned *fixed-point* FFTs. The area I
> work in is an intersection of algebraic geometry, signal processing and
> discrete mathematics. FFTW has no idea how to model 13-bit fixed point values,
> and certainly does not handle minimization of error propagation by choice of
> rounding vs. truncation in intermediate steps (rounding does not always lead
> to better error propagation compared to truncation, which is computationally
> much less intensive).
>
>> > 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.
>
> The second part is not really true. Of course C++ is a very young language
> with features that were completely unappreciated in the beginning by its
> target audience: C programmers looking for something more scalable. Well
> understood and shared idioms do not just appear on the scene. A significant
> body of work and experience is required before such idioms percolate down to
> the journeyman programmer. C++ reached that stage only circa 2005. (For a
> simple example, see how much work has been going on in the ipython-dev lists
> regarding asynchronous operations; this is not because asynchronous operations
> are not inherently difficult to understand - just that the standard idioms for
> handling asynchronous events are not yet commonly understood outside of a very
> small community (and even those idioms are still under refinement)).
>
>> 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).
>
> Of course you have coding rules, but you have such rules even in small C
> projects.

Of course, you have some convention, but when you compare PEP 7 or
Linux coding standard for C coding standard and C++ coding standards
for mozilla, google coding standards and co, you see they are order of
magnitude simpler for C than for C++. You could argue that the
projects are much simpler, too :)

>
> I partly agree (and assert that you need to use better compilers, like
> Comeau). I wish it were possible to write DSELs easily in some other language
> (preferably some enhancement of OCaml), but I haven't yet found such a
> language that has sufficient mindshare in my area of work :-(

Yes, this last parameter is almost always the one which matters the
most at the end. Certainly, a big reason for C++ success was that it
could capitalize on C mindshare.

David