Discussion :

[WhiteCrow]

@23JFK … «Une fonction récursive c'est mal car ça fait exploser la pile»

Comment te dire … utiliser la récursivité quand on programme c'est une chose, l'utiliser quand on code c'est une autre chose, et, comme le rappelle L. Lamport, malheureusement vous êtes bien trop nombreux à ne pas faire la différence.
Là où éventuellement je pourrais peut-être te rejoindre est qu'il ne faut pas l'utiliser juste pour l'utiliser. Il faut simplement l'utiliser là où elle est utile voire nécessaire. Personne ne l'utiliserait, hors apprentissage et exemple, pour un calcul de factorielle. Tout le monde a intérêt à l'utiliser quand on manipule des sdd récursives et elles sont nombreuses et utilisées partout.
Elles sont utiles et utilisées car elles rendent le code plus lisible et plus maintenable, sans compter que le code est plus facilement débugable et ne t'en déplaise vérifiable. Si tu n'en veux pas tu vas de toute façon utiliser une version «dérécursivée» et tu feras sans doute un moins bon job avec.
Maintenant si j'extrapole ce Lamport raconte, c'est que pour ce cas, le grand avantages est de penser bien avant le code comment on doit ou peut faire. Si tu n'as jamais fait ça tu n'y arriveras pas et tu resteras enfermé dans un mode de pensée qui ne te permettra pas d'avancer. Tu ne découvriras jamais l'approche de la programmation dynamique par exemple.

Il faut arrêter de penser immédiatement que le code qui implémente un programme sera traduit mot à mot par le compilo … une récursivité terminale est éliminable facilement et le sera par tout compilo moderne … y compris pour la factorielle si elle est bien codée.

Quant aux «algorithmes mathématiques inutilisables», pense simplement à un quicksort, un A*, un LCS … parce que oui, l'algo c'est des math et les algos servent aussi à produire du code efficace.
T'es pas obligé d'être bon en math pour savoir coder, mais pour coder efficacement c'est un avantage indéniable, tout comme comprendre la récursivité est un atout.

[commandantFred]

@23JFK … «Une fonction récursive c'est mal car ça fait exploser la pile»
(...)

Il faut arrêter de penser immédiatement que le code qui implémente un programme sera traduit mot à mot par le compilo … une récursivité terminale est éliminable facilement et le sera par tout compilo moderne … y compris pour la factorielle si elle est bien codée.

Quant aux «algorithmes mathématiques inutilisables», pense simplement à un quicksort, un A*, un LCS … parce que oui, l'algo c'est des math et les algos servent aussi à produire du code efficace.
T'es pas obligé d'être bon en math pour savoir coder, mais pour coder efficacement c'est un avantage indéniable, tout comme comprendre la récursivité est un atout.

Quicksort et quicksearch (recherche dichotomique) ont été publiés dans les années 60. La récursivité permet de faire un code très court mais dans les faits, on a tellement besoin de performance quand on les implémente dans un B-Tree qu'on les convertit en itératif. On supprime donc tout le protocole des appels de fonction (calcul de pile, stockage pointeur de pile, adresse de retour...)

A* est encore plus sensible à la performance. C'est un Dijkstra (un matheux polonais) avec une heuristique optimiste pour "estimer" la bonne direction. Mais les algos de recherche de chemin sont intrinsèquement lents et sur-sollicités de sorte que plusieurs constructeurs ont développé des puces à accélération matérielle pour décharger le cpu (NVidia, Tesla, Tomtom, ...) . On peut voir Dijkstra comme un exercice de TP si on est étudiant, on l'écrit en récursif et on aura une bonne appréciation mais si on doit parcourir un arbre de millions de noeuds par tranche de 16 millisecondes, on finit par désassembler le code pour gagner des petits cycles machine et fatalement, on supprime la récursion pour les mêmes raisons que pour quickSort.

La récursion, c'est aussi la gestion des parenthèses, accolades... Et les arbres de type file system... Dans ce cas, la performance est moins critique.

Je citerais aussi la FFT optimisée en DCT (discrete cosine transform) pour la compression de signal. (Une télévision en effectue des millions par seconde grâce à sa puce de décompression).

Alors oui les maths sont utiles mais ces travaux n'ont lieu qu'une fois par projet et représentent 1 à 2 % du travail de développement.
Les 98% restants sont de la gestion de données, des contrôles utilisateur...

