Quelle version de Fortran utilisez-vous ?

Fortran est l'un des plus vieux langages de programmation. Apparu en 1957, son objectif était principalement de faciliter les simulations numériques sur les ordinateurs alors naissant : son nom fut l'acronyme de formula translator. À travers les âges, il a su évoluer tout en gardant la compatibilité avec le code existant — maintenant à travers presque soixante ans.

La quantité de code existant et son adaptation au calcul scientifique font que ce langage reste aujourd'hui encore très utilisé dans certains domaines. Il n'empêche que le code écrit actuellement ne l'est plus du tout comme aux débuts du langage (et de l'informatique, au passage) : le langage a évolué, tout comme les possibilités de l'informatique en général.

La principale révolution eut lieu entre les versions 77 et 90, avec l'abandon du format fixe : la position des caractères sur une ligne n'a plus d'importance ; également, les identificateurs ne sont plus limités à six caractères ! La version 2003 a apporté la programmation orientée objet. Les diverses versions intermédiaires et ultérieures ont apporté des changements moins fondamentaux, mais tout aussi importants, notamment pour le calcul scientifique et l'optimisation du code.

La dernière version, Fortran 2008, n'est pas toujours complètement implémentée par les compilateurs : GNU Fortran n'implémente que partiellement Fortran 2003 et 2008, PathScale EKOPath complètement, Intel Fortran une bonne partie de Fortran 2008 et quelques extensions de Fortran 2015, la nouvelle version de la norme (dont la publication est prévue en 2018).

:fleche: Quelle version de Fortran utilisez-vous actuellement ?
:fleche: Quel facteur limite l'utilisation de versions plus récentes : un manque d'intérêt pour les nouvelles fonctionnalités ou une compatibilité insuffisante de la part des compilateurs ?

J'utilise du Fortran 95, pour la simplicité de sa syntaxe et la déallocation automatique des tableaux dynamiques.

