Rebol est un langage fantastique et innovant. Sa syntaxe concise, ses fonctionnalités réseau, son concept “tout-en-un” et sa compacité en font un langage unique.

Pourtant, au fil des années, le fossé s’est creusé entre les attentes des utilisateurs et la voie suivie par RebolTech.

A l’âge où un langage atteint sa maturité, il nous semble opportun de nous poser pour réfléchir à l’avenir de Rebol du point de vue de ses utilisateurs.

Notre démarche vise à faire le point sur l’existant et de proposer un plan d’évolution en rapport avec les attentes des utilisateurs, tout en gardant à l’esprit l’intérêt de RebolTech.

Rebol contient d’indéniables qualités :

• une syntaxe plus proche du langage naturel (anglais) que du langage machine (cf C, java, …)
• des structures de données performantes (manipulation de blocks, d’ensemble, …)
• une gestion du réseau qui simplifie la programmation de client/serveur
• un parseur évolué permettant le développement de mini-langages spécialisés
• une couche graphique minimum intégrant les primitives essentielles
• un mini-langage d’interface graphique très évolutif

Le tout dans un seule exécutable de moins de 600 Ko, disponible sur un nombre impressionant de plateformes !

Une fois la philosophie de Rebol intégrée, le programmeur peut développer rapidement des applications utiles qui tournent autour des points forts de Rebol : réseau, parsing ou graphique multi-plateforme.

Des tonnes de scripts sont disponibles dans tous les domaines pour montrer la productivité intense des programmeurs Rebol.

Et c’est vrai, qu’avec Rebol, il n’ a jamais été aussi rapide de passer de l’idée à l’application.

Rendons à Caesar, ce qui lui revient de droit : et donc, à Carl tous les bénéfices de l’existence de Rebol. C’est de son imagination fertile, de sa vision de l’informatique et de sa grande expérience technique, que ce puissant langage a vu le jour. Et au fil des années, Carl a amélioré son “bébé”, en ajoutant de nouvelles fonctionnalités ou en cherchant les moyens de le populariser.

Il a du jouer un exercice périlleux, partagé entre son amour du travail technique bien fait, répondant à des problématiques concrètes avec des solutions élégantes, et l’implacable réalité économique qui veut qu’un produit sans débouchés commerciaux condamne son auteur à rechercher d’autres sources de revenus ou à arréter.

Carl est toujours là, bataillant encore pour faire jaillir son langage des brumes dans lequel il stagne depuis quelques années, et cette lutte nous impose le respect.

Dans cette lutte pour faire connaitre Rebol, des programmeurs, afficionados, utilisateurs de Rebol se sont associés tout autour du monde, essayant d’apporter une pierre à cet édifice. La communauté Rebol en France ainsi que dans beaucoup d’autre pays, s’est organisée en groupe de discussion, forums d’entraide ou site de propagande.

Comme toute communauté de langage, celle de Rebol aspire à grossir : non pas pour le plaisir, mais parce-que du nombre naissent les projets, les émulsions et, par juste retour des choses, enrichissent le langage.

Mais le constat est là : la communauté est l’une, sinon *la*, plus petite communauté autour d’un langage. Difficile de se cacher la vérité quand on compare le nombre de résultat d’une recherche sur Google pour Rebol (460.000) et Ruby (27.000.000). Ces chiffres ne sont certes pas fiables à 100%, mais révèlent l’écart d’échelle considérable !

La communauté Rebol n’a pas atteint sa taille critique lui permettant d’influencer l’évolution du langage, et pour cause, Rebol étant un produit propriétaire, seul RebolTech (et donc Carl) a le pouvoir de changer les choses.

Cette communauté est très active, malgré sa très petite taille, comme le DevCon de septembre dernier a pu le montrer : quelle surprise de voir tout ce que le monde Rebol peut faire avec cette petite machine Virtuelle!

Face à la lenteur croissante en apparence du développement de Rebol, durant ces derniers mois, le sujet revient souvent : quels points sont attendus principalement par la communauté ? Les réponses à ces discussions et sondages sont nombreuses et variées. Mais un seul point reste dans toute les têtes, en première place :

• Une harmonisation des versions actuelles, et la sortie d’une version officielle non béta pour au minimum les plates-formes principales.

Ce point est vraiment important. Il permet à RT, aux reboleurs, et au reste du monde de ne plus mettre en avant une vieille version non compatible avec les scripts les plus actuels, les versions bétas n’étant utilisables qu’à nos risques et périls.

Ces fonctionnalités sont certes attendues avec impatience, mais ne sont pas au top de la liste des priorités des utilisateurs.

