Je veux bien croire que le jargon aide à exprimer ses pensées en peu de mots, mais l'économie de mots a un coût, pour le lecteur, lorsqu'il s'agit de comprendre. Il n'y a pas de honte à utiliser une ou deux phrases à la place de mots comme ontologisation hein :)
En (très) gros si j'ai bien compris la liste non numérotée de ta préface, tu dis que:
- On passe progressivement d'une représentation des données à une description des données. Par exemple (simpliste) le champ "size" d'un objet "array" peut-être représenté par un entier (non distinguable des autres entiers), ou bien décrit comme étant la taille du tableau (et donc pas un entier quelconque). La description implique entre autres que le champ size a une influence sur le nombre d'itérations d'un parcours du tableau, sur la place qu'occupe ce tableau en mémoire, etc. Si l'on se contente de représenter les données sans les décrire, alors c'est au programmeur d'interpréter leur signification dans sa tête.
- Ça serait bien que ce passage de représentation à description ne soit pas limité aux données, mais soit aussi appliqué au traitement des données. Là j'avoue que j'ai du mal à trouver rapidement un exemple pertinent, mais j'ai l'impression que ça revient à dire: ça serait bien que l'on puisse programmer des design patterns. Pour l'instant on ne peut pas les programmer, ce sont des concepts que le programmeur doit adapter à sa situation, mais avec des langages de plus haut niveau, ça serait possible.
Mais bon, justement, à cause du jargon, j'ai dû relire ça trois fois, et je ne suis pas sûr du tout d'être tombé juste :) (Paradoxalement, il n'y a pas trop de jargon dans l'article, tout est dans la préface)
# Et le langage humain de mes rêves...
Posté par Yusei (Mastodon) . En réponse au journal Le langage de mes rêves. Évalué à 3.
En (très) gros si j'ai bien compris la liste non numérotée de ta préface, tu dis que:
- On passe progressivement d'une représentation des données à une description des données. Par exemple (simpliste) le champ "size" d'un objet "array" peut-être représenté par un entier (non distinguable des autres entiers), ou bien décrit comme étant la taille du tableau (et donc pas un entier quelconque). La description implique entre autres que le champ size a une influence sur le nombre d'itérations d'un parcours du tableau, sur la place qu'occupe ce tableau en mémoire, etc. Si l'on se contente de représenter les données sans les décrire, alors c'est au programmeur d'interpréter leur signification dans sa tête.
- Ça serait bien que ce passage de représentation à description ne soit pas limité aux données, mais soit aussi appliqué au traitement des données. Là j'avoue que j'ai du mal à trouver rapidement un exemple pertinent, mais j'ai l'impression que ça revient à dire: ça serait bien que l'on puisse programmer des design patterns. Pour l'instant on ne peut pas les programmer, ce sont des concepts que le programmeur doit adapter à sa situation, mais avec des langages de plus haut niveau, ça serait possible.
Mais bon, justement, à cause du jargon, j'ai dû relire ça trois fois, et je ne suis pas sûr du tout d'être tombé juste :) (Paradoxalement, il n'y a pas trop de jargon dans l'article, tout est dans la préface)