Contrairement aux usages, je précède celle-ci d'une discussion sur l'interface entre la pensée et modélisation humaine et la machine, le langage.
Ce langage a été conçu suite à mes piètres expériences de développement, à quelques lectures et réflexions ( https://linuxfr.org/~Montaigne/19629.html ) ainsi qu'a ma pratique parfois fastidieuse de la programmation qui a continuellement forgé ma conviction que ceux-ci sont encore nettement perfectibles.
Depuis les début de l'ère informatique, le développeur se doit (c'est son rôle) d'adapter un cahier des charges pétris de préoccupations et représentation humaine en "code machine" basé fondamentalement sur l'idée de suivi automatique d'un graphe de code, qu'il soit objet ou procédurale avec des modes de représentations des informations fortement contraints par le fonctionnement intrinsèque et les limites de la machine.
Celle-ci reste encore basée sur le modèle de Von Neumann.
Il me semble que l'objectif doit rester clair et simple : coller le mieux possible aux modes de représentations humain, à sa conception des processus l'environnant, et sa perception de la structure physique, biologique, sociétale, humaine (etc..) qui l'entoure.
Décrire un langage tentant d'atteindre cet objectif doit donner au développeurs le moyen d'exprimer le plus aisément leur intuition. Victoria Livchitz, dans l'interview que je traduisais il y a quelques mois ici même, exprimait cet opinion en l'illustrant d'exemples, d'analyses et de pistes de réflexions.
J'avoue être au début du chemin, mais pense être engagé sur la bonne piste.
Je distingue plusieurs éléments qu'il reste à creuser et structurer
- Il faut une structuration ontologique d'un certain nombre de concepts et trouver un moyen de les chaîner entre eux. Il me semble que les recherches sur les ontologies sont d'inspiration trop dualiste pour y parvenir actuellement.
Par exemple, une liste de couple de valeurs numériques peuvent faire apparaître (ou non) une structure d'espace vectoriel, avec tout ce que cela implique dans la possibilité de sémantiser le code. - Je pense que plus généralement, il faudrait trouver un moyen de se servir de cette ontologisation des langage afin de permettre de créer soi même ses propres primitives, Maître-esclave, reconnaissances de formes spécifiques, etc...
- De façon plus terre à terre, il me semble indispensable de doter des objets (ou agent) d'etat pouvant évoluer et d'une possibilité de manipuler sémantiquement ses états, au début comme dans un langage du type de Prolog.
- Le langage doit être capable de permettre une adaptation permanente au contexte en étant capable de s'adapter naturellement, chaque unité sachant redéfinir toute seul son rôle dans l'organisation. Cela nécessite une métadescription de l'unité logiciel (un objet, un agent, ou autre chose) permettant de décrire le rôle de celle-ci et in fine de savoir s'adapter en adoptant par exemple un nouveau langage vers l'extérieur qui pourra lui être "appris" par la sémantique, c'est à dire en le rendant capable de réaliser des équivalences "conceptuelles" par reconnaissance de forme.
Outre la reconnaissance de forme qui suppose intrinsèquement des ontologies selon moi, cela suppose un langage plus déclaratif et descriptif des buts que les langages actuels qui décrivent la structure d'un graphe.
Outre ses considérations, il reste tout un champ de réflexion à ensemencer concernant entre autre la nature profonde du cause à effet, sa nature dans le cadre des phénomènes d'émergences systémiques (SMAs) , la place de la reconnaissance de forme dans la pensée humaine, la question de son implantation dans un langage, etc...
J'avoue que ce concept de "cause à effet" me file entre les doigt à mesure que je tente de le dissequer.
Un chantier passionnant en perspective.
Un modèle tout à fait applicable aujourd'hui, déjà largement étudié, permet d'ors et déjà de s'abstraire de la logique selon laquelle un langage de programmation reste une simple description d'un graphe : il s'agit de la programmation concurrente voire orienté agent.
C'est pour cela que j'ai cherché à concevoir un modèle de langage, au dessus du langage Lisaac (ceux qui me connaissent pourront se dire qu'on ne se refait pas...), cherchant à éliminer tout ce qui m'énerve dans la logique de programmation objet, par leurs manque.
Bref. Voici la dissertation que j'ai rédigé avec l'aide indispensable de Benoit Sonntag.
Introduction
Bon nombre de logiciels sont modélisables en termes de petites unités logicielles collaborant ensemble afin de résoudre les problèmes qu'on lui soumet. On peut parler de fonctionnement émergeant. Les paradigmes de programmation objets ont considérablement amélioré la tâche du concepteur logiciel en lui apportant un mode de découpage plus proche d'un mode de pensée humaine. On peut d'ailleurs remarquer que la montée en niveau des langages de développement logiciel est concomittente à une proximité toujours plus accrue des modes de pensés et de réprésentations humains. Le paradigme objet trouve néanmoins ses limites dans la réalisation de logiciels excédents plusieurs dizaines de millions de lignes en imposant des architectures très complexes, peu souples et peu fiables. [citer Victoria Livshitz] Cette constatation nous a amené à imaginer un modèle entièrement dédié à simplifier la tâche du développeur et surtout à lui permettre d'exprimer au mieux son intuition.
Nous pouvons synthétiser plusieurs caractéristiques :
- Un être humain conceptualise le monde en terme d'objets animés ou non d'intentionnalités.
- Les objets ont tendances à se comporter en fonction de
stimuli extérieur. - Ces objets se transmettent des informations entre eux, et ces informations peuvent donner lieu à une modification d'un comportement.
- Une cause implique un effet et vice-versa.
- Les informations manipulés dans les programmes représentent des perceptions humaines, et possèdent donc une structure ontologique
Notre modèle a pour objectif d'intégrer ces concepts tout en restant dans le cadre d'un langage objet à prototype classique. Si la modélisation d'une fourmillière nécessite un langage orienté agent, des calculs matriciels se satisfont parfaitement d'un langage orienté objet classique.
Les deux approches sont complémentaires. Par conséquent, l'une des contraintes que nous avons imposé à notre modèle est de concevoir une extension élégante dans son uniformité au langage Lisaac. Ainsi, notre modèle respecte les grandes lignes de ce langage et en particulier son caractère typé.
Les extensions ainsi prévu sont principalement orienté vers la conception de SMA réactifs et pulsionnels, l'approche par but étant particulièrement problématique à compiler d'une part et d'autre part s'intègre difficilement à un langage objet à prototype classique.
Nous identifions plusieurs mécanismes permettant d'atteindre ce but :
- Chaque agent doit pouvoir se comporter et réagir en fonction de son environnement direct. On défini donc des slots spécifiques, déclanchant un comportement si la clause est satisfaite
- Il est nécessaire, pour aider le concepteur d'un SMA, de récupérer facilement des données sur un ensemble d'objets ou d'agents. Nous proposons un système d'extraction de données, inspiré d'SQL et adapté au modèle objet. Ici, un identifiant ou une référence d'un objet n'est plus nécessaire à son accès.
- Les agents doivent pouvoir s'envoyer des messages en multicast en conditionnant la réception de ceux-ci à des critères définissable.
- Le concepteur de SMA doit pouvoir posséder un outil lui permettant de représenter plusieurs niveau de systèmes multi-agent, un SMA pouvant être un agent d'un autre SMA. entre agent.
Le choix du langage objet pour l'application de notre modèle agent se justifie essentiellement sur deux points cruciaux. Tout d'abord, les langages à classe reflètent d'une manière moins intuitive la vision que l'on peut donner à un agent. Le paradignme classe/instance des langages à classe implique que la description statique d'un classe n'est pas directement présent et vivant dans l'univers de notre application. Une instance est alors nécessaire pour qu'un premier représentant d'une classe soit présent et vivant en mémoire. Une classe ne permet pas de visualiser celle-ci comme directement un agent, mais plutôt comme un schéma de construction d'un agent. A contrario, la description d'un prototype constitue directement un objet présent en mémoire, utilisable tel quel ou clonable si nécessaire.
Ainsi, un prototype est directement en adéquation à l'image d'un premier "individu agent", comme Aden et Eve vivant dans notre SMA. Le second point est d'autre plus pragmatique. Si nous voulons démocratiser la programmation agent, de nombreux programmeur sont sensible à un point essentiel : les performances à l'exécution. Le langage Lisaac est actuellement l'unique langage à prototype possèdant un compilateur ayant de bonne performance à l'exécution.
Dans le cadre de cet article, nous ne pouvons pas réaliser une présentation détaillé du langage Lisaac. Le manuel de référence est disponible sur le site du projet Isaac (http://IsaacOS.loria.fr).
Le langage Lisaac - un langage objet à prototype
Pour donner une vue globale de Lisaac, notons simplement qu'il est syntaxiquement et sémantiquement proche du langage objet à prototypes Self , ou relativement proche du langage SmallTalk , (ce dernier étant néanmoins un langage à classe). En revanche, contrairement à Self, Lisaac se distingue par un système de type proche du langage Eiffel , avec entre autre la généricité (type paramétrique).
Caractéristiques de notre petit modèle agent
Nous allons illustrer les caractéristiques de nos extensions par l'exemple classique de la modélisation d'une fourmillière.
Régles et déclaration d'un agent
Un ensemble de règles doivent être respecter pour définir un agent :
Régle n°1 : Un prototype représentant un agent se distingue par l'affectation de la mention agent dans le slot
category de la section header du Lisaac (voir fig. ligne (1)).Régle n°2 : Un agent doit obligatoirement hériter du prototype AGENT directement ou indirectement via l'arbre d'héritage (voir fig. ligne (2)). Notons que le prototype AGENT n'est pas de catégorie agent. Le prototype AGENT implante un ensemble de fonctionnalité générique et nécessaire aux agents. Ce point fait l'objet de la section "Un agent : un prototype toujours actif". De plus, cela nous permet de respecter les règles de typage du langage Lisaac lors de la manipulation des agents.
Régle n°3 : Un prototype de catégorie agent est obligatoirement un prototype feuille et ne peut donc pas être parent d'un autre prototype. Cela implique l'absence d'un prototype de catégorie agent dans l'arbre d'héritage d'un agent. Cette règle permet une cohérence et une simplification du modèle d'exécution parallèle des agents que nous développons en section exécution.
Régle n°4 : La déclaration du slot
is_in de type agent est obligatoire dans la description du prototype AGENT (voir fig. ligne (3)). Ce slot est utilisé au niveau de la hierarchisation récurssive des SMAs et dans la communication inter-agent. Nous autorisons toutefois son absence pour un seul agent dans le système, la section meta-agent développe la présence de ce slot.
section HEADER
+ name := FOURMI;
- category := AGENT // (1)
section INHERIT
* parent_fourmi:AGENT; // (2)
section PUBLIC
- is_in:AGENT := FOURMILLIERE // (3)
Figure 1. Exemple de déclaration de l’agent F O U R M I
Définition récursive d'un agent
Une des bases de la définition d'un système multi-agent repose sur la récursivité de la notion : un SMA peut être lui-même un agent d'un autre SMA. Dans notre exemple, chaque organe d'une fourmi est un agent appartenant au SMA définissant l'entité d'une fourmi. Aussi, chaque fourmi peut être considéré comme un agent du SMA représentant la fourmillière. De même, plusieurs fourmillières peuvent définir un SMA englobant l'univers d'application de notre simulation.
Le slot
is_in imposé par la règle 4 permet d'architecturer les niveaux entre eux. Dans l'exemple de la figure , l'agent fourmi appartient à l'agent ou meta-agent, ou encore SMA fourmilliere.Cette appartenance étant réalisé par un slot classique, elle reste dynamique.
Un SMA (ou meta-agent) peut alors diriger et inter-agir en donnant des directives à ces agents de deux manières :
- via un message classique entre agents (voir section communication) ;
- via un message en multicast en utilisant comme sélection la valeur du slot
is_in.
L'agent représentant le SMA de l'univers d'application est l'unique agent n'ayant pas de slot
is_in. Dans notre exemple, l'ensemble des agents fourmiliere appartiennent au SMA englobé dans l'agent world. Celui-ci étant l'univers d'application, il ne possède pas de slot is_in décrivant son appartenance.Un agent : un prototype toujours actif
A la différence d'un objet qui n'est actif que lors d'un envoi de message, un agent doit pouvoir être toujours actif et avoir son propre comportement indépendemment des autres.
Ainsi, chaque agent a son propre contexte d'exécution. Le clonage d'un agent à pour conséquence d'obtenir un nouveau contexte d'exécution pour le fonctionnement de celui-ci. La définition de ce clonage particulier est décrit dans le prototype AGENT ; parent imposé par la règle 2 de la déclaration d'un agent. Aussi, pour éviter tout problème d'incohérence des données communes entre deux agents cloné, nous réalisons une duplication récursive de ses données (deepclone). Si le programmeur est désireux de partager des données à plusieurs agents, cela est toujours rendu possible par la construction d'un agent contenant ces données.
Cette encapsulation permet de gérer de manière fiable la cohérence de ces données lors d'accès multiple à un instant T.
Communication inter-agent
La communication est réalisé par un envoi de message classique de type
agent.slot.Si le slot contient du code (méthode ou procédure), deux cas sont possible :
- Si l'appelant réclame une réponse, par exemple
a := agent.slot, le flot d'exécution de l'appelant est stoppé jusqu'à obtention de cette valeur de retour.
- Si l'appelant ne réclame pas de réponse, le message est envoyé, stocké dans une FIFO de l'agent appelé, et l'appelant continu son flot d'exécution. Le message sera
traité ultérieurement selon le choix et le comportement de l'agent visé.
Au niveau du prototype AGENT, nous avons deux slots particuliers permettant de gérer et de maîtriser la FIFO interne des messages asynchrones :
has_new_messagede type boolean permet de savoir si un message est en attente dans la FIFO.pop_messagequi à pour objectif de déclencher l'exécution d'un message en attente dans la FIFO.
Si le slot appelé contient une donnée, nous renvoyons directement celle-ci sans passer par la FIFO et sans couper le flot d'exécution de l'agent appelé et l'agent appelant.
Les objets passés entre agents (arguments ou valeurs de retour) sont traités selon leurs types de la manière suivante :
- Si l'objet est de type
Expanded, objet de petite taille, comme un entier, un booléen, un caractère... , l'objet est directement passé d'un agent à l'autre. - Si l'objet est d'un type plus complexe (chaîne de caractère, structure, ...), nous réalisons automatiquement un clonage récursif (deepclone) pour éviter les incohérences possible causé par le partage de cet objet.
Une gestion plus complexe d'envoi de message de type mail est alors rendu possible par l'utilisation de ces primitives par une librairie standard.
Comportement
Un agent, intrinsèquement actif, doit décrire son comportement réactif. Celui-ci exprime comment l'agent se comporte à chaque instant et plus exactement quel comportement adopte t-il en fonction de son environnement.
Chaque comportement est lié à des conditions de son environnement ou à un état interne. C'est pour cela que nous décrivons le déclenchement d'un comportement à l'aide de clauses satisfaites lors de l'application de celui-ci. Chaque clause implémente le concept de cause à effet : La satisfaction d'une clause, autrement dit d'une cause directement liée à l'agent donne lieu à un effet (le comportement proprement dit).
Les clauses se posent sous forme d'une expression booléenne comportant un ensemble de termes et de connecteurs logiques.
Dans un langage objet classique, un message ayant un identifiant est à la base du déclenchement d'une action. Ici, nous remplaçons identifiant de message par la clause en question. De ce fait, le déclenchement de l'action (effet) est directement lié à la satisfaction de sa clause.
section PUBLIC
- (is_hungry) <-
(
to_eat_action;
);
Exemple : Si la clause
(is_hungry) est vrai, l'agent réalise l'action de manger.Tant que la clause est satisfaite, l'action se répète. Il peut être nécessaire de réaliser une action préalable au comportement répétitif
Preface et une action de finalisation de ce comportement Postface. Exemple :
section PUBLIC
- (is_hungry) <-
Preface
{
to_make_food;
}
(
to_eat_action;
)
Postface
{
to_clear_table;
};
Exemple : Ici, si la clause
(is_hungry) est vrai, l'agent commence par faire à manger to_make_food, puis fait l'action de manger to_eat_action tant que la clause est vrai. Avant de démarrer un autre comportement, l'agent débarrassera la table to_clear_table.Comme l'action répété peut être interrompu à tout moment, le code présent dans la partie
Postface permet de rendre la cohérence des données causé par la rupture brutal de l'action. Il est possible que plusieurs clause soit satisfaite à un même instant. Le choix du comportement prioritaire sera réalisé par une force de priorité défini après une clause.
section PUBLIC
- (is_hungry) Priority 5 <-
(
to_eat_action;
);
- (has_enemy) Priority 10 <-
(
to_beat;
);
Exemple : Si l'agent a un ennemi, il fait l'action de se battre, même si il a faim.
Notons que la priorité par défaut est de 0. En cas d'égalité des priorités, l'ordre de
déclaration des comportements rentre en jeu.
Le prototype AGENT
Nous avons décrit dans les sections précédente à certain nombre de fonctionnalité présente dans ce prototype. Ici, nous les rappelons rapidement en ajoutant certaines notions qui nous paraisse important.
section HEADER
+ name:= AGENT;
- category := MICRO;
section
- clone:SELF <- /* code system */
// Nouvelle définition du slot `clone' (deep-clone)
// Avec création d'un nouveau contexte d'exécution
- has_new_message:BOOLEAN <- /* code system */
// Vrai, si un message est en attente dans la FIFO
- pop_message <- /* code system */
// Retire et exécute un message de la FIFO
- (has_new_message) Priority 0 <-
// Comportement par défaut: Execution au plus tot d'un message en attente
(
pop_message;
);
- time:UINTEGER <- /* code system */
// Renvoi l'age de l'agent en milisecond
- timein:UINTEGER;
// Variable contenant un temps, nécessaire au calcul d'une durée.
- timeout limit_time:UINTEGER :BOOLEAN <-
// Calcul la durée écoulé entre `time' et `timein'.
// Renvoi Vrai, si cette durée est inférieur ou égal à la
// valeur `limit_time' ou si `timein' est égal à 0.
(
(timein = 0) || {(time - timein) <= limit_time}
);
Exemples de comportements attendus
Si nous voulons qu'un comportement soit interrompu pour répondre à un message, nous pouvons utiliser la forme suivante :
- (stat = 0) <-
// current_behaviour
(
// Code of behaviour
);
Par défaut, la priorité d'un comportement est 0, le comportement par défaut défini dans le prototype AGENT sera prioritaire (car déclaré de priorité 0, mais avant notre comportement). Notre comportement reprendra automatiquement son exécution après le traitement du message (au passage de
has_new_message = FALSE.Si nous ne désirons pas interrompre un comportement par un message, nous pouvons utiliser la forme suivante :
- (stat = 0) Priority 1 <-
// current_behaviour
(
// Code of behaviour
);
La priorité est supérieur au traitement d'un message.
Si nous voulons qu'un comportement de priorité supérieur à 0 soit néanmoins interrompu pour répondre à un message, nous pouvons utiliser la forme suivante :
- ((stat = 0) & (! has_new_message)) Priority 1 <-
// current_behaviour
(
// Code of behaviour
)
Postface
{
pop_message;
};
Un système multi-agent doit être réactif, et se conceptualise en temps réel. Le programmeur doit avoir la possibilité de conditionner l'exécution d'un comportement avec une limite de temps. Pour limiter l'exécution d'un comportement A à 30 millisecondes pour ensuite passer à un comportement B, nous pouvons utiliser la forme suivante :
- ((stat = 0) & (timeout 30)) <-
// Current behaviour A
Preface
{
timein := time;
}
(
// Code of behaviour A
)
Postface
{
stat := 1;
timein := 0;
};
- (stat = 1) <-
// behaviour B
(
// Code of behaviour B
)
Si nous voulons changer de comportement de manière synchrone à un
nouvelle état d'un autre agent:
- ((stat = 0) & (other_agent.stat != 1)) <-
// current_behaviour
(
// Code of behaviour
)
Postface
{
stat := 1;
};
- (stat = 1) <-
// New behaviour
(
// Code of new behaviour
);
Extraction de données
Les systèmes multi agents supposent une communication accrue, en particulier les agents complexes et cognitifs. Une modélisation complexe nécessite une bonne connaissance de l'environnement extérieur, en particulier des connaissances complexes sur les propriétés d'agent et objets extérieur. Dans les langages classiques, le programmeur est obligé de parcourir inlassablement des collections pour y trouver les données qu'il cherche. Dans un langage agent, c'est la communication qui pallie à ce manque.
Nous avons cherché un à définir un mécanisme utilisable par les agents et par les objets. C'est pourquoi le modèle Lisaac agent intègre un mécanisme d'extraction des données inspiré entre autre de SQL, il s'agit d'envoyer des requêtes permettant de filtrer des données à partir d'une ou plusieurs collections d'objets, ainsi que de déterminer une liste d'objets/agent répondant à certains critères.
On peut lister les fourmis ouvrières, s'occupant des couvains
L'objet "ensemble" est un objet dynamique
- position : NUMERIC;
- etat : SEMANTIC;
(position,etat) := list pos,etat where agent.type = OUVRIERE and
agent.current_behavior = rentrer_a_la_fourmilliere;
Lire à ce sujet la publication "QUEROM : AN OBJECT-ORIENTED MODEL TO REWRITING QUERY USING VIEWS" qui propose un très bon modèle.
http://csl.ensm-douai.fr/seriai/uploads/11/SERIAI_ICIES_CAME(...)
Conclusion
Le modèle "Lisaac Agent" se veut une synthèse pragmatique entre un langage à objet à prototype classique et un langage permettant de implémenter des systèmes multi-agent réactifs. Nous proposons un langage de haut niveau qui se veut simple, intuitif tout en restant puissant et polyvalent.
Designer des agent cognitifs y est par contre beaucoup plus difficile, ce langage se positionne clairement dans le domaine d'agent réactifs, car nous le percevons comme le prolongement naturel de l'approche objet. Néanmoins, le programmeur pourra développer des systèmes multi-agents capable de manifester des comportements cognitifs grâce à l'émergence de comportement intelligents au sein de SMA réactifs.
Ce modèle permet de constater que mise à part l'intégration du paraléllisme automatique dans le langage, un langage orienté multi-agent est très proche d'un langage objet classique.
Note : Les agents doivent "matériellement" considérés comme des threads.
Voilà, la discussion est ouverte. Je m'attend à des résistances conservatrices, comme d'habitude, mais ayez bien à l'esprit, qu'il s'agit pour moi de raisonner à 10-15 ans devant nous. On ne pourra indéfiniment programmer en Java/Lisp et consort.
Il s'agit aussi d'imaginer des logiciels diminuant intrinsèquement le nombre de bugs, et ne demandant pas des connaissances mathématiques poussées qui ne sont à la porté que d'une minorité (je dis ça pour ceux qui me répondront LISP ! Caml ! Oz ! Haskel !).
Il s'agit de libérer la puissance de l'intuition humaine.
Mes amis, soyez créatifs et visionnaires !
# Business-loto
Posté par ColonelMoutarde . Évalué à 10.
[^] # Re: Business-loto
Posté par imalip . Évalué à 10.
# Trop long...
Posté par nakan (site web personnel) . Évalué à 4.
[^] # Re: Trop long...
Posté par Nico C. . Évalué à 5.
[^] # Re: Trop long...
Posté par Alex . Évalué à 5.
Ceci-dit, j'avoue ne pas tout bien comprendre, mais je ne programme pas, ceci explique peut-être celà.
[^] # Re: Trop long...
Posté par neil . Évalué à -2.
# C'est interressant, mais...
Posté par TemPi . Évalué à 5.
[^] # Re: C'est interressant, mais...
Posté par Ontologia (site web personnel) . Évalué à 4.
Il faut savoir que ce langage est un "add-on" à Lisaac qui est un langage objet à prototype, qui lui-même est maîtrisable en deux jours par un bon codeur en Java/C++/Eiffel.
Donc on garde la plupart du temps les spécificités d'un langage objet classique.
Après il faut savoir, que matériellement un agent est un thread, et que les clauses auxquels il réagit sont des bêtes et très basiques booléens.
Donc on pourra mettre des print un peu partout pour surveiller ce qui se passe.
Seul les clauses fonctionnent en temps réel, elle sont appelés régulièrement, ou plutôt testées régulièrement, c'est un peu comme si on écrivait un code où on créerait n thread pour n objets d'une collection qu'on activerait régulièrement pour tester des booléen et lancer des méthodes.
Je veux dire que ce que créera le compilateur, ça sera des thread qui testeront régulièrement des booléen, je vois pas trop de problèmes de debugging, surtout que je pense qu'il va falloir définir une constante de temps (j'ai pas mis toutes mes idées dans le texte et je suis accompagné d'un gardien vigilent quand à la rigueur nécessaire du modèle).
Après, plus tard, il me semble qu'il serait intéressant de mettre un petit moteur logique dans le compilateur pour vérifier qu'il y a cohérence.
Malgré tout, je pense qu'il va falloir attendre l'implémentation pour le savoir ;-)
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: C'est interressant, mais...
Posté par Jerome Herman . Évalué à 10.
Debugger un programme multithreadé temps réel à coup de print ? BONNE CHANCE.
Sur ce genre de chose, le simpel fait d'ajouter un print change le comportement du programme/la priorité des threads et leur ordre d'execution.
L'idéal pour ce genre de chose c'est de pouvoir faire tourner le programme sur une VM, ou au moins de pouvoir "geler" uen partie de la machine réelle pour la dissequer calmement...
Les autres approches ont tendances à générer encore plsu de bugs qu'elles n'en résolvent.
Je veux dire que ce que créera le compilateur, ça sera des thread qui testeront régulièrement des booléen, je vois pas trop de problèmes de debugging
J'imagine que certains threads (système ou programmatiques) viendront mettre à jour les booléens de temps en temps non ?
Tous les problèmes de debugging arrivent à ce moment là (gestion de ressources, condition de courses, passage de messages foirés etc.)
[^] # Re: C'est interressant, mais...
Posté par Ontologia (site web personnel) . Évalué à 4.
Avec une constante de temps divisé par 1000 ou 10000 on pourrait surement simuler du temps réel, même sous linux et windows.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: C'est interressant, mais...
Posté par Ontologia (site web personnel) . Évalué à 2.
En effet le compilateur compilera le code de sorte que chaque thread gère un espace mémoire étanche : Toutes les données seront transmises en copie (via le deepclone), et le respect des priorités sera automatiquement "géré" par le compilateur.
Après, un interpréteur ne ferai pas de mal.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: C'est interressant, mais...
Posté par TemPi . Évalué à 4.
Hum... c'est pas limitatif, ca ? Si on veut écrire de grosses applis (> 10K objects), ca va vite écrouler la machine, non ?
[^] # Re: C'est interressant, mais...
Posté par Mouns (site web personnel) . Évalué à 5.
une des propriétés dy fameux hyperthreading est de pouvoir avoir autant de thread que l'on veut. donc si tout bout de code a son thread noyau vu en tant que processeur ... tu n'as plus de commutation de tache apparante, couteuses et source de bug innombrables.
puis une machine peut avoir plein de processus/threads/taches/traitements en cours de toute facon a moins de tous les avoir avec un flag "RUN" ... une machine quelconque s'en sort tres bien ... regarde ton linux.
[^] # Re: C'est interressant, mais...
Posté par Thomas Douillard . Évalué à 5.
(pour le terme "moniteur", je suis plus sûr, faudrait que je ressorte mes cours de système)
# Juste une question ...
Posté par ahuillet (site web personnel) . Évalué à -10.
C'est illisible, incompréhensible, et je ne serais même pas étonné que ça n'ait aucun sens.
Branlette de cerveau.
[^] # Re: Juste une question ...
Posté par Thomas Douillard . Évalué à 7.
Certains commentaires sont constructifs et émanent de gens qui savent visiblement de quoi ils parlent. Le journal a aussi le mérite de parler de choses plutot pointues (langages, SMA, ...) que tout le monde ne maîtrise pas, sur un site d'informatique plus généraliste.
Si ça t'intéresse pas, passe ton chemin, sinon c'est pas inutile de s'ouvrir un peu l'esprit.
[^] # Re: Juste une question ...
Posté par fmaz fmaz . Évalué à 3.
J'avoue que les journaux sur les optimisations de GCC ou
sur le driver xktzsdf qui est passé en version 0.00001 pre alpha
et qui permet de fait du full duplex crypto encapsulé et où
personne ne prend la peine de dire ce qu'est ce driver, je
n'y comprend rien.
# Un exemple...
Posté par jigso . Évalué à 6.
ok, section PUBLIC
- (out) <-
(
to_go_out_action;
);
[^] # Re: Un exemple...
Posté par Ontologia (site web personnel) . Évalué à 3.
section HEADER
+ name := HELLO_WORLD;
- category := MACRO;
section INHERIT
- parent_object:OBJECT := OBJECT;
section PUBLIC
- make <-
(
"Hello world !\n".print;
);
Je le répète, ce modèle n'est pas un nouveau langage c'est un ajout de primitives aux compilateurs. :-)
Tu peux parfaitement utiliser Lisaac en tant que langage objet classique.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: Un exemple...
Posté par Cali_Mero . Évalué à 10.
--> []
[^] # Re: Un exemple...
Posté par MsK` . Évalué à 1.
[^] # Re: Un exemple...
Posté par gnu_thomas . Évalué à 1.
J'ai choisis mon camp :)
# Et la marmotte...
Posté par Gauthier Monserand (site web personnel) . Évalué à 0.
désolé -> []
[^] # Re: Et la marmotte...
Posté par Larry Cow . Évalué à -3.
[^] # Re: Et la marmotte...
Posté par Gauthier Monserand (site web personnel) . Évalué à -3.
[^] # Re: Et la marmotte...
Posté par Ontologia (site web personnel) . Évalué à -1.
Ah oui ! J'oublie que dans notre société les rôles s'inversent !
Bon je -> []
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
# C'est pas mal du tout ton truc. Mais j'ai un gros doute...
Posté par Jerome Herman . Évalué à 10.
section HEADER
+ name := FOURMI;
- category := AGENT // (1)
section INHERIT
* parent_fourmi:AGENT; // (2)
section PUBLIC
- is_in:AGENT := FOURMILLIERE // (3)
et les différents méccanismes mis en place dans ton langage je me pose une question, as-tu jamais lu un livre sur les fondements de la programation paradigmatique ou multiparadigmatique ?
Par exemple ton déclarateur is_in pour décrire le slot à la construction de l'agent m'a l'air très casse gueule et peu intuitif.
De plus la variation des comportements me parait également bancale.
Par exemple pour le passage
- ((stat = 0) & (timeout 30)) <-
// Current behaviour A
Preface
{
timein := time;
}
(
// Code of behaviour A
)
Postface
{
stat := 1;
timein := 0;
};
- (stat = 1) <-
// behaviour B
(
// Code of behaviour B
)
J'ai peur. Tout d'abord quid de la gestion des popmessages dans ce cas là ? Faut-il les prendre en compte à la main dans dans le code comportemental ou sont-ils gérés en time sharing par le thread en parallèle ? Sont-ils gérés par interruption système ? Sont-ils dans une boucle invisible ? Dans les deux premiers cas quid de la fiabilité d'éxécution et dans le dernier cas quid de la garantie temps-réel ? Mêmes questions pour le timeout(30)
Ensuite pour les code comportementaux la notion de variable de décision me parait étrange dans un paradigme qui se veut porche du raisonnement humain
Pourquoi ne pas créer des slots comportementaux, pendant fonctionnels des slots agents.
Faire un truc du genre
--------------------------------------------------------
section BSLOT_HEADER
+ name := BEHAVIOUR_A;
- category := BSLOT
section RELATED_TO
* parent_fourmi:AGENT; // (2)
section ACTIVE
{//code du comportement a si actif}
section STOP
{//code du comportement a avant de passer la main}
section RESUME
{//code du comportement a en reprise de main}
section SLEEP
{//code de comportement a du programme en attente (message apr exemple)}
------------------------------------------------------------
Le code précédent deviendrait :
-------------------------------------------------
- (timeout 30)) <-
// Current behaviour A
Preface
{
timein := time;
}
(
is_active(BEHAVIOUR_A)
)
Postface
{
stop(BEHAVIOUR_A)
};
Preface
{
//condition d'arret du comportement B
}
// behaviour B
(
// Code of behaviour B
)
Postface
{
//cleaning
}
resume(BEHAVIOUR_A)
----------------------
Celà aurait a) l'avantage de ne pas se trimballer de variables (qui vont forcément géner sur ce genre de paradigme de programmation) et b) de pouvoir garder la main sur un comportement que l'on a stoppé brutalement pour des impératifs temps réel.
Mais bon il se peut que ce soit difficile/impossible à réaliser.
(N.B / il se peut qu'il y ait des monstruosité dans le pseudo-code écrit, je n'ai jamais fait de LISSAC dans ma vie, je me suis juste inspiré des exemples donnés. )
[^] # Re: C'est pas mal du tout ton truc. Mais j'ai un gros doute...
Posté par Ontologia (site web personnel) . Évalué à 3.
Sache seulement, qu'a priori, puisqu'il ne s'agit que d'un modèle, ce langage est essentiellement conçu pour tourner sur IsaacOS, et que le destin d'IsaacOS est d'être un système temps réel. C'est aussi un OS où la notion de processus n'existe pas, un processus n'est que l'association à l'instant T d'objets travaillant ensembles.
Donc imagine que le système peut donner la main à n'importe quel thread n'importe quand.
Pour le reste, il faut que j'y réfléchisse.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: C'est pas mal du tout ton truc. Mais j'ai un gros doute...
Posté par Mouns (site web personnel) . Évalué à 4.
donc un processus est assimilable à un (auto)bus transportant des informations entre objets ?
d'une certaines maniere si l'on voit un micro-noyau de type L4 ( sans scheduler ) , tout processus est assimilable à un gestionnaire d'IPC ( ou micro-noyau ) entre objet ?
ca à l'air rigolo comme idée surtout pour les implications sur l'integration des IPC ...
... quand on parle d'objet, on les identifie à leur signature ... puisque signature est une adresse et que l'action est assimilable à un service ... il n'y a qu'un pas pour y coller de l'IP.
les interets sont multiples :
- drivers cartes reseaux comme "routeur/brigde"
- partage de mémoire entre machine tres peu couteux
- migration d'objet a la maniere du "roaming"
- unification des IPC intra-host & inter-host
- possiblite d'avoir des services plus clair que ce que propose le GNU HURD ( qui est une tres bonne idée au niveau des jetons d'autorisation )
sinon pour ceux qui ont du mal, bottom-up & B2B & AJAX.
[^] # Re: C'est pas mal du tout ton truc. Mais j'ai un gros doute...
Posté par Ontologia (site web personnel) . Évalué à 2.
donc un processus est assimilable à un (auto)bus transportant des informations entre objets ?
D'après ce que je sais, c'est à dire par grand chose, tout se fait en VFT.
Pour le futur j'en sais rien, je réfléchi pas trop au bas niveau d'Isaac, c'est pas ma compétence.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
# reco
Posté par ccomb (site web personnel) . Évalué à 5.
Il y a un très bon bouquin qui aborde ce sujet :
Le connexionnisme et l'esprit de William Bechtel et Adele Abrahamsen (éditions la découverte/textes à l'appui).
Ils soutiennent que la plupart des activités mentales sont des sortes de reconnaissances de formes, les formes pouvant être n'importe quoi, y compris un motif temporel, une humeur, un stimuli quelconque.
Et ils opposent notamment le modèle connexionniste au système traditionnel à base de règles qui domine aujourd'hui avec tous les langages de programmation. Le probleme est que dès qu'on commence à parler de langage de programmation, ça implique presque automatiquement de parler de regles, et on s'éloigne alors du connexionnisme. Je ne sais pas s'il serait possible d'inventer une sorte de langage de programmation de réseaux de neurones...
[^] # Re: reco
Posté par blobmaster . Évalué à 3.
VHDL ?
je -->[ ]
[^] # Re: reco
Posté par TemPi . Évalué à 1.
Ce langage ressemble beaucoup à du VHDL.
On retrouve le paradigme des conditions d'entrée dans une procédure, on retrouve le paradigme "un object = un thread" (puisqu'en hardware, tout s'execute de manière concurrente")...
Ontologia, Avant de réinventer la roue, je t'encourage à regarder un peu plus du coté de VHDL.
[^] # Re: reco
Posté par Nicolas Boulay (site web personnel) . Évalué à 3.
"La première sécurité est la liberté"
[^] # Re: reco
Posté par LeMagicien Garcimore . Évalué à 1.
[^] # Re: reco
Posté par LeMagicien Garcimore . Évalué à 2.
VHDL est fait pour modéliser, simuler et synthétiser du materiel. L'utiliser pour modéliser des SMA, c'est faisable, c'est sûrement rigolo, mais c'est clairement contre productif à mes yeux. La sémantique du langage est tellement bordélique qu'il va s'arracher les cheveux pour modéliser un truc qui serait tout couillon dans un langage procédurale.
[^] # Re: reco
Posté par Guillaume Knispel . Évalué à 1.
# ressemblances, questions ...
Posté par Frédéric Heulin . Évalué à 3.
Cela` me fait pas mal pense' a` la pre'sentation que l'on m'avait faite de erlang, ou` tout est thread/processus justement.
(je dis pas que tu devrais basculer ton concept sur erlang mais c'est peut-e^tre une piste inte'ressante)
Sinon l'utilisation du deepclone ne risque-t-elle pas d'e^tre dangereuse ? (re'cursion agent appelant<->appele' par exemple)
[^] # Re: ressemblances, questions ...
Posté par gc (site web personnel) . Évalué à 10.
# Pas tout compris
Posté par tene . Évalué à 9.
- ne pas oublier qu'un langage, c'est aussi sa syntaxe, il est important, voir capital de rendre cela lisible. Si tu regardes les dernières évolutions des langages "les plus utilisés" (java, C#, C++, ...) il s'agit le plus souvent de sucre syntaxique!
- ne pas oublier les limitations des ordinateurs: tous (presque...) les langages sont turing complete, ce qui a pour conséquence directe que tu ne pourras pas créer de nouveautés fondamentales permettant de faire des choses impossibles avant! Ca explique sans doute pq la plupart des évolutions sont en fait perçue comme des "sucres syntaxique"... même si ces modifcations change notre façon de programmer.
- ne pas oublier non plus que ceux qui font les programmes sont des développeurs... ils ont donc leur façon de travailler, leur habitude... et leur expérience!
- Pour qu'un langage/paradigme soit adopté, il faut entre autre, qu'il apporte quelque chose, j'ai du mal à résumer les avantages de ce que tu présentes! comment résumerais-tu cela toi?
- Enfin, j'ai du mal à voir comment intégrer ce paradigme à l'existant, par exemple la vision d'un agent réagissant à une condition, c'est génial... mais que faire quand la condition est lié à l'utilisateur? j'ai l'impression que dans ce cas, cela revient à rajouter une couche entre l'évènement et la réalisation de l'action qui y est lié... on le voit par exemple en XAML: tu peux spécifier le déclenchement d'une action suite à une condition (modification d'une propriété), mais c'est utilisé pour la couche présentation, pas pour la couche métier...
voilà, mes 2 cents...
[^] # Re: Pas tout compris
Posté par Ontologia (site web personnel) . Évalué à 3.
1/ Possibilité d'écrire des applications multithreadées assez facilement. Du fait que Lisaac reste un langage objet, on pourra utiliser les fonctionalités agent au minimum : par exemple, les clauses de déclanchement de comportement ne seront activés que pour la réception de messages (voir 3/).
Tu n'as plus à te préoccuper de mutex et autres monitors
2/ L'intégration d'un SQL/Objet dans le langage qui devient en passant persistant. Imagine que lors du développement d'une GPAO, tu as besoin d'écrire une fonction "réapro" te renvoyant l'ensemble des pièces que l'on doit racheter (le seuil de quantité minimal dans le stock a été enfoncé).
Là le compilateur, te vérifie le typage, gère la BDD pour toi (on architecturera la chose de sorte que l'on puisse interfacer tout SGBD avec)
Les requêtes peuvent se faire sur des objets ou des agents présent en mémoire : tu n'as plus à parcourir des collections afin de récupérer les infos que tu y veux.
Avec un tel système, en faisant un select bien sentie, tu peux sélectionner une liste de thread (des agents) correspondant à des critères précis, récupérer la liste de ceux-ci et leur envoyer un message.
Par exemple dans un logiciel de son multipiste, tu veux couper toutes les pistes utilisant l'effet phaser.
Tu généralise ton code :
C'est un exemple trop simple pour que cela soit vraiment intéressant, mais imagine des requêtes beaucoup plus complexes, où le fait de programmer la requêtes à la main en faisant une boucle listant une collection (ce qui suppose de prévoir les bonnes méthodes public te renvoyant les informations voulues, te facilitant la tâche, etc... ) n'est plus utile.
Tu peux gagner un temps fou !
3/ Les messages asynchrones seront fortement implantés dans le langage. Tu pourras envoyer des messages particulier, attendre un reply, demander la liste historique des messages de tel objet ou tel agent, etc...
Dans le modèle, les primitives présentés suffisent à permettre de définir, dans la librairie, un service de messages très complet.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: Pas tout compris
Posté par tene . Évalué à 3.
Concernant le "SQL/Objet", je comprends l'intéret, c'est aussi ce qui se fait en autre en C# 3.0 il me semble (avec sans doute quelques différences qui m'échappe), et si c'est bien pensé, et applicable aussi bien aux données externes qu'internes, ça devrait en effet grandement simplifié la façon de penser des programmes (avec par contre le danger de mélanger les couches et de créer des composants fortement couplés sans même s'en rendre compte). Permets-moi juste de préciser que c'est surtout du sucre syntaxique tournant autour des lambdas expressions et l'utilisation de fonction en first class object.
Concernant l'aspect massivement multithread, je suis perplexe, j'ai l'impression que ça permettrait d'éviter la complexité syntaxique de ce genre de construction, mais j'ai un doute sur la simplication réelle, au contraire j'ai peur que cela rende un programme extrèmement complexe à comprendre. Quelle mécanismes existent-ils pour gérer les effets de bord? Dans tous les langages, c'est le problème, encore plus dans les langages objets (et leur idée de "remplacer un composant par un autre", pense par exemple à java et le fait que toute les méthodes soit virtuelles).
C'est déjà très complexe de faire un modèle objet single thread, gérer plus de 3 threads interdépendantes est vite un enfer... je n'oserais pas proposer à mon équipe de dev d'utiliser ce genre de chose, je vois déjà les cascades de threads créées sans même s'en rendre compte ;)
Enfin, as-tu des données sur les perf de ce langage? Je me doute que c'est encore expérimental, mais est-ce théoriquement possible de faire quelque chose de compétitif? (à savoir: le classique trade-off entre temps de dev et hardware nécessaire)
[^] # Re: Pas tout compris
Posté par Ontologia (site web personnel) . Évalué à 2.
Premièrement, je ne me suis pas gêné pour le mettre, parce que j'y ai pensé tout seul (SQL est mon "langage" de prog préféré). J'ai découvert, à l'occasion d'unjournal de TImaniac que C#3 l'incluerait. Bien que ça ne me plaise pas dans la forme retenue.
Je veux SQL intégré dans le langage, car j'en ai plus que marre de passer mon temps à parcourir des collections pour tester tel ou tel critères.
Deuxièmement, c'est effectivement du sucre syntaxique qui nécessite une modification du compilo (c'est pour ça qu'on l'a mis), mais qui simplifie la vie. C'est ça qui compte.
Concernant l'aspect massivement multithread, je suis perplexe, j'ai l'impression que ça permettrait d'éviter la complexité syntaxique de ce genre de construction, mais j'ai un doute sur la simplication réelle, au contraire j'ai peur que cela rende un programme extrèmement complexe à comprendre. Quelle mécanismes existent-ils pour gérer les effets de bord? Dans tous les langages, c'est le problème, encore plus dans les langages objets (et leur idée de "remplacer un composant par un autre", pense par exemple à java et le fait que toute les méthodes soit virtuelles).
C'est déjà très complexe de faire un modèle objet single thread, gérer plus de 3 threads interdépendantes est vite un enfer... je n'oserais pas proposer à mon équipe de dev d'utiliser ce genre de chose, je vois déjà les cascades de threads créées sans même s'en rendre compte ;)
C'est en effet un énorme problème (comme le souligne "Joel on software" : http://french.joelonsoftware.com/Articles/LeakyAbstractions.(...) ).
Mais le modèle est justement conçu pour que tu n'ais pas à penser aux threads" TU devra penser en terme d'agent vivant, sur le qui vive, attendant des évènement extérieurs.
C'est dans l'émergence de comportements que tu risque effectivement d'avoir quelques problèmes, surtout si ton agent réagit directement à des évènements extérieur.
Mais grâce au système de message (message synchrone objet classiq ou message asynchrone du type boite au lettre (le point 3/)), tu pourras rendre tes agent un tant soi peu "cognitif", limiter leur réactivité, et ainsi avoir des comportements émergeants limités.
Il existe (la méthode VOYELLE par ex) des formalismes permettant de ne pas avoir de problème, il est certain qu'il sera nécessaire de bien les formaliser avant de lacher un tel langage dans l'industrie, mais je pense que si quelques règles de base sont bien appliquée, tu n'aura pas de problème car, comme je le répète plus haut :
1/ Les threads sont autonomes et travaillent sur des données qui ne se balladent pas entre threads : toutes les données échangées se feront par copie, de sorte qu'il n'y ai pas de conflit
2/ C'est le compilateur qui gère tous les monitors et autres problème de synchro. Pour le programmeur, il ya des processus indépendants qui s'envoient des messages.
Enfin, as-tu des données sur les perf de ce langage? Je me doute que c'est encore expérimental, mais est-ce théoriquement possible de faire quelque chose de compétitif? (à savoir: le classique trade-off entre temps de dev et hardware nécessaire)
Pour le moment le compilateur n'étant pas implémenté, on en sait rien.
Par contre, sache que lisaac (l'actuel) est certainement le langage objet le plus performant au monde, il va beaucoup plus loin qu'Eiffel dont il est un descendant (et en même temps un sur ensemble) :-)
voir : http://isaacos.loria.fr/li_speed.html
Je ne sais pas ce que ça donnera, mais connaissant Benoit Sonntag, je prévoit que ça ira très très vite... ;-)
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: Pas tout compris
Posté par tene . Évalué à 3.
Ca m'intéresse qu'est ce qui ne te plait pas? que proposes-tu de mieux/différent?
Ne penses-tu pas qu'il s'agit d'un autre sujet? peut-être l'occasion de faire un autre journal, ou tu développes cela?
Mais le modèle est justement conçu pour que tu n'ais pas à penser aux threads"
C'est exactement ce que j'aurais à lui reprocher:
- avec un garbage collector certains te prétendent que tu n'as plus à penser à la mémoire, c'est faux! (c'est même plus difficile de contrôler sa mémoire avec un GC!). Il faut évidemment relativiser, peu d'application de nos jours sont réellement tracassée par leur mémoire...
- avec la prog objet, certains vendent le fait que l'analyse compte (et vive UML et autre formalisme) et que l'implémentation est un détail... c'est à nouveau faux. (ça amène des design élégant, mais jamais implémenté, ou des design "génrique" ne proposant pas de solution concrète dans un cas pratique)
- en C# tu peux déjà appeler un delegate de façon asynchrone, mais s'ils ont pensés au perf (pool de thread etc), tu as des cas explosifs (genre le delegate qui appelle des delegate etc...). Dans certains cas, ça passe par un message, à nouveau tu te retrouves parfois avec un appel bloqué qui attends des dizaines de messages avant de poursuivre!
- tu présentes un formalisme comme étant le truc qui permet de ne pas "avoir de problème" c'est vrai dans un monde théorique (et encore), un formalisme peut être vu comme un langage plus éloigné de la machine et plus proche de l'humain, cela ne le rend pas complet, correct, et surtout cela ne facilite pas forcément les choses. (pense à certains design pattern exprimé en qq mots, qq lignes de codes, et un schéma UML incompréhensible! Cependant, UML n'est pas le seul formalisme, il en existe sans doute de plus adapté selon le cas).
- Dans le même ordre d'idée, je ne pense pas que masqer l'existence de thread soit souhaitable, même le thread, qui est déjà une abstraction ne peut en général pas être utilisée tel quel, un développeur doit se demander comment se comporte son CPU (surtout sur un système multi-proc) s'il veut être efficace. Je ne doute pas de l'intéret d'une telle abstraction dans certains cas (je pense notemment au business rules engine), mais je me pose des questions sur la pertinence de mettre cela dans le langage même.
Concernant l'impact sur les performances, les thread ont un coût (dépendant de l'os et de la façon dont tu fais cela, par exemple, par défaut sous windows, chaque nouveau thread à un tas dédiés de 1Mo!), et encore plus si tu ne partages pas la mémoire, un deepcopy sera coûteux en temps et en mémoire!
Enfin ta recherche me semble de toute façon intéressante, je suis impatient de pouvoir tester les premières implémentation!
[^] # Re: Pas tout compris
Posté par Ontologia (site web personnel) . Évalué à 3.
Ca m'intéresse qu'est ce qui ne te plait pas? que proposes-tu de mieux/différent?
C'est la syntaxe qui ne me plaît pas. je la trouve compliqué.
Certes on peut faire
c'est un sucre syntaxique qui ne me plait pas.
Mais c'est un débat très secondaire, je suis bien conscient de pinailler sur des détails.
Moi je veux un SQL objet, rien d'autre, je veux pouvoir y mettre des sous requêtes, des group by, etc...
De plus, SQL, tout le monde connaît.
C'est exactement ce que j'aurais à lui reprocher:
- avec un garbage collector certains te prétendent que tu n'as plus à penser à la mémoire, c'est faux! (c'est même plus difficile de contrôler sa mémoire avec un GC!). Il faut évidemment relativiser, peu d'application de nos jours sont réellement tracassée par leur mémoire...
Effectivement, dans certains cas particuliers un Gc peu poser des problèmes.
Fort bien.
Je peu paraître extrémiste, mais je pense qu'il faut en finir avec la gestion à la main de la mémoire, il faut en finir avec les pointeurs.
Il est certes jouissif pour certains de jouer avec, mais, dans le cadre d'un gros projet de plusieurs centaines de milliers de lignes, il faut en finir, c'est un facteur de bug beaucoup trop important.
Je pense d'autre part que c'est au compilateur de gérer finement la mémoire, car un être humain ne pourra jamais le faire aussi bien, en tout cas à partir d'une certaine taille. Demander à un humain de gérer les emplacements mémoire de chaque données, à la main, pour que celle-ci se trouve contigue en mémoire afin d'accélerer le cache est très vite beaucoup trop complexes.
J'ai d'autres exemples de ce style.
Comme tu le dit, la mémoire n'est plus un problème pour la plupart des applications.
Je dirai même que c'est le boulot de compilateur de gérer celle-ci correctement, après analyse de flot.
- avec la prog objet, certains vendent le fait que l'analyse compte (et vive UML et autre formalisme) et que l'implémentation est un détail... c'est à nouveau faux. (ça amène des design élégant, mais jamais implémenté, ou des design "génrique" ne proposant pas de solution concrète dans un cas pratique)
Je ne m'occupe pas de méthode design pour le moment. Je m'occupe de créer un (des, car d'autres suiveront) langage(s) permettant d'exprimer le mieux et le plus vite possible l'intuition du développeur, que celui-ci ne soit pas obligé de se plier à des circonlocutions typiquement informaticienne pour implémenter des concepts évident pour un être humain normalement constitué.
Si tu prend une bataille navale, le concept "un croiseur envoie un message à tous les croiseurs de son équipe, dans un rayon de 400km" devient très vite un bordel immonde (et encore c'est un exemple très simple.
Il te faut parcourir une collection, trier selon l'équipe (un test) si ce n'est pas déjà fait, vérifier le type, calculer le module des positions, et le cas échéant appeler une méthode que tu devra avoir pensé pour répondre à un problème très précis (genre "aidez moi, j'ai plus de fioul").
Ce genre de chose ça me gonfle.
C'est en devant programmer ce truc précis, lors d'un projet en formation, que les idées à la base de cette publi (il n'y pas tout d'ailleurs) me sont venues car j'en avai plus que marre d'écrire 1500 boucles, en java qui plus est, où tu dois récupérer et caster ce que contiennent tes vectors.
Bref. Avec une requête SQL, un foreach, et surtout le concept de messages conditionnels en multicast, c'est réglé en 5 lignes.
Après, après... Quand j'aurai le langage fonctionnel qui aura le mérite de commencer à me satisfaire (parce que je serai satisfait qua quand on balancera les spécifs à la machine et qu'il programmera pour nous, on y arrivera un jour qu'on le veuille ou non), là je penserai peut être à réfléchir (ou trouver des gens pour ça) aux méthodes de formalisations type UML adaptée à ce langage.
Mais tout d'abord il faut commencer par le compilateur.
- en C# tu peux déjà appeler un delegate de façon asynchrone, mais s'ils ont pensés au perf (pool de thread etc), tu as des cas explosifs (genre le delegate qui appelle des delegate etc...). Dans certains cas, ça passe par un message, à nouveau tu te retrouves parfois avec un appel bloqué qui attends des dizaines de messages avant de poursuivre!
D'après le peu que j'en ai compris, le delegate est
1/ un sous-concept de messages entre objet
2/ un bricolage conçu pour contourner les limites de l'objet à classe.
Lisaac est un langage objet à prototype.
Dans un objet que tu écris, tu définis le parent, comme une variable (dans la section INHERIT)
Comme tout est objet vivant, tu peu définir finement qui est ton parent, et tu peux même en changer à l'exécution quand tu le désir.
Donc pas besoin de delegate pour dérouter des messages vers des parents comme l'explique : http://csharpro.developpez.com/page10.php
Tu fait
- tu présentes un formalisme comme étant le truc qui permet de ne pas "avoir de problème" c'est vrai dans un monde théorique (et encore), un formalisme peut être vu comme un langage plus éloigné de la machine et plus proche de l'humain, cela ne le rend pas complet, correct, et surtout cela ne facilite pas forcément les choses. (pense à certains design pattern exprimé en qq mots, qq lignes de codes, et un schéma UML incompréhensible! Cependant, UML n'est pas le seul formalisme, il en existe sans doute de plus adapté selon le cas).
C'est effectivement le plus gros problème. C'est pour cela qu'il faut réfléchir au maximum à une abstraction qui nécessite le moins possible de comprendre ce sur quoi elle s'appuie (comme tcp s'appuie sur ip) pour s'assurer de la maîtriser correctement.
C'est un gros travail.
Ce que nous proposons dans cette publi n'est qu'un modèle et il n'est pas certains que l'implémentation en soit fidèle.
Je pense néanmoins que le fait chaque thread sera dans un monde clot au niveau des données facilitera pas mal les choses.
Après c'est à voir, je pense particulièrement à l'émergence qui est un phénomène structurel.
C'est là que les méthodes joueront leur rôles. Elle sont d'ors en conception dans des labos.
- Dans le même ordre d'idée, je ne pense pas que masqer l'existence de thread soit souhaitable, même le thread, qui est déjà une abstraction ne peut en général pas être utilisée tel quel, un développeur doit se demander comment se comporte son CPU (surtout sur un système multi-proc) s'il veut être efficace. Je ne doute pas de l'intéret d'une telle abstraction dans certains cas (je pense notemment au business rules engine), mais je me pose des questions sur la pertinence de mettre cela dans le langage même.
la pertinence de le mettre dans le langage même consiste à proposer l'absraction pour les "certains cas" dont tu parles.
Un type qui fait une GPAO, un ERP, a autre chose à faire que de se prendre la têtes avec des priorités dans des threads.
Après n'oublie pas que ce qui est proposé est extension du langage que ce soit bien clair ! :-)
Rien ne t'empêche de ne pas utiliser les agents (bref de programmer en objet classique), de gérer toi même tes threads à la main, etc...
Ce que l'on présente dans cette publi, c'est une fonctionnalitée suplémentaire ! Rien d'autres.
Ceux qui jugeront utile de l'utilser l'utiliseront, les autres non. Tu as le choix.
Concernant l'impact sur les performances, les thread ont un coût (dépendant de l'os et de la façon dont tu fais cela, par exemple, par défaut sous windows, chaque nouveau thread à un tas dédiés de 1Mo!), et encore plus si tu ne partages pas la mémoire, un deepcopy sera coûteux en temps et en mémoire!
Enfin ta recherche me semble de toute façon intéressante, je suis impatient de pouvoir tester les premières implémentation!
Pour le coût, on s'adaptera aux OS existants bien que la fnalité de ce langage est de tourner sur IsaacOS qui sera un OS temps réel à terme et intégralement objet.
Pour l'implémentation ça risque de prendre du temps, surtout si messieurs les chercheurs tardent à donner le poste que Benoit Sonntag mérite...
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: Pas tout compris
Posté par tene . Évalué à 2.
Concernant C# je t'invite à regarder: http://msdn.microsoft.com/vcsharp/future/linqsamples/ le sucre syntaxique est plus évolué.
Concernant le GC je me suis sans doute mal exprimé, je ne suis pas contre, tout au contraire... mais dans ma vision des choses, ce n'est pas une façon "de ne plus devoir gérer la mémoire", juste une façon différente de gérer les choses... ça a des avantages (éviter pas mal de bug, rendre les choses plus simples, parfois plus intuitives, etc...) mais aussi des inconvénients (généralement on consomme plus de mémoire, parfois énormément plus parce qu'on ne réalise pas ce qui se passe derrière).
"C'est en devant programmer ce truc précis, lors d'un projet en formation, que les idées à la base de cette publi (il n'y pas tout d'ailleurs) me sont venues car j'en avai plus que marre d'écrire 1500 boucles, en java qui plus est, où tu dois récupérer et caster ce que contiennent tes vectors."
Peut-être un problème lié à l'utilisation de java? (genre dit rapidement: un design de m... :p).
Ce que je constate de mon côté: non tous le monde ne connait pas SQL! c'est même plutôt le contraire, il est très difficile de trouver quelqu'un de compétent en SQL!
En effet, la plupart des informaticiens peuvent te faire un "select * from news", en connais-tu bcp capable de t'estimer le temps d'exécution d'une requete, de te dire que select * from test where A=B and B=C est plus ou moins effaice que select * from test where C=B and B=A? de déterminer qu'il est temps de splitter la table parce que tu gagneras X % en perf?
Pas plus tard qu'hier, j'ai encore vu un développeur retourner l'ensemble des enregistrement d'une table, pour n'en prendre qu'un subset à afficher à l'écran! (typiquement ce qui me fait peur à intégrer le SQL dans le langage: on en aurait partout, et il serait difficile voir impossible de déterminer facilement SGBD, XML, mémoire, etc..).
"Si tu prend une bataille navale, le concept "un croiseur envoie un message à tous les croiseurs de son équipe, dans un rayon de 400km" devient très vite un bordel immonde (et encore c'est un exemple très simple."
foreach(Cruiser c in Team){
if(c.Dist(this) < 400) c.SendMessage("kikoo");
}
tu pourrais même imaginer, si la distance revient souvent faire un:
foreach(Cruiser c in TeamRange(400) c.SendMessage("kikoo");
ton exemple de distance est intéressant c'est exactement le genre de chose qui n'est pas toujours efficace en SQL.
"Mais tout d'abord il faut commencer par le compilateur."
J'ai du mal à comprendre ton approche, tu veux un compilo avant de définir comment tu vas t'en servir, j'ai tendance à penser dans l'autre sens... on arrivera pas à s'entendre là dessus :p Je suis troublé par ton article, il utilise un vocabulaire qui me fait penser à un papier universitaire, mais ta motivation semble très pragmatique, du genre "ça me fait chier de faire 30 lignes quand 2 suffiraient".
"D'après le peu que j'en ai compris, le delegate est
1/ un sous-concept de messages entre objet
2/ un bricolage conçu pour contourner les limites de l'objet à classe."
Un delegate c'est un sucre syntaxique te permettant d'appeler une méthode d'un objet depuis de façon dynamique (c'est donc le couple "signature de la méthode" et instance de l'objet, en C++ on a les pointeurs vers des méthodes, mais ça marche mal, là l'idée est là même mais c'est fortement typé, en java, c'est en gérénal le couple classe anonyme interface qui fait cela).
Je trouve l'explication sur developpez.com mauvaise... en effet ça fait bricolage! De plus c'est du mauvais code! (ça sert à quoi son truc affreux? à part montrer que c'est un design dégueu??? j'adore vraimetn ce site :p).
Les cas d'utilisation les plus courant des delegates sont: gérer les évènement (je veux appeler la méthode "toto" de ma classe quand l'utilisateur clique sur un bouton") et tout ce qui est callback.
Enfin, une suggestion as-tu déjà penser implémenter tes idées (hors sucre syntaxiques) dans un langage, voir comment cela se comporte?
[^] # Re: Pas tout compris
Posté par Ontologia (site web personnel) . Évalué à 1.
A la réflexion, moi qui défend constamment la nécessité méthodologique d'intégrer les deux approches (ascendantes et descendantes), je suis en train de tomber dans le travers en privilégiant une approche asendante pour lesquelles j'ai d'ailleurs toujours eu un faible.
N'ayant pas eu à mettre au point de gros projets dans l'industrie, n'ayant qu'une connaissance théorique d'UML, j'avoue avoir du mal à définir les problématiques.
Je pense que tu serais plus à même d'emmetre quelques idées à ce sujet. Je serai ravi de créer un petit projet visant à relever un ensemble de problématiques et de tenter de trouver des solutions.
Il serait intéressant de tenter de rêver :
- C'est à dire de définir un formalisme permettant de définir avec moins de difficultés qu'UML, avec plus d'intuitivité sans perdre de vue l'exactitude. Je veux dire "plus d'intuitivité" par la définition d'un formalisme qui nécessite moins de se plier au formalisme objet classique, de "faire rentrer un bateau miniature dans une bouteille" comme on le fait actuellement.
- Paralèllement de définir un langage permettant de supporter ce formalisme plus accessible par des primitives structurelles plus étendu, par de la reconaissance de forme, etc...
J'aurai donc quelques questions :
Les formalismes existant, comme UML, te satisfassent-ils pleinement ?
Pourquoi ?
Ne serait-il pas possible de définir un formalisme de spécification de plus haut niveau ?
Concernant le SQL.
1/ Le concept
Imagine cet exemple : J'ai une arborescence d'objets contenant chacun une pièce référencée (une nomenclature, quoi).
Je veux lister l'ensemble des pièces dont le grand-père est la référence 'A20' et dont le diamètre est supérieur à 20 mm.
Si je code ça à la main, c'est prise de tête, il faut faire un algo où je parcours l'arbre, où je teste le type des objets pour être sûr de pouvoir appeler le getter "diamètre".
Je te passe l'algorithme.
Avec mon système, je fait
arbre est l'arobrescence de pièce.
p est un ensemble de référence.
2/ L'application
Tu confond le concept et l'implémentation ou plutôt - comme je te pense trop fin pour faire cette erreur - tu me fait (gentillement) un procès d'intention en te basant sur SQL.
Si "select * from test where A=B and B=C " est plus lent ou rapide que "select * from test where C=B and B=A" alors que ces deux assertions sont logiquement équivalente, alors c'est le moteur qui a un problème.
Je pense probable que dans un second temps (voire à la première implémentation), un algorithme d'analyse de flot sera mis au point pour pondre, grâce à une heuristique, un algo rapide de calcul de la requête.
"Peut-être un problème lié à l'utilisation de java? (genre dit rapidement: un design de m... :p)."
Je n'aurait pas la prétention de dire que mon design était bon (bien que j'ai eu une excellente note sur celui-ci justement), mais ça m'a permis de me rendre compte que le design à une importance un peu trop profonde pour des détails un peu fin.
Je veux dire par là qu'à chaque fois que ton logiciel et/ou composant change, tu dois souvent changer pas mal de choses dans la logique des tes objets.
En gros le design peut avoir des causes léthales.
C'est très bien expliqué dans http://java.sun.com/developer/technicalArticles/Interviews/l(...) qui fut une des bases de ma réflexion.
J'aimerai aussi concevoir un langage dans lequel le design a moins d'importance, pour aboutir à un langage à composants adaptatif.
Ce n'est certes pas avec ce que j'ai présenté que cela se fera.
Enfin, tu remarques bien que ma contribution est d'un style universitaire, c'est normal puisque c'est un texte que l'on est ammené à soumetre à une conférence de recherche dans les tous prochains jours.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: Pas tout compris
Posté par Ontologia (site web personnel) . Évalué à 2.
Je pense qu'il ya possibiité d'obtenir de bonnes perfs sur le système de requêtes en optimisant celle-ci d'une part (coupes dans l'arbre, compilation inline de l'algo de calcul de la requête) et d'autre part en réorganisant les données de tel façon qu'on puisse retrouver assez vite les données.
Dans un contexte ou tout est compilé (ie que des micro objets), on pourrait utiliser l'analyse de flot pour organiser des indexs prévus pour "coller" à la requête.
Quand au thread, je vois pas de problèmes de perfs.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
# temps réel
Posté par Nicolas Boulay (site web personnel) . Évalué à 8.
Le temps réel exposé ici avec des clauses de timeout est un peu bizarre. Le temps réel c'est surtout avoir la garantie que le système réponde en un temps donnés.
Donc, pour ça, le plus simple est de lui garantir que le temps qu'il mesure lors d'un essais sera toujours le même.
C'est par exemple impossible à garantir sur une machine linux : cela dépends des autres processus, cela dépend de ce que doit faire le noyau et cela dépend de comment est codé les drivers utilisés (il parait que les drivers nvidia peuvent prendre le bus pci pour de très long burst qui peuvent être génant...)
Donc, il faut avoir des drivers avec des temps d'execution de fonction bornées et connu et avoir un ordonanceur adapté au problème que l'on traite.
D'un autre coté, je ne suis pas sur qu'un système multi-agent soit adapté à du temps réel. 2/3 thread cela fait déjà mal à la tête à concevoir.
"La première sécurité est la liberté"
# Re: Le langage de mes rêves
Posté par Larry Cow . Évalué à 5.
Désolé.
[^] # Re: Le langage de mes rêves
Posté par Grumbl . Évalué à 4.
http://n.favrefelix.free.fr/rond.php5/compilateur-bf
[^] # Re: Le langage de mes rêves
Posté par tfeserver tfe (site web personnel) . Évalué à -1.
[^] # Re: Le langage de mes rêves
Posté par Vivi (site web personnel) . Évalué à 3.
# Et le langage humain de mes rêves...
Posté par Yusei (Mastodon) . É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)
[^] # Re: Et le langage humain de mes rêves...
Posté par Sytoka Modon (site web personnel) . Évalué à 3.
> que l'on puisse programmer des design patterns. Pour l'instant on
> ne peut pas les programmer, ce sont des concepts que le
C'est ce qui me plaisait en Forth. Il y avait la possibilité de créer des mots avec la propriété "immédiate" qui s'éxécutaient lors de la pré-compilation (Forth est un langage semi-compilé). Il était assez facile pour un utilisateur lambda (comme moi) de rajouter ses propres structures de controle au langage.
De ce point de vue, les langages modernes sont bien pauvres.
[^] # Re: Et le langage humain de mes rêves...
Posté par Yusei (Mastodon) . Évalué à 3.
[^] # Re: Et le langage humain de mes rêves...
Posté par Sytoka Modon (site web personnel) . Évalué à 4.
Tu peux ensuite décider qu'un mot est "immédiate". Il sera donc exécuté lors de la phase de semi-compilation. Cependant, la syntaxe d'un mot "immediate" est exactemet la meme que celui d'un autre mot. C'est juste son contexte d'execution qui change.
Ca pourrait faire penser aux évaluations différées ou immédiates en Mathematica ou en Mapple selon le type d'affectation (= ou := pour Mathematica), voire la même chose avec le gnu/make.
Ici, c'est un peu différent puisque cela ne concerne pas l'affectation mais la propriété d'un mot.
[^] # Re: Et le langage humain de mes rêves...
Posté par Ontologia (site web personnel) . É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
# Re:
Posté par gph . Évalué à 3.
Notons que la priorité par défaut est de 0. En cas d'égalité des priorités, l'ordre de
déclaration des comportements rentre en jeu.
Ce genre de propriétés est maintenu dans le but d'avoir une execution deterministe ? Parce que c'est interessant de temps à autre d'explorer un peu les autres comportements. Disons que si tes agents on deux actions de même priorité, une mortelle et l'autre non, ils vont toujours faire celle qui les tuent parce que elle est indiquée en 1er dans le code source ?
Et merci pour ce journal que j'ai trouvé interessant.
[^] # Re: Re:
Posté par THE_ALF_ . Évalué à 2.
Il me semble que lorsqu'on a à traiter un grand nombre d'objets possédant un grand nombre d'interactions, ce pourrait être très intéressant de pouvoiravoir une approche de ce type en "built-in" dans le langage. Couplé avec un vrai générateur de nombre aléatoire en hardware ça serait cool.
Bon, mes 0.2 euros, je retourne à mes Monte Carlo :-D
[^] # Re: Non-Deterministic Programing
Posté par THE_ALF_ . Évalué à 3.
Enfin voila, si quelqu'un bien informé est de passage sur ce commentaire, entre deux trolls, merci :-D
# Les lois de la vie
Posté par oritorx . Évalué à 0.
J'aime l'idée, et apres tout, qu'elle programmeur ne l'aime pas ? Concevoir un modèle de vie est d'une complexité interressante à l'extreme. D'ailleurs, je pense que tant que l'intelligence ne sera pas intégralement expliquée, toutes les méthodes, aussi surprenantes qu'elles puissent être, sont sans doute toute aussi sensées qu'un réseau de neurone.
Néanmoins je reviendrait sur un principe de notre vie, nous obéissont à des lois fondamentales :
1 - Nous naissons de parents
2 - Nous affrontons des difficultés de notre environnement
- Nous nous reproduisont
3 - Nous mourront
l'étape 2 se répétant en boucle, selon notre adaptation à l'environnement, nous nous reproduiront plus ou moins souvent et toujours avec une légere différence, puis nous mourront, notre réussite ou perfection vis à vis de notre environnement influant ainsi sur la population futur.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.