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 :)
Il s'agit plus de flemme que de honte. J'adore les phrases denses et concises, sans doute parce que j'ai horreur de perdre mon temps.
Tapper m'ennuie, alors vive les préfixes et les suffixes. Après je vais peut être parfois trop loin...
- 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.
Imagine, que tu utilise dans ton programme une liste chainée de couple de réels
{(3.5,5.4),(8.4,8.6),...}.
Imaginons que dans toutes les manipulations que tu effectue dessus, il se trouve que tu respectes les axiomes d'espaces vectoriels (ie. dans ta tête lorsque tu programmes, ta liste chainée est une liste de vecteurs).
Tu additionne tes couples, tu utilises des matrices, etc...
Un "prépocesseur" détecte alors que ta liste chainée est une liste de vecteurs d'un espace vectoriel. Il te propose d'emblée tout un tas de fonctions, il vérifie que ton code ne contient pas d'erreurs mathématiques, etc...
Par exemple, si tu modélise des agents sur un terrain (de foot par exemple), et que tu décris ceux-ci par des vecteurs, tu auras automatiquement la possibilité de leur donner une direction en radian, en degré, et un module.
Si tu modélise un balon, il suffira de le définir comme objet physique doté d'une masse (le type OBJET_MASSIQUE) et il analysera le contexte d'utilisation de ton balon pour toi, te proposant calcul de trajectoire, etc...
C'est plutôt vers cette idée.
Programmer, c'est créer de toutes pièces une structure cohérente (Coherens "qui tien ensemble"). Un truc issu de ton cerveau que tu crée à partir de rien, à part les primitives offertes par ton langage.
Là, par reconnaissance de forme, l'environnement de dev détecte les objets que tu veux décrire et t'assiste en t'offrant des structures toutes faites.
On aura une réprésentation standard du concept de client, d'entreprise, d'employé, de pièce, etc... Avec à chaque fois des propriétés et des contraintes.
C'est entre "écrire de la lib" et "concevoir un moteur de reconnaissance de forme".
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: Et le langage humain de mes rêves...
Posté par Ontologia (site web personnel) . En réponse au journal Le langage de mes rêves. Évalué à 2.
Il s'agit plus de flemme que de honte. J'adore les phrases denses et concises, sans doute parce que j'ai horreur de perdre mon temps.
Tapper m'ennuie, alors vive les préfixes et les suffixes. Après je vais peut être parfois trop loin...
- 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.
Imagine, que tu utilise dans ton programme une liste chainée de couple de réels
{(3.5,5.4),(8.4,8.6),...}.
Imaginons que dans toutes les manipulations que tu effectue dessus, il se trouve que tu respectes les axiomes d'espaces vectoriels (ie. dans ta tête lorsque tu programmes, ta liste chainée est une liste de vecteurs).
Tu additionne tes couples, tu utilises des matrices, etc...
Un "prépocesseur" détecte alors que ta liste chainée est une liste de vecteurs d'un espace vectoriel. Il te propose d'emblée tout un tas de fonctions, il vérifie que ton code ne contient pas d'erreurs mathématiques, etc...
Par exemple, si tu modélise des agents sur un terrain (de foot par exemple), et que tu décris ceux-ci par des vecteurs, tu auras automatiquement la possibilité de leur donner une direction en radian, en degré, et un module.
Si tu modélise un balon, il suffira de le définir comme objet physique doté d'une masse (le type OBJET_MASSIQUE) et il analysera le contexte d'utilisation de ton balon pour toi, te proposant calcul de trajectoire, etc...
C'est plutôt vers cette idée.
Programmer, c'est créer de toutes pièces une structure cohérente (Coherens "qui tien ensemble"). Un truc issu de ton cerveau que tu crée à partir de rien, à part les primitives offertes par ton langage.
Là, par reconnaissance de forme, l'environnement de dev détecte les objets que tu veux décrire et t'assiste en t'offrant des structures toutes faites.
On aura une réprésentation standard du concept de client, d'entreprise, d'employé, de pièce, etc... Avec à chaque fois des propriétés et des contraintes.
C'est entre "écrire de la lib" et "concevoir un moteur de reconnaissance de forme".
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker