[IPOL discuss] Best Practices for Scientific Computing

[Pascal Getreuer]

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