Je n'utilise pas FORTRAN, mais j'ai tout de même une question : est-ce que la POO a vraiment un intérêt en FORTRAN ? (et en COBOL... vu que celui-ci j'en ai un peu tapé)

Citation:

---

Envoyé par Metalman

Je n'utilise pas FORTRAN, mais j'ai tout de même une question : est-ce que la POO a vraiment un intérêt en FORTRAN ? (et en COBOL... vu que celui-ci j'en ai un peu tapé)

---

Suffisamment pour rédiger des livres sur le sujet : http://dl.acm.org/citation.cfm?id=2018862. L'utilité est, comme ailleurs, de structurer son code d'une manière facile à comprendre. Pourquoi faire une ségrégation du code scientifique ?

A titre personnel, je n'ai pas besoin de faire de l'objet puisque ce ne sont que de petits codes persos pour lesquels penser fonctionnel est plus simple. Je dirais que ça dépend du contexte dans lequel tu veux déployer ton code.

Citation:

---

Envoyé par dourouc05

Suffisamment pour rédiger des livres sur le sujet : http://dl.acm.org/citation.cfm?id=2018862. L'utilité est, comme ailleurs, de structurer son code d'une manière facile à comprendre. Pourquoi faire une ségrégation du code scientifique ?

---

Rédiger des livres n'est pas vraiment une preuve... beaucoup d'auto-biographies nous le démontrent :P

Mais bref, je voulais un exemple concret (et/ou une explication plus complète).
J'ai toujours été ultra-sceptique quant à la POO.
Sur certains langages construits dans des paradigmes/époques très différent.e.s, je ne comprends pas l'utilité d'ajouter la couche objet.

Citation:

---

Envoyé par Metalman

Sur certains langages construits dans des paradigmes/époques très différent.e.s, je ne comprends pas l'utilité d'ajouter la couche objet.

---

Sceptique a la POO ?!!:weird:

Citation:

---

Envoyé par Metalman

je voulais un exemple concret (et/ou une explication plus complète).

---

Un exemple : un code SPH. http://orbi.ulg.ac.be/handle/2268/156166 (voir la section 4.2 pour les détails de l'approche orientée objet, encore un poil dans la conclusion). Là, l'avantage est d'avoir un code structuré et plus facile à comprendre pour des extérieurs, qui peuvent alors adapter le code à leurs besoins. Cependant, la notion de "didactique" s'applique à l'utilisation du code, selon l'auteur — il n'en vante pas les mérites pour ceux qui plongent directement dans le code.

http://dl.acm.org/citation.cfm?id=16...TOKEN=90447581 devrait expliquer (enfin, c'est dit dans le résumé) comment exploiter l'orienté objet pour "gérer la complexité", notamment en séparant clairement chaque modèle physique et la logique qui les couple.

À titre personnel, il m'est beaucoup plus facile d'écrire un code orienté objet — même sans toutes les simplifications syntaxiques généralement offertes par ces langages — quand il devient relativement imposant, c'est-à-dire au moins dans le millier de lignes.

Citation:

---

Envoyé par Metalman

mais j'ai tout de même une question : est-ce que la POO a vraiment un intérêt en [...] COBOL...

---

La POO a peut-être un intérêt en terme de structuration d'un projet... mais pour avoir travaillé dans une banque où l'on fait du COBOL je peux t'assurer que personne ne fait de la POO avec. Ce qui serait drôle ce serait de créer tout plein de projets stratégiques en COBOL orienté objet pour que plus personne ne puisse avoir la main dessus, la banque va s'écrouler :haha:

Je regarderai les liens, promis. :)

Mais je suis effectivement dans le cas de Gugelhupf : j'ai un peu trainé dans les banques, et la POO en COBOL là-dedans... ça n'a aucun intérêt "à cause" du paradigme mainframe/zOS et des batchs (on reste aligné sur les colonnes, et c'est tout : les structures/enregistrements suffisent à gérer cela, pas besoin d'héritage).
Avant cela j'étais sur du C, et je n'ai "jamais" accroché à la POO malgré beaucoup de tentatives scolaires et personnelles (dév en groupe de JV).

Bref, c'est pour cela que je voulais un exemple concret pour le cas du FORTRAN, qui est plus ou moins de la même génération que le COBOL, mais dont l'environnement a évolué très différemment dans le temps (malgré l'origine commune pour la plateforme mainframe).

J'ai développé une application Fortran pour faire des évaluations d'avantages sociaux. Le code est en Fortran 95 (donc pas POO), mais la structure du code est très près de la POO : Chaque type de donnée est dans son module propre, avec les méthodes associées, et des interfaces faisant que les méthodes ont des noms génériques (ex: Calc(), IndexOf(), ...). Le tout évidemment sans héritage, bien que des types de base aient été membres de type plus évolués.

Le résultat final est une application constituée de nœuds et très orientée sur les données, et non une application procédurale.

Quelle version de Fortran utilisez-vous actuellement ?

Fortran 2003

Quel facteur limite l'utilisation de versions plus récentes : un manque d'intérêt pour les nouvelles fonctionnalités ou une compatibilité insuffisante de la part des compilateurs ?

Manque de projet ! Depuis quelques années je fais beaucoup plus d'entretien que de développement.

Un petit commentaire sur les version 2003 et 2008 : J'ai lu sur un forum (Intel ou comp.lang.fortran) que la demande est plus forte pour Fortran 2008 (coarray) que pour Fortran 2003 (POO).

Salut à tous
j'utilise actuellement depuis 2004 la version Microsoft Fortran 4 pour de projets scientifiques n'ayant pas de programmation objet / c'est un langage simple qui a fonctionné avec windows 95,98,2000,XP,vista, et windows 7 /
j'essaie d'apprendre le pascal,le c++,le delphi , pour les programmations scientifiques et objet / je ne trouve pas encore de projets pour les inclure
En definitive avec meme le fortran 2003 et plus on peut peut etre aller loin
Merci de m'ecouter

Bonjour à tous.
Programmeur depuis un peu plus que 54 ans, je travaille toujours sur des problèmes mathématiques et physiques, comme, par exemple la simulation du brassage électromagnétique de métaux liquides. Pour cela, j'utilise toujours Fortran 77, ce qui fonctionne très bien. Alors, je ne vois pas à quoi il servirait de changer.
Jean-Marc Blanc