Perl a un moment été très à la mode pour la bio-informatique, et plus précisément pour le recoupement de chaînes d'ADN (normal, vu que les séquences sont représentées par des lettres, et que Perl est quand même 'achement utilisé dans le cadre de pattern matching ...).
Concernant le calcul scientifique, tous les codes que j'ai vus passer depuis bientôt 4 ans sont écrits principalement dans 3 langages : Fortran, C, et C++. Avec parfois un peu d'assembleur pour faire bonne mesure (mais comme la plupart du temps il s'agit de programmes écrits par des physiciens, l'ASM quand je le vois, c'est généralement que je l'y ai mis).
Je ne dis pas que scheme/lisp/etc. ne sont pas faits pour ça, mais euh. Un peu quand même en fait. Plus exactement : faire un soft de CFD (Computational Fluid Dynamics) nécessite d'utiliser des bibliothèques/fonctions d'algèbre linéaire dense et creux. Jusque là, pas de problème, on peut utiliser n'importe quel langage. Mais quand on parle de logiciel de calcul intensif, le moindre cycle compte (au moins pour les fonctions les plus appelées), et là on commence à voir poindre pas mal de soucis, pour la plupart liés à l'architecture. De ce côté, Fortran et C(++) se débrouillent mieux bêtement parce qu'ils sont plus « bêtes » que LISP/Scheme/OCaml/etc.
[^] # Re: Craintes
Posté par lasher . En réponse au journal La mort d'un troll : GCC supportera les plugins. Évalué à 4.
Concernant le calcul scientifique, tous les codes que j'ai vus passer depuis bientôt 4 ans sont écrits principalement dans 3 langages : Fortran, C, et C++. Avec parfois un peu d'assembleur pour faire bonne mesure (mais comme la plupart du temps il s'agit de programmes écrits par des physiciens, l'ASM quand je le vois, c'est généralement que je l'y ai mis).
Je ne dis pas que scheme/lisp/etc. ne sont pas faits pour ça, mais euh. Un peu quand même en fait. Plus exactement : faire un soft de CFD (Computational Fluid Dynamics) nécessite d'utiliser des bibliothèques/fonctions d'algèbre linéaire dense et creux. Jusque là, pas de problème, on peut utiliser n'importe quel langage. Mais quand on parle de logiciel de calcul intensif, le moindre cycle compte (au moins pour les fonctions les plus appelées), et là on commence à voir poindre pas mal de soucis, pour la plupart liés à l'architecture. De ce côté, Fortran et C(++) se débrouillent mieux bêtement parce qu'ils sont plus « bêtes » que LISP/Scheme/OCaml/etc.