Euh. Le fait est que l'utilisation de FORTRAN tient à plusieurs choses, mais 3 retiennent particulièrement mon attention :
1/ Beaucoup des bibliothèques d'analyse numérique ont leur API en FORTRAN [1], ce qui force le programmeur/utilisateur à comprendre un minimum comment fonctionne ce langage (et dans le cas de pas mal de numériciens et physiciens, ils ont carrément appris la programmation avec ce langage, car il permet certaines constructions très pratiques qui n'existent pas nativement en C, comme par exemple les instructions vectorielles « natives »).
2/ En F77, comme il n'y a pas de pointeur, il n'y a aucun risque d'aliasing, c'est-à-dire de pointeurs différents dont les zones mémoires pointées se recouvriraient. C'est une propriété extrêmement importante en ce qui concerne les transformations optimisantes qu'un compilateur peut appliquer sur un code.
Avec FORTRAN 90 et ses successeurs, il est toujours possible de signaler qu'il n'y a pas de recouvrement de zones mémoires (tout comme en C avec certains compilateurs d'ailleurs), mais là ça devient la responsabilité du programmeur de s'en assurer a priori.
Comme je l'ai dit précédemment, on a aussi la présence d'instructions « vectorielles », qui permettent d'effectuer une même opération entre deux tableaux, de façon transparente, et qui simplifie du coup énormément l'écriture de programmes.
3/ À cause de 1/ et 2/, le FORTRAN se prête déjà bien à tout ce qui est analyse numérique, mais tout ça, on pourrait certainement le dire avec Haskell ou LISP, en effet. Ce qui différencie FORTRAN du reste des langages, c'est qu'en plus, il est, tout comme le C, proche de la machine, ce qui est extrêmement important.
Enfin, une petite remarque : FORTRAN est lui aussi « issu des maths ». :-)
[1] Ce qui est gênant, car il m'arrive de voir parfois des implémentations en f77 qui sont sémantiquement correctes, mais à des années lumières de l'optimisation souhaitée pour les architectures actuelles.
[^] # Re: Le fortran
Posté par lasher . En réponse au journal Qu'est-ce qu'un langage sécurisé ?. Évalué à 3.
1/ Beaucoup des bibliothèques d'analyse numérique ont leur API en FORTRAN [1], ce qui force le programmeur/utilisateur à comprendre un minimum comment fonctionne ce langage (et dans le cas de pas mal de numériciens et physiciens, ils ont carrément appris la programmation avec ce langage, car il permet certaines constructions très pratiques qui n'existent pas nativement en C, comme par exemple les instructions vectorielles « natives »).
2/ En F77, comme il n'y a pas de pointeur, il n'y a aucun risque d'aliasing, c'est-à-dire de pointeurs différents dont les zones mémoires pointées se recouvriraient. C'est une propriété extrêmement importante en ce qui concerne les transformations optimisantes qu'un compilateur peut appliquer sur un code.
Avec FORTRAN 90 et ses successeurs, il est toujours possible de signaler qu'il n'y a pas de recouvrement de zones mémoires (tout comme en C avec certains compilateurs d'ailleurs), mais là ça devient la responsabilité du programmeur de s'en assurer a priori.
Comme je l'ai dit précédemment, on a aussi la présence d'instructions « vectorielles », qui permettent d'effectuer une même opération entre deux tableaux, de façon transparente, et qui simplifie du coup énormément l'écriture de programmes.
3/ À cause de 1/ et 2/, le FORTRAN se prête déjà bien à tout ce qui est analyse numérique, mais tout ça, on pourrait certainement le dire avec Haskell ou LISP, en effet. Ce qui différencie FORTRAN du reste des langages, c'est qu'en plus, il est, tout comme le C, proche de la machine, ce qui est extrêmement important.
Enfin, une petite remarque : FORTRAN est lui aussi « issu des maths ». :-)
[1] Ce qui est gênant, car il m'arrive de voir parfois des implémentations en f77 qui sont sémantiquement correctes, mais à des années lumières de l'optimisation souhaitée pour les architectures actuelles.