D'autre part, un développeur n'écrit pas de FFT ni de Dijkstra, ni de quicksort (j'ai écrit un algo de tri par swap en 1992, je m'en rappelle encore !) - il utilise une librairie ou fait un portage depuis un code externe. Si vous l'écrivez quand même, c'est soit pour vous amuser, soit parce que vous ne connaissez pas la fonction implémentée dans le langage que vous utilisez.

Si un dev dit qu'il a écrit une FFT en partant de la formule mathématique, non seulement, personne ne le croira mais je pense que les gens vont éviter de lui adresser la parole ensuite. Il boira ses cafés seul.

La conséquence logique est que si vous avez besoin d'un algo mathématique pointu (traitement de signal ?) vous appelez un consultant pour écrire une librairie destinée à vos développeurs. Si vous avez la compétence en interne , tant mieux mais rappelez-vous que le gars aura une tâche très ingrate. Voilà ce que me disent 40 années passées dans ce milieu. L'auteur de la librairie FFT a fini chômeur parce qu'il n'y avait plus de boulot pour lui une fois la librairie terminée.

Donc , encore une fois, les développeurs doivent surtout implémenter un algorithme. Le réécrire est absurde ou relève d'une prestation ponctuelle. (projet dans le projet)

1. Voir Dijkstra, FFT etc... sur rosettacode.org

[Shepard]

Quicksort et quicksearch (recherche dichotomique) ont été publiés dans les années 60. La récursivité permet de faire un code très court mais dans les faits, on a tellement besoin de performance quand on les implémente dans un B-Tree qu'on les convertit en itératif. On supprime donc tout le protocole des appels de fonction (calcul de pile, stockage pointeur de pile, adresse de retour...)

En tout cas, PostgreSQL (https://github.com/postgres/postgres.../nbtree/README) et SQLite (https://github.com/mackyle/sqlite/bl...er/src/btree.c) utilisent des versions récursives.

A* est encore plus sensible à la performance. C'est un Dijkstra (un matheux polonais) avec une heuristique optimiste pour "estimer" la bonne direction. Mais les algos de recherche de chemin sont intrinsèquement lents et sur-sollicités de sorte que plusieurs constructeurs ont développé des puces à accélération matérielle pour décharger le cpu (NVidia, Tesla, Tomtom, ...) . On peut voir Dijkstra comme un exercice de TP si on est étudiant, on l'écrit en récursif et on aura une bonne appréciation mais si on doit parcourir un arbre de millions de noeuds par tranche de 16 millisecondes, on finit par désassembler le code pour gagner des petits cycles machine et fatalement, on supprime la récursion pour les mêmes raisons que pour quickSort.

Ok, mais les puces de NVidia, Testla et Tomtom, elles utilisent de la récursion, ou pas ? Par rapport aux cycles CPU (du coup on est revenus dans le domaine du software), ça dépend du langage de programmation. Mais les microprocesseurs utilisent des jump/goto et donc une boucle ou de la récursion reviennent exactement au même.

Voir aussi https://stackoverflow.com/questions/...r-than-looping

La récursion, c'est aussi la gestion des parenthèses, accolades... Et les arbres de type file system... Dans ce cas, la performance est moins critique.

Qui décide ça ? Une bonne librairie a quand même pour rôle de fournir la meilleure solution possible à un problème, non ? Sinon elle disparaît au profit d'une autre librairie qui le fera.

Je citerais aussi la FFT optimisée en DCT (discrete cosine transform) pour la compression de signal. (Une télévision en effectue des millions par seconde grâce à sa puce de décompression).

Je ne sais pas comment fonctionne la puce de décompression d'une télé. Par contre au niveau software, FFTW3 qui est la référence dans le domaine, est implémenté de manière récursive (https://www.google.com/url?sa=t&rct=...Gc6yBDM4e6HHxQ).

Alors oui les maths sont utiles mais ces travaux n'ont lieu qu'une fois par projet et représentent 1 à 2 % du travail de développement.
Les 98% restants sont de la gestion de données, des contrôles utilisateur...

Je pense que ça dépend fortement du domaine dans lequel tu travailles.

D'autre part, un développeur n'écrit pas de FFT ni de Dijkstra, ni de quicksort (j'ai écrit un algo de tri par swap en 1992, je m'en rappelle encore !) - il utilise une librairie ou fait un portage depuis un code externe. Si vous l'écrivez quand même, c'est soit pour vous amuser, soit parce que vous ne connaissez pas la fonction implémentée dans le langage que vous utilisez.

Crois-le ou non, ça n'a rien de sorcier ... Mais effectivement, c'est du temps perdu. Tout le monde utilise FFTW3.

La conséquence logique est que si vous avez besoin d'un algo mathématique pointu (traitement de signal ?) vous appelez un consultant pour écrire une librairie destinée à vos développeurs. Si vous avez la compétence en interne , tant mieux mais rappelez-vous que le gars aura une tâche très ingrate. Voilà ce que me disent 40 années passées dans ce milieu. L'auteur de la librairie FFT a fini chômeur parce qu'il n'y avait plus de boulot pour lui une fois la librairie terminée.

Ça dépend du tempérament et des attentens du dévelopeur. Implémenter Levenshtein m'intéresse bien plus que faire une interface web qui appelle une API.

Donc , encore une fois, les développeurs doivent surtout implémenter un algorithme. Le réécrire est absurde ou relève d'une prestation ponctuelle. (projet dans le projet)

Je pense que tu sous-estimes tes compétences. Quelqu'un qui sort de l'école et qui a suivi une formation de web developer est incapable d'implémenter un algorithme tel que A* correctement.

[commandantFred]

Questions intéressantes.

Ce n'est en tout cas pas le cas pour PostgreSQL (https://github.com/postgres/postgres.../nbtree/README) ni pour SQLite (https://github.com/mackyle/sqlite/bl...er/src/btree.c).

Ok, j'ai extrapolé les conclusions d'un team de jeu à quickSort, c'est audacieux. Quicksort est un algo vieux comme le monde et utilise un callback qui complique sérieusement le calcul de perf.
Déplier les boucles, supprimer les divisions, éviter les sqrt()... a toujours beaucoup de sens aujourd'hui. Par contre, les IF et appels de fonction sont optimisés par la prédiction de branchement. Je ne suis pas à jour là dessus.
De même, il ne sert plus à rien d'optimiser les calculs sur des entiers. Toutes les librairies modernes utilisent le GPU même en l'absence de puce dédiée. (jeux d'instructions MMX, SSE...)

Faire un benchmark décent pour comparer les techniques prend plusieurs jours.

Ok, mais les puces de NVidia, Testla et Tomtom, elles utilisent de la récursion, ou pas ? Par rapport aux cycles CPU (du coup on est revenus dans le domaine du software), ça dépend du langage de programmation. Mais les microprocesseurs utilisent des jump/goto et donc une boucle ou de la récursion reviennent exactement au même.

Voir aussi https://stackoverflow.com/questions/...r-than-looping

Bonne question. Le câblage peut rendre la gestion de pile quasi transparente.
Par contre, les tests de nœuds adjacents sont parallélisés. Dès lors, l'avantage de la récursion devient très relatif. Un petit défaut de la récursion est qu'elle parcoure chaque branche jusqu'au nœud terminal avant de passer à la branche suivante. Si le process temps réel est interrompu, on n'a pas évalué le premier niveau de profondeur en entier. La récursivité est donc "non-interruptible"...

Qui décide ça ? Une bonne librairie a quand même pour rôle de fournir la meilleure solution possible à un problème, non ? Sinon elle disparaît au profit d'une autre librairie qui le fera.

Pour la gestion d'arbres ou l'imbrication d'opérateurs "()[]{} if/endif" , la récursivité est parfaite de mon point de vue. Par contre, une librairie "stratégique" comme HTML/Javascript utilise un parser en mode "automate". Chaque caractère change l'état de l'analyseur syntaxique, les traitements sont déportés derrière un array de pointeurs sur fonction (ou delegates). Impossible de faire récurser un parser. Or c'est l'algorithme telecom le plus fiable de l'avis de tous.
Par contre, pour gérer un langage stocké dans un fichier, on peut utiliser des REGEX (ou bidouiller les strings à la main). Dans ce cas, la récursivité est d'un grand secours selon moi.

Je ne sais pas comment fonctionne la puce de décompression d'une télé. Par contre au niveau software, FFTW3 qui est la référence dans le domaine, est implémenté de manière récursive (https://www.google.com/url?sa=t&rct=...Gc6yBDM4e6HHxQ).

Là, on entre dans un domaine que je connais bien.
Faster Fourier Transform in the West m'a donné du fil à retordre. En fait, le nom est assez explicite, c'est bien si on a beaucoup de temps à consacrer à l'étude de la FFT. C'est un peu une blague d'étudiant.
Une fois les notions apprivoisées, il faut l'oublier. FFT est une technique beaucoup trop stratégique pour qu'une simple librairie software fasse référence. Toutes les déclinaisons de la conversion temporel/séquentiel sont calculées sur GPU, y compris le fenêtrage (Hanning). En l'absence de GPU, une émulation basée sur MMX/SSE sera substituée (un peu comme au temps des FPU émulées sur 486). FFT est une discipline scientifique (traitement de signal) , on n'est plus vraiment sur de l'algorithmique. C'est plus gros.

Je pense que ça dépend fortement du domaine dans lequel tu travailles.

Je comprends ça en regardent mes points de popularité auprès des étudiants...
Néanmoins, il faut se mettre à la place d'un mathématicien seul dans une équipe de développeurs qui s'arrachent les cheveux sur l'IHM, les BDD. Le management n'aime les maths que si on compte les sous en général. Les managers écoutent plutôt les développeurs qui gèrent l'IHM parce que c'est là que se décide la productivitédu software (et son visuel). Si un matheux parle de trigonométrie ou de récursivité lors des réunions, la plupart des gens vont s'endormir. On est très seul dans ce genre de job.

Crois-le ou non, ça n'a rien de sorcier ... Mais effectivement, c'est du temps perdu. Tout le monde utilise FFTW3.

Voir plus haut

Ça dépend du tempérament et des attentens du dévelopeur. Implémenter Levenshtein m'intéresse bien plus que faire une interface web qui appelle une API.

Oui, le tempérament, c'est important.
Une API Web qui devraient t'intéresser : WebGL. Il y a de quoi faire des maths 24/7 et l'API est tellement bien écrite qu'on se sent fier de l'utiliser. En plus , c'est très standardisé ce qui met à l'abri de l'obsolescence.
Une des pires expériences de développeur que j'ai vu si souvent est celle où on réalise qu'on a bossé dix ans sur un outil qui est stoppé par son éditeur ou remplacé par quelque chose de complètement différent. WebGL est une bonne garantie et la demande devrait croitre sans fin avec le cloud.

Je pense que tu sous-estimes tes compétences. Quelqu'un qui sort de l'école et qui a suivi une formation de web developer est incapable d'implémenter un algorithme tel que A* correctement.

Merci pour ton post intéressant (et sympa).

[kain_tn]

Citation : de très beaucoup concepts mathématiques donnent de la bonne grosse merde en programmation exemple: la récurrence.

Une phrase comme ça, c'est quasiment le plus bel argument pour dire : de meilleures connaissances en maths, ce serait quand même un plus pour les informaticiens.

Pour les absolutistes de la récursion en programmation, ça pose souvent des problèmes de piles. Maintenant c'est caché par le gigantisme des mémoires par rapport à de petites fonctions qui s'appellent-elles mêmes, mais à la fin, c'est toujours le manque de RAM qui gagne. Il y a aussi le problème de réalisme des maths qui ne tiennent généralement pas compte du temps de résolution du problème alors que dans le monde réel, c'est un point critique de la programmation.

J'avais un prof qui voulait que l'on foute de la récursion partout dès que cela était possible ; un vrai absolutiste. Il ne voulait pas entendre que chaque appel de fonction empilait des données qu'il faudrait au mieux désempiler, au pire qui ferait tout bonnement planter le programme. Les maths n'intègrent pas implicitement les données fondamentales de temps et de limites physiques. Il y a des tas d'algorithmes mathématiques inutilisables à cause de ces deux contraintes fortes du monde réel pour les machines de monsieur tout le monde, c'est parfois un avantage comme en cryptographie, mais plus souvent un inconvénient.

Avec des langages fonctionnels purs, la récursion ne pose pas de problème. Il y a des optimisations de compilation qui permettent de transformer une récursion en simple boucle.

On en revient donc au problème habituel: bien comprendre la stack sur laquelle on travaille.

Il faut arrêter de penser immédiatement que le code qui implémente un programme sera traduit mot à mot par le compilo … une récursivité terminale est éliminable facilement et le sera par tout compilo moderne … y compris pour la factorielle si elle est bien codée.

Merci.

Donc , encore une fois, les développeurs doivent surtout implémenter un algorithme. Le réécrire est absurde ou relève d'une prestation ponctuelle. (projet dans le projet)

Je ne suis pas tout à fait d'accord: si l'on étend cette manière de penser à d'autres corps de métiers, alors le développeur n'a pas non plus à comprendre les règles métier de sa société puisqu'il doit se contenter de les implémenter, et on justifie de ce fait l'image du développeur qui "pisse du code", au lieu d'une personne versatile, capable d'un raisonnement poussé.

Personne (ou presque) ne va réimplémenter une bibliothèque de chiffrement par exemple, par contre bien comprendre ce qui se passe en dessous permet de l'utiliser efficacement et de ne pas mettre en place un chiffrement défectueux par nature.

[rafoim]

Les maths n'intègrent pas implicitement les données fondamentales de temps et de limites physiques. Il y a des tas d'algorithmes mathématiques inutilisables à cause de ces deux contraintes fortes du monde réel pour les machines de monsieur tout le monde.

Tu peux faire une modélisation mathématique en partant du principe que tu possèdes une machine théorique ayant une mémoire finie. Puis, tu peux améliorer en construisant un second modèle qui prend en compte des limitations que tu introduis afin de de te rapporter à des limites physiques. D'ailleurs, de manière générale, il me semble que les maths modélisent plutôt bien la réalité physique ( voir science physique. Pour dire les choses autrement, les maths ne sont pas une opinion et encore moins une religion pro-récurrence. Il n'y pas de "parti pris" des maths.

[rafoim]

Tu peux faire une modélisation mathématique en partant du principe que tu possèdes une machine théorique ayant une mémoire finie.

Je voulais dire une mémoire infinie. Mes excuses.

[23JFK]

Tu peux faire une modélisation mathématique ... il me semble que les maths modélisent plutôt bien la réalité physique ( voir science physique.

Bah non ?... Les mathématiques n'ont absolument aucun rapport obligé avec le réel. C'est la physique qui pose des limites observées du réel aux outils mathématiques. Les théories des cordes permettent tout et n'importe quoi en matière d'univers, tandis que les équations de Newtons ne rendent finalement que très partiellement compte de la réalité par rapport à la Théorie de la Relativité Générale qui elle-même échoue aux cas limites (physique quantique, singularité des trous noires).

[rafoim]

Bah non ?... Les mathématiques n'ont absolument aucun rapport obligé avec le réel. C'est la physique qui pose des limites observées du réel aux outils mathématiques. Les théories des cordes permettent tout et n'importe quoi en matière d'univers, tandis que les équations de Newtons ne rendent finalement que très partiellement compte de la réalité par rapport à la Théorie de la Relativité Générale qui elle-même échoue aux cas limites (physique quantique, singularité des trous noires).

Je n'ai pas dit que les mathématiques avaient un rapport obligé au réel. j'ai même dit exactement le contraire, à savoir que le mathématicien peut faire le choix de modéliser certaines contraintes issues du réel, effectivement fournies par l'expérimentation en physique.. Et c'est le principe de l'utilisation des maths en sciences physiques. Les mathématiques appliquées à l'informatique savent aussi intégrer les contraintes du réel: les calculs de complexité algorithmique ont des applications directes en terme d'évaluation des rapidités d'exécution. Pas la peine d'étaler, avec une rigueur pas toujours heureuse, plein de gros mots issus de la physique récente. De toute façon, toutes les théories en physique utilisent les mathématiques comme langage. La physique de Newton, qui continue d'être utilisée dans bien des domaines, en sont un exemple évident. Dire que les mathématiques ne savent pas rendre compte de la réalité physique est donc bien rigolo.

[23JFK]

... Dire que les mathématiques ne savent pas rendre compte de la réalité physique est donc bien rigolo.

Je n'ai pas dit qu'elles ne le pouvaient pas, seulement que cela n'était pas leur objet. Les mathématiques ne s'occupent que des relations ; c'est la physique qui impose à l'outil mathématiques les limites du monde réel.

[Madmac]

ça faisait longtemps que j'avais pas posté , mais la les commentaires pique les yeux.
Oui les développeurs ont un manque trop grand de connaissance en math.
genre si j'écrit ça :
var u=0
while (u <= 0) {
u--
}

on vois bien que ça boucle , et ben c'est de l'algèbre et des maths ...
et oui il y a des matheux qui sont des boulets en développent mais ça n'implique pas que tous les matheux sont nulle en développement ou que plus de mathématique ne ferait pas de meilleurs développeur.
Beaucoup de développeur font de l'algèbre quand il code , mais ils n'en ont tous simplement pas conscience.
Pitoyable développez comme toujours les gens qui poste sur ce site , je critique pas les articles qui eux sont juste des copier coller d'article traduit parfois ....

Le problème fondamental de son analyse est avec la quantité de connaissance requise pour être un programmeur, les programmeurs terminent leur formation avec le strict minimum pour exercer leur métier. Ajouter plus de math n'est tout simplement pas réaliste. À mon avis, il prend le problème par le mauvais bout: Les gens qui sont formés pour les maths appliquées devrait ajouter la programmation pour fabriquer des algorithmes qui exploitent les maths appliquée. Par exemple, pour l'ensemble des programmeurs est plus fréquent de devoir utiliser des filtres à Transformée de Fourier, que d'élaborer la fonction de transformée de Fourier. C'est le genre de truc que l'on devrait trouver dans des ouvrages de référence de programmation.

Comme plusieurs secteur des sciences, il existe deux branches: la branche fondamentale et la branche appliquée. Le problème qu'il n'existe pas de science fondamentale en programmation.

[iclo]

On ne cesse de réduire la formation académique des développeurs : la norme devient de plus en plus d'avoir un bagage de quelques semaines de formation "en codage" et de moins en moins d'avoir un bac + 3 ou bac+5 . On a donc des gens avec juste une connaissance d'un langage de programmation et plus aucune connaissance théorique en algo, en logique.

Résultat des courses, le niveau et la qualité du travail des développeurs est en chute libre, et on a de plus en plus des blanc becs de 20 ans qui veulent toucher le même salaire qu'un master en entrée de poste.

Tout ça est bien encouragé par la pénurie de profils techniques.

[walfrat]

Avant de s'enflammer sur le contenu de l'article, reprenons la citation de base :

Si vous voulez vraiment faire les choses correctement, vous devez écrire votre algorithme dans les termes des mathématiques

La grande majorité des développeurs n'écrivent pas d'algorithmes* il les consommes (ex : utilisation des "sort" déjà implémentés, utilisations des collections automatiquement triés, index des base de données, etc). De fait ce que dit notre expert tiens à une catégorie de développeurs plus restreintes : ceux qui participent sur des systèmes distribués et qui espèrent s'en tirer en étant malin.

Et je suis d'accord avec lui, on peut s'en tirer en étant juste logique et rusé sur nos petite/moyenne application mais si tu veux entrer dans la cours des grand et faire des systèmes répartis qui gèrent des milliard de donées => MATHS MATHS ET ENCORE DES MATHS. Des mathématiques pour cassés la complexité de ton problèmes, des mathématiques pour optimiser la moindre portion de ton algorithme, des mathématiques pour faire des statistiques afin de comprendre ce qui se passe sur ton monstre qui gère des milliards de données afin d'avoir une chance de comprendre ce que tu peux encore améliorer.

* je n'ai pas compter les "petits algorithmes" genre rechercher un objet avec un id dans une liste, comparer deux liste qui sont des choses beaucoup trop basiques pour être en lien avec l'article.

[neothoms]

N'importe quoi.

23 ans de métier et je n'ai pas vu un développeur informatique faire des maths plus de 2 ou 3 fois.
99,9999% des informaticiens n'ont pas besoin des maths.
La raison pour laquelle les "vieux" cherchent toujours à faire apprendre les maths c'est parce que les maths et l'informatique requièrent un raisonnement logique et une méthode pour l'appliquer. Mais apprendre les maths ou apprendre l'informatique çà n'est pas apprendre la logique c'est utiliser celle que l'on a déjà.

La rationalité et la logique sont des choses qui ne s'apprennent pas. C'est d'ailleurs pour celà que la grande majorité des développeurs (et des mathématiciens) sont médiocres.

En informatique, les disciplines qui pourraient se rapprocher des maths, sont la data et surtout l'IA. Mais même là, les développeurs IA et data se contentent bien souvent de chercher au pif un modèle statistique qui colle.
Ils ne conçoivent presque jamais une formule mathématique eux même.

[rafoim]

N'importe quoi.

23 ans de métier et je n'ai pas vu un développeur informatique faire des maths plus de 2 ou 3 fois.
99,9999% des informaticiens n'ont pas besoin des maths.
La raison pour laquelle les "vieux" cherchent toujours à faire apprendre les maths c'est parce que les maths et l'informatique requièrent un raisonnement logique et une méthode pour l'appliquer. Mais apprendre les maths ou apprendre l'informatique çà n'est pas apprendre la logique c'est utiliser celle que l'on a déjà.

La rationalité et la logique sont des choses qui ne s'apprennent pas. C'est d'ailleurs pour celà que la grande majorité des développeurs (et des mathématiciens) sont médiocres.

En informatique, les disciplines qui pourraient se rapprocher des maths, sont la data et surtout l'IA. Mais même là, les développeurs IA et data se contentent bien souvent de chercher au pif un modèle statistique qui colle.
Ils ne conçoivent presque jamais une formule mathématique eux même.

L'article que nous commentons ici a été publié, il me semble, par quelqu'un d'assez brillant. Je ne sais pas si il est de bon ton de commenter son commentaire par "n'importe quoi".
En tant qu'enseignant, j'avancerai qu' il y a une forte corrélation observée des étudiants entre compétences en maths et compétences en informatique. Et d'ailleurs, les étudiants qui sont dégoûtés par la programmation crient souvent de manière effrayée: " mais c'est des maths!". Or non, ce ne sont pas des maths. Dans beaucoup de domaines du développement, il n'y a pas besoin de connaître les notions de maths habituellement enseignées dans le secondaire. Mais d'autres branches des mathématiques comme l'algorithmique ( oui, l'algorithme d'Euclide existe bien avant l'ordinateur et le mot algorithme vient du nom d'un mathématicien et astronome arabe "al khwarizmi") ou la théorie des graphes ( il n'y a pas des arborescences en info?) sont en connexion directe avec l'info.
Il semble en effet que ce soit peu enseigné pour grand nombre de développeurs qui "se débrouillent" et ce parfois avec une grande habileté. Toutefois, comme signalé plus haut dans un autre commentaire, il est regrettable que l'info ne soit que peu dispensée de manière fondamentale. Si on cherchait un peu à former des étudiants qui ne sont pas dépendants d'une ou deux technologies récentes mais qui aient du recul, une réelle capacité de réflexion, peut-être ferait-on le choix d'un enseignement informatique fondamental. Très rapidement, on se rendrait compte que cela revient à enseigner quelque chose qui est assez proche des maths (cf discussions précédentes sur les algorithmes de tri). Autre exemple: travailler sur les complexités algorithmiques n'est pas inutile pour, par la suite, prendre l'habitude de chercher des optimisations du code.

Et je ne suis pas d'accord pour dire que cela doit être réservé à une courte élite de développeurs qui seraient ceux qui innovent. Mes étudiants se mélangent les pinceaux en compilant des codes existants car il leur manque souvent une compréhension de fond.

[commandantFred]

C'est un peu le problème de cet article.

Dire que l'informatique dépend des maths est un point de vue des années 60. J'ai plein de collègues proches de la retraite qui le pensent.

Mon projet actuel ne requiert aucune mathématique , même pas au 2eme ou 3eme degré, rien. Je deale avec des flux, je triggue avec les datasets de plusieurs BDD qu'il faut connecter et faire les requêtes.

Mon projet précédent était une IHM avec scroll et zoom. Si vous trouvez que la multiplication/division d'un facteur de zoom relève des maths, alors je suis un matheux pur jus, mais ce me semble bien peu de chose. Des facteurs, des offsets à ajouter. Si j'en oublie un , ça plante l'affichage, je débugge et ça marche, voilà. Je ne peux pas appeler ça des maths...

J'ai beau avoir fait des années de traitement de signal avec des tonnes de maths double précision et des enjeux industriels importants (vies humaines), mes dernières missions consistaient à les mettre aux normes OS, internet et file system. Les maths écrites depuis 20 ans marchent très bien, RAS de ce côté, rien à ajouter. Je n'ai pas fait de maths depuis 2016 dans un jeu vidéo et trois lignes de N-Body en 2018. Oui, c'est des maths et le résultat est magique mais la majorité écrasante des algorithmes datent de 2 siècles (FFT justement). Rien de folichon, rien qui justifie qu'on y consacre des années d'étude. Vous pouvez apprendre les notions qui vous manquent à la volée, en début de mission, dans les transports plutôt que d'écouter des mp3 !

Dans les hackatons, je suis resté à la première place des années. Les +3000 participants essayaient de me battre (il ont fini par y arriver par forfait, ça ne m'amuse plus du tout, je suis 2eme maintenant)

Qu'avaient en commun mes adversaires pour ne jamais réussir à me passer devant ?

Une vision de la programmation trop modélisée. Erreur courante chez les jeunes. Ils analysent un modèle parfait, dimensionné au micron près. Grosse erreur.
Mon code qui gagne est plutôt moche, structures de données bourrin, très répétitives, très tolérantes. Algos éprouvés.

Résultat :
Si je dois mettre à jour, je n'ai rien à changer, juste ajouter un peu d'intelligence ici ou là
Alors qu'un programme très modélisé s'effondre au moindre changement, le mien peut être perdant dans certains cas précis mais ça ne compromet en rien son fonctionnement global. Pas d'effondrement, je recule un peu mais je reste sur le podium.

Les maths en programmation peuvent faire beaucoup plus de mal que de bien.

Oui certains employeurs vous demanderont beaucoup de maths MAIS c'est en général parce qu'ils ont eux-mêmes un cursus important en maths. C'est un réflexe corporatiste. Rien à voir avec un prérequis pour coder.

Les matheux de haut vol (astrophysique, méca des fluides, thermodynamique, ...) sont mauvais sur les hackatons. Je leur parle sur le chat mais je ne les vois jamais dans le tableau des scores.

[d_d_v]

J'ai fait Maths sup/spé avant des études d'ingénieur. Et en 22 ans d'xp chez des éditeurs de logiciels, je ne suis tombé que sur du code écrit sans aucune rigueur, et à aucun moment, je n'ai eu besoin de connaissances en mathématiques (ou alors vraiment très très peu) .

[Etotsha]

Moi, je dirais qu'il y en a de ceux qui programment tout en ayant pas des bases solides en Mathématique ou encore, il y a de ces programmeurs qui ont un niveau de mathématique en dessous de la moyenne. La logique est beaucoup plus préférable.

[Dutiona]

Pour les absolutistes de la récursion en programmation, ça pose souvent des problèmes de piles. Maintenant c'est caché par le gigantisme des mémoires par rapport à de petites fonctions qui s'appellent-elles mêmes, mais à la fin, c'est toujours le manque de RAM qui gagne. Il y a aussi le problème de réalisme des maths qui ne tiennent généralement pas compte du temps de résolution du problème alors que dans le monde réel, c'est un point critique de la programmation.

Ça dépend si la récursion est terminale ou non terminale... Jamais entendue parler de la "Tail-call optimization" ? Si le dernier appel de la fonction récursive est celui qui renvoie le résultat alors il n'y a tout simplement pas de problèmes de piles. Des langages faisant usage très important de la récursion, comme le scheme/lisp, requièrent, dans leur standard, que cette optimisation soit implémentée.

[WhiteCrow]

C'est un peu le problème de cet article.

Dire que l'informatique dépend des maths est un point de vue des années 60. J'ai plein de collègues proches de la retraite qui le pensent.
[...]

Ce n'est pas ce qui est dit. La principale idée que Lamport essaye de transmettre dans la première partie est simple : «on apprend aux étudiants à coder alors qu'on ferait bien mieux de leur apprendre à programmer.»
Le gros problème de la vidéo c'est que le mot «math» intervient et que cela focalise autant les «pro math» que les «anti math.» Il n'est pas, dans cette première partie de la vidéo, question de programmer des algorithmes mathématiques ou de vouloir imposer le point de vue que les matheux font de meilleurs informaticiens. Le mot «math» est réellement un épouvantail radioactif !

Quant au «point de vue des années 60», ce n'est pas par choix, mais un simple constat : tous les paradigmes de programmation majeurs datent de cette époque ; il n'y a eu quasiment aucune avancée majeure depuis, ptêt juste la reconnaissance de l'importance de l'immutabilité, et encore. Est-ce un hasard que cela corresponde à la période où être informaticien demandait beaucoup plus un background matheux ? je ne le sais pas. Ce que je peux constater c'est qu'effectivement il n'y pas besoin d'être matheux, ni rigoureux, ni même futé pour développer ; tout comme il n'est pas nécessaire d'être architecte pour construire une maison, ou cuisinier pour suivre une recette, ou … peu importe l'image.

Cependant il faut également reconnaître que dans tout développement un tant soit peu conséquent, il est nécessaire d'avoir de la méthode. Il est important de réfléchir avant de se lancer (ce que dit en gros Lamport). Si on a un background scientifique ça aide énormément car normalement on apprend la méthode scientifique, et on est ouvert à l'apprentissage des différentes méthodes auxquelles nous sommes confrontés par la suite.
Et effectivement, si on apprend aux étudiants à coder (pisser du code) sans leurs apprendre à programmer (réfléchir avant) on arrive à un troupeau d'informaticien aussi utile qu'un troupeau de moines copieurs.