Le langage de mes rêves | |
paullys | 13-Jan-2011/9:20:35+1:00 |
paullys | 13-Jan-2011/9:33:34+1:00 |
Si je devais inventer un langage, il serait a même d'exécuter les scriptes que j'ai fais jusqu'à ce jour: -Rétro-compatibilité R2. Il permettrait de développer y compris des solutions critiques en terme de vitesse ou de temps réel, par un dialect qui ouvre l'accès au plus bas niveau. Il serait multi-threadé. Il aurait un mécanisme d'incorporation de code étranger. Il serait accessible aux débutants car congruent. Il aurait un jeu d'instructions puissant et réduit puisque les autres besoins sont remplis par le dialect bas niveau. Son Gui serait à l'indentique composé d'un jeu d'instructions puissant et réduit complété par un dialect bas niveau. Son gui serait 3D extensible. Il serait portable, stable, modulable et modulaire. Enfin il serait élégant. Et vous de quel langage révez vous? | |
shadwolf | 13-Jan-2011/12:20:23+1:00 |
d'un langage qui face bien quand on discute autour de la machine a café! ahahahaha pardon c'est plus fort que moi! Plus basiquement rebol me plait, c'est juste qu'il est géré n'importe comment... bien malin est celui qui aujourd'hui peut dresser une liste complète des changements de R3 vers R2. | |
sebastien | 13-Jan-2011/14:11+1:00 |
D’abord un premier mot pour dire que je suis heureux des différents postes publié depuis ce début d’année car cela montre combien la popularité de rebol est tjrs présente Mon langage de rêve c’est R2, mais remis à jours Effectivement R2 contient déjà de quoi répondre à de nombreux besoin, malheureusement il faudrait qu’il soit remis à jours et que la documentation et les exemples soit plus clair. Le VID devrait être amélioré Pouvoir s’adapter à) de nouveau besoin et une plus grande ouverture au bibliothèque externe ou ouverture a d’autre code Il lui faudrai aussi un outil d’aide au developpement (IDE) | |
Bertrand | 13-Jan-2011/16:07:41+1:00 |
J'ai juste l'impression que R2(D2, non je plaisante ...) a été laissé en "stand-by" à cause de l'annonce, qui date un peu, d'un R3 "rébolutionnaire" et qui tarde aussi, et que l'on craint en même temps, à cause des changements drastiques qu'il pourrait y avoir, notamment en matière d'IGU ("GUI" pour les franglophones) ... Tout comme Sébastien, Rebol 2 me convient parfaitement, pour ce que j'en fais et sans doute le peu que j'en exploite réellement ('suis pas un pro de la prog), mais avec sans doute quelques mises-à-jour majeures. Après avoir (encore) abandonné un temps Rebol, ne voyant pas avancer le schmilblick, j'ai décidé de renoncer complètement à Rebol 3, pour me (re)mettre à utiliser un peu plus à fond Rebol 2, comme s'il n'existait rien d'autre de mieux pour le moment. A trop attendre le langage "idéal" on ne fait plus rien avec ce qu'on a, et qui fonctionne bien malgré tout. Plus de docs et de tutos sur View et sur VID, et d'expériences partagées, seraient en effet bien utiles pour redonner un peu de vigueur à Rebol, un des meilleurs langages de script, voire de programmation (puisqu'il existe encore une nuance). Je dis ça pour en avoir essayé et testé, à mon niveau et en fonction de mes besoins, d'autres qui ne l'égalent pas ... à part peut-être NewLISP (sauf si on déteste les parenthèses) et FBSL (un Basic pas comme les autres, mais malheureusement pas multiplateforme). En fait je suis d'accord aussi avec Shadwolf quand il dit que Rebol est géré n'importe comment, et c'est bien dommage, à moins que l'on veuille qu'il reste un langage marginal ou intimiste. | |
jocko | 13-Jan-2011/17:05:27+1:00 |
Je fais beaucoup de choses avec R2, que je trouve assez abouti. Je l'utilise en scripts pour le travail quotidien, et en compilé (rebol-sdk) pour les applis qui ne doivent plus bouger. Je n'attends pas de Rebol ce pour quoi il n'est pas fait, et j'utilise Matlab pour le calcul, la simulation et la visualisation scientifique, et C++ pour le traitement d'image et la vidéo. Python est une alternative intéressante à Rebol en termes de productivité et de versatilité, mais on est rapidement noyé sous la variété des packages. Le côté graphique n'est pas parfait non plus. Je n'estime pas essentiel d'avoir un IDE pour un langage interprété. J'utilise Crimson Editor comme éditeur, qui fait de la coloration syntaxique, qui permet de définir des outils (ex: lancement du script, nettoyage et mise en forme avec astyle ...) L'essentiel pour moi est une documentation complète et à jour, ce qui est presque le cas pour R2, sauf pour la partie graphique. | |
trigram | 13-Jan-2011/18:44:38+1:00 |
Pour ma part, je crois beaucoup à l'idée du projet R2 Ultimate / Entreprise et au WAMP like (il faudra d'ailleurs trouver un nom). Pour le WAMP like, si on arrive à faire un micro système Web embedded, c'est un truc qui en milieu Pro peut marcher car on est toujours confronté à des problématiques de réaliser une petite appli Web très rapidement sans à avoir à déployer un nouveau serveur parce que forcément les mecs de l'infra vont poser plein de question et à Pâques on y est encore Ce que j'apprécie dans REBOL est que de n'importe où, je peux installer la solution et faire tourner n'importe quel programme REBOL... et donc résoudre parfois très rapidement des problématiques... Certes il n'est pas parfait, mais il rend des services. Et par ailleurs, je milite sur le fait qu'il faille bien parler du langage REBOL et de la VM REBOL qui permet de faire tourner des programmes écrit en REBOL. Vu de l'extérieur la nuance n'est pas forcément évidente. Nico | |
deglingo | 13-Jan-2011/22:41:51+1:00 |
Le langage de mes rêves, c'est presque Rebol ! C'est Rebol avec quelques apports (le multi-threading par exemple) qui me permettraient de l'utiliser à fond dans mon boulot, et pas seulement comme un super couteau suisse ou comme une boîte à outils de tests. C'est quand même le top de pouvoir manipuler des structures (les 'block!') contenant à la fois du code et des données, cela permet une sacrée souplesse, d'utiliser la fonction PARSE, etc... En fait, dans mon boulot, je développe des grosses applications serveurs JAVA/J2EE fonctionnant en cluster, qui font des appels bases de données complexes, avec beaucoup de traitements métier, de nombreuses mises à jour concurrentes, des appels à des systèmes de messages (type JMS), qui acceptent un nombre simultanée de requêtes très important. J'essaie d'imaginer un Rebol "multi-threadé" qui permettrait de faire cela, avec des serveurs type "UniServe / Cheyenne" de DocKimbel en cluster...avec des centaines de clients web ou R3GUI qui attaqueraient ces serveurs en parallèle....avec l'architecture qui va bien derrière pour être "scalable", comme y disent les ricains ! La partie GUI pemettrait de faire des applications au look "pro", et aurait une batterie de composants graphiques de haut niveau. Le pied quoi ! | |
paullys | 14-Jan-2011/9:22:17+1:00 |
En gros ceux qui sont venus sur ce post, veulent un rebol patché? | |
RebKodeur | 14-Jan-2011/9:28:58+1:00 |
Je partage totalement le point de vue de Jocko, à part qqs composants graphiques, R2 me convient. La non-comptabilité des scripts de r2 vers r3 est une grosse erreur à mon sens, d'autant que comme il a été dit cela fait des années que nous l'attendons.. Un rebol open-source serait parfait, car forcément un groupe l'aurait porté sur les smartphones ce qui aurait été excellent pour son essort! Je pense que l'erreur de Carl est celle-là : vouloir faire un R3 coupé du R2 (ce qui est vraiment rare dans le monde de l'évolution des langages) et de n'avoir pas terminé après tout ce temps et surtout loupé le passage au smartphone !! Mais je me plains pas ! Avec R2 je fais presque tout, compilé pour les clients avec le SDK. Ces erreurs de Carl fait que cela repousse les nouveaux et donc minise le nombre de personnes dans la communauté... | |
coccinelle | 14-Jan-2011/11:37:16+1:00 |
Je suis aussi d'accord avec vous Jocko et RebKodeur, globalement R2 me convient. Ce qui me manque le plus dans R2, c'est quelques contrôles dans VID (très classiquement scroll-panel, tab-panel, border-panel et tree-view), le plugin, le multi-langue, une base de donnée, un truc comme easy-soccer, un truc comme magic et un outil de test comme RUN (Rebol UNit). Il est clair que tout ça existe et que tout un chacun peut se créer son propre environnement mais c'est disseminé sur le net et ce serait vraiment beaucoup plus confortable autant pour les débutants que pour les autres, d'avoir tout ça en standard dans R2. | |
trigram | 14-Jan-2011/11:41:15+1:00 |
Je pense que l'erreur de Carl est celle-là : vouloir faire un R3 coupé du R2 Brian H. en a un peu conscience et travaille sur l'implémentation de fonctionnalité de R3 en R2. Du coup, à partir du moment on commence à avoir se genre de démarche, c'est que l'on se rend compte que l'on fait peut-être fausse route... Néanmoins, et je ne veux pas recréer de polémique, il y a l'idée de Carl du module Hybride Open-Source pour R3 et il n'y a pas eu beaucoup de monde qui se soit lancé dans la bataille pour proposer de extension à Rebol via le host-kit. Il n'y a ma connaissance que le projet de RMA de R3/GUI. Après, je sais qu'il manque de la doc sur le host-kit, qu'il a changé de direction... bref... pas la peine de polémiquer plus sur le sujet. Aller, juste pour vous confortez et de continuer à supporter REBOL et à croire en Carl... From twitter.com/rebolweek #Carl creator of #rebol is rank 13 of "Most influencing programmers" http://www.hyenalabs.com/?p=717 Pour les aspects Open Source de R2, c'est un appel de Nick à lancer le débat sur le sujet... @paullys En gros, pour moi oui. REBOL reste une très bonne solution, il faut juste l'améliorer et l'idée de repartir de R2 ne me choque et me va plutôt bien. | |
coccinelle | 14-Jan-2011/11:42:56+1:00 |
J'ajouterais aussi que pour moi, le support CGI est bien suffisant pour ce que je fais, personnellement, j'utilise en local ZMWS et que ça me suffit amplement. | |
shadwolf | 14-Jan-2011/14:46:44+1:00 |
@ bertrand c'est plus qu'une impression c'est tout a fait cela . R2 n'a pas eu de mise à jour en 2006,2007, 2008, 2009. Out of the blue comme disent les anglophone (de but en blanc, sans crier gare) en novembre 2009 Carl disparait puis dans ses voeux de nouvelle année il nous annonce que R3 ayant pris du retard il voulait faire un geste, et donc il a mis à jour rebol et libéralisé le restant des fonctions payantes de rebol/view. Ce qui est passé inapperçu. Si notre communauté francophone a l'époque avait été active ca aurait fait parti des gros titres. En novembre 2010 même rendement. Il faut dire que l'année 2010 a été marquée par rebol-host-kit et R3/GUI de RM-Asset. Donc pour moi le fait que R2 est été abandonné suite à l'annonce du projet R3 est un fait manifeste. Il faut dire que de toute façon du temps ou rebol 2 etait le sujet principal d'attention nous n'avions pas des mise à a jour beaucoup plus régulières qu'une ou deux fois l'an. | |
Didec | 14-Jan-2011/15:22:16+1:00 |
C'est pas exactement ça. Quand R3 à commencé, il n'était pas prévu que cela donne ce que ça donne aujourd'hui. Ce devait être une évolution de R2 avec des ajouts (genre Thread). Vous allez me dire : "Y'avait pas de liste définie à l'avance de ce qu'il devait être, donc c'est normal !" Non, c'est pas seulement ça : certains ajouts prévus et en particulier l'UTF8 ont de facto brisé la compatibilité R2/R3. Ex : il n'était plus possible d'obtenir le même résultat avec R2 et R3 en chargeant un binaire et en le passant en string!. Et surtout, plus possible de gérer l'index sur un string! et sur un binaire! à l'identique : en UTF8, les caractères ne font pas tous 1 octet ! Hors ces difficultés n'avaient pas été prévues au début. Ce constat à découlé du développement lui-même. A partir de là, il y a 2 lignés : R2 et R3. Tout comme R1 est incompatible avec R2. - R2 convient très bien à tous ceux qui n'ont pas à traiter des données "internationales". - R3 est indispensable à tous ceux pour qui ce n'est pas le cas (les chinois par exemple). Du coup, R3 se retrouve en cours de route affranchi de sa compatibilité ascendante avec R2 et donc on peut maintenant corriger les tares de ce dernier (ex: les ports, les faces view, certains résultats de conversion...), mais cela prolonge les développements. Se faisant le temps passe et les utilisateurs de R2 se rendant compte que ce dernier n'évolue pas alors que c'est encore le seul utilisable. Le grondement de la foule remonte jusqu'à Carl : "il faut maintenir R2 car R3 n'est pas prêt d'arriver !". Et donc les corrections de bugs sur R2 reprennent. Dans le même genre, je me rappelle très bien de la période de développement de Windows VISTA. Il y avait pleins d'annonces faites, particulièrement sur le changement de NTFS pour WinFS. Mais VISTA à pris beaucoup de retard dans sa sortie, repoussé maintes fois. Et finalement, pas de WinFS, ni dans VISTA, ni dans SEVEN (et en plus c'était une merde). Et pourtant M$ n'est pas RT : ils ont des moyens autrement plus conséquents. Comme quoi le développement logiciel "On sait où ça commence, on sait pas où ça termine !". | |
deglingo | 14-Jan-2011/15:44:17+1:00 |
Un des problèmes majeurs de Rebol, c'est la taille de l'entreprise Rebol Technologies, le nombre de personnes qui contribuent au langage, et le support. Quelle est l'entreprise de taille moyenne/importante qui voudrait miser sur Rebol pour monter son Système d'Informations sachant que le langage est développé par 1 personne (Carl) et que le support (production) est assuré par cette même personne ? (bon, il y a plus de contributeurs avec Rebol 3 et l'apparition du Host-Kit) C'est vraiment pas rassurant pour un DSI. Carl peut décider demain d'arrêter Rebol. Est-ce que le langage continuera à vivre sans lui ? Il n'a pas intérêt à passer sous un camion ! On va lui demander de publier son bilan de santé en ligne !!! Je plaisante... Concernant la rupture Rebo2/Rebol3, Python a fait un peu la même chose entre Python 2 et Python 3 (http://www.python.org/ ). Il n'y a pas que Rebol. | |
trigram | 14-Jan-2011/16:51:04+1:00 |
@deglingo J'ai suggéré d'ouvrir une section Worldwide sur rebol.com dont le but serait de recenser les reseller locaux pouvant vendre des licences et offrir du support. En france, il y a Softinnov qui peut le faire. Et Jedi avec Neosysta affichait du consulting & formation autour de Rebol... En Allemagne, il y a TGD consulting avec Dirk Weynand. Après il y a en certainement d'autres... Même si il s'agit que de petite structure, c'est déjà un bon début de tisser un réseau... Effectivement, impossible de vendre REBOL à un DSI. Il faut le faire en sous-marin et si il le découvre, lui expliqué que tel ou tel truc tourne sous REBOL et que cela rend bien des services.... Ou alors, il faut une petite application vitrine... Il me semble avoir vu une explication de la technique du Doc dans un compte-rendu de Jedi suite au Meeting REBOL A la cantine de 2010. Par contre, au niveau du marché des TPE et petite PME, il y a souvent des mini-SI développé par le gamin du patron, ou un stagiaire ou l'informaticien du coin... Alors est-ce que REBOL serait pire ? Non, ce serait même mieux... Cela fait parti des points à aborder au niveau du groupe de Lobying. Pour la cassure R2/R3, effectivement on peut trouver plein d'exemple dans des langages ou des framework... Par contre, il faut offrir soit une moulinette de migration quand c'est possible, soit un guide de réécriture avec les bonnes pratiques... C'est le strict minimum au regard de l'investissement qui a été consacré à l'écriture de certaines applications. | |
paullys | 14-Jan-2011/16:53:17+1:00 |
Je veux pas faire le rabat-joie, mais le titre du topic est "langage de mes rêves" pas et pourquoi donc Carl n'a pas fait ceci ou cela. C'est un Dream Storming au départ. | |
trigram | 22-Jan-2011/1:13:29+1:00 |
Le langage de mes rêves est un langage qui me permet de résoudre une problématique rapidement car je suis fénéant comme tout informaticien... Et évidemment pas besoin d'écrire une tartine de code, de devoir instancier des dizaines de classes pour juste faire un envoi mai ou scruter un FTP. Qui intègre une couche d'IHM graphique parce que la console, c'est bien pour les geeks que sont les mecs de l'infra. Qui intègre un système de SGBD performant qui se répliquer facilement. Enfin le langage de mes rêves est ATAWAD ! | |
Jedi | 22-Jan-2011/12:16:48+1:00 |
Hello, Aujourd'hui et pour l'avenir, le langage de mes rêves serait un (seul) langage simple permettant enfin de réaliser facilement et rapidement des applications Web RIA, tout en un (interface, métier et BDD). A l'opposé des usines à gaz à la mode comme les .Net, J2EE et même LAMP... REBOL aurait pu / pourrait le faire, mais avec le temps : trop de manques ou trop en décalage par rapport à ce genre de besoins... a+ Sébastien 'Jedi' Jeudy. -- http://www.neosysta.com & http://twitter.com/neosysta | |
coccinelle | 23-Jan-2011/11:37:42+1:00 |
C'est tout à fait pareil pour moi, un langage qui me permette de faire rapidement et simplement des applications RIA. C'était vraiment l'idée derrière easy-soccer et sql-protocol conjointement avec le plugin. Et comme tu dis, Rebol pourrait le faire mais les directions prises par Carl sont sûrement trop en décalage avec cela. | |
RebKodeur | 23-Jan-2011/12:28:42+1:00 |
De mon côté je suis le point de terminer une application complète en javascript, php, ajax pour laquelle je n'aurai ensuite qu'à créer un fichier config pour chaque page que je voudrais afficher. La page config ne sera qu'une définition des champs de la base de données, les liens foreign keys et la primary key. L'applic crée ensuite la table si elle n'existe pas, et affiche la liste de tous les éléments de la table (foreign fields compris) + le formulaire qui permet de modifier/ajouter/ et supprimer les éléments d'une liste. Le reload de la page ne se faisant pas, puisqu'ajax.. C'est pas impossible que j'utilise une interface visuelle en Rebol pour créer les relations entre table et compléter les champs.. De sorte que je n'ai plus besoin de compléter le fichier config pour chaque page crée.. | |
trigram | 23-Jan-2011/16:04:43+1:00 |
Faut-il créer un topic suite à ce topic : est-ce que que REBOL par son aptitude à réaliser des dialectes, sa force dans le prototypage (cf topic Scala et l'annonce....) ? Ou posé autrement : est-ce que REBOL peut contribuer au langage de nos rêves ? | |
rosanoff | 24-Jan-2011/5:51:53+1:00 |
Bonjour, le langage de mes rêves est R2 en Open Source Software publié sous une licence double: commercial et GPLv2, un peu comme MySQL ou Klone http://www.koanlogic.com/klone/index.html . Bon dev. à tous. | |
paullys | 24-Jan-2011/14:11:01+1:00 |
Le langage de mes rêves n'est pas nécessairement open source, s'il y a VM, seul le bytecode est impérativement ouvert ...et comme toutes ses autres fonctionnalités...DOCUMENTé!!! | |
paullys | 24-Jan-2011/14:12:34+1:00 |
Pour synthétiser, le langage de nos rêves est un RAD? mais tiny and powerfull! | |
DocKimbel | 24-Jan-2011/15:00:45+1:00 |
Je crois que vous confondez un peu langage et frameworks/librairies. Le RAD est une problématique au niveau framework (ex: Rails) ou IDE (ex: Visual Basic), ce n'est pas directement lié aux caractéristiques du langage (même si la verbosité peut jouer un peu, ce n'est pas le coeur du sujet quand on souhaite faire du RAD). Je pense que la plupart de vos demandes peuvent être couvertes par un (ou plusieurs) bon(s) framework(s) RIA/RAD au-dessus de REBOL (ou autre). Ma vision personnelle du langage idéal est un langage avec une syntaxe simple et intuitive (comme REBOL) mais suffisamment générique pour être un bon choix quelque soit la tâche (scripting, glue, traitement lourd, calcul lourd, système, embarqué, GUI, 3D, jeux, serveurs, etc...) sans avoir à recourir à un autre langage pour pallier à ses manques (typiquement, le C pour pallier au manque de performance). Qu'il soit open source est maintenant une obligation (une évidence même) pour moi, c'est la seule manière de garantir sa pérennité et son évolution. L'expérience REBOL/RT devrait être suffisamment convaincante pour les sceptiques. | |
paullys | 24-Jan-2011/16:45:05+1:00 |
Merci DocKimbel pour ta participation à ce topic. Cependant les rêves des uns des autres, même s'il ne répondent pas à des stratifications théoriques sont intéressants de 2 points de vue: -comprendre ce qu'attendent les programmeurs réels (il n'y a pas que les pros et les techies). -si un langage novateur doit arriver, il remettra au moins en partie en cause les distinctions opérées jusqu'à maintenant. D'ailleurs rebol et une partie des langages scripts (interprétés) à l'origine de leur succès je pense, déplacent les frontières entre ce qui appartient au langage de programmation et ce qui appartient à la mise en oeuvre de ce langage (framework). Et je pense que les participants n'ont pas tort en ce que ce que l'on nomme langage aura tendance, je pense, à déborder de son ancien cadre pour englober d'autres composantes jugées externes. Je pense d'ailleurs que le manque de flexibilité ou plutot le coup de la flexibilité des langages avec compilations et exécution différées condamne ces derniers langages. Je pense que l'avenir est à l'interprétation et à la compilation on the fly (et surtout transparente). quelque chose comme le double régime (compilation, interprétation)permise par des langages comme forth. Mais avec un framework de facilitation (la forme dialecte est intéressante pour intégration je pense) des tâches évoluées. En ce qui concerne la pérennité, oui l'open source est la meilleure solution. Mais un lead programmeur qui sait fédérer et emporter l'adhésion d'une large part de la communauté est aussi importante. Car l'inconvénient de l'open source est la possible multiplication des initiatives et donc une dilution des énergies. | |
Jedi | 24-Jan-2011/17:16:11+1:00 |
Je pense que la plupart de vos demandes peuvent être couvertes par un (ou plusieurs) bon(s) framework(s) RIA/RAD au-dessus de REBOL (ou autre). Ouaip, mais de mon côté, je n'en ai pas encore vu :/ Mais peut-être passé à côté... Et dire que les plus grosses demandes IT actuelles tournent autour des solutions JEE et .Net (beurk). a+ Sébastien 'Jedi' Jeudy. -- http://www.neosysta.com & http://twitter.com/neosysta | |
paullys | 24-Jan-2011/17:26:19+1:00 |
Le problème des couches sur des couches est que l'on finit toujours par quelque chose à la consistance douteuse et que l'on s'éloigne du tiny. L'aspect tout en un est important pour les différents participants je crois. Une bonne intégration de toutes les dimensions de la programmation dans un tout cohérent est d'après moi primordiale. C'est pour cela que je pense que le langage de programmation débordera les notions framework, IDE et on retrouvera tout ce petit monde sous le nom de langage de prog. A mon avis le nombre de fonctionnalité et la facilité de mise en oeuvre de ses fonctionnalités (jugées aujourd'hui comme externes) sera une source importante de différentiation des différents langages, plus importantes peut-être que les qualités intrasèques du langage (ce que nous appelons langage aujourd'hui) | |
DocKimbel | 24-Jan-2011/20:16:41+1:00 |
@paullys: je te rejoins sur le besoin d'enrichir les langages, mais je pense qu'une frontière est toujours utile entre ce qui est disponible par défaut (la librairie standard) et ce qui peut être chargé (librairies/framework externes) quand on en a besoin uniquement. Dans le cas de REBOL, la quantité de fonctionnalité intégrée est très grande en standard (sans doute plus que la plupart des autres langages), cela est très utile pour faire du scripting, mais quand on développe une application, on a rarement besoin de tout, le SDK est heureusement là pour permettre d'inclure uniquement ce qui est utile et ne pas surcharger le produit final. Néanmoins, ce sujet mérite effectivement réflexion, les besoins moyens des développeurs aujourd'hui ne sont pas tout à fait ceux d'il y a 10 ans. Les dialectes fournissent souvent une excellente solution pour manipuler une librairie ou utiliser un framework, je suis d'accord. C'est comme çà que je comprends ta remarque "on retrouvera tout ce petit monde sous le nom de langage de prog.". En revanche, les IDE restent toujours très demandés, beaucoup de jeunes développeurs n'envisagent pas de travailler sans IDE, regarde le succès d'Eclipse par exemple. Je ne vois pas cette tendance s'inverser dans les prochaines années, bien au contraire. Car l'inconvénient de l'open source est la possible multiplication des initiatives et donc une dilution des énergies. Cela peut-être un inconvénient comme une opportunité, ça dépend des situations et des projets. Les gestionnaires de versions récents (les DVCS) et un des services phares dans ce domaine, GitHub, mettent l'accent sur le "forking" des dépôts de code comme mode d'organisation des contributions. De plus en plus de projets open-sources (même des gros financés par des sociétés commerciales, par ex. "Titanium Developer") encouragent le forking. Je n'ai pas d'avis tranché sur cette question. https://github.com/appcelerator/titanium_mobile : "Titanium is an open source project. Please help us by contributing to documentation, reporting bugs, forking the code to add features or make bug fixes or promoting Titanium on twitter, etc." @Jedi: il y a certains outils comme le Layout-builder de Carl et l'IDE RADIS (de François et Christophe), mais je pensais effectivement à de nouveaux outils/frameworks plus spécialisés et plus orienté web (à la Rails). J'avais envisagé de fabriquer un Rails-killer il y a 2-3 ans, au-dessus de Cheyenne, mais j'ai vite renoncé en voyant que la situation de REBOL ne s'arrangerait pas. | |
coccinelle | 24-Jan-2011/20:58:53+1:00 |
Personnellement, je trouve dommage tous ces framework et toutes ces librairies qui peuvent être chargées en cas de besoins. Au contraire, c'est une des choses que j'aime particulièrement dans Rebol, c'est qu'il est plutôt plus riches que beaucoup d'autres. A mon avis, mieux vaut une plateforme encore plus riche que Rebol si elle veut se différencier des autres environnement. Concernant les IDE, cela ne m'a jamais manqué avec Rebol, par contre un VDE pour composer sont interface utilisateur, ça oui, ça manque et les bribes proposées à droite et à gauche ne m'ont jamais convaincues. Idem pour la base de donnée, un outil graphique pour pouvoir la dessiner, ça ça manque vraiment. | |
paullys | 24-Jan-2011/22:32:59+1:00 |
Pour moi il y a d'un côté les pros et les techies (les techies ont plutôt tendance à s'aligner sur les pros) et de l'autre les casuals programmer et les activités récréatives des pros. Les besoins des casuals et récréatifs me semblent prioritaires car ils sont les moins aptes (notamment en terme de temps) à combler les manques. Alors que les pros peuvent consacre plus de temps et d'énergie à créer et rechercher ce qui fait défaut puisque une rentabilité est possible avec les utilisations futures. C'est pour cela qu'il me semble devoir créer un langage aux capacités étendues ce qui correspond aux besoins des casuals et permettre aux pros de retrancher ce qui est en trop. Je me réfère encore à forth et ses capacités auto-génératives. C'est un principe que Rebol n'a pas poussé assez loin d'ailleurs. Au sujet des IDE, perso tels qu'ils existent aujourd'hui je préfère les makefiles. Un IDE ca veut faire trop choses, c'est un logiciel de plus qui ajoute sa logique sur la logique de codage/debuggage/compilation/linkage. Comme si cette logique n'était pas encore assez lourde et longue. Pour le versionning, je suis pour la réflexion sur un nouvel outil toujours avec la priorité donnée aux casuals prog, qui permettrait juste par les noms et les extensions de se retrouver dans un arbre de dev. | |
paullys | 24-Jan-2011/22:35:54+1:00 |
Correction au lieu de "un IDE ca veut faire trop de chose" je voulais dire un IDE est trop présent et ajoute de la complexité. | |
trigram | 24-Jan-2011/23:02:54+1:00 |
Je pense que RT était précurseur avec REBOL en commencant à rassembler plusieurs concepts en un... Langage, interpreteur ultra léger et multi-OS, bureau virtuel... Finalement, le Cloud et le HTML 5 avant l'heure avec une gestion quasi native du mode connecté / déconnecté... en quelque sorte C'est exactement ce qu'est en train de faire Google avec Chrome et maintenant Chrome OS. IDE Eclipse est effectivement l'IDE incontournable du moment et pour un bon moment. ;( Maintenant depuis la mort de Borland, il ne reste plus que Microsoft a avoir une approche WYSIWYG top down... Je dessine mon application et ensuite je code son comportement... Le layout-editor était une base assez aboutie. Dommage que personne n'ait fini le projet de Carl... Rails killer Bien dommage de ne pas avoir concrétisé. Je pense que Quarter Master de Chris RG peu être pas mal. Maintenant, il faut le finaliser. Couplé à une bonne librairie JS... Ca peut être pas mal. Fork Je suis contre d'une manière générale. Je pense que l'on a besoin d'un leader (qui peut-être un groupe de personnes) qui décide de la voix à suivre... Après quand on se trouve dans l'impasse comme avec RT (pas de volonté commerciale, pas de vision marketing), le fork - si l'on est en mode Open-source - peu devenir nécessaire... @Jedi Usine à gaz... Pompe à fric aussi ces machins là, une application toute bête te coûte souvent un bras et à maintenir devient vite un véritable enfer. T'as intérêt soit à avoir des très bons développeurs en interne et savoir les garder soit ne pas perdre ton prestataire qui a réaliser l'application et qui sait la maintenir à moindre frais... | |
paullys | 25-Jan-2011/11:00:18+1:00 |
Je participe ici aux sujets lancés dans le topic Rsharp, car ce topic me semble plus proche de ces sujets. Je ne crois pas à un dev visuel (d'autre chose que l'IHM) qui serait plus efficace que le dev par mot. Car les mots permettent la meilleure appropriation et adaptation à ses propres concepts. Comme une histoire racontée par un film est plus "limitante" que la même histoire racontée par un livre. | |
paullys | 25-Jan-2011/11:05:55+1:00 |
Je reprends l'idée de l'IDE: il faut quelque chose qui améliore la lisibilité du code (colorisation, indentation). Qui colle au modele de dev interactif que permet l'interprétation. Qui permettent le dev IHM en WYSIWYG. | |
Jedi | 25-Jan-2011/11:15:44+1:00 |
Au moins, le point intéressant ici-même, c'est qu'on ressent les mêmes besoins / idées / limites de ce que l'on souhaiterait avoir Autre point intéressant : c'est que dans les dernières idées / remarques échangées, c'est qu'il y a un gros manque de ce genre de choses dans l'industrie IT... Mais je reste aussi convaincu que c'est dans l'intérêt des gros de l'industrie (Microsoft, Oracle,...) de pondre des outils bien lourds et trop spécifiques : ça assure du travail à l'avenir IT. a+ Sébastien 'Jedi' Jeudy. -- http://www.neosysta.com & http://twitter.com/neosysta | |
paullys | 25-Jan-2011/12:37:17+1:00 |
Ce n'est pas tant leur intérêt que leur incapacité à faire autre chose, à explorer d'autres voies. ILs attendent donc les innovations des petites structures et les achètent.Puis ils repackagent le tout et revendent. Ce sont des grossistes... aucune valeur ajoutée. | |
ldci | 25-Jan-2011/12:53+1:00 |
Pour l'IDE, quelque chose d'intéressant http://developer.palm.com Cherchez Tools/Ares Pour le Fun, j'ai réalisé en JS avec EditArea (http://www.cdolivet.com/) une colorisation syntaxique et autres gadgets Ca pourrait servir de base pour un IDE fonctionnant dans un navigateur WEB | |
trigram | 26-Jan-2011/0:18:23+1:00 |
@ldci Il y a aussi le App Inventor pour Droid. @Jedi Effectivement, c'est rassurant et encourageant pour la suite car on sait où on veut aller. On connaît notre point de départ qui est REBOL et sait à peu prêt par où on va passer (Légéreté, Rapidité, Evolutivité, Mobilité, etc) et ce que l'on veut atteindre le Nirvana | |
jocko | 26-Jan-2011/7:01:11+1:00 |
@ldci Comme je l'ai déjà dit, je ne trouve pas vraiment indispensable de consacrer beaucoup d'énergie à développer un IDE sophistiqué. Smallr, que tu as développé, me semble un bon point de départ, et quelque chose de presque suffisant (http://www.rebol.org/view-script.r?script=smallr.r) . Pourquoi pas une petite coloration syntaxique dessus ? J'apprécie en perticulier la construction automatique du "header" lors de la création d'un nouveau script de type console. Pour ma part, j'y ajouterais un "wizard" pour la construction de squelettes d'applications graphiques, par exemple comme le script-wizard que j'avais fait (http://www.colineau.fr/rebol/index.html#section-4), ainsi qu'une routine d'indentation automatique comme clean-script (http://www.rebol.org/view-script.r?script=clean-script.r) | |
ldci | 26-Jan-2011/9:12:47+1:00 |
@jocko: Bonnes suggestions. Pour la colorisation j'attendais que le code de Shad soit complètement finalisé (ex: ne fonctionne pas sous mac osx). Le wizard, c'est une bonne idée. On peut ainsi installer une gestion minimale des faces de rebol. Si tu as un peu de temps on pourrait s'y mettre pour intégrer ces éléments dans SmallR dont j'avais espéré qu'il serait repris par d'autres. @tous: Avis aux amateurs qui voudraient participer ... | |
shadwolf | 9-Feb-2011/5:23:12+1:00 |
@ldci pour ce qui est de area-tc rebol2/view sur linux et macosx a mon avis ca n'arrivera jamais. Le probleme ne vient pas de mon code il vient surtout du fait que les font-fixed qui nous servent a placé les lettres au bon endroit ne sont pas suporter sur linux et macosx... du fait que rebol ai été sommairement porté de windows a linux puis a macosx sur cette partie ca nous fiche en l'air la composition du texte. Et donc l'édition puisque l'un depend de l'autre. Il faudrait que Cyphre face evoluer le systeme de rendu de texte dans AGG et que se soit dispo partout dans R2/View mais apparement c'est pas dans ses plans. C'est R3 qui a la priorité et la préférence et ils preferent tous se concentrer dessus plutot que d'essayer d'améliorer R2 ... Ceci dit je me suis retirer de la communauté Rebol. Car je n'aime pas du tout la façon de procéder. | |
ldci | 9-Feb-2011/9:28:47+1:00 |
@Shad Ca fait plaisir de voir que même retiré de la communauté, tu suis les posts. Pour Mac et Linux, je suis d'accord, mais la réponse qu'on nous donne c'est attendez R3 qui va régler ces pbs de fonts. | |
paullys | 10-Feb-2011/9:12:37+1:00 |
L'analyse de shad me semble exacte. Dès lors pour continuer a dev sous R2, il faut considérer qu'il n'y aura pas d'amélioration (en tous cas dans les domaines qui nous intéressent) et partir des bases communes aux principales versions de R2. Effectivement il y a de fortes limitations dans la version osx de r2, dont la gestion des fonts. Pour moi une solution serait de repartir de la base: draw et redessinner à la main les caractères. | |
PierreCh | 20-Feb-2013/18:29:06+1:00 |
J'ajoute mon petit grain de sel: le langage de mes rêves, c'est Rebol2, avec VID bien sûr, ET des menus déroulants dignes de ce nom, en natif, ET des raccourcis clavier (automatiques, allez, tant qu'à rêver) pour tous les widgets qui ont un titre. Peut-être aussi quelques incongruités seraient-elles à considérer. Genre, par exemple, tolérer qu'on puisse écrire 2+2 pour obtenir 4. Des trucs comme ça qui agacent parfois (un peu). | |
DideC | 21-Feb-2013/10:52:11+1:00 |
Pour le ">> 2+2" qui donne "== 4" tu peux oublier de suite. Rebol n'impose aucun séparateur d'instruction à la noix (du genre ";" en fin de ligne), mais il y a un séparateur d'instruction qui est le "blanc". Un "blanc" étant un espace, une tabulation, un saut de ligne. Faire fi de ce principe de base rendrait le parseur Rebol beaucoup plus complexe et donc plus lent ! Tu veux que Rebol soit plus lent ? | |
coccinelle | 21-Feb-2013/12:18:40+1:00 |
2+2 donne une erreur MAIS >> (2)+(2) == 4 Rebol nous surprendra toujours !!! | |
PierreCh | 22-Feb-2013/10:20:19+1:00 |
En effet, plus que surprenant, ce dernier exemple... J'en déduis que le ( ou le ) séparent les mots "plus" que le "blanc". DideC: non, bien sûr, je ne souhaite pas un Rebol plus lent. Mais je suis à chaque fois frustré quand je rouvre une console rebol, ces jours-ci, pour m'en servir comme d'une calculette. Ce que je faisais, ces dernières années, avec python. Quand on suit de l'index gauche un texte sur du papier et que c'est la main droite qui claviote les opérations (chose fort courante), il est on ne peut plus frustrant et inconfortable de devoir taper sur la barre d'espace à tout bout de champ (c'est le cas de le dire). Je suis d'accord, je chipote, ce n'est pas là que Rebol brille de tous ses feux. Mais en même temps, ça m'oblige à rouvrir mon python. Et ensuite, une fois dedans, ça me dérebolise la tête, et je suis tenté de pythonner... | |
DocKimbel | 22-Feb-2013/13:34:15+1:00 |
@PierreCh: En effet, plus que surprenant, ce dernier exemple... J'en déduis que le ( ou le ) séparent les mots "plus" que le "blanc". Les "blancs" ne sont pas les seuls séparateurs en REBOL, il y a aussi les "super-délimiteurs", du type []()<>"{} qui permettent de séparer les valeurs. Mais je suis à chaque fois frustré quand je rouvre une console rebol, ces jours-ci, pour m'en servir comme d'une calculette. Ce que je faisais, ces dernières années, avec python.[...]Je suis d'accord, je chipote, ce n'est pas là que Rebol brille de tous ses feux. Bien au contraire...voici une solution possible: REBOL [] context [ digit: charset "0123456789" not-digit: complement digit load-calc: func [str [string!] /local new pos s e][ new: make block! 1 unless parse str [ pos: any [ s: [some digit | some not-digit] e: (append new load copy/part s e) ] ][ print ["*** Syntax Error at:" pos] ] new ] set 'calc does [ forever [ str: ask "calc>> " print ["==" do load-calc str] ] ] ] Pour l'utiliser, tu charges le script dans une session REBOL (ou bien tu le copies/colles), puis tu tapes calc pour passer en saisie "sans les blancs" et ESC pour revenir à la console de base: >> calc calc>> 1+2+3-5 == 1 L'ajout du support des parenthèses est laissé à la discrétion du lecteur. | |
DocKimbel | 22-Feb-2013/13:36:09+1:00 |
Désolé d'avoir abimé l'affichage de ce thread en utilisant la basile [ code ] au lieu de [ i ]...une possibilité de prévisualisation de son message avant de poster manque cruellement... | |
PierreCh | 23-Feb-2013/14:37:48+1:00 |
Youpi, ça marche! Je continue à me dépythonniser, donc. Faut juste que je me mette ça dans mon .pythonrc. Flûte, non, c'est pas ça... Ah oui, ça me revient: dans mon .rebol/view/user.r Et j'aurai juste à faire calc quand je veux calculer "bêtement": super, merci! | |
PierreCh | 24-Feb-2013/21:33:22+1:00 |
Je continue à tenir le rôle du râleur de service, mais il y a encore 2-3 choses qui sont assez crispantes, quand j'essaye de Reboler au quotidien. Donc je rajoute ça au menu du langage de mes rêves: - Ctrl-C, si ça pouvait "breaker" le déroulement du script (comme dans python, au hasard), au lieu de killer, ça serait reposant... - Un support digne de ce nom de l'historique (qui cherche dans les sessions précédentes), de la recherche, de la complétion (qui est déjà très bien dans Rebol2; manquerait à compléter les raffinements), des touches classiques du genre Ctrl-W, Del, Home, End (je sais, il y a quelques astuces pour avoir quelques de ces touches qui marchent, mais ce serait peinard d'avoir ça "de série"). Tout ceci ajouterait un confort estimable pour la programmation en console, qui est formidable pour prototyper du code. | |
coccinelle | 25-Feb-2013/7:59:45+1:00 |
Pour le ctrl-C, au lieu de râler, demande plutôt sur le forum comment on fait !!! Esc, appuie sur la touche Esc, cela fait ce que tu souhaites. | |
DideC | 25-Feb-2013/9:53:40+1:00 |
Tu sais Pierre, il y en a d'autres qui trouve la console de R2 pas mal, mais perfectible. Alors il la perfectionne eux-même. Une simple recherche sur Rebol.org te donnera pas mal de scripts qui proposent une ou plusieurs améliorations de la console R2. Il suffit de s'en inspirer pour faire toi même la console de tes rêves : http://www.rebol.org/search.r?find=console&form=yes | |
coccinelle | 25-Feb-2013/11:30:35+1:00 |
Si tu veux garder l'historique de la console, il te suffit de faire un save ou un load de l'historique :save-history: does [ save %conshist.r system/console/history ] load-history: does [ system/console/history: load %conshist.r ] Et si tu veux sauver ton historique automatiquement lors du quit, il te suffit de redéfinir le mot quit : my-quit: :quit quit: func [ /return value integer! ][ save-history either return [ my-quit/return value ][ my-quit ] ] Ce ne sont que des exemples. | |
coccinelle | 25-Feb-2013/11:36:04+1:00 |
Petite erreur dans la redéfinition de quit, le code ci-dessous est mieux. my-quit: :quit quit: func [ "Stops evaluation, save the console history and exits the interpreter." /return value [integer!] ][ save-history either return [ my-quit/return value ][ my-quit ] ] | |
PierreCh | 25-Feb-2013/14:37:28+1:00 |
Merci à tous! Le coup du system/console/history: load %conshist.r est fort astucieux, j'imaginais pas que l'on pût y écrire. Bon, maintenant que tout le monde est réveillé, j'arrête de râler ,;o) Je n'ai pas le reflexe d'aller picorer sur les scripts de rebol.org, et c'est un tort: ça m'a l'air très riche. | |
shadwolf | 26-Feb-2013/2:35:42+1:00 |
moi je veux raler ... un certain fou furieux avait fait un script pour colorer le texte de la console... evidement c etait trop genial pour etre repris et ameliorer... c est ce genre de nullité fondementale qui me fout les boules avec la communauté rebol. Foutrement incapable de voir le geni ou il se trouve ... bref ... c est pas maintenant que ca changera. | |
shadwolf | 26-Feb-2013/2:39:52+1:00 |
mais de quoi je me plaind? hein serrieux la console de r3 est tellement geniale ... puis c est pas comme si r3 disposait d un gui de toute facon ;P | |
PierreCh | 17-Mar-2013/16:24:14+1:00 |
shadwolf: le fou furieux, il aurait pas laissé son script coloriseur de console quelque part? Sur http://www.rebol.org/ ? Si non, faudrait l'y mettre, non?Foutrement incapable de voir le geni ou il se trouve ... bref ... c est pas maintenant que ca changera. Hm. Dommage. Faudrait que ça change... Avec l'ouverture (en cours: de toute évidence, il y a encore pas mal de chemin à faire dans le coin de Rebol (pas de Red, de ce que je puis voir): l'ouverture, ça ne concerne pas que les sources), ça ne pourra qu'aller en ce sens. Il faut que ça se fasse. | |
Login required to Post. |