L’ordre indiqué permet de débloquer la situation afin de donner plus de liberté aux programmeurs Rebol.

• View et Command stable sur les plateformes MacOS X, Linux et Windows
• un meilleur support des DLL C conventionnelle suivant le systeme (*dialectes simples?) + mécanique de call back
• Support dll dans les VM gratuites (ce que tout autre langage propose de base)

Concernant View :

• La possibilité d’intégrer dans les layout des widgets externes (genre zone d’affichage direct draw, opengl …)
• Plugin IE: Il ne reprend pas les exceptions du proxy, donc son utilisation en intranet est impossible !
• OpenGL et OpenAL dans View (pas forcément le plus important mais pouvant ouvrir des marchés à Rebol)
• Des widgets VID standard qui font pas jardin d’enfant. Et qui correspondent aux habitudes des utilisateurs de l’informatique moderne.
• La possibilité de déplacer dynamiquement les widget d’un layout (example j’agrandis la fenetre les éléments qui sont dedans se redimensionnent)
• Drag&Drop géré comme il se doit sur Lin, Win & OSX
• Layout plus adaptés aux options des OS (fenetres transparentes, topmost, etc..)
• Séparateur qui permet quand on le déplace de redimensionner les widgets qu’il sépare

Concernant Core (et donc View) :

• permettre de définir des formats pour la transformation en string de décimal,devise,nombre etc
• système de threads OS dependant (ceci dit une bonne implémentation en REBOL peut être tout aussi efficace Francois Jouen (ldci) l’a parfaitement démontré reste a simplifié sont systeme je pense pour que cela soit plus proche encore de la phylosophie de REBOL)

Concernant SDK :

• Avec le SDK, pouvoir créer des exécutables pour toutes les platformes supportées: développer sur un platforme, déployer sur toute les autres (comme Runtime Revolution le fait très bien)

Concernant IOS :

• Rebol/Serve (IOS) devient un service sous NT/2000 afin d’éviter l’ouverture d’une session pour son lancement

Divers :

• un générateur de document PDF intégré à Command (en natif avec support de la compression)
• un système d’impression multiplateforme (parce que parfois, on a besoin de faire des applications qui impriment)

• Mise à jour de command pour gérer le nouveau cryptage des mots de passe dans MySQL 4.x et 5.x

• Support de DB2, PostgreSQL dans command (pour info, PostgreSQL est géré par l’excellent travail de Dockimbel)
• Ajout d’un protocole LDAP dans command (pour info, il existe un proto chez softinnov.com)
• un command sous la forme d’un module Apache (pour info, il vaut mieux, question de performance, utilser fastcgi)
• un parseur XML amélioré
• Support de WSDL,SOAP et UDDI (parce qu’ils sont les standards permettant de communiquer avec J2EE et .NET)

Sans imposer un mode opératoire, il serait souhaitable d’adopter un plan de développement qui permettrait à la fois de produire des releases stables régulièrement (tous les 6 mois semble un objectif atteignable) et la correction des bugs les plus génants le plus tôt possible. Après avoir trier, supprimer, ajouter et prioriser toutes les demandes de nouvelles fonctionnalités, il serait adéquat de maintenir une roadmap de développement :

• chaque fonctionnalité à venir est listée dans le numéro de version
• chaque numéro de version se voit attribuée une date de release
• chaque pré-release fait l’objet d’une période de test/rapport de bug/correction SANS AUCUNE NOUVELLE FONCTIONNALITE !
• une fois cette période passée, la version est releasé avec l’ensemble des outils attachés (sdk, docs, …)

Ce process vise plusieurs objectifs :

• sortir régulièrement des nouvelles releases montrent l’activité d’un projet et crée une dynamique positive
• “freezer” les versions évitent l’écueil rencontré dans le développement de view 1.3 et est une pratique largement utilisé dans les autres projets
• imposer une période de test permet de sortir une version la plus stable possible

Suggestion concernant la priorisation des nouvelles fonctionnalites :

Un outil en ligne, chez Rebol, permet d’entrer une nouvelle demande de fonctionnalité. Celle-ci peut-être précisée après un cycle de question-réponse avec RebolTech. Une fois la demande finalisée, elle est soumise à un vote sur une période pré-déterminée. Le résultat de ce vote détermine l’évolution de la roadmap.

• Comme le blog, qui a eu l’effet de redonner un peu de vie aux sites de RT, en montrant que non RT n’était pas mort, et que des personnes travaillaient réellement derrière, ces évolutions donneraient un message clair au reste du monde : “rebol est toujours vivant, il sort une nouvelle version stable pour x plates-formes!”