Discussion :

[el_slapper]

Je suis presque d'accord avec toi, à quelques détails près :

je vois pas en quoi le fonctionnel pèserait sur la performance ?

D'autres ont répondu.

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.....)

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)

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.

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)

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).

[Neckara]

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.

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.

[Neckara]

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.

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.

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.

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.

[fredoche]

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 ?

[pschiit]

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

[Invité]

Ç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.

[Invité]

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.

[Neckara]

Désolé mais tout ça c'est de la rhétorique. Les performances de pytorch/tensorflow viennent de la partie C++, point.

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.

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.

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.

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.

[Invité]

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.

[Neckara]

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...

[Invité]

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 ?

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.

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é.

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.

[emixam16]

(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!

[CaptainDangeax]

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...

[Neckara]

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.

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 ?

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 ?

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.

[fredoche]

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

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

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

[Neckara]

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…

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.

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.

[Invité]

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.

[Invité]

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...

[Neckara]

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/

[floyer]

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).