Discussion :

[davcha]

A compétence égale, on développe plus rapidement avec une approche impérative/objet ou avec une approche fonctionnelle ?

Je pose cette question plusieurs fois, en fait. Je la pose, au moins deux fois :
- dans l'absolu, en comparant uniquement les différents paradigmes
- en tenant compte de l'existant, c'est à dire des différentes librairies déjà existantes.

Bien entendu, dans les deux cas, le but est d'obtenir un logiciel complet, sécurisé, "bugless" autant que possible, et suffisamment performant pour ne pas être jeté à la poubelle par le client.

[LLB]

J'ai l'impression que dans ton etat
d'esprit j'utilise le C++ par contrainte. Dans le mien c'est le
meilleur choix.

Peux-tu expliquer ce choix alors ?

Meme pour les projets perso j'utilise souvent le C++.

Pareil. Est-ce seulement une question d'habitude, parce que tu connais mieux le C++ ? Sinon, pourquoi utiliser ce langage plutôt qu'un autre, qui soit de plus haut niveau (fonctionnel, ou non) ?

A compétence égale, on développe plus rapidement avec une approche impérative/objet ou avec une approche fonctionnelle ?
- dans l'absolu, en comparant uniquement les différents paradigmes

Quand on compare les langages associés (c'est plus simple de comparer la productivité sur un langage que sur un paradigme), avec du typage statique, on remarque souvent que les langages fonctionnels sont plus concis, plus sûrs. Le gain en productivité me semble clair (j'en ai fait plusieurs fois l'expérience).

- en tenant compte de l'existant, c'est à dire des différentes librairies déjà existantes.

Ça dépend. Là, c'est plus dur à comparer, puisque ça dépend des bibliothèques disponibles et des besoins. En fait, ça n'a plus rien à voir avec le paradigme, mais avec le support dont bénéficient les langages.

Ici, c'est clair que Caml s'en sort moins bien que Java sur certains besoins. Sur d'autres, Caml s'en sort très bien (exemple classique, écrire un interpréteur/compilateur).

Pour ma part, après un an d'utilisation de F#, je n'ai jamais rencontré le moindre problème de bibliothèques. Mes outils peuvent répondre à la majorité de mes besoins : pour faire du web côté serveur, je peux utiliser ASP.NET ; côté client, Silverlight marche plutôt bien ; pour faire un jeu vidéo, j'ai beaucoup de bibliothèques accessibles, dont XNA, et je peux même faire un jeu pour XBox ; pour faire de la compilation, F# s'en sort extraordinairement bien, les bibliothèques pour la génération d'IL étant assez puissantes ; pour la manipulation de fichiers textes, pour l'écriture de scripts, il s'en sort assez bien aussi ; pour tout ce qui touche à l'algo aussi, j'en suis très satisfait ; etc.

Bien entendu, dans les deux cas, le but est d'obtenir un logiciel complet, sécurisé, "bugless" autant que possible, et suffisamment performant pour ne pas être jeté à la poubelle par le client.

C'est justement pour répondre à tous ces besoins que j'ai choisi F#.

Évidemment, on peut trouver quelques cas où F# ne convient pas (bas-niveau, etc.), mais c'est le même problème pour tous les langages.

[souviron34]

La qualité est rarement un gage de réussite en informatique, tant au niveau matériel, que logiciel. Souviron, je ne vais pas t'apprendre ça quand même -_- Les impératifs commerciaux et économiques sont plus important que le reste. Ce n'est pas le cas partout, et peut être que l'industrie dans laquelle tu travailles y échappe si je ne me trompe pas. Mais en général ça reste pathétiquement vrai.

Je ne sais pas où tous vous travaillez, mais de mon côté en 25 ans je n'ai travaillé QUE sur des projets où la qualité était ESSENTIELLE, et même vitale : logiciels critiques avec vies en jeu, ou développement une fois avec durée de vie du logiciel > 10 ou 15 ans..

Donc je ne peux QUE m'inscrire en faux par rapport à ce que vous dîtes. C'est peut-être le fait des développements Web ou Windows, je ne sais pas, mais il faut dire que je n'ai jamais travaillé sur un logiciel se vendant MOINS de 1 à 2 millions... et dans ces cas la qualtié est primordiale.. AVANT les impératifs commerciaux : car si le client est mécontent, on le sent passer...

Maintenant, pour le reste du débat, je m'en retire, car visiblement cela correspond à ce que je disais au début : je suis un vieux crouton, et c'est de la recherche , que ce soit dans le fond ("cela VA aller en s'améliorant", "le manque de bibliothèques" et "les problèmes de compatiibilité), que dans la forme (tout ce qui n'est pas du même avis est rétrograde et hasbeen).

Amusez-vous bien...

[gorgonite]

Maintenant, pour le reste du débat, je m'en retire, car visiblement cela correspond à ce que je disais au début : je suis un vieux crouton, et c'est de la recherche , que ce soit dans le fond ("cela VA aller en s'améliorant", "le manque de bibliothèques" et "les problèmes de compatiibilité), que dans la forme (tout ce qui n'est pas du même avis est rétrograde et hasbeen).

Amusez-vous bien...

nous abandonnes pas...
sinon comment obliger les purs universitaires à nuancer leurs propos

[SpiceGuid]

Je trouve l'exemple extrêmement mal choisi si le but est de défendre le fonctionnel. C'est du code purement impératif, et je ne vois aucune difficulté à donner l'équivalent C (ou y aurait-il une subtilité qui m'a échappé ?).

Comment que je suis grillé, je vais me cacher dans une grotte pour la journée.

[gasche]

A compétence égale,

Je pose cette question plusieurs fois, en fait. Je la pose, au moins deux fois :
- dans l'absolu, en comparant uniquement les différents paradigmes
- en tenant compte de l'existant, c'est à dire des différentes librairies déjà existantes.[/quote]

Le "à compétence égale" coince : en pratique, les bons développeurs dans les langages fonctionnels sont :
- soit des gens ayant fait des études universitaires d'informatique, donc avec genre un Bac+5
- soit des programmeurs non-universitaires très ouverts, ce qui est un sous-ensemble des programmeurs compétents

En gros, la probabilité de trouver un utilisateur de langage fonctionnel chez des Bac+2 d'info est extrêmement faible, et le niveau moyen des programmeurs des langages fonctionnels est très élevé, plus que celui des programmeurs en général (je ne dis pas qu'un Bac+2 orienté pratique est moins compétent qu'un Bac+5 orienté théorique, mais on ne peut pas parler de "compétences égales", même si le Bac+2 est certainement beaucoup plus efficace que le Bac+5 sur certaines choses).

C'est probablement lié à l'histoire "universitaire" des langages en question, mais surtout aussi à mon avis à leur forte facilité d'abstraction : les programmeurs à l'aise avec le fonctionnel sont ceux qui ont une forte faculté d'abstraction, ce qui est aussi corrélé à la compétence.

Enfin, certains concepts de certains langages fonctionnels sont assez difficiles à comprendre (à mon avis, assimiler les monades demande un effort très conséquent). Imaginer que du jour au lendemain *tous* les acteurs de l'informatique pourraient se mettre à coder en Haskell est plus qu'utopique, pour ces raisons de compétence.

Cependant, il ne faut pas oublier que certains langages impératifs/objets demandent, pour être bien utilisés, de grandes compétences, même si la "courbe d'apprentissage" est moins raide. Il me semble très difficile de savoir bien coder en Programmation Orientée Objet, et une grande partie des programmeurs de ces langages ne la maîtrisent pas.

on développe plus rapidement avec une approche impérative/objet ou avec une approche fonctionnelle ?

Cela va évidemment dépendre du problème pour lequel il faut développer un programme.

Dans certains domaines, l'approche fonctionnelle (ainsi que les différents outils, non liés au concept de fonction, mais présents uniquement dans les descendants de ML : typage souvent inféré, polymorphisme paramétrique, types algébriques, filtrages...) est clairement supérieure.
Dans d'autres domaines, c'est moins clair, en tout cas on a moins de preuves.

Cependant, je pense qu'on peut répondre "oui", car la plupart des avantages de ces langages peut être apporté sans devoir forcément modifier *beaucoup* les habitudes de programmation. Un programme OCaml n'est pas tellement éloigné dans sa conception qu'un programme en C, il a juste beaucoup moins de choses à faire en moins (préciser les types de chaque variable/fonction, gérer la mémoire à la main, tout un ramdam pour les gestions d'erreurs, etc...), et pas mal d'outils en plus (la récursivité, des fonctions facile à manipuler, les listes built-in, le filtrage, un typage fiable).

Certaines caractéristiques de certains langages, en particulier l'évaluation paresseuse par défaut et le fait d'être fonctionnel pur (pas du tout d'effet de bord) nécessitent au contraire une remise en question assez profonde de la part du programmeur, et peuvent avoir des coûts non négligeables (en tout cas inexplorés actuellement) dans certains domaines applicatifs. Mais dans l'ensemble, c'est plus du "gagnant-gagnant" qu'autre chose.

- en tenant compte de l'existant, c'est à dire des différentes librairies déjà existantes.

Là, ça va dépendre beaucoup des domaines. En général cependant, les langages fonctionnels souffrent de leur manque d'utilisateurs, et sont donc pas mal en retard au niveau du support des bibliothèques.

C'est un domaine qui est en progrès, avec des choses comme F# ou OCaml-Java par exemple, mais actuellement, langage fonctionnel est synonyme d'une certaine isolation de ce côté là : difficile de trouver un langage fonctionnel qui permette d'utiliser le toolkit Qt, par exemple.
Ceci dit, la réponse à ce niveau là est aussi l'utilisation de différents langages dans un même projet/logiciel : la force des langages fonctionnels se situe souvent dans les parties du programme où "il faut réfléchir"; pour la couche GUI, un langage de script sera sûrement tout aussi efficace, et s'il s'interface avec le langage fonctionnel (je sais que Perl, Python et Ruby s'interfacent bien avec OCaml), on peut très bien les utiliser pour coder ces parties là (et donc utiliser les moultes bibliothèques qu'ils supportent).

et suffisamment performant pour ne pas être jeté à la poubelle par le client.

Tu n'as pas de soucis à te faire de ce côté là. Les langages fonctionnels sont actuellement tout à fait satisfaisants au niveau des performances. Sauf cas particulier (calcul intensif sur architecture exotique, etc...), ils seront tout aussi satisfaisants que tous les autres langages compilés.
Une grande partie des programmeurs utilise des langages beaucoup plus lents (Python, PHP, Ruby...) sans problèmes, pour tous ceux là ça posera encore moins de problèmes.

Enfin, je tiens à signaler qu'OCaml possède un modèle objet très riche (par contre, assez différent de ce qu'on voit d'habitude). Il n'y a pas lieu d'opposer "impératif/objet" et "fonctionnel" : on peut utiliser une organisation objet en fonctionnel (Haskell ne le permet pas, mais a des fonctionnalités qui permettent de récupérer tout de même une grande partie des avantages (et désavantages :p ) de l'approche objet), même si ce n'est souvent pas nécessaire.
On peut même faire de l'objet en fonctionnel pur, et cela peut donner des trucs très jolis (il y a une classe pour faire des "fold" dans camlp4 qui est tout à fait sublime d'utilisation).

