Devant la puissance de l'argumentation j'ai mis le temps...
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.
p := select obj from arbre where obj.père.père.is_ref "A21" and obj.diamètre > 20;
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) . En réponse au journal Le langage de mes rêves. É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