Oui, sauf que la comparaison ne tient pas la route : le concept de type n'existe pas en Assembleur (celui de fonction non plus d'ailleurs), du coup il ne lui est pas nécessaire de disposer d'une déclaration pour vérifier la concordance des types entre le prototype et l'appel.
Attends, je te la refais. Pour moi, un langage qui est capable de vérifier la concordance des types dans ce code source…
1 2 3 4 5 6 7 | int mafonction (int param1, char param2) { return 42; } int main() { return mafonction(12, 'a'); } |
…mais pas dans celui-ci…
1 2 3 4 5 6 7 | int main() { return mafonction(12, 'a'); } int mafonction (int param1, char param2) { return 42; } |
…j'appelle ça un langage teubé. Mais j'ai bien conscience que c'est une conception personnelle, hein. 
c'est précisémment une des raisons qui me pousse à utiliser le C et à considérer l'utilisation de la plupart des autres langages comme une hérésie étant donné leur consommation monstrueuse de ressources comparé au C
Je comprends cette logique de la recherche de performances, mais j'avoue me poser la question de sa pertinence quand :
- on a des machines au moins mille fois plus puissantes que celles pour lesquelles le C a été optimisé, et que certains langages de très haut niveau comme le Haskell arrivent la plupart du temps à générer un exécutable qui tourne à peine 2 à 3 fois plus lentement que son équivalent en C ;
- cette performance s'obtient au prix d'un temps considérable passé sur la programmation, parce que pour citer Natalya (grande amatrice du C, je rappelle) « pour réinventer la roue, il faut redéfinir la géométrie ».
C'est surtout ce dernier point sur lequel nous achoppons. En codant en assembleur, on peut parfois obtenir des programmes plus rapides et dix fois plus petits que leurs homologues en C, mais rien que convertir un nombre en chaîne de caractères est un calvaire : le C produit un code moins optimisé, mais le gain en confort de programmation en vaut la chandelle. Ben c'est pareil pour le C vis-à-vis de certains langages de plus haut niveau (pas tous, hein, je parle pas de PHP).
En outre, les langages de haut niveau permettent généralement de réduire le temps de déboguage et d'augmenter la réutilisation du code existant. En programmation fonctionnelle ou logique, par exemple, si une fonction pure fonctionne au moment de sa programmation, elle fonctionnera toujours quel que soit le contexte dans lequel elle sera réutilisée, parce qu'elle ne permet pas les effets de bord. L'absence d'accès trop direct à la mémoire garantit aussi de ne pas se manger une erreur de segmentation un jour ou l'autre. Etc.
En résumé, la perte de temps à l'exécution est avérée mais apparaît négligeable au regard du gain de temps à la programmation et à la correction, ainsi qu'au regard des erreurs évitées à l'exécution.
Par exemple, est-ce que tu accepterais qu'un mathématicien ne sache pas compter et n'aie aucune maitrise des formules trigonométriques ou analytiques de base juste parce qu'on a des outils modernes comme des calculettes ou des logiciels de calcul formels ?
Ne pas savoir compter risquerait, en effet, d'être rédhibitoire. Cela étant, si un apprenti mathématicien est capable de penser directement en termes de groupes, corps et anneaux, que le fait de ne pas voir de différence fondamentale entre additionner des entiers, additionner des vecteurs et combiner des symétries lui simplifie la vie et lui permet d'accéder plus vite aux résultats que nous mettons actuellement une bonne décennie de maths à atteindre, je ne vois aucune raison de lui enseigner autrement.
Après tout, c'est comme ça qu'on fait dans l'apprentissage de la grammaire, surtout d'une langue étrangère : on présente la structure générale et on donne des exemples de mise en pratique. Pourquoi ne pas présenter la structure générale (les groupes) et ensuite des exemples particuliers (les entiers, les vecteurs) ? Mis à part que cela nous paraît inhabituel ? Cette bataille à couteaux tirés nous montre qu'il n'est pas forcément judicieux d'introduire le concept « de base » de nombre dans l'enseignement des maths, vu qu'en progressant on finit par se rendre compte qu'il est excessivement difficile à définir.
Et c'est un point qui m'a fait tiquer plusieurs fois dans ton intervention : à aucun moment on ne définit une méthodologie pour décider de ce qui est « de base » et de ce qui ne l'est pas, on se contente de considérer que ce que l'on enseigne actuellement en début de formation constitue les bases. Mais ce n'est pas nécessairement le cas. On peut tout à fait sauter directement à un niveau d'abstraction différent et enseigner à partir de là sans se préoccuper de ce qu'il y a en dessous, du moins jusqu'à ce qu'ayant acquis un niveau avancé on touche aux limites que ce niveau d'abstraction tient du niveau inférieur.
Pour faire une analogie, je n'ai pas besoin de comprendre quoi que ce soit à la chimie sous-jacente pour apprendre que les pâtes sauce au poivre sont plus réussie si je fais cuire les pâtes dans la sauce qui si j'ajoute la sauce aux pâtes préalablement cuites : je suis à un niveau d'abstraction supérieur, et il vaut mieux apprendre les bases de ce niveau d'abstraction directement plutôt que passer plusieurs années à étudier la chimie pour préparer du risotto.
Et je doute sincèrement que « les primitives de base des langages procéduraux » soient un pré-requis indispensable à l'apprentissage de la programmation. Se représenter SHA-1 comme un compacteur qui prend des entrées de taille fixe pour les fusionner les unes dans les autres et obtenir une sortie de la même taille quel que soit le nombre d'entrées est à mon avis plus efficace et plus simple que se le représenter comme un ensemble de cases mémoires auxquelles on fait subir un certain nombre de déplacements et opérations. La programmation fonctionnelle est tout à fait abordable par un parfait débutant, à condition de réserver pour plus tard la compréhension fine du fonctionnement réel de la machine deux niveaux d'abstraction plus bas.
Si quelqu'un veut commencer par le C comme premier langage pour se préparer à d'autres langages, il en a parfaitement le droit, et écrire un tutoriel pour ce genre de personnes est une bonne chose
Si quelqu'un qui connaît le Python veut découvrir le Ruby pour savoir ce qu'il a de différent avec le Python, il en a parfaitement le droit, mais ce n'est pas pour autant que le tutoriel « Ruby pour les Pythonistes » est un choix pertinent pour un cours unique de Ruby sur le ZdS. Parce que la politique éditoriale ici est de ne pas multiplier les tutos qui abordent un thème très similaire, et en particulier, de n'avoir qu'un seul big-tuto from scratch par langage. Dans ces conditions, il faut écrire un cours de C dont l'approche sera pertinente pour le plus de visiteurs possibles et non parce qu'une catégorie donnée d'iceux « a le droit » d'avoir le tuto de ses rêves. Et en l'occurrence, on est nombreux à penser que l'approche pertinente est de considérer le C comme un langage du type « découvrez de plus près comment fonctionne votre machine » au même titre que l'assembleur.