[Jean-Marc.Bourguet]

Peux-tu expliquer ce choix alors ?

Dans le cas du boulot, l'existant est un facteur qui suffit à lui tout seul. La nécessité de contrôler la mémoire sont un autre facteur important -- le facteur 1.5 à 2 généralement cité comme overhead des GC est totalement prohibitif: les jobs qui passent en 32 bits ne passeraient plus, ceux qui nécessitent la version 64 bits passeraient en mode swap ou exigerait des clients l'achat de mémoire supplémentaire. Le risque serait également important (les gros projets Lisp et OCaml dont j'ai entendu parler -- entre autres sur lambda-the-ultimate -- sont d'un ordre de grandeur moins grand; et naturellement je me demande la part de fonctionnel et d'impératif dans ces projets, ma propre expérience avec le lisp m'incite à penser que l'impératif y est présent). Cela sans parler des facteurs humains.

Pareil. Est-ce seulement une question d'habitude, parce que tu connais mieux le C++ ? Sinon, pourquoi utiliser ce langage plutôt qu'un autre, qui soit de plus haut niveau (fonctionnel, ou non) ?

Quelles sont caractéristiques pour toi d'un langage de plus haut niveau que le C++? (J'ai du mal à admettre le présupposé de la question qu'il y a des langages d'usage général de plus haut niveau; moi je ne vois guère que des DSL. On peut travailler à bas niveau en C++, on n'est pas obligé.).

L'existant est encore un facteur. Plus faible mais existant. Mes projets perso, l'objectif c'est d'avoir quelque chose au final.

C'est un fait que je connais mieux le C++, mais c'est surtout que je ne connais pas assez les autres et je ne percois toujours pas le gain que j'aurais par rapport à l'investissement (je préfère consacrer le temps que je réserve à l'apprentissage à explorer moins en profondeur d'autres langages qu'à en maîtriser un suffisemment pour y être plus productif qu'en C++) et que j'ai aussi une certaine tendance dans mes projets perso à faire des choses de bas niveau (eh, je continue à écrire de l'assembleur dans certains, ce que je n'ai plus fait de façon professionnelle depuis environ 15 ans).

De mon point de vue, la chose qui peut faire passer l'industrie telle que je la vois (je n'ai certainement pas la prétention de la connaître dans son ensemble) vers les langages fonctionnels, c'est la parallélisation: l'absence d'état partagé y est un atout que certaines entreprises installées pourraient vouloir exploiter. Les autres avantages ne sont vraissemblablement exploitables que par une start-up...

