IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

Débats sur le développement - Le Best Of Discussion :

Pourquoi la programmation fonctionnelle n’est-elle pas la norme de l’industrie du code ?


Sujet :

Débats sur le développement - Le Best Of

  1. #1
    Chroniqueur Actualités
    Avatar de Patrick Ruiz
    Homme Profil pro
    Redacteur web
    Inscrit en
    Février 2017
    Messages
    1 804
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Cameroun

    Informations professionnelles :
    Activité : Redacteur web
    Secteur : Communication - Médias

    Informations forums :
    Inscription : Février 2017
    Messages : 1 804
    Points : 50 740
    Points
    50 740
    Par défaut Pourquoi la programmation fonctionnelle n’est-elle pas la norme de l’industrie du code ?
    Pourquoi la programmation fonctionnelle n’est-elle pas la norme de l’industrie du code ? L’auteur de « Elm in action » s'exprime
    « C’est une question de temps avant que la POO soit détrônée »

    Il existe une panoplie de manières d’aborder la programmation informatique. Dans le jargon du milieu, on parle de paradigme de programmation. En incluant celui dit impératif, on répertorie à minima trois grandes familles et leurs dérivés. Certaines de ces approches font quasiment office de norme dans l’actuelle industrie de la programmation informatique. C’est par exemple le cas de la programmation orientée objet dont on a appris qu’elle permet d’améliorer l’organisation des bases de code procédurales.

    Toutefois, Richard Feldman est d’avis que « l’on est quelque part au milieu d’une transition du style programmation orientée objet vers celui dit fonctionnel. » « Des langages de programmation comme Kotlin prennent à la fois la programmation orientée objet et celle dite fonctionnelle en charge. C’est quelque chose que vous n’auriez pas vu dans une FAQ du langage Java dans les années ‘90. En fait, de plus en plus de langages mettent en avant le support du style fonctionnel en avant comme argument de vente. Les développements en cours laissent penser que de plus en plus d’acteurs de la filière sont d’accord que l’approche fonctionnelle est bonne », ajoute-t-il.

    Il y a quelques mois, l’étude « Emploi développeur 2018 » est parue sur cette plateforme. En tête de liste des langages les plus demandés et les mieux payés, on retrouve Java. Sa première présentation officielle s’est faite le 23 mai 1995 au SunWorld comme langage de programmation structuré, impératif et orientée objet. C’est Java 8 (sorti en 2014) qui est venu mettre les développeurs qui font usage de ce langage de programmation sur les rails du style fonctionnel au travers des expressions lambdas. En fait, la remarque de Feldman vaut pour bon nombre de langages de cette enquête dvp pour lesquels on note que de plus en plus de livres orientés programmation fonctionnelle paraissent.

    Nom : 11.png
Affichages : 54933
Taille : 242,3 Ko

    « C’est le signe que quelque chose a changé des années ‘90 à nos jours. L’approche fonctionnelle attire de plus en plus d’acteurs de la filière. Ce n’est plus qu’une question de temps pour la voir s’imposer », conclut Feldman.

    La montée en puissance de langages de programmation pour le web comme Elm au travers de bibliothèques comme Elm-ui pourrait accélérer la transition entrevue. Cela permettrait de lister la programmation d’interfaces utilisateur comme domaine « phare » d’un langage à paradigme fonctionnel. En sus, des facteurs additionnels comme le fait pour certaines plateformes de réserver l’exclusivité à des langages de programmation à paradigme fonctionnel pourraient contribuer à poser le tableau tel que vu par Feldman. Ceci c’est sans prise en compte d’ingrédients comme le marketing autour des solutions proposées. Il s’agit là d’une liste non exhaustive d’atouts que l’approche fonctionnelle ne réunit pas à date, mais qui a contribué à propulser l’approche orientée objet. Sur l’axe de l’exclusivité de la plateforme, il n’y a qu’a voir avec C# dont on peut penser que son lancement était destiné à attirer des développeurs Java. Enfin, comment oublier la campagne à 500 millions de dollars que Sun a mise sur pied en 2003 pour la promotion de Java.


    La sortie de Richard Feldman n’est pas sans faire penser à des développements antérieurs qui suggèrent de passer à l’approche fonctionnelle.

    En effet, à mi-parcours de l’année qui tire à son terme, Ilya Suzdalnitski de l’entreprise Replicon affirmait que « considérer la programmation orientée objet comme standard de l’industrie pour l’organisation des bases de code est, pour lui, une grosse erreur. » Son développement laissait filtrer que l’usage de la programmation orientée objet dévie l’attention des développeurs de ce qui doit la retenir : la résolution des problèmes. « L’approche orientée objet introduit plus de complexité que l’inverse surtout pour des bases de code importantes », avait-il souligné avant d’ajouter qu’ « il est difficile d’écrire du code orienté objet aisé à maintenir, les tests unitaires sont difficiles à appliquer à une base de code montée suivant l’approche orientée objet, le refactoring de code est une vraie galère sans des outils comme Resharper. »

    L’ingénieur de Replicon avait insisté sur ceci que la racine des maux avec la POO telle que pratiquée via des langages comme Java ou C# est qu’elle n’est pas implémentée telle qu’Alan Kay l’a conçue. « On n’aurait jamais dû parler de concepts comme l’héritage, le polymorphisme ou avoir à traiter avec une myriade de patrons de conception », avait-il souligné. Ilya Suzdalnitski accusait les langages phares du moment de mettre en avant une POO qui ne s’aligne pas sur la définition originelle de l’encapsulation et sur la communication par messages entre programmes indépendants.

    « En Erlang, on pratique la programmation orientée objet sous sa forme la plus pure. À l’inverse des langages de programmation phares, Erlang s’appuie sur l’idée centrale de la POO – les messages. Dans ce langage, les objets communiquent via des messages immuables », avait-il indiqué.

    Au travers de cet exemple, l’ingénieur de Replicon suggérait que programmation fonctionnelle et programmation orientée objet « pure » sont une seule et même chose. En droite ligne avec ce détail, il avait surtout mis en avant la supériorité de la programmation fonctionnelle vis-à-vis de la POO telle que pratiquée avec Java, C#, C++ et autres.

    « Le but ultime de tout développeur de logiciel devrait être d'écrire du code fiable. Rien d'autre n'a d'importance si le code est bogué et peu fiable. Et quelle est la meilleure façon d'écrire un code fiable ? Simplicité. La simplicité est le contraire de la complexité. Erlang est probablement le langage le plus fiable au monde. La majeure partie de l'infrastructure mondiale des télécommunications (et donc de l'Internet) s'appuie sur ce dernier. Certains des systèmes écrits en Erlang ont une fiabilité de 99.999999999 % », avait-il insisté.

    Nom : 12.png
Affichages : 18837
Taille : 43,9 Ko

    Dans sa présentation, Feldman rappelle qu’il a travaillé sur plusieurs projets en s’appuyant sur l’approche orientée objet avant de passer à l’approche fonctionnelle. Depuis des années qu’il pratique cette dernière, il l’a trouvée intéressante, ce qui l’a amené à se poser la question de savoir pourquoi l’industrie continue de faire usage de l’approche orientée objet.

    Source : video

    Et vous ?

    Partagez-vous l’avis selon lequel l’approche fonctionnelle finira par s’imposer comme norme ?
    Quelle est votre expérience avec l’approche fonctionnelle ? Introduit-elle moins de complexité que l’approche orientée objet ?
    Votre expérience des tests unitaires et du refactoring de code a-t-elle souvent été pénible sur des bases de code montées en s’appuyant sur l’approche orientée objet ? Si oui, pourquoi ?

    Voir aussi :

    La programmation orientée-objet est-elle dépassée ? Une école en sciences informatiques l'élimine de son programme d'introduction
    Faut-il éviter de distraire les débutants avec l'orientée objet ?
    Comment pourriez-vous expliquer l'orienté objet ? Steve Jobs a essayé d'expliquer ce concept
    Contribuez au club : Corrections, suggestions, critiques, ... : Contactez le service news et Rédigez des actualités

  2. #2
    Inactif  


    Homme Profil pro
    Doctorant sécurité informatique — Diplômé master Droit/Économie/Gestion
    Inscrit en
    Décembre 2011
    Messages
    9 012
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 30
    Localisation : France, Loire (Rhône Alpes)

    Informations professionnelles :
    Activité : Doctorant sécurité informatique — Diplômé master Droit/Économie/Gestion
    Secteur : Enseignement

    Informations forums :
    Inscription : Décembre 2011
    Messages : 9 012
    Points : 23 209
    Points
    23 209
    Par défaut
    Rhôoo, mais vous avez un jour d'avance.

    Tout ce perd ma p'tite dame, les traditions, c'est plus c'que c'était.

  3. #3
    Expert éminent sénior
    Profil pro
    Inscrit en
    Décembre 2007
    Messages
    6 803
    Détails du profil
    Informations personnelles :
    Localisation : France, Hérault (Languedoc Roussillon)

    Informations forums :
    Inscription : Décembre 2007
    Messages : 6 803
    Points : 32 044
    Points
    32 044
    Par défaut
    Citation Envoyé par Neckara Voir le message
    Rhôoo, mais vous avez un jour d'avance.

    Tout ce perd ma p'tite dame, les traditions, c'est plus c'que c'était.
    Pour faire presque aussi trollesque : la programmation fonctionnelle ne s'est jamais imposée parce-que c'est une bouse illisible par quiconque n'est pas son auteur.

    C'est triste parce-que c'est quand même carrément puissant, comme paradigme de programmation. Mais il faut une agilité intellectuelle exceptionnelle(ainsi qu'un entrainement spécifique) pour arriver à en tirer la substance. C'est bien plus exigeant que l'objet ou le procédural. Le programmeur moyen n'est pas armé pour faire face à un code en fonctionnel - alors qu'il peut être productif dans les autres paradigmes. C'est pourquoi la programmation fonctionnelle est vouée à rester une niche. Une niche surpuissante, mais une niche quand même. C'est bien d'avoir du fonctionnel en natif dans un langage - mais ça ne servira pas à la majorité.
    Les 4 règles d'airain du développement informatique sont, d'après Michael C. Kasten :
    1)on ne peut pas établir un chiffrage tant qu'on a pas finalisé la conception
    2)on ne peut pas finaliser la conception tant qu'on a pas complètement compris toutes les exigences
    3)le temps de comprendre toutes les exigences, le projet est terminé
    4)le temps de terminer le projet, les exigences ont changé
    Et le serment de non-allégiance :
    Je promets de n’exclure aucune idée sur la base de sa source mais de donner toute la considération nécessaire aux idées de toutes les écoles ou lignes de pensées afin de trouver celle qui est la mieux adaptée à une situation donnée.

  4. #4
    Membre chevronné
    Avatar de emixam16
    Homme Profil pro
    Chercheur en sécurité
    Inscrit en
    Juin 2013
    Messages
    333
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Calvados (Basse Normandie)

    Informations professionnelles :
    Activité : Chercheur en sécurité

    Informations forums :
    Inscription : Juin 2013
    Messages : 333
    Points : 1 827
    Points
    1 827
    Par défaut
    Citation Envoyé par Patrick Ruiz
    Certains des systèmes écrits en Erlang ont une fiabilité de 99.999999999 %
    J'ai ri.

    C'est quoi le 0.000000001%? Qu'on se trompe en disant c'est sur à 100%? Que le stagiaire renverse du café sur le serveur? Que Windows Update force un démarrage?

    Voici un code sur à 99.999999999 %. Enfin, comme l'auteur, je donne ce chiffre à la louche, hein?
    Code c : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
     
    int main() {
        printf("Wow, ce programme est vraiment fiable.\n");
        return 0;
    }

    Tout ça pour dire, une fiabilité "tout court" ça n'a aucun sens.

  5. #5
    Expert confirmé Avatar de yildiz-online
    Homme Profil pro
    Architecte de domaine
    Inscrit en
    Octobre 2011
    Messages
    1 443
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Belgique

    Informations professionnelles :
    Activité : Architecte de domaine

    Informations forums :
    Inscription : Octobre 2011
    Messages : 1 443
    Points : 4 559
    Points
    4 559
    Par défaut
    Citation Envoyé par emixam16 Voir le message
    J'ai ri.

    Voici un code sur à 99.999999999 %. Enfin, comme l'auteur, je donne ce chiffre à la louche, hein?
    Code c : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
     
    int main() {
        printf("Wow, ce programme est vraiment fiable.\n");
        return 0;
    }

    Tout ça pour dire, une fiabilité "tout court" ça n'a aucun sens.
    Sans #include, c'est bien moins que 99.999999999 %, ça dépend du compilo.
    PXL le retro-gaming facile: Essayez-le

    Yildiz-Engine an open-source modular game engine: Website
    Yildiz-Online a 3D MMORTS in alpha: Facebook page / Youtube page

  6. #6
    Membre chevronné
    Avatar de emixam16
    Homme Profil pro
    Chercheur en sécurité
    Inscrit en
    Juin 2013
    Messages
    333
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Calvados (Basse Normandie)

    Informations professionnelles :
    Activité : Chercheur en sécurité

    Informations forums :
    Inscription : Juin 2013
    Messages : 333
    Points : 1 827
    Points
    1 827
    Par défaut
    Citation Envoyé par yildiz-online Voir le message
    Sans #include, c'est bien moins que 99.999999999 %, ça dépend du compilo.
    Je sais. C'était d'ailleurs volontaire. J'illustrais ironiquement le fait que la fiabilité dépend d'un ensemble d'hypothèses (quel est mon compilateur et mon environnement, considère t'on que le matériel est fiable à 100%?, ...).

    Ici, si je compile mon code avec gcc foo.c -o foo, j'aurais un joli warning mais mon programme s’exécutera comme prévu. Si j'utilise gcc -include stdio.h foo.c -o foo je n'aurais même pas de warning. Avec un autre compilateur (ou peut-être une autre version de gcc) le code pourrait ne pas marcher.

    Du coup, peut on dire que mon code est fiable à ~100%? Ça dépend des hypothèses. Une fiabilité "tout court" ça n'a aucun sens!

    (Mais j’admets que j'aurais du expliciter un peu plus mon raisonnement, à la relecture, la transition entre le code et la phrase de conclusion ne saute pas aux yeux)!

  7. #7
    Membre régulier
    Profil pro
    Consultant
    Inscrit en
    Novembre 2003
    Messages
    23
    Détails du profil
    Informations personnelles :
    Localisation : Belgique

    Informations professionnelles :
    Activité : Consultant

    Informations forums :
    Inscription : Novembre 2003
    Messages : 23
    Points : 116
    Points
    116
    Par défaut
    Le gros problème de la programmation massivement fonctionnelle c'est en effet qu'elle est difficilement lisible si on essaie de généraliser son emploi : on arrive quand même assez vite à des trucs qui sont en effet écris sur une seule ligne de code au lieu de 3 mais qui vont demander 5 fois plus de temps au développeur lamba pour comprendre ce qu'on fait.

    Certains de mes profs de Master se voulaient grands gourou du fonctionnel, avec des langages de programmation comme Oz : merveilleux selon eux mais utilisés par personne ou presque en dehors de la sphère universitaire où la notion de coûts de maintenabilité est une notion abstraite et très très lointaine.

    Au final, les "chercheurs" peuvent inventer tout ce qu'ils veulent, c'est quand même l'industrie qui fera de leurs idée des succès ou des flops retentissants.

  8. #8
    Membre actif
    Homme Profil pro
    Développeur informatique
    Inscrit en
    Février 2006
    Messages
    70
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 37
    Localisation : France, Alpes Maritimes (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Développeur informatique
    Secteur : High Tech - Électronique et micro-électronique

    Informations forums :
    Inscription : Février 2006
    Messages : 70
    Points : 218
    Points
    218
    Par défaut
    Comme toujours, il s'agit de trouver le bon outil pour le bon problème...

    Je me suis rendu compte que le fonctionnel était utile à mon projet au moment où j'ai commencé à multiplier les CompletableFuture dans un contexte fortement asynchrone.
    Mais dire que j'ai remplacé l'objet par le fonctionnel n'a pas de sens...
    Il ne devrait pas s'agir de mode, mais de réel besoins !

    Quand à l'écriture lisible, c'est surtout de l'expérience et des bonnes pratiques. Qui n'a jamais écris un objet / classe pourrie à ses début dans la POO ^^
    L'enfer des callback dans des callback est une réalité ! Mais il y a là aussi des bonne pratiques pour les éviter. Et devinez quoi ? C'est grâce à la POO qu'on peut écrire quelque chose comme :

    do( (...) -> ... )
    .then( (...) -> .... )
    .then( (...) -> .... )
    .end( (...) -> .... )

  9. #9
    Invité
    Invité(e)
    Par défaut
    Citation Envoyé par emixam16 Voir le message
    J'ai ri.

    C'est quoi le 0.000000001%? Qu'on se trompe en disant c'est sur à 100%? Que le stagiaire renverse du café sur le serveur? Que Windows Update force un démarrage?
    ...
    Si ta question est vraiment sérieuse, moi j'aurais plutôt envie de pleurer de voir qu'un "Doctorant en sécurité" ne connait pas cette anecdocte.
    https://stackoverflow.com/questions/...es-reliability
    https://en.wikipedia.org/wiki/Erlang...guage)#History

  10. #10
    Invité
    Invité(e)
    Par défaut
    Citation Envoyé par el_slapper Voir le message
    Mais il faut une agilité intellectuelle exceptionnelle(ainsi qu'un entrainement spécifique) pour arriver à en tirer la substance. C'est bien plus exigeant que l'objet ou le procédural. Le programmeur moyen n'est pas armé pour faire face à un code en fonctionnel - alors qu'il peut être productif dans les autres paradigmes.
    A lire cela, on a l'impression que le procédural ou l'objet c'est presque intuitif. Sauf que ça demande aussi un gros apprentissage avant d'être productif.

    Dans des études informatiques classiques, il y a combien d'heures consacrées au procédural ? à l'objet ? au fonctionnel ? Et ben voilà : le fonctionnel est ultra minoritaire alors forcément ça nous parait incompréhensible mais c'est peut-être juste qu'on n'a beaucoup moins l'habitude qu'un langage à la C.

  11. #11
    Modérateur
    Avatar de sevyc64
    Homme Profil pro
    Développeur informatique
    Inscrit en
    Janvier 2007
    Messages
    10 188
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 51
    Localisation : France, Pyrénées Atlantiques (Aquitaine)

    Informations professionnelles :
    Activité : Développeur informatique

    Informations forums :
    Inscription : Janvier 2007
    Messages : 10 188
    Points : 28 051
    Points
    28 051
    Par défaut
    Citation Envoyé par emixam16 Voir le message
    C'est quoi le 0.000000001%? Qu'on se trompe en disant c'est sur à 100%? Que le stagiaire renverse du café sur le serveur? Que Windows Update force un démarrage?
    C'est facile de critiquer !

    Comme toujours avec les stats et autres sondages, on ne retient que le chiffre et on oublie toujours de préciser la marge d'erreur, qui a pourtant toute son importance.

    Ici c'est quoi ? 99.999999999 % à +/-3%, +/-5%, +/-10% ?



    --- Sevyc64 ---

    Parce que le partage est notre force, la connaissance sera notre victoire

  12. #12
    Expert confirmé Avatar de Zefling
    Homme Profil pro
    Développeur Web
    Inscrit en
    Avril 2007
    Messages
    1 167
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Puy de Dôme (Auvergne)

    Informations professionnelles :
    Activité : Développeur Web
    Secteur : High Tech - Multimédia et Internet

    Informations forums :
    Inscription : Avril 2007
    Messages : 1 167
    Points : 4 647
    Points
    4 647
    Par défaut
    Citation Envoyé par Sebajuste Voir le message
    C'est grâce à la POO qu'on peut écrire quelque chose comme :

    do( (...) -> ... )
    .then( (...) -> .... )
    .then( (...) -> .... )
    .end( (...) -> .... )
    Sauf qu'il me semble que ce n'est pas de l'objet ça.

  13. #13
    Expert éminent sénior
    Profil pro
    Inscrit en
    Décembre 2007
    Messages
    6 803
    Détails du profil
    Informations personnelles :
    Localisation : France, Hérault (Languedoc Roussillon)

    Informations forums :
    Inscription : Décembre 2007
    Messages : 6 803
    Points : 32 044
    Points
    32 044
    Par défaut
    Citation Envoyé par SimonDecoline Voir le message
    A lire cela, on a l'impression que le procédural ou l'objet c'est presque intuitif. Sauf que ça demande aussi un gros apprentissage avant d'être productif.

    Dans des études informatiques classiques, il y a combien d'heures consacrées au procédural ? à l'objet ? au fonctionnel ? Et ben voilà : le fonctionnel est ultra minoritaire alors forcément ça nous parait incompréhensible mais c'est peut-être juste qu'on n'a beaucoup moins l'habitude qu'un langage à la C.
    ça tombe bien, j'ai fait zéro heures d'études dans chacun des trois domaines. Enfin, j'ai eu un boot camp de 5 semaines en COBOL - donc pur procédural. L'objet et le fonctionnel, j'ai appris par moi-même(et notamment en ces lieux). donc si je suis sans doute un peu partial pour le procédural, je pense pouvoir comparer le fonctionnel et l'objet. L'objet a une difficulté majeure : il faut forcer son esprit à l'idée que la donnée et le code qui s'applique à la donnée sont ensemble, dans un bundle(que l'on nomme classe, dans le jargon). C'est un saut intellectuel non négligeable, mais une fois qu'on a pigé ça, tout le reste s’enchaîne. Les pratiques massivement différentes entre les 2 paradigmes découlent quasiment toutes de là.

    Le fonctionnel, c'est quand même bien plus massif. Une fois qu'on a pigé le principe du récursif(qui à mon sens est déjà moins accessible au commun des mortels), Il reste des milliards de trucs à apprendre qui ne se devinent pas. Plein d'astuces dans tous les sens, que non seulement il faut connaitre et maitriser, mais en plus qui ne sont pas à la portée du premier venu. Tout ça pour faire un programme de complexité moyenne. Alors qu'en procédurale ou en objet, l'investissement initial est bien moindre.

    Après, pour arriver à un haut niveau de maîtrise, pas de secret, hein, il faut plein de pratique, et pas mal de théorie, quel que soit le paradigme. Mais sauf haut potentiel, le paradigme fonctionnel est beaucoup plus difficile d'accès. Et l'industrie a du mal à trouver des hauts potentiels. J'ai vécu 8 ans à faire du COBOL. Pourquoi ce langage est-il encore vivant? Il y a plein de raisons, mais l'une d'entre elle est que des gens médiocres arriveront quand même à faire le boulot. Mal, salement, lentement, mais ils finiront par faire marcher le bouzin. Allez mettre les mêmes devant du LISP. Le boulot doit être fait, et par les gens qu'on a sous la main.
    Les 4 règles d'airain du développement informatique sont, d'après Michael C. Kasten :
    1)on ne peut pas établir un chiffrage tant qu'on a pas finalisé la conception
    2)on ne peut pas finaliser la conception tant qu'on a pas complètement compris toutes les exigences
    3)le temps de comprendre toutes les exigences, le projet est terminé
    4)le temps de terminer le projet, les exigences ont changé
    Et le serment de non-allégiance :
    Je promets de n’exclure aucune idée sur la base de sa source mais de donner toute la considération nécessaire aux idées de toutes les écoles ou lignes de pensées afin de trouver celle qui est la mieux adaptée à une situation donnée.

  14. #14
    Membre régulier
    Femme Profil pro
    Architecte de base de données
    Inscrit en
    Décembre 2019
    Messages
    42
    Détails du profil
    Informations personnelles :
    Sexe : Femme
    Âge : 36
    Localisation : France, Sarthe (Pays de la Loire)

    Informations professionnelles :
    Activité : Architecte de base de données
    Secteur : Conseil

    Informations forums :
    Inscription : Décembre 2019
    Messages : 42
    Points : 100
    Points
    100
    Par défaut
    Citation Envoyé par iclo Voir le message
    Le gros problème de la programmation massivement fonctionnelle c'est en effet qu'elle est difficilement lisible si on essaie de généraliser son emploi : on arrive quand même assez vite à des trucs qui sont en effet écris sur une seule ligne de code au lieu de 3 mais qui vont demander 5 fois plus de temps au développeur lamba pour comprendre ce qu'on fait.

    Certains de mes profs de Master se voulaient grands gourou du fonctionnel, avec des langages de programmation comme Oz : merveilleux selon eux mais utilisés par personne ou presque en dehors de la sphère universitaire où la notion de coûts de maintenabilité est une notion abstraite et très très lointaine.

    Au final, les "chercheurs" peuvent inventer tout ce qu'ils veulent, c'est quand même l'industrie qui fera de leurs idée des succès ou des flops retentissants.
    Oui il y a 30 ans les universitaires nous ont déjà fait le coup avec un CAML puis 10 ans plus tard avec OCAML. Et ce langage est resté prospérer dans le monde des universitaires qui n'ont jamais développé d'appli.

  15. #15
    Candidat au Club
    Profil pro
    Inscrit en
    Novembre 2006
    Messages
    1
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Novembre 2006
    Messages : 1
    Points : 4
    Points
    4
    Par défaut
    C'est marrant car je n'ai pas eu ce ressenti du tout depuis le début. A la fac, dans ma jeunesse, on avait la même année un cours qui utilisait Ada, et un qui utilisait Scheme.

    - Avec Ada, lors du premier TP (après un an de C et 2 ans de turbo pascal), si on arrivait à compiler un Hello World on avait de la chance.
    - Avec Scheme (un dialecte de Lisp), chacun des énoncés, avec manipulation de données, de fonctions etc, réussissait du premier coup.

    Alors certes ce n'est qu'une expérience personnelle, et, si j'ai kiffé Haskell, je n'ai pas été explorer les arcanes les plus obscurs du langage, mais j'y ai trouvé une simplicité et une fluidité qui contrastent avec ce que je lis dans ces commentaires, et ce dès le premier instant.

    ~

    Sinon j'aime bien l'expression utilisée par @iclo, et le côté paradoxal de dire que la programmation n'est pas faite pour un développeur lambda .

  16. #16
    Membre régulier
    Femme Profil pro
    Architecte de base de données
    Inscrit en
    Décembre 2019
    Messages
    42
    Détails du profil
    Informations personnelles :
    Sexe : Femme
    Âge : 36
    Localisation : France, Sarthe (Pays de la Loire)

    Informations professionnelles :
    Activité : Architecte de base de données
    Secteur : Conseil

    Informations forums :
    Inscription : Décembre 2019
    Messages : 42
    Points : 100
    Points
    100
    Par défaut
    on essaie de mettre nos enfants à la programmation
    déjà que les profs qui sont des truffes en programmation ont du mal avec le procédural et l'objet …. j'imagine avec le fonctionnel

  17. #17
    Invité
    Invité(e)
    Par défaut
    Citation Envoyé par sacdebille Voir le message
    Oui il y a 30 ans les universitaires nous ont déjà fait le coup avec un CAML puis 10 ans plus tard avec OCAML. Et ce langage est resté prospérer dans le monde des universitaires qui n'ont jamais développé d'appli.
    Pas du tout.
    Ocaml a directement inspiré F# (https://en.wikipedia.org/wiki/F_Shar...ming_language)).
    Ocaml a directement inspiré Reasonml (https://reasonml.github.io/).
    Ocaml est utilisé de façon non-négligeable dans la finance (https://www.janestreet.com/technology/).
    Ocaml est utilisé de façon non-négligeable chez facebook (https://github.com/facebook?utf8=%E2...language=ocaml).
    etc

  18. #18
    Invité
    Invité(e)
    Par défaut
    Citation Envoyé par el_slapper Voir le message
    ...
    Le fonctionnel, c'est quand même bien plus massif. Une fois qu'on a pigé le principe du récursif(qui à mon sens est déjà moins accessible au commun des mortels), Il reste des milliards de trucs à apprendre qui ne se devinent pas. Plein d'astuces dans tous les sens, que non seulement il faut connaitre et maitriser, mais en plus qui ne sont pas à la portée du premier venu. Tout ça pour faire un programme de complexité moyenne. Alors qu'en procédurale ou en objet, l'investissement initial est bien moindre.
    Pour moi, ça confirme que c'est une question d'habitude. La base du fonctionnel, c'est juste les fonctions et la récursivité, et ça existe aussi dans les autres langages. Evidemment les choses se compliquent un peu quand on veut développer un vrai logiciel mais l'objet aussi ça se complique quand on aborde le polymorphisme, la composition, les design patterns... sans même parler des prototypes et des classes génériques...

    Citation Envoyé par el_slapper Voir le message
    ... J'ai vécu 8 ans à faire du COBOL. Pourquoi ce langage est-il encore vivant? Il y a plein de raisons, mais l'une d'entre elle est que des gens médiocres arriveront quand même à faire le boulot. Mal, salement, lentement, mais ils finiront par faire marcher le bouzin. Allez mettre les mêmes devant du LISP. Le boulot doit être fait, et par les gens qu'on a sous la main.
    LISP existe depuis les années 50 et est toujours utilisé. Et d'autres langages fonctionnels sont aussi couramment utilisés. C'est juste qu'on en entend moins parler.

  19. #19
    Membre extrêmement actif
    Profil pro
    Inscrit en
    Décembre 2003
    Messages
    1 616
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Décembre 2003
    Messages : 1 616
    Points : 3 965
    Points
    3 965
    Par défaut
    Ça va probablement faire mal à beaucoup mais le fonctionnel a connu un regain d'intérêt avec la montée en puissance de JavaScript, et le fait qu'il autorise du fonctionnel assez simplement et depuis sa naissance. Ça fait un moment que ça fait le buzz dans ce domaine. Douglas Crockford lors de ses conférences passionnantes sur ce langage en parlait déjà en 2010 : https://yuiblog.com/blog/2010/02/24/video-crockonjs-3/
    Des bibliothèques JS comme underscore ou Lodash ont désormais 10 ans ou 7 ans d'ancienneté et étaient déjà tournées vers ce paradigme.

    On crache souvent sur le javascript surtout ici mais peu ont conscience de cette capacité à porter certains progrès. Et vu que c'est probablement le langage le plus utilisé au monde...

    Perso j'ai appris la récursivité en faisant du PERL il y a plus de 20 ans sur des systèmes unix (AIX en l’occurrence), et j'ai trouvé ça assez génial. Je n'avais absolument pas idée que c'était assez fondamental du fonctionnel.
    J'ai depuis ce moment toujours utilisé ce type d'algo quand je le pouvais, et je me foutais bien du fonctionnel ou non. Le problème majeur est que le résultat est craché à la dernière itération, à la sortie de la récursion, et il y a 20 ans c'était drôlement sensible, surtout sur des systèmes partagés. C'est juste simple et évident à écrire

    Quand à cette époque j'ai appris (ou abordé plutôt) les 3 paradigmes évoqués, via 3 ou 4 langages (VB pour le procédural, PERL et javascript autorisant le fonctionnel, java pour l'objet) l'objet m'a semblé le moins naturel tel qu'il se présente en java. Le fonctionnel a un coté naturel, comme l'impératif ou le procédural.
    La programmation objet pure pose des problèmes d'organisation mentale basique que ne pose pas les autres paradigmes : Où je mets mes méthodes ? A quel objet ou classe quand ces méthodes peuvent justement s'appliquer à plusieurs. Parfois ça peut paraitre évident, parfois absolument pas

    Bon le fait d'avoir écrit JS va surement m'attirer beaucoup de critiques, mais que je crois que la réalité est là, et que cela part de la popularité de ce langage, dans le monde anglo-saxon évidemment.
    Émotion
    Infantilisation
    Culpabilisation

    Christophe Alévèque - 18 Mars 2021

  20. #20
    Membre actif
    Homme Profil pro
    Développeur informatique
    Inscrit en
    Février 2006
    Messages
    70
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 37
    Localisation : France, Alpes Maritimes (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Développeur informatique
    Secteur : High Tech - Électronique et micro-électronique

    Informations forums :
    Inscription : Février 2006
    Messages : 70
    Points : 218
    Points
    218
    Par défaut
    Citation Envoyé par Zefling Voir le message
    Sauf qu'il me semble que ce n'est pas de l'objet ça.
    Et pourtant si. Il s'agit d'un objet de contrôle, dont la signature d'une méthode ressemble à ceci :

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    class Observable {
    ...
       public Observable do(LambdaFunction f);
    ...
    }
    Suivant les paradigmes, l'objet retourné peut être this, on une autre instance de la classe Observable (ce qui est le cas de ReactiveX : http://reactivex.io/ ) .

Discussions similaires

  1. Pourquoi ce programme ne m'affiche pas le bonjour
    Par phenix1988 dans le forum C++
    Réponses: 6
    Dernier message: 29/01/2009, 18h15
  2. Réponses: 3
    Dernier message: 04/03/2007, 10h34
  3. Réponses: 4
    Dernier message: 19/08/2006, 23h58

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo