 |
| R-Sharp | |
| DocKimbel | 20-Jan-2011/23:57:32+1:00 |
| Enfin dockimbel tu es l'auteur de R-Sharp? Si oui peut-on un peu discuter de la genèse du projet, de l'état d'avancement et d'une finalisation possible de ce projet? J'ai démarré ce projet en 2004 comme une expérimentation, après avoir accumulé pendant plusieurs années suffisamment d'information pour avoir un modèle viable de l'implémentation de REBOL, car les évolutions de REBOL avaient sérieusement ralenties et le côté propriétaire du langage commençait à me peser au quotidien dans mon travail (absence de doc sur le modèle mémoire, le GC, bugs natifs corrigés au bout de x mois/années voire jamais corrigés, pas de possibilité d'étendre les types, etc..). Ne souhaitant pas faire un clone exact en terme d'implémentation (pour éviter un clash frontal avec RT), j'avais profité de l'occasion pour tester de nouvelles approches, comme par exemple: - implémentation des blocks en mode "node-based" au lieu "array-based" (source: Carl) pour REBOL (en gros, tableau de pointeurs sur des cellules vs tableau de cellules) - boucle d'interprétation itérative au lieu de récursive pour REBOL (supputation, mais très probable) permettant de manipuler plus facilement l'état de l'interpréteur et faciliter l'implémentation de co-routines et de l'optimisation "tail call" pour les appels récursifs. - garbage collector de type "moving collector", permettant de compresser les zones libérées afin de réduire la consommation globale de mémoire comparé à REBOL (je trouvais que REBOL consommait trop de mémoire pour les tâches qu'il avait à réaliser). - la possibilité de définir ses propres opérateurs infixes (ex: !=: make op! func [a b][a <> b]) Les premiers tests ont montrés que mon approche n'était pas trop mauvaise (je craignais une perte de perfs importante comparé aux choix de Carl dans R2), R-sharp était 20-30% plus lent que R2, mais en permettant une plus grande souplesse dans la gestion mémoire et de l'interpréteur. Au bout de quelques mois, le projet est devenu public et j'ai eu une réaction de Carl : il m'a envoyé plusieurs emails pour m'expliquer longuement que faire un clone était une mauvaise chose pour REBOL et la communauté, que cela allait ruiner ses efforts et me demandait de ne pas continuer. Il a couplé çà avec une annonce (fin 2004 ou début 2005, je ne me souviens plus trop) sur la mailing-list de la sortie "imminente" d'une interface "plugin" pour REBOL permettant l'écriture d'extensions du langage en C ! (L'interface "plugin" a été implémentée seulement 5 ans après dans le cadre du "host-kit" R3). Suite à cette annonce et ne voulant pas être un problème dans l'évolution de REBOL, j'ai cédé et j'ai arrêté de publier de nouvelles versions de R-sharp. (Certaines parties de code ont été reprises dans le projet Orca, mais non gardées dans Boron) J'ai néanmoins continuer à faire des forks internes de R-sharp pour tester d'autres approches. J'ai également fait un prototype d'interpréteur REBOL en REBOL incluant un débugger pas à pas et une console dans le style gdb (http://www.gnu.org/software/gdb/). Ca marchait plutôt bien, mais les performances étaient très mauvaises (50 à 100 fois plus lent que REBOL en C) et c'était donc inutilisable en pratique. Le code n'était pas optimisé, mais je ne pense pas qu'il soit possible de descendre en dessous de 20 à 30 fois plus lent en utilisant un interpréteur, ce qui est déjà trop. Je n'ai pas poussé plus loin cette expérimentation. Rétrospectivement, je pense que j'ai fait une grosse erreur en arrêtant R-sharp en 2005, on aurait pu avoir, depuis plusieurs années, un clone (à 99%) open-source et performant...Je me suis toujours demandé ce qu'il serait arrivé, si la communauté aurait suivi, si RT aurait laissé tombé ou pas... L'état d'avancement de la dernière version de R-sharp est à peu près 50% de R2/Core de l'époque (pas très différent du R2/Core actuel). Je ne compte plus travailler dessus, je considère ce projet comme obsolète. Pour être tout à fait franc, je suis actuellement en train de travailler sur un nouveau projet de même ordre, commencé en novembre dernier, mais je ne veux pas en parler tant que certaines étapes de maturité du projet ne sont pas atteintes. Tout ce que je peux dire, c'est que ce nouveau projet est beaucoup plus ambitieux que ne l'était R-sharp. Je pense pouvoir faire une annonce d'ici un mois, si je décide de pérenniser ce projet. Je n'en parle ici que pour expliquer pourquoi je considère R-sharp comme obsolète. PS: je voudrais en profiter pour tordre le coup à une idée reçue : REBOL n'est pas une VM (machine virtuelle), mais un interpréteur. Il n'y a pas de langage ou d'abstraction intermédiaire (comme une jvm) en interne dans REBOL, car cela impliquerait une compilation vers un langage bas-niveau, or, le langage REBOL n'est pas compilable en code machine dans son ensemble (confirmé par Carl). La seule VM existante dans le monde REBOL était Rebcode (http://www.rebol.com/docs/rebcode.html) | |
| trigram | 21-Jan-2011/7:40:09+1:00 |
On comprend mieux l'histoire du financement...  http://www.digicamsoft.com/cgi-bin/rebelBB.cgi?thread=%3C19Jan2011102600761443100%3E Je me réjouis à l'avance de cette idée et j'espère qu'elle ira jusqu'au bout. Gageons que ce genre de thread puisse continuer à raviver la communauté francophone... que l'activité du forum continue sur cette pente ascendante (GreG des Stats ?!) Et que cela viennent en parallèle des projets autour d'un R2 Entreprise / Ultimate, de REBOL Duplex, du REBOL + Cheyenne + sql-protocol.... Doc, je te laisse à ton et rdv dans un mois. Bon courage. | |
| GreG | 21-Jan-2011/9:17:07+1:00 |
| Je me souviens bien de R-Sharp et même de sa présentation durant un Rebol Day. Je l'avais téléchargé, compilé, et j'avais commencé à analyser comment il marchait. Hélàs, pour les raisons que tu mentionnes ici, il a été abandonné. Avec ton expérience, comment analyses-tu la "lenteur" de RT? Est-ce que tu penses que RT est conscient du problème d'un R2 presque gelé et d'un R3 toujours en lab? | |
| jocko | 21-Jan-2011/9:44:37+1:00 |
| Je crois me souvenir aussi qu'à une époque, cette annonce avait boosté RT, qui avait accéléré (un peu) ses développements. D'une manière générale, j'ai l'impression que Carl prend tout son temps ... sauf lorsqu'il sent un début de concurrence, ce qui l'oblige à finaliser des choses. Doc, je ne peux que t'encourager ! | |
| paullys | 21-Jan-2011/9:57:03+1:00 |
| Ton projet est une grande nouvelle, une très grande nouvelle même pour la communauté Rebol! Une compatibilité R2 est-elle possible (même en conditions dégradées)? Si tu ne prévoyais pas de compatibilité R2, je t'invite à fortement à y songer car dans le choix des reboliens entre ton projet et R3, ce sera un argument que je pense décisif. Ensuite l'avantage que je vois dans une VM pour les perfs (m^me si en première reflexion une VM impose une étape supplémentaire) c'est que l'ouverture du bytecode permet à d'autres langages et donc d'autres communautés d'accéder au coeur de ton langage tout en gardant la main sur ta manière de générer le bytecode. Ce langage est proche de Scala? Comment participer à ton projet? | |
| Jedi | 21-Jan-2011/10:10+1:00 |
| Pareil ici : FONCE ! Ca, c'est le genre de projet qui risque de sacrément bousculer les choses... (parce que bon, le fonctionnement de RT et de Carl, à force, no comment... pour ne pas dire no future...) a+ Sébastien 'Jedi' Jeudy. -- http://www.neosysta.com & http://twitter.com/neosysta | |
| DocKimbel | 21-Jan-2011/12:26:19+1:00 |
| Avec ton expérience, comment analyses-tu la "lenteur" de RT? Est-ce que tu penses que RT est conscient du problème d'un R2 presque gelé et d'un R3 toujours en lab? Carl est seul à développer le noyau R3, il prend le temps de bien faire tout en expérimentant beaucoup car il n'a aucun contrainte de temps ! Carl est pleinement conscient que R2 est figé et que R3 avance très lentement. Simplement, il a gardé des références du passé, comme par exemple la comparaison avec Perl, qui était le principal "concurrent" en ligne de mire de REBOL à sa sortie. Comme Perl 6 (grosse refonte de Perl) n'est toujours pas sorti après plusieurs années de dev (3, 4 ou 5 ans ?), il considère que R3 n'est pas "trop" en retard...Une autre raison existe aussi pour expliquer le retard de R3, c'est qu'il doit faire de temps en temps un certain nombre de devs payants pour des entreprises clientes afin de se financer. Le "time to market" comme disent les anglo-saxons est devenu crucial aujourd'hui dans le monde du logiciel, la règle est souvent de sortir le plus vite possible une application ou un service quitte à ce qu'il soit instable...on peut le regretter, mais dans le contexte actuel du marché, c'est une stratégie qui fonctionne souvent bien. Personnellement, je préfère limiter le nombre de fonctionnalités plutôt que de fournir un produit qui n'est pas stable pour respecter une deadline. @Jocko: tu as tout à fait raison, la concurrence est une des rares choses qui puisse stimuler Carl. @Paullys: attention, ce n'est pas encore officiel . Compatibilité R2: oui en partie, difficile à estimer pour l'instant, je table sur du 90%, mais ce sera difficile à atteindre. En matière d'arguments "décisifs", il y a du lourd de mon côté (çà, c'est pour le teasing ), mais le simple fait d'être pleinement open-source est je crois l'avantage n°1. Il n'y a pas de VM dans mon langage, néanmoins, il sera portable vers des VM du marché (JVM et CLR sont des cibles incontournables, mais je ne suis pas sûr d'être celui qui fera le portage par manque de temps, donc s'il y a des volontaires, il y aura des sous-projets intéressants à mener).Ce langage est proche de Scala? Non, REBOL reste globalement le modèle à suivre pour moi, mais il y a des influences venant de Scala. Comment participer à ton projet? Contrairement à Carl, je ne compte pas tout écrire tout seul, car je veux aller vite, donc les bonnes volontés seront les bienvenues et le langage est étudié pour permettre de facilement déléguer certaines parties à d'autres sans impacter le noyau (par ex. je ne pourrais pas développer tous les datatypes seul, ni tous les protocoles de communication, c'est trop de travail pour le délai que je me fixe). Mon objectif est d'avoir une v1 en 2011 (et pas en décembre), quitte à repousser certaines fonctionnalités importantes dans les versions suivantes. Mais j'ai besoin encore d'un mois pour terminer le prototypage du noyau, décider de la stratégie et du planning, et faire une annonce officielle. @Jedi: merci ! | |
| ldci | 21-Jan-2011/14:06:02+1:00 |
| @DocKimbel: ça c'est une bonne nouvelle. Bon, il va falloir aller chercher des financements de type ANR? Ca peut se faire si on s'organise. | |
| paullys | 21-Jan-2011/14:31:51+1:00 |
| Open source! écrits en C? Viens dans mes bras Dockimbel!!! C'est l'émotion | |
| DocKimbel | 21-Jan-2011/16:44:16+1:00 |
| @ldci: ça serait idéal, le financement risque d'être un facteur limitatif pour moi, j'ai prévu un business model dans ma stratégie, mais il ne pourra me financer que partiellement durant les premiers mois...Je te propose d'en reparler une fois mon annonce officielle faite. @paullys: non pas en C, le prototype est écrit en REBOL, la version finale sera écrite dans le langage lui-même (oops, j'en dis trop là ). L'interfaçage avec le C reste un point crucial pour moi, je m'inspire de Lua pour cette partie là. Le code source sera publié sous licence BSD ou LGPL pour pouvoir être intégré dans des applications fermées si nécessaire. | |
| DocKimbel | 21-Jan-2011/16:48:10+1:00 |
| @trigram: comme je n'avais pas prévu de parler de ce projet avant fin février, je souhaiterai que l'information ne soit pas encore diffusée sur les canaux AltME, rebolweek, ou autre forums... | |
| trigram | 21-Jan-2011/17:26:06+1:00 |
| @DocKimbel Quelqu'un me parle ? Pas de soucis. De toute facon, si aucun des bloggers autorisés ne bouge sur Rebol Week, j'arrête de contribuer au blog, d'alimenter le Twitter, Facebook et Buzz. Je préfère me concentrer sur la communauté francophone REBOL à aujourd'hui et au futur DocKimbol  De toute manière, je ne parlerai plus de ce sujet pour : 1/ te laisser travailler sur le sujet... 2/ attendre de voir si tu décides fin février que ton projet est viable et de l'ouvrir au monde... Nico | |
| paullys | 21-Jan-2011/17:41:37+1:00 |
| quand je dis que Rebol est une merveille pour le prototypage!! j'ai un petit bout de code de parser simplifié pour calculatrice scientifique (juste les fonctions accesibles en rebol) qui grâce a rebol est sorti en quelques heures! | |
| deglingo | 21-Jan-2011/19:33:22+1:00 |
| Ca, Doc, c'est la meilleure nouvelle de ce début d'année !! Sacré teasing !!! On a vraiment envie d'en savoir plus, j'ai quelques questions qui me viennent à l'esprit, mais j'attendrai ton annonce officielle pour les poser... faire une V1 en moins d'1 an, c'est ambitieux, ça décoiffe !! En tout cas, "may the force be with you" !!! Et, je pense que ça ne peut être que bénéfique pour la communauté Rebol. Je re-cite à ce propos les mots du créateur d'Orca/Boron : I have no idea what Carl thinks about my projects. As with everything else ever designed by man, Rebol is an amalgamation of previously known ideas. The more widely ideas and information are spread and the greater the variety of combinations we can explore, the better off we'll all be. | |
| ldci | 21-Jan-2011/21:30:12+1:00 |
| @ldci: ça serait idéal, le financement risque d'être un facteur limitatif pour moi, j'ai prévu un business model dans ma stratégie, mais il ne pourra me financer que partiellement durant les premiers mois...Je te propose d'en reparler une fois mon annonce officielle faite. @DocKimbel: Aucun problème. On verra ce point en temps utile. | |
| wet_wet_wet | 22-Jan-2011/23:02:14+1:00 |
| SCALA was mentioned in one of the previous comments, looks like there is an article on theserverside.com about SCALA. see link below. http://www.theserverside.com/news/thread.tss?thread_id=61703 on another note, I think dockimbel's initiative for an alternative language should be followed through. this will allow the group to break free and set the group free from Rebol's stagnation and inconsistent and slow releases. One day he will crawl out from his cave and find that he is the only person using Rebol, his Rebolution having turned into a RebolImplosion. | |
| wet_wet_wet | 22-Jan-2011/23:04:32+1:00 |
| [ typo corrected to avoid any confusion :- "he" replaced by "CARL" ] SCALA was mentioned in one of the previous comments, looks like there is an article on theserverside.com about SCALA. see link below. http://www.theserverside.com/news/thread.tss?thread_id=61703 on another note, I think dockimbel's initiative for an alternative language should be followed through. this will allow the group to break free and set the group free from Rebol's stagnation and inconsistent and slow releases. One day Carl will crawl out from his cave and find that he is the only person using Rebol, his Rebolution having turned into a RebolImplosion. | |
| paullys | 24-Jan-2011/14:05:36+1:00 |
| @Dockimbel J'ai ouvert un topic "langage de mes rêves" en commençant par mes propres songes, à quelle distance des songes éveillés postés se situe ton langage? Pourquoi Rsharp est obsolete? | |
| paullys | 24-Jan-2011/14:06:40+1:00 |
| Ou plus malicieusement, Dockimbel, viens nous dire à quel langage tu rêves. | |
| DocKimbel | 24-Jan-2011/14:29:17+1:00 |
| R-sharp: je le considère obsolète car il est trop calqué sur REBOL au niveau de l'implémentation et j'ai mis du temps à réaliser que REBOL n'est pas un langage de programmation générique, son implémentation actuelle le cantonne à être un langage "glue" ou langage de script de haut niveau, il n'est pas adapté pour faire du traitement lourd de données, notamment du calcul lourd, comme illustré par ce benchmark: http://shootout.alioth.debian.org/gp4/performance.php?test=nbody (REBOL est dans les derniers). Je pense que ce n'est pas une fatalité en soi, mais une limitation de l’implémentation de RT. | |
| Didec | 24-Jan-2011/16:23:41+1:00 |
| Juste pour m'amuser quelques minutes, j'ai un peu corriger le code Rebol de ce n-body-problem et ma version ne prend que 88% du temps de la version publiée. 12% de rabais c'est pas beaucoup en période de solde, mais c'est déjà ça Mais bon, ça reste méga lent pour du calcul scientifique, c'est sure. | |
| paullys | 24-Jan-2011/17:16:25+1:00 |
| C'était l'objet du rebcode. Une bonne définition et solide implémentation du rebcode puis la réecriture de rebol en rebcode aurait pu apporter beaucoup de ce coté là ainsi que du côté de la cohérence du langage. | |
| DocKimbel | 24-Jan-2011/19:04:26+1:00 |
| @Didec: bonne tentative, mais on part de trop loin (~960 fois plus lent que la meilleure solution en C) et les possibilités d'optimisation sont très limitées. @paullys: oui, rebcode aurait pu donner de bons résultats dans ce genre de test, mais l'écriture de formules complexe est pénible en rebcode à cause de son expressivité très limitée (calquée sur de l'assembleur). De toute façon, il a été abandonné par RT autant en R2 qu'en R3. | |
| ldci | 24-Jan-2011/19:13:01+1:00 |
| C'est vraiment dommage l'abandon de RebCode: les tests étaient assez prometteurs et finalement la syntaxe restait rebol like test1: rebcode [] [ set a fin set i deb seti n maxv repeat i n [ add a i] return a ] ; rebol 2 test2: func [ ] [ a: fin i: deb n: maxv repeat i n [a: a + i] return a ] | |
| DocKimbel | 24-Jan-2011/20:21:24+1:00 |
@ldci: oui, je le regrette aussi, on aurait pu écrire un compilateur REBOL->rebcode pour passer outre la limitation de 2 arguments maximum par fonction, pour les expressions plus complexes comme: e: e + (0.5 * b1/mass * ((b1/vx ** 2) + (b1/vy ** 2) + (b1/vz ** 2))) (tiré du benchmark n-body) | |
| shadwolf | 25-Jan-2011/1:44:15+1:00 |
| faut que je parte pour que les discution ici devienne intéressante... pff ... Rebcode en effet est a ajouter a la looooooooooogue liste des choses ennorme lancé en l'air par Carl et qui n'ont jamais été plus loin. Ce qui me fâche avec R3 c'est ca... Depuis que R3 est lancé tout les trucs en béta que carl avaient sortie sont en suspend... DocKimbel moi j'aime bien R-sharp c'est de loin des clones celui qui me plait le plus. Si R-Sharp reprend ce sera pour aller ou avec? Arriveras tu à en vivre? Une subvention de premettra de tennir quelques mois mais après? Ne serait ce pas préférable d'avoir un travail sur le longterme ou d'imaginer autre chose que rebol en reprenant tout les points fort de rebol et en essayant de gommer les points faibles. Un des points faibles a mon sens c'est le typage des données est il possible d'avoir des type identique au C et des type libre comme rebol. un avantage de rebol c'est son aspect compact et sa syntaxe épurée. C'est a tel point bien fait que souvant tu fait en une ligne rebol ce que d'autre language prendrait 10 ou 15 lignes. Idée folle mais peut on imaginér qu'un dialecte rebol momentanément soit compilé et exécuté au plus près de la machine? Une fois fini il retournerait en mode rebol normmal et les données dont il aurait besoin lui serait préchargées dans un espace d'exécution propre et qu'en suite cet espace soit récupéré par rebol... Evidement le porblème posé par ce genre de chose c'est qu'en devenant processeur dépendant on doit avoir autant de traducteur/assembleurs que de processeurs. Cependant on peut constaté une convergence vers la plateform X86 de nos jours et sur mobil une convergence vers la plateform ARM. Enfin peut être que penser la programmation en terme de langage c'est devenu obsolète. Illumination Software Creator me semble une bonne piste de recherche mais on pourait peut être pousser cette réflexion plus loin. Après moi je ne sais pas je vois rebol mourir a petit feu. Et tout ce qui etait original disparait. | |
| DocKimbel | 25-Jan-2011/9:27:59+1:00 |
| @shadwolf: sans vouloir trop en dévoiler, mon projet couvre la plupart des points que tu cites. "en reprenant tout les points fort de rebol et en essayant de gommer les points faibles" => c'est exactement ma ligne directrice, d'où mon désintérêt pour un clone pur ! Enfin peut être que penser la programmation en terme de langage c'est devenu obsolète. Ca c'est un sujet qui me passionne, j'ai essayé (à mon petit niveau) de faire des recherches sur un modèle de programmation visuelle (que j'aurai pu prototyper avec View ), mais je n'ai jamais abouti à un résultat qui soit plus expressif et plus clair que des lignes de codes sous forme de texte. La quantité d'information que l'on peut exprimer sous forme de lignes de code est assez énorme, l'équivalent sous forme de représentation graphique est souvent trop lourd, comparativement. Notamment pour la compréhension rapide d'un algorithme, je ne vois pas comment faire mieux que la lecture de lignes de code. Ma position actuelle est que la représentation textuelle des algorithmes reste la meilleure option, mais on peut "l'assister" (plutôt à un niveau macroscopique, ç.a.d., en vue d'avion) par des représentations visuelles (en utilisant des découpages non-linéaires, des flèches de relations, etc...). Des initiatives comme l'IDE Java "CodeBubbles" me paraissent très intéressantes. L'approche "Subtext" (http://www.subtextual.org/) est également intéressante, mais montre rapidement, à mon avis, les limites de la représentation visuelle au niveau d'une instruction ou même d'une ligne de code.Une voie qui me semble pour l'instant peu explorée est l'utilisation de l'IA pour comprendre un besoin fonctionnel simple exprimé par un développeur et pouvoir générer automatiquement une ou plusieurs solutions sous forme d'algorithmes, puis de lignes de code générés automatiquement. C'est un axe de recherche que je compte suivre à mes heures perdues (c.a.d. pas en 2011 ). | |
| Jedi | 25-Jan-2011/11:07:07+1:00 |
| 'Une voie qui me semble pour l'instant peu explorée est l'utilisation de l'IA pour comprendre un besoin fonctionnel simple exprimé par un développeur et pouvoir générer automatiquement une ou plusieurs solutions sous forme d'algorithmes, puis de lignes de code générés automatiquement.' Mince, c'est ce dont je rêve ! (ah, on me fait signe que ce n'est pas le topi 'Langage de mes rêves' ici )a+ Sébastien 'Jedi' Jeudy. -- http://www.neosysta.com & http://twitter.com/neosysta | |
| shadwolf | 25-Jan-2011/19:11:25+1:00 |
| DockImbel si tu lances un tel projet il se pourai que je revienne pour y participer. Quand j'entend clone pur je me dit tiens on va encore avoir une version limité de rebol/core qui n'est pas capable de comprendre now/time/precise . Il y a des éléments que j'aime bien dans Freebell (le fait que ca tourne dans un navigateur, le fait que le gars ai fait son propre VID basé sur.En fait pour ce qui est des ide graphique on a eu un essai qui etait RADIS (et qui aurait pu etre amélioré) on a eu aussi le projet ladybird de coccinelle et rebkodeur. Moi je cherchait un moyen efficace de faire de la mise en valeur de code ecrit. Mais a terme je voyait l'idée REBOL comme une interface graphique d'aide au développement ultra rapide d'application avec des outils visuels ultra bien fait en VID et permettant soit de faire fabriquer en quelques click un interface graphique complexe et de cabler les différentes partie. VID ayant les limitation qu'on lui connait tous j'avais alors milité fortement et soutenu un projet communautaire de librairie graphique ce qui normalement était sensé etre intégré dans rebol a la place de vid et permettre puisque tout le monde y apportait d'etre la plus riche possible et péraine quelque soit la version de rebol derriere. RebGUI est né puis a été abandonnée. rebGUI qui etait vraiment simple au début est parti dans un trip de complexité pour au final finir par etre trop complexe pour s'en servir serieusement. Que faut il a mon sens représenter dans une version graphique de la programmation. Les unité logique fonctions, et variables ou strutures globale et les relations que ses unité logiques ont entre elles Chacque unité logique pouvant etre éditée a tout moment pour en changer le contenu avec du code. Ca c'est l'approche conventionnelle... Mais en fait on continu a pensé de facon traditionelle l'organisation du code et on essaie d'adapter a un model qui est trop résumé un model qui est très flexible. Au final on perd tellement de flexibilité que ce genre d'IDE graphique convient a des utilisation très très précises (essentiellement pour faire les jeux videos d'ailleurs (cf SCOL engine de cryo, The Foundry intégré dans Star Trek Online de Cryptic, Unreal Editor...) Ce sont donc des boite noires toute faites prête a l'emploi ou on ne connait juste que les entrées (arguments de la fonction ou en concept orineté objet appeller les membres et le constructeur de la classe) et on ne conconait que les sorties les sorties pouvait soit etre envoyer dans une variable globale soit directement rédirigé vers une autre boite. Soit on parle en terme d'action qu'on on arrive dans la boite on appelle cette fonction , quand on click sur ce bouton dans la boite on déclenche telle fonction et quand on sort de la boite on se ouvre telle autre boite. C'est ce model basé sur les "actions" qui soutend Illumition Software Creator. Le processus de création est simple car il est penser pour faire des application minimaliste essentiellement graphique et essentiellement destinée a etre généré pour des plateforme mobile. Mais on perd la flexibilité on pour toujours rajouter de nouvelles unité logique (appellons les des boites) mais ces boites sont assujéties au meme impératifs que les autres. Vous l'aurez compris c'est un sujet qui me passionne vraiment. Mais comment arrivé a avoir a la fois la simplicité de l'organisation graphique unité logiques / relation (le model UML, ou SGDBR MERISE en sont des extenstions tout comme les model orienté objet finalement) tout en concervant l'exterme flexibilité de la ligne de code et je dirait meme plus de la ligne de code rebol.... Est ce pertinant de représenté un 1 liner rebol qui fait une disaine d'action concaténée sur une ligne par 10 boites à l'écran chacune relié l'une a l'autre ? Ce genre d'exemple est assez exterme j'en conient mais parfait pour se dire que oui la réprésentation graphique peu aboutir a un malström pas possible qui sur ajoute de la complexité la ou son but premier etait de rendre les choses simple et évidentes. De meme un ennorme logiciel avec des centaine de boites ne permet plus du tout de suivre l'enchainement logic des action. Evidement on peut en revenir au Concept Object des Poupée gigogne ou on fait plein de boite qu'on encastre les unes dans les autres pour au final finir avec un méga boite qui va se déroulée par niveau d'intégration/relation. Mais là aussi suivre les gros projet est plus que compliqué. Et surtout on a une vue limité de ce qui est mit dans les boites... Ceci montre bien nécéssité de penser la représentation graphique de la construction des application en des terme différents de ce qui a été fait jusque là. Pour à la fois rester flexible mais aussi rester instantanément lisible et compréhensible. Ce qui sont finalement 2 buts diamétralement opposés. | |
| shadwolf | 25-Jan-2011/19:47:55+1:00 |
| Voir openspace3d pour voir ce qu'est devenu SCOL/SCS. | |
| shadwolf | 25-Jan-2011/20:06:22+1:00 |
| http://www.scolring.org/ site officiel et présentation SCOL/SCS: http://www.framasoft.net/article1626.html | |
| shadwolf | 25-Jan-2011/20:07:01+1:00 |
| C'est francais c'est gratuit ca marche très bien autant de raison pour que tout le monde l'ignore non ? | |
| trigram | 26-Jan-2011/8:56:37+1:00 |
| En 2000, avec l'avenement de Java et d'UML, j'ai cru que l'on modéliserait et que le code découlerait des différents diagrammes... Mais j'attends toujours l'outil magique... | |
| Philippe | 27-Jan-2011/0:55:58+1:00 |
| @Trigram Le vrai problème n'est pas de modéliser : je sais faire des dizaines de diagrammes de séquences via un script Rebol de moins de 30 lignes, et un call sur le Web. Le vrai problème, c'est d'arriver à définir des exigences dans un cahier des charges, exigences fonctionnelles ou non, qui soient clairement comprises, modèlisables, et MESURABLES. J'utilise professionnellement des outils comme Enterprise Architect qui permet de gérer les exigences, les vues fonctionnelles, organiques, les usecases, de coupler cela à du Quality Center pour gérer les tests, etc.. Mais le problème (à part le temps de le faire), ce n'est pas de remplir, c'est d'avoir des exigences suffisamment carrées pour développer ...et tester derrière. D'où l'intérêt d'une sorte d'IA qui assisterait la MOA et le développeur pour définir tout çà. C'est un vrai métier. Voir pour rire : http://fr.wikipedia.org/wiki/Antipattern ===Philippe | |
|
Login required to Post. | |