[souviron34]

De mon point de vue, la chose qui peut faire passer l'industrie telle que je la vois (je n'ai certainement pas la prétention de la connaître dans son ensemble) vers les langages fonctionnels, c'est la parallélisation: l'absence d'état partagé y est un atout que certaines entreprises installées pourraient vouloir exploiter. Les autres avantages ne sont vraissemblablement exploitables que par une start-up...

bah MPI est deja utilise depuis longtemps avec des langages que vous nommez imperatifs, et l'integration avec des logiciels existants se passe correctement.

Des exemples que j'ai vu, la compatibilite (meme partielle) du code existant est LE facteur majeur.

MPI s'integre tout a fait bien dans n'importe quel programme en C ou Fortran.

Je suis neanmoins d'accord avec le cas des start-up, mais ca limite quand meme pas mal l'usage, non ?

[Jean-Marc.Bourguet]

quand j'écris une structure de données de ce type :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
type ('a,'b) tree =
 | Node of 'a * ('b,'a) tree
 | Empty

Ou :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
type 'a tree =
  | Op of ('a -> 'a -> 'a) * 'a tree * 'a tree
  | Val of 'a

En général, lorsque je demande à un développeur C/C++/Java/C#, de m'écrire l'équivalent dans son langage, les résultats sont catastrophiques. La clarté en prend un coup, c'est inévitable. Mais très souvent, la sûreté est réduite de façon dramatique. Je ne parle même pas des limitations du langage (qui font que NULL est une valeur acceptée par le compilateur), mais de l'implémentation : beaucoup de développeurs utilisent des bidouilles (genre, on ajoute un booléen dans la structure pour savoir si c'est un noeud ou une feuille), parce que c'est plus simple à implémenter que de le faire "proprement" avec une hiérarchie de classes.

Bizarre, l'équivalent pour moi n'est pas une hiérarchie de classes mais un record avec variants (en Ada ou en Pascal). Donc une struct contenant une union de struct en C ou en C++ -- pas la chose qui s'y exprime de la manière la plus claire (ok, on peut utiliser la règle introduire pour valider l'usage fait par X, donc se réduire à une union de struct ayant les premiers membres en commun). Le problème d'utiliser une hiérarchie de classes comme équivalent est qu'on se retrouve avec l'extensibilité dans l'autre dimension (cfr expression problem). Si on se force à utiliser la version classe, pour changer de dimension, il faut utiliser quelque chose comme le pattern visiteur. Ca peut se justifier, mais pas quand on demande simplement l'équivalent d'une structure de donnée.

