[IPOL discuss] Best Practices for Scientific Computing

[Miguel Colom]

Well, nowadays the terms "high-level" and "low-level" are relative and  
they're redefined with the characteristics of the new languages.

Of course, when C was developed, it was considered a very high-level  
language, because the alternative was to use assembler code. Even  
assembler was considered once high-level compared to coding directly  
with ones and zeros using punched cards!

It's true that it's possible to use compiler flags to check the bounds  
of the arrays, but you have still to deal with memory pointers and  
memory allocation.

A bad pointer allocation in a compiled C/C++ can happen easily and  
errors in the memory allocation are also common (a double free, a bad  
pointer in the free, ...)
Since most operations involve pointers, there's plenty of situations  
in which they can lead to bad behavior, sometimes in a silent and  
difficult to trace way.

Of course, there're compiler flags to check array bounds, like Pascal  
mentioned,  and also to check the memory assignment/freeing/region  
overlapping/etc, such as Valdrind and others.

But, in my opinion, the very existence of these tools means that the  
language is low-level. And even the most simple programs need to use  
pointer arithmetic and memory allocation.

However, I agree that for us in IPOL C/C++ is the best alternative,  
for the reason that have been already discussed.

Best,
Miguel

Quoting Pascal Monasse <monasse at imagine.enpc.fr>:

> Hi all,
>
> I agree totally with Pascal, it is a good summary of the constraints we have
> in the choice of language.
>
> I also think that C++ permits high-level programming, depending on  
> your choice
> of structures. For the most important structure, an array, you can use it as
> in C, with explicit memory allocation and deletion, but you can also use the
> vector class of STL, which has an optional bound checking (though the way to
> enable it is not in the standard):
> - automatic in debug mode under Windows with Visual C++
> - with compiler flag -D_GLIBCXX_DEBUG with gcc
> These options are not on by default, because you always have to choose:
> 1. bound-checking (slow, safe)
> 2. no bound-checking (fast, dangerous)
> Whatever the language, you cannot have fast+safe. It is true that most of the
> time option 2 is chosen, but the programmer *can* choose option 1. In this
> sense, C++ can be used as a high level language.
>
> Best,
> Pascal
>
> On Friday, October 05, 2012 08:12:53 PM Pascal Getreuer wrote:
>> Dear all,
>>
>> > Write code in the highest-level language possible.: Are we doing that?
>>
>> Reading between the lines, Jean-Michel's question highlights a
>> limitation on IPOL.  By requiring C/C++, we prevent authors from
>> choosing the highest-level language for the application (MATLAB,
>> Mathematica, Java, or Python, for example).  We are pretty much making
>> the choice for them, C++ notwithstanding.
>>
>> It would be really awesome if some day IPOL could accept code in more
>> languages.  There are challenges though.
>>
>> Foremost, languages should preferably be well-known, portable, and
>> free.  If a language is not free (MATLAB...) or not portable
>> (Microsoft VBA...), it locks out potential IPOL readers from using it.
>>  And if the language is less well-known, it would be harder to find
>> reviewers.
>>
>> There are also technical considerations.  Languages need to be stable
>> and efficient on the demo servers.  Specific maintenance to individual
>> programs is not possible.  This reminds me of the discussions we have
>> had about libraries :-\.
>>
>> So the answer is "no", we do not live up to the ideal of allowing "the
>> highest-level language possible."  It is still a pretty good balance
>> of the philosophies.  The Software Guidelines advises C/C++ by default
>> and to consider other languages only if they are ISO-standardized---I
>> agree this is the way to go.
>>
>> Best,
>> Pascal
>>
>> On Fri, Oct 5, 2012 at 4:23 PM, Miguel Colom <colom at cmla.ens-cachan.fr>
> wrote:
>> > Quoting Pierre Moulon <pmoulon at gmail.com>:
>> >> And for me C++ is already a High-Level language.
>> >> It offer high level programming option (concepts, traits, C++11:
>> >> functors,
>> >> lambda), but if you want you can go to the deep/dark side (intrinsic,
>> >> pointer arithmetic...).
>> >
>> > Well, for me it's not a high-level language, because:
>> > - The programmer has to deal with the calls of the memory
>> > allocation/freeing and pointers to actual memory zones are returned. -
>> > The references to the objects/data are just pointers that contain actual
>> > memory addresses.
>> >
>> > In my opinion, this is enough to say C/C++ is low-level.
>> >
>> > Think, for example, in the case of declaring an array of 100 positions.
>> > If you try to access position 123, a Python script would say that you're
>> > trying to access a position beyond the bounds of the array. In C/C++ it
>> > would cause a SegFault exception, in case it is detected by the OS. If
>> > the buffer overwrite does not produce a segment violation, it wouldn't be
>> > either detected.
>> >
>> > The majority of the errors in a C/C++ program are caused by trying to
>> > access memory not allocated. This gives an idea of the low-level or how
>> > close the language is to the CPU.
>> >
>> > Indeed, it's not casual that the Linux kernel and device drivers are
>> > written in C, since it's very low-level.
>> >
>> > Best,
>> > Miguel
>> >
>> >
>> > _______________________________________________
>> > discuss mailing list
>> > discuss at list.ipol.im
>> > https://tools.ipol.im/mailman/listinfo/discuss
>>
>> _______________________________________________
>> discuss mailing list
>> discuss at list.ipol.im
>> https://tools.ipol.im/mailman/listinfo/discuss
> --
> Pascal Monasse
> IMAGINE, Ecole des Ponts ParisTech
> Tel: 01 64 15 21 76
> _______________________________________________
> discuss mailing list
> discuss at list.ipol.im
> https://tools.ipol.im/mailman/listinfo/discuss
>