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. #61
    Expert éminent sénior
    Profil pro
    Inscrit en
    décembre 2007
    Messages
    6 062
    Détails du profil
    Informations personnelles :
    Localisation : France, Hérault (Languedoc Roussillon)

    Informations forums :
    Inscription : décembre 2007
    Messages : 6 062
    Points : 28 052
    Points
    28 052
    Par défaut
    Je suis presque d'accord avec toi, à quelques détails près :

    Citation Envoyé par fredoche Voir le message
    je vois pas en quoi le fonctionnel pèserait sur la performance ?
    D'autres ont répondu.

    Citation Envoyé par fredoche Voir le message
    Tous ces débats me paraissent surannés. Ça fait 20 ans que je fais de l'appli web, j'ai toujours eu des SGBD(R), des serveurs web, du réseau, des navigateurs, de la programmation front et backend. Le langage là-dedans intervient à quelques endroits, mais bon... La réelle valeur ajoutée d'un bon développeur c'est de faire faire le job au bon stack (on disait tiers avant) pour lequel celui-ci est bien adapté.
    Oui, ça c'est vrai. Tant que tu as de bons développeurs. Il n'y en a pas assez pour tout le monde(jeunisme, diplomisme, etc.....)

    Citation Envoyé par fredoche Voir le message
    Et dans ce que tu évoques, faire de l'opération ensembliste, c'est juste évident que je le ferais dans mon SGBD, et que si je dois de toute façon en faire, il me faut un SGBD. Je ne pourrais jamais être aussi performant de manière programmatique que d'utiliser ce service qui est optimisé pour ça. Pour des outils que je connais comme SQL server, c'est 25 ans d'optimisation par des dizaines voir des centaines d'ingénieurs.
    (.../...)
    Peut-être que l'architecture est contrainte pour ce que tu évoques en COBOL... Mais je crois que je connais assez bien la problématique des (grands) projets informatiques à la française, et vu la publicité des réussites de ces dernières années, plus moi ce que j'ai pu voir dans mon propre parcours pro, je finis par avoir quelques intuitions sur le pourquoi du comment de beaucoup d'échecs.
    Voilà, tu as une idée du pourquoi je n'avais pas accès à SQL. 9 mois de paperasse pour avoir le droit de créer une base. Le délai du projet était inférieur à ça. Mais c'est la vraie vie, les contraintes auxquelles nous sommes soumises. Autre exemple : je suis dans un contexte ou livrer un modif en prod, c'est 4 minutes chrono, et faire modifier une table de paramétrage, c'est une semaine. Dans ce contexte, la bonne pratique de ne pas mettre de données en dur dans le programme, de tout mettre en paramétrage - parce-que c'est plus efficace à maintenir, ne tient pas. Je ne suis pas très fier de ça. Mais quand on me demandait un changement rapide, changement rapide il y avait.

    (merci d'envoyer les tomates trop mures à la rédaction, qui transmettra)

    Citation Envoyé par fredoche Voir le message
    Après quel que soit le langage, et la mise en forme adoptée (fonctionnel, objet, procédural), on arrive toujours à exprimer des idées, ou des traitements. C'est comme pour les langages humains, il existe des milliers de langues sur Terre, des centaines sous forme écrite, et ça n'empêche pas Tintin et Astérix d'être publié dans plusieurs dizaines d'entre elles, et de faire passer les mêmes messages.
    Sauf que certains idées passent mieux dans certains paradigmes que dans d'autres. 90% de mon boulot, en COBOL, c'était de longues suites de garnissages de données. Des scripts fonctionnels, quoi. Aucune algorithmique - à part parfois le rapprochement de fichiers. Le procédural, dans ce cas, c'est le plus efficace - ça va droit au but. Pas de fioritures fonctionnelles(l'immutabilité quand tu dois mettre à jour des montants, et que ta spec, c'est tout un tas de petites mises à jour successives, euh, tu oublies) ou objet(une classe avec 50 données et 2000 méthodes, c'est à peu près la seule manière de faire ça sans des découpages ineptes. Ai-je besoin de dire pourquoi il ne faut pas faire ça?).

    Les 10% restants étaient les plus marrants, et en même temps j'y ai senti les limites du procédural pur. Douloureusement pour cette histoire ensembliste. Mais j'ai réussi quand même. Comme tu dis, on arrive à faire passer les idées quand même.

    Citation Envoyé par Neckara Voir le message
    Je pense que la différence est plus que négligeable dans ces cas de figures, et ce qui importera sera plus le temps de développement.
    Sachant qu'au pire on peut toujours essayer de compiler le code python au lieu de directement l'interpréter.
    Réponse d'ingénieur : ça dépend. Mes clients actuels(des hôpitaux) ont tendance à faire des économies de bout de chandelle sur tout, et la problématique de performance pour eux est fondamentale...vu les brouettes dont ils disposent. Un de nos concurrents à quitté la France(et l'Espagne, de mémoire) la queue basse - sa solution demandait 10 fois plus de CPU que la notre. Aux USA, ils se donnent les moyens(en même temps, il faut voir le coût de leurs frais médicaux)

    Citation Envoyé par Neckara Voir le message
    Pour les cas plus "généraux", je pense qu'on est d'accord sur le fait que python sera légèrement plus lent que C/C++, mais que cela n'est pas très important au vu des machines actuelles, et qu'il y a d'autres facteurs plus limitants comme les I/O, la complexité de l'algo implémenté, etc.
    Deux points fondamentaux, l'algo et l'I/O. Que tu as bien raison de souligner. A ajouter un troisième point : le contexte. L'algo ensembliste que j'avais mis au point prenait une minute - sur un traitement total de 6 heures. Sur les 6 heures de la chaîne complète, tu avais facilement 5h30 d'I/O. Je n'ai donc pas optimisé l'algo - ça n'était pas pertinent.

    Le contexte, c'était que ça s'appliquait par agent, pas sur la volumétrie totale. Chaque agent n'avait pas plus de 150 entrées(par définition, on me faisait sabrer au delà) - et généralement moins de 50. Donc, l'algo immonde à la puissance 4 que j'avais fait ne débordait pas. Bien évidemment, si ils avaient voulu faire leurs regroupements sur toute la banque, j'aurais explosé le CPU. 1000 fois 50 à la puissance 4, contre 50 000 à la puissance 4... Ca fait un milliard de minutes, à vue de nez(sans calculatrice - si je me suis gouré, une correction est la bienvenue). Dans un autre contexte(banque entière et non pas chaque agent calculé séparément), mon algo aurait été définitivement inacceptable.

    A ce niveau, la puissance de la machine n'importe plus du tout. Un milliard de minutes, même en rajoutant du CPU, euh... Et justement, en utilisant des standards ensemblistes optimisés(genre SQL), on retombe sur des choses gérables en termes de performances. J'aurais eu bien du mal, avec du procédural, à approcher leurs performances, comme fredoche le dit si bien. C'est mon point : ce n'est pas toujours vrai, mais dans certains cas, le choix du paradigme est stratégique.

    (après, Python C++, je ne suis pas assez calé, je vous laisse vous écharper).
    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.

  2. #62
    Expert éminent sénior

    Avatar de Neckara
    Homme Profil pro
    Doctorant sécurité informatique — Diplômé master Droit/Économie/Gestion
    Inscrit en
    décembre 2011
    Messages
    8 561
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 26
    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 : 8 561
    Points : 21 481
    Points
    21 481
    Par défaut
    Citation Envoyé par SimonDecoline Voir le message
    Merci beaucoup, j'ai appris plein de choses et c'est complètement en rapport avec la discussion. Je ne m'y attendais vraiment pas.
    Ironise, pourtant c'est totalement en rapport avec la discussion.

    Citation Envoyé par Neckara Voir le message
    C'est vrai que je dois être super inexpérimenté de dire qu'on s'en fout du langage, qu'on s'en fout de ces 1s de temps d'exécution supplémentaire, et que ce qui importe, c'est surtout la bibliothèque qui te permet de faire tes 400 semaines de calculs en à peine 168h. Et qu'à 1s près de lenteur d'exécution, c'est négligeable.
    Si, pour les performances, les bibliothèques importent plus que le langage utilisé, et que le choix se fait en fonction du confort d'utilisation du langage, alors cela est aussi le cas pour le choix entre différents paradigmes ou langages appartenant à ces différents paradigmes.

    En reformulant, le choix entre un langage fonctionnel et un langage OO ne se fait pas sur les performances de ces derniers, mais sur leur facilité/confort d'utilisation, notamment au vu des bibliothèques disponibles.
    D'ailleurs C++ est généralement légèrement moins performant que C. Cependant on ne va pas qualifier C++ de langage "lent", la différence en terme de performance étant négligeable 99,999% du temps.
    En revanche, C++ offre une syntaxe et des bibliothèques qui permettent de coder plus "confortablement" qu'en C.

    Quant au langage dans lesquels les bibliothèques sont codées, on en a franchement rien à faire.
    Quand je fais un "import" en Python, je n'ai aucune idée du langage qu'il y a derrière, et en même temps, j'en ai rien à faire, c'est aussi le principe d'encapsulation.
    De même en C++, je n'ai aucune idée de ce qui a été développé en C, C++, ASM, ou si cela a été codé en C avec optimisations de 2-3 fonctions directement sur l'ASM généré.
    Pire en fonction de l'environnement d'exécution, le langage dans lequel a été implémanté la bibliothèque utilisé peut changer...


    Ça vaut bien le coup d'avoir des années d'expérience pour passer à côté de choses aussi basiques.
    "Parce que le diable est dans les détails, une vision sans nuance ne peut prétendre à la compréhension du monde."

    Mon ancienne page perso : https://neckara.developpez.com/

  3. #63
    Expert éminent sénior

    Avatar de Neckara
    Homme Profil pro
    Doctorant sécurité informatique — Diplômé master Droit/Économie/Gestion
    Inscrit en
    décembre 2011
    Messages
    8 561
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 26
    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 : 8 561
    Points : 21 481
    Points
    21 481
    Par défaut
    Citation Envoyé par el_slapper Voir le message
    Réponse d'ingénieur : ça dépend. Mes clients actuels(des hôpitaux) ont tendance à faire des économies de bout de chandelle sur tout, et la problématique de performance pour eux est fondamentale...vu les brouettes dont ils disposent. Un de nos concurrents à quitté la France(et l'Espagne, de mémoire) la queue basse - sa solution demandait 10 fois plus de CPU que la notre. Aux USA, ils se donnent les moyens(en même temps, il faut voir le coût de leurs frais médicaux)
    Il est difficile de savoir, je présumes, si la différence de calcul avec votre concurrent venait du langage utilisé, des bibliothèques utilisées, de la complexité des algorithmes, de mauvaises pratiques de développement (mauvaise gestion des I/O, de la mémoire), etc.

    J'ai un benchmark, qui montre (2ème réponse) peu de différences entre numpy et une implémentation C++ (calcul CPU) :
    https://stackoverflow.com/questions/...blas-and-numpy

    Pour le cas particulier des calculs intensifs sur GPU, c'est rare que le CPU soit le facteur limitant. Enfin, en théorie, ça ne devrait pas être le cas.


    Enfin tout cela pour dire que, bien que la performance puisse être relativement importante en fonction du contexte, la différence de performances entre python/C++ (ou d'autres langages) n'est pas forcément aussi grosse.
    Sachant que si le client est très "radin", il va, je présume, aussi regarder le prix que vous lui proposez, or le temps de développement et compétences requises influencent ce prix.


    Donc je suis d'accord que la performance globale de ton programme importe, cependant, je ne suis pas sûr que le langage utilisé soit le facteur le plus impactant.


    Citation Envoyé par el_slapper Voir le message
    Deux points fondamentaux, l'algo et l'I/O. Que tu as bien raison de souligner. A ajouter un troisième point : le contexte. L'algo ensembliste que j'avais mis au point prenait une minute - sur un traitement total de 6 heures. Sur les 6 heures de la chaîne complète, tu avais facilement 5h30 d'I/O. Je n'ai donc pas optimisé l'algo - ça n'était pas pertinent.
    Totalement d'accord. Il faut optimiser les "bottle neck" en suivant la loi de Pareto.

    Par contre, il faut quand même regarder la complexité si l'algo a pour objectif d'être scalable. Notamment éviter les complexité trop grandes (exponentielles ou factorielles ) qui vont très vite exploser si on augmente le nombre d'entrée.


    Citation Envoyé par el_slapper Voir le message
    Le contexte, c'était que ça s'appliquait par agent, pas sur la volumétrie totale. Chaque agent n'avait pas plus de 150 entrées(par définition, on me faisait sabrer au delà) - et généralement moins de 50. Donc, l'algo immonde à la puissance 4 que j'avais fait ne débordait pas. Bien évidemment, si ils avaient voulu faire leurs regroupements sur toute la banque, j'aurais explosé le CPU. 1000 fois 50 à la puissance 4, contre 50 000 à la puissance 4... Ca fait un milliard de minutes, à vue de nez(sans calculatrice - si je me suis gouré, une correction est la bienvenue). Dans un autre contexte(banque entière et non pas chaque agent calculé séparément), mon algo aurait été définitivement inacceptable.
    Totalement d'accord.

    Citation Envoyé par el_slapper Voir le message
    A ce niveau, la puissance de la machine n'importe plus du tout. Un milliard de minutes, même en rajoutant du CPU, euh... Et justement, en utilisant des standards ensemblistes optimisés(genre SQL), on retombe sur des choses gérables en termes de performances. J'aurais eu bien du mal, avec du procédural, à approcher leurs performances, comme fredoche le dit si bien. C'est mon point : ce n'est pas toujours vrai, mais dans certains cas, le choix du paradigme est stratégique.
    Je ne saurais pas trop me prononcer sur ce point, je ne sais pas exactement ce que tu fais.

    Par exemple, est-ce qu'en procédural il n'y aurait pas des bibliothèques dédiées à ce que tu fais, est-ce qu'il y aurait des astuces tricky en procédural, ou est-ce que tu n'avais pas d'autres solutions ?
    Après, c'est peut-être possible en procédural, mais demanderait un temps de développement bien trop important (e.g. 5 ans) pour se rapprocher de ta solution que tu auras codé relativement rapidement (e.g. 1 mois).

    Bref, comme je ne sais pas ce que tu fais, je ne saurais trop quoi en dire.
    "Parce que le diable est dans les détails, une vision sans nuance ne peut prétendre à la compréhension du monde."

    Mon ancienne page perso : https://neckara.developpez.com/

  4. #64
    Membre expert
    Profil pro
    Inscrit en
    décembre 2003
    Messages
    1 523
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : décembre 2003
    Messages : 1 523
    Points : 3 548
    Points
    3 548
    Par défaut
    Citation Envoyé par el_slapper Voir le message
    Le procédural, dans ce cas, c'est le plus efficace - ça va droit au but.
    Tu sais j'ai pas de souci avec ça, avec le procédural, je n'ai pas de chapelle. Je suis un fervent adepte du KISS : https://fr.wikipedia.org/wiki/Principe_KISS
    Quand tu liras ça, tu verras aussi qu'il est fait référence à Unix, au pipe, et au chainage de traitements simples donc.
    L'immutabilité c'est une chose, mais la réelle beauté du fonctionnel tient plus à la composition, qui n'est ni plus ni moins que du pipe.

    Dans ce sens chainer des traitements il n'y a guère de différence avec la méthode procédurale. Et ça va droit au but aussi.

    tu le dis toi-même :
    Des scripts fonctionnels, quoi
    Mais enfin je ne vais pas me battre là dessus. C'est l'esprit de chacun et sa capacité à appréhender ces concepts.

    En Cobol de toute façon pas de fonctionnel n'est-ce pas ?

  5. #65
    Membre actif
    Profil pro
    Inscrit en
    janvier 2011
    Messages
    99
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : janvier 2011
    Messages : 99
    Points : 234
    Points
    234
    Par défaut
    Intellectuellement, c'est sympa de faire du fonctionnel.
    Mais à maintenir, c'est une plaie.
    Même pour la personne qui a créé le code, retrouver comment une récursion a été pensé un an après devient très compliqué .
    Pour qq1 d'autre ça devient très chaud

  6. #66
    Membre expert
    Homme Profil pro
    Développeur informatique
    Inscrit en
    avril 2017
    Messages
    914
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Développeur informatique

    Informations forums :
    Inscription : avril 2017
    Messages : 914
    Points : 3 969
    Points
    3 969
    Par défaut
    Citation Envoyé par Neckara Voir le message
    Ça vaut bien le coup d'avoir des années d'expérience pour passer à côté de choses aussi basiques.
    Merci encore. C'est vraiment sympa de ta part de remettre les gens à leur place et de partager un peu de ton immense savoir. Grâce à toi la discussion sur la programmation fonctionnelle avance à pas de géant.

  7. #67
    Membre expert
    Homme Profil pro
    Développeur informatique
    Inscrit en
    avril 2017
    Messages
    914
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Développeur informatique

    Informations forums :
    Inscription : avril 2017
    Messages : 914
    Points : 3 969
    Points
    3 969
    Par défaut
    Citation Envoyé par pschiit Voir le message
    Intellectuellement, c'est sympa de faire du fonctionnel.
    Mais à maintenir, c'est une plaie.
    Même pour la personne qui a créé le code, retrouver comment une récursion a été pensé un an après devient très compliqué .
    Pour qq1 d'autre ça devient très chaud
    Je pense exactement le contraire : le fonctionnel est plus facile à maintenir, notamment parce qu'il y a moins de side effects. Les langages fonctionnels sont souvent haut-niveau et on a rarement besoin d'écrire des recursions. Le dernier projet "fonctionnel" sur lequel j'ai bossé a une centaine de fonctions et aucune n'est récursive. Par contre, il y a beaucoup de map/reduce, et c'est bien plus lisible que des boucles.

  8. #68
    Expert éminent sénior

    Avatar de Neckara
    Homme Profil pro
    Doctorant sécurité informatique — Diplômé master Droit/Économie/Gestion
    Inscrit en
    décembre 2011
    Messages
    8 561
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 26
    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 : 8 561
    Points : 21 481
    Points
    21 481
    Par défaut
    Citation Envoyé par SimonDecoline
    Désolé mais tout ça c'est de la rhétorique. Les performances de pytorch/tensorflow viennent de la partie C++, point.
    Citation Envoyé par SimonDecoline
    Ok tu m'as convaincu : gcc n'est pas capable de générer du SSE et pytorch/tensorflow reposent sur des grosses libs ASM sans lesquelles on aurait des perfs pourries.
    Citation Envoyé par SimonDecoline
    Oui, je sais, ma remarque précédente était ironique. En fait, ça fait des années que je bosse sur des calculateurs CPU et GPU, notamment avec tensorflow et pytorch, mais je ne me sentais pas trop d'entamer une discussion stérile et hors-sujet où Neckara m'aurait appris mon boulot, du haut de son expérience d'une semaine.
    Citation Envoyé par SimonDecoline Voir le message
    Merci beaucoup, j'ai appris plein de choses et c'est complètement en rapport avec la discussion. Je ne m'y attendais vraiment pas.
    Citation Envoyé par SimonDecoline Voir le message
    Merci encore. C'est vraiment sympa de ta part de remettre les gens à leur place et de partager un peu de ton immense savoir. Grâce à toi la discussion sur la programmation fonctionnelle avance à pas de géant.
    C'est sûr que tes réponses font bien plus avancer la discussion...
    Voilà presque tes seules contributions sur notre échange, aucun apport technique, l'aspect C++ de PyTorch/TensorFlow ayant été évoquée par un autre membre précédemment.


    Quand même dingue que malgré tes années d'expériences tu ne sois pas capable de me répondre sur l'aspect technique de mes réponses et te retrouve à ironiser en faisant valoir mon inexpérience comparée à la tienne.
    Or la seule preuve de ta compétence que tu nous donnes ici est ta déclaration d'en avoir une plus grosse.

    Tu es peut-être super compétent, mais ton comportement n'en est pas moins déplorable et indigne de ton expertise.


    Puis bon, ce n'est pas comme si mes réponses mettaient l'accent sur un point important : les bibliothèques disponibles importent plus que le langage lui-même (pour la vitesse d'exécution).
    Et que le choix du langage se fait sur la facilité/confort de développement qu'il offre, notamment via son offre de bibliothèques.
    "Parce que le diable est dans les détails, une vision sans nuance ne peut prétendre à la compréhension du monde."

    Mon ancienne page perso : https://neckara.developpez.com/

  9. #69
    Membre expert
    Homme Profil pro
    Développeur informatique
    Inscrit en
    avril 2017
    Messages
    914
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Développeur informatique

    Informations forums :
    Inscription : avril 2017
    Messages : 914
    Points : 3 969
    Points
    3 969
    Par défaut
    Citation Envoyé par Neckara Voir le message
    C'est sûr que tes réponses font bien plus avancer la discussion...
    Aucun de tes commentaires n'a de rapport avec le sujet de la programmation fonctionnelle. Si tu veux qu'on discute sérieusement, fais des commentaires sérieux en rapport avec le sujet.

  10. #70
    Expert éminent sénior

    Avatar de Neckara
    Homme Profil pro
    Doctorant sécurité informatique — Diplômé master Droit/Économie/Gestion
    Inscrit en
    décembre 2011
    Messages
    8 561
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 26
    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 : 8 561
    Points : 21 481
    Points
    21 481
    Par défaut
    Citation Envoyé par SimonDecoline Voir le message
    Aucun de tes commentaires n'a de rapport avec le sujet de la programmation fonctionnelle. Si tu veux qu'on discute sérieusement, fais des commentaires sérieux en rapport avec le sujet.
    Ben oui, mes commentaires ne sont soit pas sérieux soit pas en rapport avec le sujet.

    As-tu ne serais-ce que visionné la vidéo qui a lancé cette discussion ?
    Le choix d'un langage ne se fait pas uniquement sur les qualité intrasèque du langage (e.g. vitesse d'exécution), mais aussi et surtout sur tout ce qu'il y a à côté (e.g. bibliothèque, communauté).
    Le choix du paradigme étant très lié au choix du langage, pour utiliser un paradigme, il faut utiliser un langage l’implémentant.

    Et après tu te permets d'ironiser et de donner des leçons...
    "Parce que le diable est dans les détails, une vision sans nuance ne peut prétendre à la compréhension du monde."

    Mon ancienne page perso : https://neckara.developpez.com/

  11. #71
    Membre expert
    Homme Profil pro
    Développeur informatique
    Inscrit en
    avril 2017
    Messages
    914
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Développeur informatique

    Informations forums :
    Inscription : avril 2017
    Messages : 914
    Points : 3 969
    Points
    3 969
    Par défaut
    Citation Envoyé par Neckara Voir le message
    Ben oui, mes commentaires ne sont soit pas sérieux soit pas en rapport avec le sujet.
    Ben non. Tu es parti d'une remarque sur les performances c++/python et tu n'as parlé que de ça. Tes remarques les plus proches du sujet sont des généralités du genre "peu importe le langage, ce sont les libs qui sont importantes". C'est quoi le rapport avec la programmation fonctionnelle ?

    Citation Envoyé par Neckara Voir le message
    As-tu ne serais-ce que visionné la vidéo qui a lancé cette discussion ?
    Oh, une question rhétorique pour essayer de me décrédibiliser. Malheureusement pour toi, je connais Feldman depuis des années et j'ai vu presque toutes ses vidéos au moins une fois.

    Citation Envoyé par Neckara Voir le message
    Le choix d'un langage ne se fait pas uniquement sur les qualité intrasèque du langage (e.g. vitesse d'exécution), mais aussi et surtout sur tout ce qu'il y a à côté (e.g. bibliothèque, communauté).
    Le choix du paradigme étant très lié au choix du langage, pour utiliser un paradigme, il faut utiliser un langage l’implémentant.
    Quel rapport avec le sujet ? Si ton argument c'est que le fonctionnel ne permet pas d'avoir des libs et des communautés satisfaisantes, il va falloir développé.

    Citation Envoyé par Neckara Voir le message
    Et après tu te permets d'ironiser et de donner des leçons...
    Relis tes messages précédents et tu verras que tu es mal placé pour faire ce genre de reproche.

  12. #72
    Membre expérimenté
    Avatar de emixam16
    Homme Profil pro
    Doctorant en sécurité
    Inscrit en
    juin 2013
    Messages
    308
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Aube (Champagne Ardenne)

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

    Informations forums :
    Inscription : juin 2013
    Messages : 308
    Points : 1 571
    Points
    1 571
    Par défaut
    (Note: je vais rester totalement neutre dans ce post pour éviter d'enflammer inutilement le conflit)

    @Neckara, @SimonDecoline
    Franchement, votre discussion commence à tourner en dialogue de sourd. Je sais que chacun à le droit de défendre sa position mais je pense que vu à quel point la discussion a divergé, il serait plus préférable de la continuer dans un autre fil de discussion ou en privé.

    Comme dans n'importe quel débat, vous pouvez ne pas être d'accord avec votre interlocuteur mais si vous voulez le convaincre, essayez d'être bienveillant avec lui. Évitez ce qui peut s'apparenter à des attaques personnelles, ça va juste le braquer. Personnellement quand j'ai une critique à formuler, j'essaye d'insister aussi sur les points ou je suis d'accord, en général ça permet de garder un débat apaisé et enrichissant pour tout le monde.

    Bref, nous sommes sur internet et nous n'avons rien à vendre donc rien à gagner à imposer notre point de vue à des "inconnus". La seule chose à gagner ici c'est d'apprendre des choses. Donc à nous de tout faire pour améliorer les niveaux de la conversation. Ne répondons pas aux provocations.

    (Note: je suis désolé si ce message peut paraître "Bisounours", mais j'espère qu'il peut recentrer le débat sur le sujet originel )

    Je ne veux pas lancer un nouveau /hs, merci de ne pas répondre à ce message mais plutôt au sujet originel de ce thread!

  13. #73
    Membre éprouvé
    Profil pro
    Ingénieur système Linux N3
    Inscrit en
    juillet 2008
    Messages
    285
    Détails du profil
    Informations personnelles :
    Localisation : France, Ille et Vilaine (Bretagne)

    Informations professionnelles :
    Activité : Ingénieur système Linux N3

    Informations forums :
    Inscription : juillet 2008
    Messages : 285
    Points : 912
    Points
    912
    Par défaut Fonctionnel illisible
    Citation Envoyé par pschiit Voir le message
    Intellectuellement, c'est sympa de faire du fonctionnel.
    Mais à maintenir, c'est une plaie.
    Même pour la personne qui a créé le code, retrouver comment une récursion a été pensé un an après devient très compliqué .
    Pour qq1 d'autre ça devient très chaud
    Oui, et non.
    Une récursion un peu chiadée où le développeur n'a pas commenté ce qu'il a voulu faire, OK, mieux vaut ré-écrire en partant des specs.
    Pour une requête SQL ou l'exemple haskell quicksort, ça va...

  14. #74
    Expert éminent sénior

    Avatar de Neckara
    Homme Profil pro
    Doctorant sécurité informatique — Diplômé master Droit/Économie/Gestion
    Inscrit en
    décembre 2011
    Messages
    8 561
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 26
    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 : 8 561
    Points : 21 481
    Points
    21 481
    Par défaut
    Citation Envoyé par SimonDecoline Voir le message
    Malheureusement pour toi, je connais Feldman depuis des années et j'ai vu presque toutes ses vidéos au moins une fois.
    Grand bien te fasse.

    Tu devrais donc savoir que la vidéo qui a initié cette discussion ne parle pas une seule fois de l'avantage ou désavantage du paradigme fonctionnel sur les autres, mais propose une explication de la popularité des langages non-fonctionnels par le contexte historique, ainsi que par des features qui ne sont ni intrinsèques au langage, ni intrasèque au paradigme.

    Citation Envoyé par SimonDecoline Voir le message
    Tes remarques les plus proches du sujet sont des généralités du genre "peu importe le langage, ce sont les libs qui sont importantes". C'est quoi le rapport avec la programmation fonctionnelle ?
    Pour faire de la programmation fonctionnelle, tu n'utilises pas un langage ?
    Ce langage n'a pas de bibliothèques ?

    Tu ne vas pas choisir d'utiliser un langage plutôt qu'un autre, ou un paradigme plutôt qu'un autre, par le biais de plusieurs critères quels qu'ils soient, en fonction de tes besoins ?

    Citation Envoyé par SimonDecoline Voir le message
    Quel rapport avec le sujet ? Si ton argument c'est que le fonctionnel ne permet pas d'avoir des libs et des communautés satisfaisantes, il va falloir développé.
    Pour les libs, faut-il te rappeler la vidéo ? De mémoire il parle de "killer app". Par exemple Python a été très utilisé pour de deep/calcul intensif grâce à TensorFlow/PyTorch. Or pour, e.g. Haskell, il a fallu attendre 1 an avant d'avoir les premiers bindings Torch, sachant que ce n'est pas un binding officiel, et que seule l'API Python a une garantie de stabilité. C'est un critère important, et cela ramène des utilisateurs vers Python.

    Regarde le forum, quels langages sont mis en avant ? Cela est directement lié à la communauté qu'il y a derrière le langage.
    Si tu regarde le sous-forum Haskell y'a presque rien, 5 sujets en 2019. En comparaison, C/C++ a son propre groupe de forum, il a 6 sujets rien qu'aujourd'hui (et je lui ai connu des périodes bien plus actives).
    (sujets dont la dernière rréponse date d'aujourd'hui).

    Quand tu vas dans commencer à apprendre la programmation de manière autodidacte, vers quels langages vas-tu te tourner ?
    Idem, dans l'éducation supérieur quels sont les langages les plus fréquemment enseignés ?

    Cela impact énormément le choix du langage et de paradigme sur tes projets, ce, plus la dette technique.
    Derrière, ce n'est pas qu'une histoire d'avoir une bonne communauté réactive, mais d'avoir une très bonne communauté très réactive à tout endroit.
    Si tu n'es pas devant tes concurrents, tu es derrière.


    Je n'ai aussi pas parlé que de libs et de communauté, mais aussi de confort/facilité d'utilisation du langage (et par extension du paradigme).
    N'est-ce pas justement un critère important ?

    N'est-il pas aussi important de noter que la notion de vitesse d'exécution intrasèque du langage n'est pas vraiment un critère pertinant, sauf cas exceptionnels ?


    Citation Envoyé par SimonDecoline Voir le message
    Ben non. Tu es parti d'une remarque sur les performances c++/python et tu n'as parlé que de ça.
    Tout ce que j'ai dis sur BLAS peut s'appliquer à tout autre langage.
    "Parce que le diable est dans les détails, une vision sans nuance ne peut prétendre à la compréhension du monde."

    Mon ancienne page perso : https://neckara.developpez.com/

  15. #75
    Membre expert
    Profil pro
    Inscrit en
    décembre 2003
    Messages
    1 523
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : décembre 2003
    Messages : 1 523
    Points : 3 548
    Points
    3 548
    Par défaut
    Citation Envoyé par el_slapper Voir le message
    D'autres ont répondu.
    Dans la vidéo d'intro, à partir de 44:05 le gars y répond.
    Et en gros à moins que tu aies vraiment des besoins spécifiques, alors C/C++/RUST, sinon la plupart des langages sont à garbage collector. Et il conclue sur la notion de mythe sur le fait que le style fonctionnel soit lent


    Citation Envoyé par Neckara Voir le message
    Idem, dans l'éducation supérieur quels sont les langages les plus fréquemment enseignés ?
    Mon fiston en 2e année d'IUT info a étudié pour l'instant :
    Pascal
    C / C++
    C# / Java
    et PHP
    Surtout du java visiblement

    Et je trouve vraiment scandaleux qu'il n'ait pas eu encore un seul cours de Javascript. Ce sur quoi je soupçonne encore une forte méconnaissance de ce langage dans le domaine universitaire français, et la profonde inertie qui de plus caractérise notre pays. Le reflet pur et simple de ce que je vois sur ce forum où c'est listé comme le langage le plus détesté car probablement le plus méconnu. Avec probablement en plus le coté non prestigieux, non académique de ce langage pour des universitaires.

    C'est des trains de retard et des gamins qui vont devoir se former à la dure ou sur le tas sur un langage quasi universel et qui a beaucoup de spécificités pointues

    Citation Envoyé par Neckara Voir le message
    N'est-il pas aussi important de noter que la notion de vitesse d'exécution intrasèque du langage n'est pas vraiment un critère pertinant, sauf cas exceptionnels ?
    Voir plus haut les dernières minutes de la vidéo

  16. #76
    Expert éminent sénior

    Avatar de Neckara
    Homme Profil pro
    Doctorant sécurité informatique — Diplômé master Droit/Économie/Gestion
    Inscrit en
    décembre 2011
    Messages
    8 561
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 26
    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 : 8 561
    Points : 21 481
    Points
    21 481
    Par défaut
    Citation Envoyé par fredoche Voir le message
    Et je trouve vraiment scandaleux qu'il n'ait pas eu encore un seul cours de Javascript. Ce sur quoi je soupçonne encore une forte méconnaissance de ce langage dans le domaine universitaire français, et la profonde inertie qui de plus caractérise notre pays.
    2 ans c'est très court.

    De souvenir, j'ai eu très rapidement du JS en ingé lors de cours de web (avec HTML/CSS), mais rien sur e.g. Webpack, NPM, ou autre.
    Le principe est de se dire qu'on te donne les bases dans plusieurs domaines, et que ce sera à toi de t'auto-former pour approfondir les domaines qui te seront utiles.

    Pour l'IUT, je ne saurais dire si j'en avais fait ou non.


    Sachant qu'en plus la tendance est à la baisse du nombre d'heures dans les formations pour faire des économies budgétaires…



    Citation Envoyé par fredoche Voir le message
    Le reflet pur et simple de ce que je vois sur ce forum où c'est listé comme le langage le plus détesté car probablement le plus méconnu.
    Ce n'est pas parce qu'on aime pas qu'on méconnait.

    Du JS j'en bouffe en permanence et je suis très loin de le porter dans mon cœur. Je préfère de loin la syntaxe du Python, ce bien avant même de bien connaître Python.

    J'utilise JS car c'est actuellement le plus adapté à mes besoins, et j'aime grandement les paquets fournis par NPM.
    Cependant, il y a des choses que j'ai du mal à pardonner à JS, comme la manière dont il gère les entiers.


    Citation Envoyé par fredoche Voir le message
    Voir plus haut les dernières minutes de la vidéo
    Oui, c'est un mythe, mais c'est aussi un critère non-pertinent.

    En revanche pour parler de lenteur… j'ai vu des applications qui se basaient sur une couche Matlab… ça mettait une minute à se charger.
    "Parce que le diable est dans les détails, une vision sans nuance ne peut prétendre à la compréhension du monde."

    Mon ancienne page perso : https://neckara.developpez.com/

  17. #77
    Membre expert
    Homme Profil pro
    Développeur informatique
    Inscrit en
    avril 2017
    Messages
    914
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Développeur informatique

    Informations forums :
    Inscription : avril 2017
    Messages : 914
    Points : 3 969
    Points
    3 969
    Par défaut
    Citation Envoyé par CaptainDangeax Voir le message
    Oui, et non.
    Une récursion un peu chiadée où le développeur n'a pas commenté ce qu'il a voulu faire, OK, mieux vaut ré-écrire en partant des specs.
    Pour une requête SQL ou l'exemple haskell quicksort, ça va...
    Quand on utilise un langage fonctionnel au quotidien, on fait assez peu de récursivité en fait. On utilise généralement des fonctions de plus haut niveau, qui masque complètement leur fonctionnement interne récursif.
    Pour une requète SQL, il n'y a pas besoin de récursivité, il suffit juste d'appeler une fonction du driver du SGBD, comme dans les autres paradigmes.
    Quant au quicksort, la récursivité vient de l'algo lui-même et non du langage. D'ailleurs même dans la libc, qsort est implémenté de façon récursive.

  18. #78
    Membre expert
    Homme Profil pro
    Développeur informatique
    Inscrit en
    avril 2017
    Messages
    914
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Développeur informatique

    Informations forums :
    Inscription : avril 2017
    Messages : 914
    Points : 3 969
    Points
    3 969
    Par défaut
    Citation Envoyé par fredoche Voir le message
    Mon fiston en 2e année d'IUT info a étudié pour l'instant :
    Pascal
    C / C++
    C# / Java
    et PHP
    Surtout du java visiblement

    Et je trouve vraiment scandaleux qu'il n'ait pas eu encore un seul cours de Javascript.
    Moi, ce qui me choque c'est que ça fait 6 langages en 2 ans, mais aucun langage fonctionnel. Et après on va dire que le fonctionnel n'est pas naturel. Bah c'est un peu logique si on ne l'aborde pas dans les formations...

  19. #79
    Expert éminent sénior

    Avatar de Neckara
    Homme Profil pro
    Doctorant sécurité informatique — Diplômé master Droit/Économie/Gestion
    Inscrit en
    décembre 2011
    Messages
    8 561
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 26
    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 : 8 561
    Points : 21 481
    Points
    21 481
    Par défaut
    Citation Envoyé par SimonDecoline Voir le message
    D'ailleurs même dans la libc, qsort est implémenté de façon récursive.
    L'implémentation semble être itérative, en simulant la récursivité via une stack (ce qui est assez commun) :

    1. Non-recursive, using an explicit stack of pointer that store the next array partition to sort.
    https://github.com/lattera/glibc/blo...stdlib/qsort.c


    D'ailleurs question stupide, pour un langage fonctionnel, comment les récursions sont gérées en interne ?
    Il passent comme des appels de fonctions avec tout ce que cela implique au niveau des registres CPU/la pile, ou c'est transformé dans une version itérative via une stack ?


    Moi, ce qui me choque c'est que ça fait 7 langages en 2 ans, mais aucun langage fonctionnel. Et après on va dire que le fonctionnel n'est pas naturel. Bah c'est un peu logique si on ne l'aborde pas dans les formations...
    Ben prend n'importe quel classement des langages TIOBE, popularité, utilisation github, t'as pas beaucoup de langages fonctionnels dans le top.
    Le but de l'éducation supérieur c'est aussi de former à ce que les étudiants seront le plus probablement amené à utiliser.

    Ce n'est pas le rôle de l'éducation supérieur de prendre parti et de décider qu'il faut faire du fonctionnel parce que c'est le paradigme que j'aime.
    Déjà qu'on a pas le temps de creuser en détails tous les bon principes de développement (e.g. ssémantique d'entité/de valeur).

    https://emploi.developpez.com/actu/2...lent-vraiment/
    https://www.tiobe.com/tiobe-index/
    https://githut.info/
    "Parce que le diable est dans les détails, une vision sans nuance ne peut prétendre à la compréhension du monde."

    Mon ancienne page perso : https://neckara.developpez.com/

  20. #80
    Membre régulier
    Homme Profil pro
    autre
    Inscrit en
    septembre 2015
    Messages
    53
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Yvelines (Île de France)

    Informations professionnelles :
    Activité : autre

    Informations forums :
    Inscription : septembre 2015
    Messages : 53
    Points : 109
    Points
    109
    Par défaut
    Citation Envoyé par Neckara Voir le message
    Quant au langage dans lesquels les bibliothèques sont codées, on en a franchement rien à faire.
    Quand je fais un "import" en Python, je n'ai aucune idée du langage qu'il y a derrière, et en même temps, j'en ai rien à faire, c'est aussi le principe d'encapsulation.
    Indirectement, c’est important, puisque cela conditionne les performances. Ainsi, lorsque je trace une figure, autant que les fonctions de tracé (driver graphique), ne vérifient pas le type des paramètres à chaque pixel ce qui ferait tout ralentir. Mais effectivement c’est le résultat qui compte.

    Pour le programme appelant, cela dépend si ses performances sont importantes (une IHM qui répond en 0,01s ou 0,02s ne fera pas la différence), et sont conditionnées par les bibliothèques (90% du temps dans BLAS ou FFTW rendrait peu pertinent une optimisation au niveau des procédures appelantes. Un 10% dans les bibliothèques et on peut s’intéresser à optimiser le code ou prendre un meilleur langage).

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