Re :-) Gontran a écrit : > Le Mercredi 18 Mai 2005 17:35, Charles-Henri d'Adhémar a écrit : > >>Salut a tous :-) > > > Salut :-) > > J'ai l'impression que la discussion sur le langage de programmation pour > développer Nsetup tend à déborder sur Ncooker :-) Et je n'en vois absolument > pas les raisons. Pourquoi d'un seul coup remettre en cause l'utilisation de > Bash pour coder Ncooker ? On va réécrire Ncooker en Python ou en Ruby parce > que ça fait « bien » ou y a-t-il « vraiment » une raison valable de le > faire ? parce que c'est orienté objet ? Et qu'est-ce que ça va apporter de > plus à Ncooker alors qu'il est déjà modulaire en Bash ?? Et en mesure-t-on > toutes les conséquences ??? Comment allons-nous utiliser le fichier build des > NBUILDs en python ? ...
Dans aucun de mes propos il n'a été question de réécrire dans l'immédiat Ncooker dans un autre language que le bash. > > Depuis quelques jours, j'entends parler de langage « moderne », portable, > facile à maintenir, lisible, objet, plus rapide, optimisé ... Je rejoins > Julien sur ses nombreuses contre-remarques : de nombreuses réflexions ne sont > pas sérieuses ! Python est mieux parce qu'il force l'indentation ? En quoi > est-ce mieux alors qu'on peut utiliser la même indentation pour d'autres > langages ? Perl est illisible ? Il l'est autant que le développeur le veut > bien. J'ai l'impression qu'on cherche à opter pour un langage de > programmation pour ses qualités générales en oubliant les véritables besoins > de Nsetup. Tu as raison en soulevant que beaucoup d'arguments sont douteux et basés sur peu d'expérience (que je revendique totalement pour certains languages comme bash, python et ruby). Maintenant mon argument sur perl était tout à fait justifié, basé sur une expérience (certes modeste), et je ne peux pas te laisser dire que mon argument n'est pas sérieux. C'est vraiment très difficile à rendre propre. Si c'est pour avoir 3 lignes de commentaire pour une ligne de code c'est quand même pas super productif. As-tu déjà travaillé en perl ? J'ai codé NXdialog avec Tuxa. On est sûrement pas des très bon développeurs, c'était ma première expérience en perl (Tuxa est beaucoup plus expérimenté), mais en tout cas on en a chié pour se relire. Même son propre code. Comment expliques-tu le succès indéniable de php sur perl, alors que techniquement perl offre quasiement les mêmes possibilités? Enfin bref, le but n'est pas de te provoquer ni de rentrer dans des détails techniques. J'ai sûrement dit des conneries, mais pas celle que tu as cité ! > J'ai également l'impression que de nombreuses affirmations sont avancées sur > des aprioris. Nous sommes nombreux à reconnaître ne pas avoir d'expériences > significatives dans ces langages, alors arrêtons d'avancer des arguments sans > fondements et cherchons, testons, essayons ! On va se planter ? Tant mieux ! > Comme ça, on saura qu'il ne faut pas faire de telle manière ! Certains > pensent que Python répond aux besoins de Nsetup ? D'autres que c'est Ruby ? > Et bien que chacun développe dans le langage de son choix en parallèle ! > Qu'a-t-on a y perdre ? Rien ! Les personnes concernées vont enrichir leur > expérience personnelle (et se seront fait plaisir, comme le dit Chicha :-) ), > et au moins on aura quelque chose pour tester, pour voir ce que ça donne, > pour comparer, et surtout pour faire des critiques objectives ! Je vais même plus loin en disant : vu la taille modeste des projets, et les contraintes techniques mineures (c pas Ncooker qui va bouffer tout le cpu ou la ram) qu'on le fasse en bash python ruby c++, java ou autre le résultat sera le meme pourvu qu'on soit bon à la conception. > Il ne faut pas obligatoirement avoir le modèle complet d'une application pour > commencer à coder. On peut très bien commencer avec quelque chose de petit et > le faire évoluer au fur et à mesure. Je ne vois pas en quoi il est gênant que > de nouveaux besoins apparaissent en cours de développement alors qu'ils > n'étaient pas prévus au départ. Je dirai même que c'est tout à fait normal. À > partir de ce qui est fait, on a de nouvelles idées qui amènent de nouveaux > besoins. C'est vrai que c'est besoin peuvent montrer que le design et les > choix techniques de départ ne correspondent pas. Faut-il pour autant dire > qu'on avance pas ? Bien au contraire, on avance ! Car on sait à présent que > certaines implémentations ne sont pas adaptées, qu'il faut les modifier, les > améliorer ou carrément les changer. Et pour moi, ça c'est progresser. Et > c'est d'ailleurs ce qui se passe pour Ncooker : la gestion des messages est > revue parce ce qu'elle s'avère ne pas correspondre aux besoins au fur et à > mesure que le développement avance. Le fonctionnement de la commande Check a > été revu parce qu'il est mieux que toutes les erreurs soient détectées en > unse seule fois. Je partage ton opinion, mais encore faut-il qu'il y ait un résultat avant de le remettre en cause. Là où je disais que ce n'est pas bon de remettre en cause le design et les choix techniques sans cesse c'est pas sur des détails aussi précis que print_msg ou autre mais sur l'architecture et les choix techniques globaux. Je suis le premier à me remettre en cause sur des choix techniques bas-niveaux. Mais je n'ai aucune envie qu'on remette en cause l'architecture d'Ncooker tant qu'on a pas fait les commandes build, install et remove qui sont les fonctionnalités premières d'Ncooker. Avant de se remettre en cause globalement je souhaite un résultat sur lequel discuter. Au niveau Ncooker les choses avances, mais pas encore assez pour qu'on puisse faire une remise en cause de fond. Au niveau Nsetup je ne suis pas sûr que ce soit le cas, mais peut-être que je me trompe. J'ai l'impression qu'on remet en cause chaque semaine l'architecture globale de l'outils, sans aboutir une seule fois à une solution claire et précise et un début d'implementation qui permette de juger du résultat. Je rajouterai aussi : Se faire plaisir oui. Tout seul non ! On est tous embarqué dans une aventure : il y a des choix fait par la communauté il faut s'y tenir. A titre personnel j'aimerais programmer avec un language objet tel que le Ruby. Mais j'aimerais encore plus aboutir à un Ncooker qui fonctionne. C'est pourquoi ça m'est égal qu'on code Ncooker en bash, et je participe volontier, car une fois encore, vu la taille modeste du projet, peu importe le language. Mais ça me ferait chier que tel ou tel développe dans son coin le même outils pour se faire plaisir. Ce serait un manque de respect total des autres membres du projet à mon avis. > > Je pense que beaucoup de solutions ont été proposées pour Nsetup, et il est > plus que temps de les tester :-) Ben voilà, on dit la même chose : se masturber le cerveau ça va bien 5 minutes mais il faut quand même avancer. Maintenant Guiguilinux a manifesté des difficultés et des besoins. Il a droit à une réponse. Je viens de faire un mail de reflexion sommaire sur les languages de programmation utilisables, selon moi, dans le cadre du projet. Partages-tu cette analyse (sans grande prétention technique, je le reconnais bien volontier, mais basée cependant sur une pratique de tous les languages que j'ai mentionné mis à part python et ruby dont je reconnais mes a priori explicitement dans le mail) ? Es-tu d'accord pour que Guiguilinux fasse Nsetup en python ? ++ Chicha (tout va bien malgré le ton parfois direct que je peux prendre dans ce mail :-), et comme souvent vous verrez que Gontran et moi sommes d'accord mais qu'on a du mal à le reconnaitre :-p )
