[IPOL discuss] Best Practices for Scientific Computing

[Pascal Monasse]

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