Bah, c'est aussi évident que sans contexte, c'est difficile de tirer des règles générales : on n'enseigne pas de la même manière à des enfants, à des adolescents, à des jeunes adultes, ou à des seniors. De même, ça dépend de la formation en question : est-ce que les gens ont une formation scientifique (et donc une solide base en maths), ou pas. Enfin, ça dépend tout bêtement des gens, certains vont capter quelque chose du premier coup, d'autres ne capteront jamais. En particulier, j'ai l'impression que certaines personnes sont totalement inaptes à "exécuter" un programme de tête (a = 1; b = 2; b = (a+b)/b; a=(a+b)/2; est-ce a == b ? "euuuuuhhhhh"), ce qui rend la programmation beaucoup plus difficile pour eux (ils ne s'en sortent qu'en copiant des patterns, mais ne peuvent pas innover).
Pour le typage, à mon avis, le frein principal est le traitement des entrées/sorties, avec ce p*** de problème de la différence entre 42 et "42" qui fait perdre un temps fou à tout le monde. S'il y a un seul truc que je garderais de perl, c'est les conversions implicites entre les nombres et les chaines de caractères qui représentent des nombres. Parce que bon, il faut être honnête, 99.9...% des opérations de ce style ne sont absolument pas ambigües, et je trouve ça super sympa de pouvoir lire une ligne d'entrée du style "tomate oignon 2 carottes 3 poireaux" avec une seule variable...
la sémantique n'a pas une interprétation automagique pour coller à tes besoins non exprimés
C'est peut-être quand même une faiblesse des langages de programmation, non? Et peut-être même des logiciels en général. Souvent, quand on veut concevoir un truc plus intuitif, on peut, et je trouve que certains langages sont bourrés d'inutilités syntaxiques psychorigides. Par exemple, tous les compilateurs C ou C++ récents sont capables de te dire "ligne 318, il manque un ; à la fin". Bah oui, en effet, 99.99% du temps, le ";" est inutile, il suffirait d'interpréter les sauts de ligne comme des ;.
En gros, le problème n'est pas de demander à la machine de choisir entre deux options quand les instructions ne sont pas claires. On est d'accord, c'est quasiment impossible. Le problème est plutôt de concevoir des interfaces souples, qui donnent quelque chose de sensé plutôt qu'une erreur de compilation. Typiquement, les fonctions à arguments facultatifs sont une avancée considérable; mais tous les langages de programmation sont systématiquement truffés d'inutiles lubies psychorigides qui peuvent vraiment rebuter les débutants.
[^] # Re: Décalage
Posté par arnaudus . En réponse à la dépêche MicroAlg: langage et environnements pour l’algorithmique. Évalué à 4. Dernière modification le 23 octobre 2014 à 16:45.
Bah, c'est aussi évident que sans contexte, c'est difficile de tirer des règles générales : on n'enseigne pas de la même manière à des enfants, à des adolescents, à des jeunes adultes, ou à des seniors. De même, ça dépend de la formation en question : est-ce que les gens ont une formation scientifique (et donc une solide base en maths), ou pas. Enfin, ça dépend tout bêtement des gens, certains vont capter quelque chose du premier coup, d'autres ne capteront jamais. En particulier, j'ai l'impression que certaines personnes sont totalement inaptes à "exécuter" un programme de tête (a = 1; b = 2; b = (a+b)/b; a=(a+b)/2; est-ce a == b ? "euuuuuhhhhh"), ce qui rend la programmation beaucoup plus difficile pour eux (ils ne s'en sortent qu'en copiant des patterns, mais ne peuvent pas innover).
Pour le typage, à mon avis, le frein principal est le traitement des entrées/sorties, avec ce p*** de problème de la différence entre 42 et "42" qui fait perdre un temps fou à tout le monde. S'il y a un seul truc que je garderais de perl, c'est les conversions implicites entre les nombres et les chaines de caractères qui représentent des nombres. Parce que bon, il faut être honnête, 99.9...% des opérations de ce style ne sont absolument pas ambigües, et je trouve ça super sympa de pouvoir lire une ligne d'entrée du style "tomate oignon 2 carottes 3 poireaux" avec une seule variable...
C'est peut-être quand même une faiblesse des langages de programmation, non? Et peut-être même des logiciels en général. Souvent, quand on veut concevoir un truc plus intuitif, on peut, et je trouve que certains langages sont bourrés d'inutilités syntaxiques psychorigides. Par exemple, tous les compilateurs C ou C++ récents sont capables de te dire "ligne 318, il manque un ; à la fin". Bah oui, en effet, 99.99% du temps, le ";" est inutile, il suffirait d'interpréter les sauts de ligne comme des ;.
En gros, le problème n'est pas de demander à la machine de choisir entre deux options quand les instructions ne sont pas claires. On est d'accord, c'est quasiment impossible. Le problème est plutôt de concevoir des interfaces souples, qui donnent quelque chose de sensé plutôt qu'une erreur de compilation. Typiquement, les fonctions à arguments facultatifs sont une avancée considérable; mais tous les langages de programmation sont systématiquement truffés d'inutiles lubies psychorigides qui peuvent vraiment rebuter les débutants.