Computing languages

A major issue related to collaborative developments is the selection of the programming language(s) supporting common projects. In the workshop series, language issues have received a lot of attention. Progressively this field of research has drifted from FORTRAN only computing to object-oriented programming (OOP). C++ and, for some applications, Java have become the workhorses of the new physics research computing activity. However, some of the physicists used to contribute strongly to simulation, data analysis or even on-line programming have been lost in this process as the learning curve is much longer than for FORTRAN. This is a typical example of the societal changes mentioned in the previous section.

The computing technology is becoming so heavy that, like mechanical construction already two decades ago, it is now becoming a ``chasse gard\'ee'', a property, sometimes unwantedly, of computing experts. This may prove to be inefficient in the long term. Any physicist (accelerator expert, experimentalist, theorist) should be able to implement his/her own ideas or conceptual work into a practical code to be used by the rest of the community. I do not believe that outsourcing code development will benefit our community in the end.

In the meantime FORTRAN has evolved from FORTRAN 77, to 90, 95 and 2003. This last standardization has been designed to produce an advanced OO language still retaining its numerical computation performance and capability (quadruple precision for some compiler), highly parallelizable code and optimized numerical libraries. In addition, it has a quite efficient C/C++ interface.

Without embarking on a ``religious war'', one should re-examine the language issue in the light of its social acceptance aspect, probably in the framework of a mixed language environment. Also related to this discussion are the benefits and trade-offs of compiled and interpreted languages. Interpreted languages, being ``interactive", are easier to learn and to use than compiled languages, but lack execution efficiency and rapidity. The more technical issue is what are the benefits to use interpreters built on genuine compiled languages like Cint/Root or Ch for C++ instead of compiled version of interpreter-born languages like Python or Ruby.

• FORTRAN 95, 2003 - Is there still a place for FORTRAN in Physics Research
• Interpreted/Compiler Languages - Cint, Ch, or Python and Ruby