En pratique naturellement, dans le premier cas, on a simplement

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
template <typename a, typename b>
struct tree {
   a first;
   tree<b, a>* second;
};

et le cas Empty, c'est le pointeur nul.

[Keihilin]

Je m'intéresse aux langages fonctionnels par pure curiosité; n'ayant pour le moment jamais eu de "besoins" qui m'auraient pousser à abandonner mes outils habituels de POO.

C'est donc en pur néophyte que j'apporte ma contribution au débat en posant une question:

- Ne pensez-vous pas que l'offre de langages fonctionnels est un peu éparpillée et que cela peut constituer un frein à l'adoption du paradigme par l'industrie ?

En effet, pour quelqu'un qui débute, il n'est pas évident de choisir parmi oCaml, Haskell, Anubis, F# et j'en passe. On aimerait pouvoir faire un choix avec des critères tels que productivité, pérennité, performance, choix de bibliothèque, inter-opérabilité...mais je trouve difficile d'avoir une vue d'ensemble permettant de prendre une décision.

Il faudrait peut être que le marché se choisissent une ou deux "stars" (comme Java et .Net dans la catégorie informatique de gestion) afin de convaincre les développeurs qu'investir dans l'apprentissage de ses langages leur ouvrira des portes.

[davcha]

F# profite de l'ensemble des librairies .NET, non ?

Enfin, comme je bosse beaucoup sur .NET, personnellement, c'est vers F# que je me tournerais, naturellement.

[LLB]

Dans le cas du boulot, l'existant est un facteur qui suffit à lui tout seul.

C'est ce que j'appelle un non-choix : il est préférable de garder C++ pour des raisons historiques.

La nécessité de contrôler la mémoire sont un autre facteur important

Ça, c'est une contrainte très forte qui interdit la grande majorité des langages actuels. Le choix est donc très limité quand on a ce genre de contraintes.

Je comprends tout à fait ça, et il est inutile de te proposer un autre langage dans ces conditions. Du coup, le débat fonctionnel / impératif me semble inutile pour ce cas là.

Pour tes projets persos, c'est la même réponse. On ne peut pas discuter du choix de langage, si tu n'as pas réellement ce choix. C'est tout à fait compréhensible de vouloir utiliser les outils avec lesquels on est habitué. C'est ce que je voulais dire par « contrainte » : aucun autre langage que C++ ne pourrait convenir (du coup, inutile de savoir quel langage est meilleur.

Quelles sont caractéristiques pour toi d'un langage de plus haut niveau que le C++? (J'ai du mal à admettre le présupposé de la question qu'il y a des langages d'usage général de plus haut niveau; moi je ne vois guère que des DSL. On peut travailler à bas niveau en C++, on n'est pas obligé.).

Le terme n'est peut-être pas très bien choisi (et peut prêter à discussion), mais je vais expliquer ce que je voulais. Selon Wikipedia, un langage de haut-niveau « permet au programmeur de s'abstraire de détails inhérents au fonctionnement de la machine ». Je crois que certains langages sont plus détachés que d'autres du fonctionnement de la machine. Comme tu le cites, les DSL ont font partie : sed, make et les autres ont été conçus de façon totalement indépendante du fonctionnement de la machine.

J'espère que tu seras d'accord avec moi quand je dis que le C est un langage de bas-niveau. Le C++ offre certes beaucoup plus d'abstractions que le C, mais une bonne partie du C++ découle du fonctionnement de la machine. L'exemple le flagrant est la présence de pointeurs. Bien sûr, on s'en sert beaucoup moins souvent qu'en C, mais ils restent importants : la preuve, dans le seul code C++ donné ici, tu en as utilisé un. Un autre exemple : la gestion explicite de la mémoire et des allocations. Cela provient directement de la conception de la machine.

Si tu veux des exemples de langages de plus haut-niveau que le C++, regarde par exemple Lisp, Ruby ou Perl. Dans ces langages, il y a peu de choses qui rappellent la machine. On peut aussi citer Haskell où l'ordre d'évaluation ne correspond pas les règles que l'on suit en assembleur (évaluer les arguments avant d'appeler la fonction semble naturel en assembleur). Ou encore : dans certains langages, toutes les valeurs sont des objets. Alors qu'en C++, tu manipules explicitement un char, int, unsigned int, long ou autres, dans certains langages, tu manipules juste des entiers, qui ne sont pas limités à 32 ou 64 bits ; entre les deux approches, laquelle trouves-tu de plus haut-niveau ?

Pour simplifier beaucoup, compare la longueur du code source et sa clarté. Le code dans un langage de haut-niveau est généralement plus court que son équivalent dans un langage de bas-niveau. De même que les DSL sont souvent imbattables dans leurs domaines, un langage de haut-niveau aura souvent du code plus concis et plus abstrait que son équivalent bas-niveau.

Donc une struct contenant une union de struct en C ou en C++

Et la sûreté dans tout ça ? L'union est quand même l'une des choses les moins sûres de C. Ton compilateur ne peut absolument rien vérifier (tu dois ajouter un entier/booléen pour te souvenir de ce que tu as mis dans l'union). En cas de problème, l'erreur de segmentation arrive (en C/C++, pas Ada). La seule protection en C++ est de faire très attention en manipulant l'union, et de cacher les mécanismes dans des private. Je trouve ça assez dommage. En comparaison, Caml me certifie qu'à tout moment structure de donnée est parfaitement valide. Sans compter que, dans ton code C++, le pointeur peut pointer sur n'importe quoi.

(Désolé quand même, mon exemple n'était pas très bien choisi ; en plus, j'ai fait une faute dedans)

En effet, pour quelqu'un qui débute, il n'est pas évident de choisir parmi oCaml, Haskell, Anubis, F# et j'en passe.

Et comment choisis-tu entre C++, Java, C#, VB, Delphi, Python, Ruby et Ada ? Ce sont des langages à dominante impérative et gérant l'orienté-objet.

Parmi les principaux langages fonctionnels, il y a en gros :
- Lisp et sa famille (CLisp, Scheme...) : typage dynamique, fonctionnel impur ;
- famille ML (Caml, SML, F#...) : typage statique, fonctionnel impur ;
- Haskell : typage statique, fonctionnel pur.

F# profite de l'ensemble des librairies .NET, non ?

Oui. Avec un léger bémol quand même : les bibliothèques .NET sont parfois conçues de façon impératives (ou pire : peuvent renvoyer null !). Mais oui, ça marche plutôt bien.

[SpiceGuid]

Il faudrait peut être que le marché se choisissent une ou deux "stars" (comme Java et .Net dans la catégorie informatique de gestion)

Oui ce sont des standards de fait, mais ce ne sont pas des langages, ce sont plutôt des machines virtuelles, et qui sont d'ailleurs tout à fait accessibles en fonctionnel:

• Scala ou Cafestérol visent la JVM
• F# vise .Net

[Garulfo]

Je ne sais pas où tous vous travaillez, mais de mon côté en 25 ans je n'ai travaillé QUE sur des projets où la qualité était ESSENTIELLE, et même vitale : logiciels critiques avec vies en jeu, ou développement une fois avec durée de vie du logiciel > 10 ou 15 ans..
Donc je ne peux QUE m'inscrire en faux par rapport à ce que vous dîtes. C'est peut-être le fait des développements Web ou Windows, je ne sais pas, mais il faut dire que je n'ai jamais travaillé sur un logiciel se vendant MOINS de 1 à 2 millions... et dans ces cas la qualtié est primordiale.. AVANT les impératifs commerciaux : car si le client est mécontent, on le sent passer...

Mais attention, j'avais fait un effort exprès pour mentionner que tu es dans un cas particulier. En fait, je suis de même je ne travaille (hors académique) que dans des domaines où la qualité et la fiabilité sont primordiales: Nasa, Siemens, DOD, etc. Mais ce sont des cas très particulier de l'industrie. Un des projets sur lequel je collabore est d'emmener les développeurs de système d'information à utiliser des méthodes formelles. Si je me rappelle bien tu es en rapport avec l'aéronautique ? Rien à voir avec l'industrie « général » de l'informatique.

On estime que plus de 50% des développeurs au Canada travaillent sur des systèmes d'informations dont une grand part attaché à la programmation Internet. En général un système doit sortir dans un créneau commercial savamment dosé. La qualité est secondaire (tertiaire ?)... On préfèrera un logiciel non abouti, peu testé, mal construit mais qui sort à temps qu'un logiciel de grande qualité. L'histoire de l'informatique à son lot de matériel qui on s'eut s'imposer par leurs prix et non leurs qualités. Le but de la recherche en génie logiciel est de réussir à produire mieux au même prix (ou moins cher).

Maintenant, pour le reste du débat, je m'en retire, car visiblement cela correspond à ce que je disais au début : je suis un vieux crouton, et c'est de la recherche , que ce soit dans le fond ("cela VA aller en s'améliorant", "le manque de bibliothèques" et "les problèmes de compatiibilité), que dans la forme (tout ce qui n'est pas du même avis est rétrograde et hasbeen).

Moi je ne pense pas ça. Je suis académique, et je sais bien que si on ne comprends pas la garde actuelle qui œuvre dans l'industrie, on ne réussira certainement pas à faire comprendre que d'autres méthodes peuvent être meilleures. En effet, le frein à l'utilisation de méthode formelle, par exemple, n'est pas la compétence (et pas vraiment le prix puisque de plus en plus c'est abordable) mais plutôt le principe d'inertie qui s'oppose à tout changement par peur/incompréhension/appréhension/fainéantise Donc je trouve fondamental de comprendre et considérer les avis de « vieux croutons » qui connaissent l'industrie comme toi et J.-M. Bourguet (pour ne citer que vous deux). J'ai accusé plusieurs fois J.-M. dans une autre discussion de ne pas comprendre la problématique de la pédagogie et donc le cadre d'enseignement. Et bien il est aussi vrai que des académiques perdent parfois de vue l'industrie et donc ne font finalement rien progresser du tout.

Je pense que la programmation fonctionnelle souffre d'une image déplorable qui n'est plus valable depuis le temps (voir n'a jamais été valable). Les arguments contre ne tiennent pas en général, sauf un : les gens ne connaissent pas le fonctionnel et donc il est difficile pour un chef de projet de faire faire un développement en fonctionnel. Pour le reste, que ce soit la syntaxe ésotérique (comme si la première fois qu'on aborde le C++ c'était naturel), les performances (ocaml est de loin supérieur à Java), l'artificialité du paradigme (tiens les maths ne sont pas « naturels » ? mais alors pourquoi est-ce la voie qui a été choisi pendant 2000 ans) etc. tout peut être contredit ou très relativisé.

D'un point de vue académique, le fonctionnel est nécessaire car il permet de voir des approches très difficiles à montrer ailleurs (la programmation par continuation par exemple). D'un autre côté, comme l'a dit J.-M., en général, un spécialiste dans un langage, saura utilisé les forces de son langage pour faire: la même chose; sensiblement la même chose. Mais pour cela, il faut savoir qu'il existe une telle approche. Et parfois l'industrie a un retard incroyable dans ces connaissances (ce qui peut être vu de la faute des académiques qui ne font pas d'effort de communication parfois). L'exemple de l'algorithme A* est frappant. Cet algorithme est connu depuis 1968 en IA et est présenté dans presque tous les cours concernés. Hors ça ne fait que 10/15 ans qu'il est intégré au monde du jeu vidéo pour le déplacement de nos petits bonhommes préférés.

Je crois complètement en l'avenir du fonctionnel. Pas du pur fonctionnel ! Car il est absurde de vouloir être « pur » à 100% (ça marche pas dans la sélection naturel, ça marche pas plus en programmation). Montrer des programmes en pur objet ou pur fonctionnel, c'est bon pour les salles de classes pour mettre l'emphase sur les points ET les points faibles. Je ne manque pas une occasion de dire à mes étudiants de toujours choisir les bons outils et non de coller à une approche ou un langage.

Je pense que le choix des langages dans un projet personnel est une mauvaise mesure de la qualité du langage : on choisit souvent ce dans quoi on est le plus productif. C'est comme en amour ça, une première bonne impression peut être la base de tout

En tout cas, des langages comme Ruby (qui est un vrai langage fonctionnel) ou Python (qui triche un peu mais peut être utilisé aisément comme tel) remettent le fonctionnel en place dans une utilisation de tous les jours. Ceci peut faire changer la vision des choses et améliorer donc les conditions des langages fonctionnels.

[Garulfo]

bah MPI est deja utilise depuis longtemps avec des langages que vous nommez imperatifs [...]
Des exemples que j'ai vu, la compatibilite (meme partielle) du code existant est LE facteur majeur.[...]

Complètement d'accord. C'est de ça dont je parlais quand je parlais d'inertie entre autre

Pourquoi que « nous » nommons impératifs ? Tu ne les nommes pas ainsi ? Par opposition à la taxonomie établie ?

[LLB]

Oui ce sont des standards de fait, mais ce ne sont pas des langages, ce sont plutôt des machines virtuelles, et qui sont d'ailleurs tout à fait accessibles en fonctionnel:

* Scala ou Cafestérol visent la JVM
* F# vise .Net

De là à considérer ces solutions, utilisées par quasiment personne, comme des "stars", il va falloir attendre un peu. En tout cas, il est difficile de conseiller ces solutions à des débutants ou à des grandes entreprises. Elles manquent encore de maturité.

En tout cas, des langages comme Ruby (qui est un vrai langage fonctionnel)

Oui, il possède toutes les fonctionnalités qu'on attend d'un langage fonctionnel. Mais pourtant, je ne trouve pas qu'il incite à ce mode. La pensée impérative est bien plus présente dans le langage, pour ce que j'en ai vu (un point qui me gène beaucoup : la déclaration et l'assignation ont la même syntaxe, on ne se rend donc pas toujours compte des effets de bord).

ou Python (qui triche un peu mais peut être utilisé aisément comme tel) remettent le fonctionnel en place dans une utilisation de tous les jours.

J'ai perdu espoir en Python depuis le jour où Guido van Rossum a écrit ce texte : http://www.artima.com/weblogs/viewpost.jsp?thread=98196
Tout n'a finalement pas été appliqué, mais ça en dit long sur la vision de Guido. Python n'incite absolument pas au fonctionnel. Détail marquant : le if est impératif comme en C, il ne renvoie rien (sans compter le mot-clef return, typiquement impératif).

Bien sûr, je pinaille un peu sur ces deux points, mais je suis d'accord avec toi dans le fond. Tous les langages récents s'inspirent, et de plus en plus, des langages fonctionnels. La différence langage fonctionnel / langage impératif s'estompe (mais en général, chaque langage a un paradigme dominant).

[Garulfo]

Oui, il possède toutes les fonctionnalités qu'on attend d'un langage fonctionnel. Mais pourtant, je ne trouve pas qu'il incite à ce mode.

J'ai perdu espoir en Python depuis le jour où [...] Python n'incite absolument pas au fonctionnel.

Ce que je voulais dire est que Ruby est un langage fonctionnel, au sens propre : les fonctions (les fermetures pour être précis) sont des données de base du langage.

Python triche un peu puisque ce sont des méthodes en fait. On peut faire la même chose en Java (mais avec plus d'effort).

Donc, ce que je voulais effectivement amené, c'est que les nouveaux langages tendent à implémenter les fonctionnalités du fonctionnel (amusant comme terme ). Ruby offre même un appel avec la continuation courante (call with current continuation ou callcc en abrégé). Ocaml en a un, mais Xavier Leroy dit lui même que l'implémentation est très naïve et non recommandée sur un vrai projet. À moins que cela n'ai changé.

[souviron34]

On estime que plus de 50% des développeurs au Canada travaillent sur des systèmes d'informations dont une grand part attaché à la programmation Internet. En général un système doit sortir dans un créneau commercial savamment dosé. La qualité est secondaire (tertiaire ?)... On préfèrera un logiciel non abouti, peu testé, mal construit mais qui sort à temps qu'un logiciel de grande qualité. L'histoire de l'informatique à son lot de matériel qui on s'eut s'imposer par leurs prix et non leurs qualités. Le but de la recherche en génie logiciel est de réussir à produire mieux au même prix (ou moins cher).

Pôv' de nous !!!

Je pense que la programmation fonctionnelle souffre d'une image déplorable qui n'est plus valable depuis le temps (voir n'a jamais été valable). Les arguments contre ne tiennent pas en général, sauf un : les gens ne connaissent pas le fonctionnel et donc il est difficile pour un chef de projet de faire faire un développement en fonctionnel. Pour le reste, que ce soit la syntaxe ésotérique (comme si la première fois qu'on aborde le C++ c'était naturel), les performances (ocaml est de loin supérieur à Java), l'artificialité du paradigme (tiens les maths ne sont pas « naturels » ? mais alors pourquoi est-ce la voie qui a été choisi pendant 2000 ans) etc. tout peut être contredit ou très relativisé.

je peux être d'accord avec toi sur ce point.

Cependant, comme le dit LLB, ces solutions ne sont utilisées par quasi-personne, et qui en développant un produit veut être le premier à payer les pots cassés d'une tentative de développement industriel basé sur de la recherche (à part un projet en laision avec un institut de recherche) ?
(ou une boîte qui peut se permettre, comme M$).

D'un point de vue académique, le fonctionnel est nécessaire car il permet de voir des approches très difficiles à montrer ailleurs (la programmation par continuation par exemple). D'un autre côté, comme l'a dit J.-M., en général, un spécialiste dans un langage, saura utilisé les forces de son langage pour faire: la même chose; sensiblement la même chose. Mais pour cela, il faut savoir qu'il existe une telle approche. Et parfois l'industrie a un retard incroyable dans ces connaissances (ce qui peut être vu de la faute des académiques qui ne font pas d'effort de communication parfois). L'exemple de l'algorithme A* est frappant. Cet algorithme est connu depuis 1968 en IA et est présenté dans presque tous les cours concernés. Hors ça ne fait que 10/15 ans qu'il est intégré au monde du jeu vidéo pour le déplacement de nos petits bonhommes préférés.

Comme tu le dis, d'un point de vue académique

Je crois complètement en l'avenir du fonctionnel. Pas du pur fonctionnel ! Car il est absurde de vouloir être « pur » à 100% (ça marche pas dans la sélection naturel, ça marche pas plus en programmation). Montrer des programmes en pur objet ou pur fonctionnel, c'est bon pour les salles de classes pour mettre l'emphase sur les points ET les points faibles. Je ne manque pas une occasion de dire à mes étudiants de toujours choisir les bons outils et non de coller à une approche ou un langage.

Je pense que le choix des langages dans un projet personnel est une mauvaise mesure de la qualité du langage : on choisit souvent ce dans quoi on est le plus productif. C'est comme en amour ça, une première bonne impression peut être la base de tout

En tout cas, des langages comme Ruby (qui est un vrai langage fonctionnel) ou Python (qui triche un peu mais peut être utilisé aisément comme tel) remettent le fonctionnel en place dans une utilisation de tous les jours. Ceci peut faire changer la vision des choses et améliorer donc les conditions des langages fonctionnels.

Je crois (et cela rejoint le premier point que j'ai cité de toi), que malheureusement (et j'insiste sur ce point : j'aimerais que ce soit le contraire, mais la réalité est là), cela additionné du premier point va vers la même tendance que "l'orthographe n'est pas importante" et "foin du français et de ses règles complexes"...

Ce qui part d'une bonne intention (et qui est correctement utilisé par des gens sachant de quoi ils parlent), est entièrement dévoyé et amène à la catastrophe car utilisé par des gens non seulement n'ayant plus les bases mais ne comprenant même pas pourquoi on en aurait besoin..

Ainsi, dans les arguments que j'entend ici, ce serait "super" de ne pas connaître les limites de la machine, d'être "loin"..

Résultat : une demande toujours plus grande de mémoire pour faire le même boulot qu'on faisait avant avec 100 voire 100 000 fois moins de mémoire.. Un "laxisme" dans la prise en compte des contraintes et d'une programmation rigoureuse (voir ton exemple sur les développements Web et Windows).

Je ne peux juger par moi-même, ne connaissant pas ces langages. Je m'offusque simplement qu'on me mette en avant comme avantage qu'on n'a plus besoin de connaître les limites...

Encore une fois, autant l'argot utilisé par Frédéric Dard est une langue à part entière, autant les SMS en tant que langage d'une génération est un appauvrissement sans nom (et malheureusement vraisemblablement définitif) du français d'une génération de jeunes....

Que ce soit la langue ou la manipulation des machines pour leur faire dire ce qu'on souhaite, il existe des règles et des limites à suivre et à connaître, SURTOUT si on veut pouvoir s'en affranchir avec brio..

Pourquoi que « nous » nommons impératifs ? Tu ne les nommes pas ainsi ? Par opposition à la taxonomie établie ?

bah juste une petite pointe, puisque jusqu'à venir sur ces quelques discussions je n'en avais jamais entendu parler....

[Keihilin]

Et comment choisis-tu entre C++, Java, C#, VB, Delphi, Python, Ruby et Ada ? Ce sont des langages à dominante impérative et gérant l'orienté-objet.

Le marché a choisi pour moi...
Java et C# s'imposent d'eux-mêmes pour le développement d'applications de gestion. C++ est un choix prioritaire dès lors qu'il s'agit de manipuler du matériel.
Je ne dis pas qu'il y a un cloisonnement complètement hermétique, mais il y a quand même des grandes lignes sur lesquelles certains langages se sont imposés.

Parmi les principaux langages fonctionnels, il y a en gros :
- Lisp et sa famille (CLisp, Scheme...) : typage dynamique, fonctionnel impur ;
- famille ML (Caml, SML, F#...) : typage statique, fonctionnel impur ;
- Haskell : typage statique, fonctionnel pur.

Merci pour cette classification. Du coup j'ai 2 questions supplémentaires :

Comment faire un choix entre deux familles ou deux de ces langages ? Quels-sont les avantages/inconvénients les uns par rapport au autres ?

D'autres part, Impur veut dire que le paradigme n'est pas 100% respecté et que le langage comporte des fonctionnalités pouvant induire des effets de bord, c'est ça ?

Dans ce cas, quels avantages apportent ces langages impurs ? Avec mes maigres connaissances du fonctionnel, j'ai l'impression de pouvoir imiter en C# (3.0) beaucoup de spécificités de F# par exemple. (Démo sur demande )

[Jean-Marc.Bourguet]

Avec mes maigres connaissances du fonctionnel, j'ai l'impression de pouvoir imiter en C# (3.0) beaucoup de spécificités de F# par exemple. (Démo sur demande )

Ca me rappelle quelque chose:

Any sufficiently complicated program contains an ad-hoc, informally-specified bug-ridden slow implementation of half of Common Lisp.

Le programme sur lequel je travaille contient une implementation specifiee formellement et relativement sans bugs -- je doute qu'elle soit rapide par contre -- de Scheme.