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 ? ... 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. 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 ! 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 pense que beaucoup de solutions ont été proposées pour Nsetup, et il est plus que temps de les tester :-) ++ Gontran > > Globalement je suis pour une programation orientee objet des que le soft a > un niveau conceptuel avance : Ncooker et Nsetup meriteraient une > programmation oriente objet. > > Maintenant d'autres arguments font que le bash a ses atouts aussi. On a > choisit > de developper Ncooker en bash, on va aller au bout de la chose. Si on > s'appercoit qu'a l'usage bash c pas cool et ben on refera un nouveau > Ncooker dans un autre language pour une autre version de Nasgaia. Mais > actuellement on va aller au bout de la solution bash et voir ce que ca > donne. > > En ce qui concerne Nsetup, il ne faudrait pas tomber dans le piege > classique de > du developpement d'un progamme : au fur et a mesure de l'avancement de > nouveaux > besoins apparaissent, on a envie de faire de nouvelles fonctionnalite qu'on > avait pas prevu au depart, on se rend compte qu'on aurait pas du le > designer comme ca, et on reprend sans cesse le design et les choix > techniques. Et on avance pas... > > Donc reglons une fois pour toute cette histoire de language et de gui et > tenons-nous y ! > > Quel language ? > > - Il faut un language repandu sur les systemes unix de facon a ce que le > programme soit portable et accessible (que tout le monde puisse > participer), ce > qui nous donne : > > -------------------- > COMPILE : > > ASM (et encore, qui sait coder en assembleur de nos jours ? ;-) ) > C > C++ > > INTERPRETE : > > bash > python > perl > php > ruby > > SEMI COMPILE : > > java > C# > > -------------------- > > - Ncooker etant un outils de base, il faut le minimum de dependance, son > installation doit etre facile, et ne doit dependre que de projet 100% dans > l'esprit de Nasgaia. > > On elimine donc Java et C# ;-) > > - Le code doit etre lisible et facile a maintenir. > > On elimine l'assembleur et perl ;-) > > - COMPILE ou INTERPRETE ? Les languages de scripts sont tres sympa a > utiliser, facile a debuguer, le code est facilement accessible et > modifiable, mais dependent de leur interpreteur : si le projet est gros les > performances risquent d'etre mediocres. Dans notre cas je considere que les > projets sont petits et donc qu'un language interprete est tout a fait > adapate. > > Il nous reste donc : > > Bash, Python, Ruby et php > > Il semblerait (peut etre que je me trompe) que php soit plus adapte > pour le dev > web (mais si je pense qu'il pourrait tout a fait convenir) > > Il nous reste donc : > > Bash, Python et Ruby. > > Selon qu'on veuille un language objet ou pas on elimine bash > Tout ce qui precede s'applique a Ncooker aussi bien qu'a Nsetup. > > Maintenant, la ou Nsetup differe c'est au niveau gui : > > En ce qui me concerne, je pense que si on arrive a pondre un interface > Ncurse, GTK et QT on couvrira 98% des besoins de nos utilisateurs. > > Donc il faut un language pouvant gerer ces 3 toolkits directement > (python-gtk, ruby-gtk,...) ou indirectement (bash et dialog). > > Je pense que techniquement on pourrait faire un tres bon Nsetup avec > n'importe quel language parmis Bash, Python et Ruby. > > A mon avis c'est a ceux qui developpent Nsetup de choisir. Mais il faut > choisir > et s'y tenir ! > > A titre tout a fait personnel je choisirai un language oriente objet. Entre > Python et Ruby je ne sais pas ! Python je connais tres peu et Ruby pas > du tout. > J'ai une image de python comme etant une grosse usine a gaz, et de Ruby > comme etant un Bash oriente objet. Mais j'ai peut-etre totalement faux ! > Compte tenu de mes a priori, et compte tenu que j'adore apprendre de > nouveaux languages : > > Je choisirai RUBY > > Mais une fois encore, je pense que c'est aux developpeurs d'Nsetup de > choisir... > Mois ca me ferait tres chier de coder dans un language que je n'ai pas > choisit. > A mon avis (je vais me faire certainement taper dessus pas Gontran ou > Julien ou > Riri mais je le dis quand meme ;-) ) : Guiguilinux : "Fait toi plaisir, > mais fais le !". Donc Python apparement.... > > ++ > Chicha > > Quoting Jean-Michel BESSOT <[EMAIL PROTECTED]>: > > -----BEGIN PGP SIGNED MESSAGE----- > > Hash: SHA1 > > > > salut > > Qui a dit qu'il n'y avait pas de dialog avec python? > > http://pythondialog.sourceforge.net/ > > vive le dieu google ;) > > ++ > > -----BEGIN PGP SIGNATURE----- > > Version: GnuPG v1.4.1 (GNU/Linux) > > Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org > > > > iD8DBQFCi1GZg92ALbF0m+ARAsV1AJ9291+x6ng22xGZN3b0Mm7onSiiugCcCMki > > UeqlSA4To8PBdtug7PO2Tok= > > =BuL9 > > -----END PGP SIGNATURE----- > > > > _______________________________________________ > > Nasgaia-dev mailing list > > [email protected] > > https://mail.gna.org/listinfo/nasgaia-dev > > _______________________________________________ > Nasgaia-dev mailing list > [email protected] > https://mail.gna.org/listinfo/nasgaia-dev
