Je suis surpris que personne n'ait donné la réponse évidente et, je suppose, la plus utilisée dans la pratique: il suffit de ne pas lire les messages d'erreur.
La grande majorité de la valeur de la plupart des messages d'erreur est simplement que quelque chose ne va pas sur telle ou telle ligne. La plupart du temps, je regarde le numéro de la ligne et j'y vais. Ma "lecture" du message d'erreur à ce stade correspond généralement à tout ce que mon regard attire en passant, pas même un écrémage. S'il n'est pas clair immédiatement ce qui ne va pas sur la ligne ou à proximité, je lirai le message. Ce flux de travail est encore meilleur avec un IDE ou un outillage qui met en évidence les erreurs sur-le-champ et met automatiquement en œuvre la suggestion de Karl Bielefeldt de ne prendre en compte que de petites modifications.
Bien sûr, les messages d'erreur ne pointent pas toujours vers la ligne appropriée, mais ils ne pointent souvent pas non plus la cause première appropriée. Par conséquent, même une compréhension complète du message d'erreur serait d'une aide limitée. Il ne faut pas longtemps pour avoir une idée des messages d'erreur les plus fiables pour localiser la ligne appropriée.
D'un côté, la plupart des erreurs qu'un novice est susceptible de commettre seront probablement douloureusement évidentes pour un programmeur expérimenté, sans l'aide du compilateur. D'un autre côté, ils sont beaucoup moins susceptibles d'être aussi évidents pour le novice (même si beaucoup le seront aussi, la plupart des erreurs sont des erreurs stupides). À ce stade, je suis tout à fait d’accord avec Robert Harvey: le novice doit simplement se familiariser davantage avec la langue. Il n'y a pas moyen d'éviter cela. Les erreurs de compilation qui font référence à des concepts inconnus ou qui semblent surprenantes devraient être considérées comme des incitations à approfondir la connaissance de la langue. De même dans les cas où le compilateur se plaint mais que vous ne voyez pas pourquoi le code est erroné.
Encore une fois, je suis d'accord avec Robert Harvey pour dire qu'une meilleure stratégie d'utilisation des erreurs de compilation est nécessaire. J'ai souligné certains aspects ci-dessus et la réponse de Robert Harvey en donne d'autres. On ne sait même pas ce que votre ami espère faire avec un tel "glossaire", et il est très peu probable qu'un tel "glossaire" soit réellement d'une grande utilité pour votre ami. Les messages du compilateur ne sont certainement pas le lieu idéal pour une introduction aux concepts du langage 1 et un "glossaire" n’est pas vraiment un meilleur endroit pour cela. Même avec une description claire du message d'erreur, cela ne vous indiquera pas comment résoudre le problème.
1 Quelques langues, comme Elm et Dhall (et probablement Racket), ainsi que quelques implémentations de langues "orientées débutant" tentent de le faire. Dans cet esprit, le conseil de MSalters d'utiliser une implémentation différente est directement pertinent. Personnellement, je trouve que de telles choses ne sont pas convaincantes et ne visent pas vraiment le bon problème. Cela ne veut pas dire qu'il n'y a pas moyen de créer de meilleurs messages d'erreur, mais pour moi, ils ont tendance à tourner autour de la clarification des croyances du compilateur et de la base de celles-ci.