Par contre ça en a beaucoup pour la clarté du programme (sans annotation de type, c'est plus dur de lire le code et de comprendre ce qu'il fait), et la redondance apportée par ces annotations permet à nos outils (les compilateurs) de dire parfois "attention, tu utilises la variable x comme un pointeur, mais tu l'as déclarée comme un entier, n'y a-t-il pas confusion ?", ce qui élimine des bugs.
Il me semble que tu te limites trop. Tu embarques ça dans le terme "outils", mais je ne pense pas qu'un code informatique doit se limiter à du texte dans un éditeur de fichier. Eclipse introduit des sorte de lien hypertexte, l'auto-completion et la vérification d'erreur en ligne, cela aide beaucoup le codeur. Il y a une masse d'information qui pourrait être fournis par l'outil de dev, qui ne nécessite pas une notation du codeur. L'idée est qu'un codeur veut de la concision, quitte à faire trop de raccourci (oublies de vérifier les erreur ou les exceptions), mais un relecteur veut de la clarté (il est plus facile de vérifier l'oublie d'un test d'erreur qu'un catch d'exception). Un codeur veut un texte pour décrire ses objets rapidement, un relecteur veut un diagramme de classe ou de machine d'état ou de block pour tout appréhender rapidement.
Je pense vraiment qu'il faut arrêter de voir la sémantique d'un langage uniquement à travers une suite de caractère. Et la meilleur méthode pour écrire un code, n'est pas forcément la meilleur pour le relire.
[^] # Re: Concernant la clarté
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Pourquoi la recherche en langages de programmation ?. Évalué à 5.
Il me semble que tu te limites trop. Tu embarques ça dans le terme "outils", mais je ne pense pas qu'un code informatique doit se limiter à du texte dans un éditeur de fichier. Eclipse introduit des sorte de lien hypertexte, l'auto-completion et la vérification d'erreur en ligne, cela aide beaucoup le codeur. Il y a une masse d'information qui pourrait être fournis par l'outil de dev, qui ne nécessite pas une notation du codeur. L'idée est qu'un codeur veut de la concision, quitte à faire trop de raccourci (oublies de vérifier les erreur ou les exceptions), mais un relecteur veut de la clarté (il est plus facile de vérifier l'oublie d'un test d'erreur qu'un catch d'exception). Un codeur veut un texte pour décrire ses objets rapidement, un relecteur veut un diagramme de classe ou de machine d'état ou de block pour tout appréhender rapidement.
Cette vidéo est absolument à voir : https://www.youtube.com/watch?v=PUv66718DII C'est un rêve de dev d'avoir une boucle de rétroaction aussi rapide.
Je pense vraiment qu'il faut arrêter de voir la sémantique d'un langage uniquement à travers une suite de caractère. Et la meilleur méthode pour écrire un code, n'est pas forcément la meilleur pour le relire.
"La première sécurité est la liberté"