Le problème principal qu'il y a à interfacer un cerveau humain avec un ordinateur est que l'ordinateur est une machine à calculer alors que le cerveau est une machine à reconnaitre (tellement puissante qu'elle peut même par le jeu de description reconnaitre des choses qu'elle n'a jamais rencontré auparavant). Au jour d'aujourd'hui toute la puissance de la machine réside dans sa bétise intégrale : elle n'interprète absolument pas ce qu'on lui donne et fait ce qu'on a demandé même si c'est idiot. C'est surpuissant car 1°) celà garanti un fonctionnement cohérent 2°) celà permet au programmeur (la plupart du temps équipé d'une machine à reconnaitre) de comprendre ce qui se passe exactement en morcelant le déroulement pour trouver les erreurs.
Les gros inconvennients de tes paradigmes est qu'ils imposent une interpretation non triviale de l'intention du programmeur. Aujourd'hui c'est techniquement infaisable et pour le futur je ne suis pas sur que celà soit souhaitable. Il est extrèmement délicat de méler affectation, variables et contrats pour plusieurs raisons.
La première est que l'ordre d'évaluation change tout, par exemple si je commence par valider mes contrats, puis que j'affecte mes états, puis que j'évalue mes variables rien ne me dit qu'à la fin de l'évaluation des variables mes contrats sont encore valide... De plus si j'évalue mes variables puis que je valide mes contrats rien ne me dit non plus qu'une des validation n'a pas modifié une variable qui invalide un contrat précédamment validé etc. Pour finir variable -> etat -> contrat n'a pas forcément le même résultat que contrat -> etat -> variable.
La seconde est que lorsque les variables, contrat et etats s'inter-affectent il est horriblement complexe (en fait impossible si le langage est Turing complet) de valider qu'il n'y a pas de référence circulaire ou de deadlock
Par exemple : [(soleil = visible), (pluie=non), (température > 20°c)] -> {il fait beau} -> {il fait jour et chaud} -> [(soleil = visible), (pluie=non), (température > 20°c)]
Il est nécessaire qu'une personne décide si le contrat affecte l'état, ou si c'est l'état qui valide le contrat ou encore si ce sont les variables qui valide le contrat qui à son tour affecte l'état. La machine ne peut pas prendre cette décision.
Or là on touche le problème de fond, le troisième problème, demandez à un être humain si c'est parcequ'un nombre est négatif qu'on met un signe moins devant ou si c'est parcequ'il y a un signe moins devant qu'on le considère comme négatif et il risque un peu de faire la tête. En fait l'interpretation est décidée en fonction de l'ordre dans lequel arrive les données. -4 est recconu comme valeur négative de quatre et valeur négative de quatre est transcrite comme -4. Pour recalquer ce comportement à un système informatique il faut éclater la notion de variable en trois notions :
- l'unité
- la donnée
- la valeur.
L'unité pourrait être vue comme un méta-ensemble de types, c'est ce qui fixe le cadre de ce dont on est en train de parler. Un bonne exemple d'unité serait "vitesse du sous-marin A exprimée en km/h et évaluée à l'instant t=T+2min et 30 seconde de jeu"
La donnée est le contenu de l'unité, c'est à dire soit une information arbitraire saisie ou décidée à l'initialisation, soit le résultat d'une suite de calcul ou d'évènement sur cette donnée.
La valeur est la justification de la donnée en d'autre terme ce qui permet de faire la différence entre un -4 que l'on interprère en nombre quatre en négatif et un nombre quatre en négatif que l'on note -4. bref tout ce qui permet de décider mathématiquement de quoi la valeur est une conséquence et quelles seront ses causes et donc ultimement de décider de l'ordre d'évaluation juste.
Bon il est 5h du mat, je suis pas sur d'avoir résussi à être clair...
# Plusieurs problèmes avec tes primitves
Posté par Jerome Herman . En réponse au journal Des langages de haut niveau. Évalué à 2.
Les gros inconvennients de tes paradigmes est qu'ils imposent une interpretation non triviale de l'intention du programmeur. Aujourd'hui c'est techniquement infaisable et pour le futur je ne suis pas sur que celà soit souhaitable. Il est extrèmement délicat de méler affectation, variables et contrats pour plusieurs raisons.
La première est que l'ordre d'évaluation change tout, par exemple si je commence par valider mes contrats, puis que j'affecte mes états, puis que j'évalue mes variables rien ne me dit qu'à la fin de l'évaluation des variables mes contrats sont encore valide... De plus si j'évalue mes variables puis que je valide mes contrats rien ne me dit non plus qu'une des validation n'a pas modifié une variable qui invalide un contrat précédamment validé etc. Pour finir variable -> etat -> contrat n'a pas forcément le même résultat que contrat -> etat -> variable.
La seconde est que lorsque les variables, contrat et etats s'inter-affectent il est horriblement complexe (en fait impossible si le langage est Turing complet) de valider qu'il n'y a pas de référence circulaire ou de deadlock
Par exemple : [(soleil = visible), (pluie=non), (température > 20°c)] -> {il fait beau} -> {il fait jour et chaud} -> [(soleil = visible), (pluie=non), (température > 20°c)]
Il est nécessaire qu'une personne décide si le contrat affecte l'état, ou si c'est l'état qui valide le contrat ou encore si ce sont les variables qui valide le contrat qui à son tour affecte l'état. La machine ne peut pas prendre cette décision.
Or là on touche le problème de fond, le troisième problème, demandez à un être humain si c'est parcequ'un nombre est négatif qu'on met un signe moins devant ou si c'est parcequ'il y a un signe moins devant qu'on le considère comme négatif et il risque un peu de faire la tête. En fait l'interpretation est décidée en fonction de l'ordre dans lequel arrive les données. -4 est recconu comme valeur négative de quatre et valeur négative de quatre est transcrite comme -4. Pour recalquer ce comportement à un système informatique il faut éclater la notion de variable en trois notions :
- l'unité
- la donnée
- la valeur.
L'unité pourrait être vue comme un méta-ensemble de types, c'est ce qui fixe le cadre de ce dont on est en train de parler. Un bonne exemple d'unité serait "vitesse du sous-marin A exprimée en km/h et évaluée à l'instant t=T+2min et 30 seconde de jeu"
La donnée est le contenu de l'unité, c'est à dire soit une information arbitraire saisie ou décidée à l'initialisation, soit le résultat d'une suite de calcul ou d'évènement sur cette donnée.
La valeur est la justification de la donnée en d'autre terme ce qui permet de faire la différence entre un -4 que l'on interprère en nombre quatre en négatif et un nombre quatre en négatif que l'on note -4. bref tout ce qui permet de décider mathématiquement de quoi la valeur est une conséquence et quelles seront ses causes et donc ultimement de décider de l'ordre d'évaluation juste.
Bon il est 5h du mat, je suis pas sur d'avoir résussi à être clair...