Quel langage fonctionnel choisir ? Caml, Lisp ou Scheme ?

**gorgonite** · 22/04/2007, 22h02

Il faut toutefois poser un bémol à ce que tu affirmes (qui comme toujours est un peu excessif, car trop passionné

). Une utilisation correcte de la programmation fonctionnelle dans un projet industriel peut se révéler plus couteuse en raison du niveau de formation nécessaire pour avoir des personnes compétentes. Le paradigme fonctionnel n'est pas trivial, et le codage d'un simple projet oblige à effectuer une analyse assez poussée... et une personne devant reprendre le code devra tenter de comprendre, et se remettre dans la logique, de ses prédecesseurs : plus on augmente en abstraction, plus ça demande d'effort pour comprendre ce qu'il se passe, bien que le code soit plus court
(un webmaster n'a pas besoin d'etre docteur es info pour maintenir un site, alors qu'une personne voulant effectuer un prototype d'un projet complexe en langage fonctionnel ferait mieux de l'être

)

par ailleurs, si l'on doit comparer la taille du code, ce ne sera pas forcemment meilleur dans tous les cas... comment faire plus compact que du perl pour manipuler des fluxs de texte

(même si c'est moche et illisible

)

pour infos (pour ceux qui l'ignoreraient), je n'ai rien contre la programmation fonctionnelle (sinon je suis complètement masochiste

)

**ol9245** · 23/04/2007, 06h32

Envoyé par InOCamlWeTrust

En informatique, et parmis la faune des informaticiens, on peut faire deux catégories : ceux qui font de l'informatique parce que c'est leur boulot, et ceux qui en font parce que c'est leur passion.

Cette distinction m'étonne. Beaucoup de gens aiment passionément ce qu'ils font, même si c'est leur boulot.

Je comprends bien ce que tu dis à propos de MATLAB : ... pratique des fois, mais dont je ne suis absolument pas fan

On est sur la meme longueur d'onde alors, meme si on le dit avec des mots differents.

L'objet de ce thread est avant tout le choix d'un bon langage fonctionnel, adapté à l'utilisation que l'on veut en faire.

C'est bien ça. Déslé d'avoir un peu élargi au choix d'un langage en général. C'était juste une manière de ne pas poser le fonctionnel en religion alors que le choix d'un langage répond a de multiples impératifs qui imho ne laisse que peu de place au choix de principe.

Concernant ta remarque sur les langages de programmation et l'industrie, elle ne montre qu'une chose : l'échec ...

Tu y vas fort quand même. Mais je te rejoins sur un constat maintes et maintes fois refait : le code informatique est le produit industriel le moins normé et le moins fiable qui existe. La seule définition d'une norme de fiabilité pour du code informatique est encore à l'état d'objectif de recherhe pour les labos ! Le public est forcé de suivre. Un bouton ne marche pas sur ton mixer, tu te fais rembourser. Un bouton ne marche pas sur windows : tu vas sur les forums pour apprendre à vivre avec.

c'est bien parce que les outils (ici les langages de programmation) sont de mauvaise conception.

Le problème est plus profond. En 2002 je bossais dans un labo US et j'ai pu faire venir pendant 15 jours un collègue électronicien pour fabriquer un nouvel instrument de mesure qu'on a d'ailleurs breveté par la suite. En gros, il fait l'électronique et je fais le soft qui attaque son jouet, récupère les données brutes, fait une modélisation inverse en temps réel et crache les paramètres. On bosse ensemble 12h/jours. On se connait bien et on connait chacun nos outils comme notre poche. Ce qui m'a le plus étonné dans cette expérience, c'est qu'à chaque étape ou il fallait réunir ce qu'il avait fait en hard avec ce que j'avais fait en soft, il avait toujours fini avant moi.
Ecrire du soft est une tâche intrinsèquement complexe.

La programmation tout objet implique une verbosité déconcertante ...

Oui, c'est ce qui ressort aussi de mes conversations avec un chef de projets qui fait l'informatique de la bourse de Paris. Trop de code = maintenance impossible. le VC++ n'est même plus du C tellement il y a de code généré automatiquement par l'environnement. Ce Et ce code n'est pas porté vers le haut. (je ne peux plus re compiler mes applis VC++ d'il y a 3 ans !!!!!)

En fait, prendre l'industrie comme exemple est en soi une mauvaise démarche, à mon goût, car les cas de mauvaise programmation et de programmes bidon, mal foutus y sont légion.

C'est un exeple intéressant au contraire. Idéalement, un code devrait pouvoir être écrit par des "petites mains" à niveau de formation modeste, pilotées par un chef de projet. En fait, on constate que même des très grosses applis (Windows server par exemple) sont éccrite par un seul homme. C'est le même problème que pour al normalisation que je citais plus haut. La quantité d'information contenue dans un morceau de sucre c'est 10 lignes. Avec ces 10 lignes, non seulement tu normes ton morceau de sucre, mais tu le fais fabriquer par quequ'un d'autre. La quantité d'information contenue dans un code informatique, c'est le code informatique lui-même. Pour le décrire, il faut l'écrire. C'est en ce sens que les problèmes de fiabilité, de maintenance, etc, bref tout ce qui a trait à la normalisation au sens large est difficile en informatique.
Proposer un nouveau langage, fonctionnel ou non, pour concentrer cette quantité d'information en un plus petit nombre de lignes, c'est un moyen de gérer le problème, pas de le résoudre.
La solution, c'est la hiérarchie. cad une immense bibliothèque de trucs déja cablés et éprouvés. Ces briques n'ont plus besoin de norme. On sait qu'elles marchent. point à la ligne. FORTRAN, que tu cites plusieurs fois à juste titre, a permis ça et a survécu malgré sa laideur. MATLAB est entrain de faire ça et survivra vraissemblablement malgré sa laideur.

En recherche en informatique, le but est de proposer non seulement des applications qui sont à la pointe, mais aussi de montrer les bonnes et saines méthode de programmation, dans la mesure du possible. Les algorithmes sont compliqués, souvent, et avoir recours à un langage fonctionnel est un très bon choix car il permet une abstraction très élevée.

J'y ai cru. Je n'y crois plus. Je crois que la bonne et saine méthode de programmation est de ne pas programmer

Juste de trouver et d'assembler des briques qui sont éprouvées et qui marchent.

Ainsi, la mode ne peut être un bon argument...

Je ne défend pas cet argument. Il s'impose à nous. C'est tout !

La taille de la communauté ? Hmmmm... je dirais plus sa réactivité et son esprit

Oui, tu as tout à fait raison. C'est le débit d'information qui circule qui compte et non pas ne nombre de personnes en jeu.

Ben voila. C'est sympa cette discussion. Au plaisir de lire ta réaction alors ?

OL

**gorgonite** · 23/04/2007, 10h31

ce n'est pas du tout la place pour ce débat... il va donc falloir ne pas le continuer sur ce thread

**millie** · 23/04/2007, 18h14

J'ai pas exactement tout lu, mais on pourrait ouvrir un thread (à peine trollesque) pour placer cette conversation, je pensais à quelque chose du genre :
- Qu'apportes la programmation fonctionnelle par rapport aux langages impératifs et objets ?

Enfin, si gorgonite, tu as une meilleure idée, fais le moi savoir