La plupart des concepts n'ont pas besoin d'être dans le "cache interne" car le compilateur garde ces concepts pour toi et te rappelle quand tu fais une erreur.
Une annotation visuelle dans le code passe à un moment par notre mémoire de travail, même si c'est un temps bref et qu'on la laisse vite de côté. Du coup, une telle annotation visuelle n'allège la mémoire de travail que si l'information qu'elle apporte nous était nécessaire sur le moment pour comprendre le code, par exemple en nous évitant d'avoir à établir des invariants dans notre tête. Par contre, si sur le moment l'info n'est pas utile pour ce qu'on veut comprendre, au contraire, elle nous distrait.
Ce concept permet en fait de libérer de la charge cognitive, car tu sait que quand une variable n'est pas mutable, elle ne change pas. Si tu connais la valeur de la variable au début de la fonction, tu n'a pas besoin de mettre tout le code de la fonction dans ta mémoire de travail pour savoir que la valeur de cette variable n'a pas changer
En effet, sauf que souvent le fait qu'une variable aille être utilisée de façon mutable ou non s'intuite du fait d'autres informations déjà analysées, comme le nom ou type de la variable ou le nom des fonctions qui l'utilisent. Du coup, souvent, une annotation de mutabilité ou non dans le code représente juste un bit d'information redondant, utile pour le compilateur mais pas forcément pour le développeur. Une information redondante risque de saturer la mémoire de travail.
Cela dit, le cas de la mutabilité ou non mutabilité est assez secondaire (un bit d'information, c'est peu de place), par rapport à d'autres choses comme la généricité (où analyser l'information additionnelle relative à la couche d'abstraction est nécessaire pour comprendre le code, ce n'est pas juste une information annexe).
En pratique, il y a assez peu de temps de vie explicites. Et encore une fois, quand c'est nécessaire, ça permet de faciliter le raisonnement sur la validité des objets que tu dois déduire toi même dans d'autre langages qui n'ont pas se concept.
Tout à fait : si c'est notre objectif de lecture du moment, les annotations vont nous éviter de remplir la mémoire de travail avec des raisonnements garantis par le compilateur. Mais seulement si ce qui nous intéresse sur le moment a un lien avec ces garanties.
Au final, je trouve pas qu'il soit facile de toujours trancher sur l'utilité relative de certaines fonctionnalités. Il faudrait pour cela des études statistiques pas évidentes à mettre en place.
Un autre exemple parlant est celui des bibliothèques standard : dans certains langages, elles essaient d'être plutôt minimales et ne pas ajouter de fonctions qui se déduisent facilement des autres. Dans d'autres langages, la barrière d'entrée pour de nouvelles fonctions est moins importante.
Trop peu de fonctions a tendance à distraire le développeur, car il doit souvent réécrire des petites fonctions à l'aide de celles qu'il connait. Trop de fonctions a tendance à distraire aussi le développeur, car il hésite entre réécrire ou bien chercher la bonne fonction dans la documentation ; or, celle-ci étant plus longue et contenant plus de fonctions secondaires, elle demande plus d'efforts à notre mémoire de travail lors du parcours : l'essentiel est moins immédiatement visible.
[^] # Re: let's go...
Posté par anaseto . En réponse au journal Appel à contribution pour un nouveau langage !. Évalué à 2.
Une annotation visuelle dans le code passe à un moment par notre mémoire de travail, même si c'est un temps bref et qu'on la laisse vite de côté. Du coup, une telle annotation visuelle n'allège la mémoire de travail que si l'information qu'elle apporte nous était nécessaire sur le moment pour comprendre le code, par exemple en nous évitant d'avoir à établir des invariants dans notre tête. Par contre, si sur le moment l'info n'est pas utile pour ce qu'on veut comprendre, au contraire, elle nous distrait.
En effet, sauf que souvent le fait qu'une variable aille être utilisée de façon mutable ou non s'intuite du fait d'autres informations déjà analysées, comme le nom ou type de la variable ou le nom des fonctions qui l'utilisent. Du coup, souvent, une annotation de mutabilité ou non dans le code représente juste un bit d'information redondant, utile pour le compilateur mais pas forcément pour le développeur. Une information redondante risque de saturer la mémoire de travail.
Cela dit, le cas de la mutabilité ou non mutabilité est assez secondaire (un bit d'information, c'est peu de place), par rapport à d'autres choses comme la généricité (où analyser l'information additionnelle relative à la couche d'abstraction est nécessaire pour comprendre le code, ce n'est pas juste une information annexe).
Tout à fait : si c'est notre objectif de lecture du moment, les annotations vont nous éviter de remplir la mémoire de travail avec des raisonnements garantis par le compilateur. Mais seulement si ce qui nous intéresse sur le moment a un lien avec ces garanties.
Au final, je trouve pas qu'il soit facile de toujours trancher sur l'utilité relative de certaines fonctionnalités. Il faudrait pour cela des études statistiques pas évidentes à mettre en place.
Un autre exemple parlant est celui des bibliothèques standard : dans certains langages, elles essaient d'être plutôt minimales et ne pas ajouter de fonctions qui se déduisent facilement des autres. Dans d'autres langages, la barrière d'entrée pour de nouvelles fonctions est moins importante.
Trop peu de fonctions a tendance à distraire le développeur, car il doit souvent réécrire des petites fonctions à l'aide de celles qu'il connait. Trop de fonctions a tendance à distraire aussi le développeur, car il hésite entre réécrire ou bien chercher la bonne fonction dans la documentation ; or, celle-ci étant plus longue et contenant plus de fonctions secondaires, elle demande plus d'efforts à notre mémoire de travail lors du parcours : l'essentiel est moins immédiatement visible.