 |
| Et encore un nouveau qui rejoint la rebolution! | |
| rocky1 | 29-May-2010/20:38:29+2:00 |
| Encore un nouvel utilisateur de REBOL? Peut être... En fait ça fait déjà longtemps que j'avais essayé ce langage, à ce moment là je n'avais pas été vraiment emballé, ayant même qualifié ce langage d'exotique. Pourtant, j'ai réessayé récemment et au final, j'y ai trouvé pas mal de bonnes idées qui font de REBOL un langage de programmation vraiment intéressant. Autant de fonctionnalités dans une si petite VM est tout simplement spectaculaire quand on connait la taille des runtimes comme .NET, ou Java. Il est dommage que ce langage ne soit pas plus populaire, et surtout manque de crédibilité dans le monde professionnel. Je tâte pour l'instant, je lis les tutoriaux ça et là et me documente un peu. Ca n'est jamais du temps perdu. La première application que j'essaie de faire serait déjà une messagerie temps réel avec un serveur et de multiples clients. L'idée est de diffuser un message par exemple à tous les clients connectés, je cherche un peu de ce coté mais les exemples compréhensibles manquent un peu, et surtout, je vois que REBOL ne gère pas les threads? Donc, ça se passerait comment pour gérer un pool de connexions et savoir si une a envoyé un message pour le retransmettre par exemple? Comment se fait la programmation multi-tâches en REBOL et est-elle possible? | |
| ldci | 31-May-2010/9:20:02+2:00 |
| Re bienvenue sur Rebol Pour ton application, il est très facile de diffuser un message à tous en utilisant les possibilités de broadcasting de Rebol. De la même façon l'utilisation de la fonction awake sur chacun des ports permet de résoudre le problème du multitâches. Lors de la dernière Devcon à Paris, j'avais présenté le principe d'un Rebol Agent-oriented Middleware qui remplit toutes ces fonctions. Code disponible sur demande. A + | |
| GreG | 31-May-2010/10:01:35+2:00 |
| Tu connais peut etre AltME qui est fait en Rebol et qui ressemble a ce que tu veux faire? | |
| deglingo | 31-May-2010/20:12:49+2:00 |
| Par-contre, le fait de ne pas avoir de multi-tâche doit être sans doute plus problématique dans des cas de très forte charge : un serveur applicatif en Rebol devant accepter un nbre très élevé d'utilisateurs concurrents, chaque requête d'un utilisateur faisant des accès base de données, accès à différentes ressources réseau, etc... Ou alors, il faudrait déployer une débauche d'architecture : load-balancing + nbreux serveurs physiques, etc... Pas sûr que l'on pourrait faire le site web de la future Coupe du Monde de Foot ou des Jeux Olympiques en Full Rebol sans une architecture beaucoup plus complexe qu'avec une solution JAVA/J2EE ! A voir... | |
| deglingo | 31-May-2010/20:57:32+2:00 |
| Le site QTask de gestion de projets collaborative (http://www.qtask.com/ ) dont le coeur est développé 100% en Rebol est l'un des quelques exemples de réalisation à grande échelle dans ce langage : http://www.qtask.com/public/support/faq.php#rebol + Architecture : http://www.qtask.com/public/support/architecture.php Cela serait intéressant pour la communauté Rebol d'avoir un retour de leur part sur leur gestion de la programmation concurrente, de leur façon de répartir la charge sur la partie Rebol, du nbre d'utilisateurs concurrents auxquels ils font face, etc... | |
| GreG | 31-May-2010/22:39+2:00 |
| Je pense que Dockimbel est surement pret egalement a partager son experience en la matiere, pour rappel c'est l'auteur du serveur web Cheyenne. | |
| rocky1 | 4-Jun-2010/22:05:23+2:00 |
| Merci pour les liens. J'ai regardé déjà un peu Cheyenne, c'est tout de même vrai que le Rebol casse tout à fait les habitudes classiques de programmation, et ceci rend le code source assez ardu à lire pour quelqu'un qui a un passé de programmation plus classique (je suis plutôt touche à tout, mais mon langage professionnel et quotidien c'est VB/.NET etc). Pour la question de montée en charge, étant donné qu'il y a très peu de programmes pro en REBOL, difficile de comparer. Altme serait visiblement une solution P2P, mais là c'est encore différent | |
| shadwolf | 28-Jun-2010/3:16:09+2:00 |
| Bienvenue rocky1 En fait on en a parler longtemps avec Carl Sassenrath et c'etati avant la mode des processeurs multicoeur. Nous avions réclamé a l'epoque un support du multi threading ce quoi carl a répondu par -> en language interpreter le threading n'est pas une stratégie efficace, je lui prefere le traitement asynchrone. Des taches asynchrones traités tres tres rapidement par l'interpreteur donne l'illusion d'un traitement multi-thread tout en simplifiant énnormément l'écriture de l'algorithme de traitement asynchrone. Illustration ultime de cette phylosophie le serveur web Cheyenne. Qui est un vrai serveur web pleinement foncitonnel sans thread et dont le code fait moins de 5000 lignes. Ceci etant dit sur rebol.org tu trouveras un script simulant tres habilement un gestionnaire de multi-thread fait pas ldci. Apres sur le fait que rebol ne soit pas plus connu et pas plus pris au serrieu. Ca c'est une question a laquelle la communauté rebol ou le peu qu'il en reste essaie de répondre depuis maintenant 10 ans. Ceci dit je peux donner mon avis personnel sur le sujet. Rebol est trop différent trop novateur comme il tend a redefinir l'industrie les gens ce disent c'est quoi ce truc qui essaie de changer mes habitudes? En suite il y a que dans le monde professionnel les langage interprétés ont mauvaise réputation. Ils sont lent, avec plein de parentheses ou de contraintes idiotes, ont des structure de données anarchiques etc... Résultat le langage interpreté ayant eu le plus gros succes c'est a ce jour PHP ... Qui reprend les principe syntaxique et gramaticaux du C++ tout en le simplifiant car on est pas obligé d'avoir un objet pour faire du PHP alors qu'en java ou C++ sans un objet minimum pas de logiciel. Et comme chacun le sait PHP on lui a attribué un domaine bien précis et il est impensable de le voir evoluer en dehors de ce cadre. Ces professionnelles oublient cependant de mentionner les interret principaux des des langages interpreter. Distribution de petite taille, enseignement et apprentissage aisé du a l'accès directe au code source, le programme est le code source donc si on voit quelque chose qui nous plait on peut aisément l'integrer a nos propres logiciels. Cet aspect est dans le monde professionnel un point négatif ses secrets de fabrication il faut absoluement se les garder pour soit c'est ce qu'on appel le secret industriel. Les langage interpretés sont aisément portables. Et les logiciels ecrit a l'aide de ses langage interprétés sont exécutable ou que ce trouve la console. Maitenant on peut se poser une question simple pourquoi REBOL n'existe pas sur ipad ou iphone et android. A mon avis c'est dans les environement mobiles que rebol tirerait tout son sens. Quand on voit le SDK de l'ipad on est mort de rire ... c'est idiotement complexe pour rien... | |
|
Login required to Post. | |