C'est rigolo parcque j'ai l'impression qu 'on est d'accord sur la pluparts des points du débat :)
C'est pas trop la mort à parser, et les perfs ne sont pas importantes.
Oué enfin dans le cas de ton lecteur mp3, comment tu indiques à l'utilisateur la position courante ? comment dans ton programme de gravure tu précises voir traite le message retourné par cdrecord ? C'est rarement une communication On/Off, même pour ds programmes aussi triviaux. Comment tu sépares ce qui est une erreur et ce qui n'en ai une simple information, voir un résultat ? Sachant que la doc ne te renseigne pas du tout sur la nature des messages retournés à parser, c'est à toi de te démerder, la doc t'indiques juste quoi appeler.
Rien que dans k3b tu vois ca m'énerve sérieusement que quand il foire une gravure il me dise juste "cdrecord a retourné une erreur". Ouh merci pour l'info.
C'est sur, mais bon, pour lancer un mp3 ou une gravure, on va peut-etre pas non plus faire une norme ISO hein ? :)
Bah non mais tout bêtement on expose les APIs qu'on a du faire pour les utiliser. C'est juste une question de bonne pratique : on sépare ce qui fait le boulot de l'interface (même console), auquel cas ce n'est absolument pas plus dure de proposer celà aux programmeurs en plus.
(Au fait ce que je dis s'applique également aux fichiers de conf sous Unix/Linux en général : personne n'a la même syntaxe, c'est imbittable à parser par une application tierce-partie.) Quelle différence il y a entre une API maison ou une ligne de commande maison ?
Dans un cas c'est documenté, pas dans l'autre. Dans un cas les moyens de comunications sont multiples et dans l'autre réduit au parsing. C'est d'une abberation total, regarde :
- le front-end transforme un appel de méthode interne en chaîne de caractères compréhensible par le programme console
- le programme console parse la chaîne de caractère et transforme celà en passage de paramètre d'une méthode appelée derrière.
C'est pas un peu très idiot ?
- gérer tous les projets avec des methodes lourdes (sauce RUP)
- gérer tous les projets avec des methodes légeres (sauce XP)
Juste pour la précision, RUP tire pas mal de pratique de XP et les 2 sont complémentaire et à choisir selon l'effectif. Enfin emrci pour l'historique, même si je ne vois pas en quoi celà va dans ton sens :)
S'interdire des approches c'est se compliquer la vie dans les cas où l'approche n'est pas appropriée.
Bah voilà exactement, et avec certains programmes qui croyait proposer une interface "universelle" par console, on se retrouve avec des aberrations parcqu'ils n'ont pas voulu proposer d'API, petit plus pas bien compliqué qui faciliterait la vie de bien des applications.
il prend mon programme et en fait une lib s'il a besoin d'une lib.
Oui effectivement, seulement si il a les sources.
Celà peut être légitime de se dire qu'on a pas envie de se casser le cul pour d'éventuels utilisateurs, mais le minimum, à l'heure actuelle, et quand même de se dire que notre programme a de grande chances d'être utilisé par un utilisateur qui n'a rien d'un être humain, et pour qui la langue de shakespeare distribuée au compte goute dans un format à la con (chaîne de caractère) n'est pas du tout un moyen de communication privilégié.
J'ai cité 2 exemple qui sont tout à fait convenables en termes de GUI et qui marchent très bien comme ça.
Comme je te l'ai indiqué plus haut, même pour ces 2 cas précis c'est insuffisant. Si le volume change ou si bêtement le lecteur n'arrive plus à lire un morceau, etc, il y a pleins de messages à parser si on vuet qu'il y est un tant soit peu d'interactivité. Pareil pour la gravure, faut bien indiquer en permanence l'état des buffers, signaler des messages sur la vitesse courante de gravure, bref, il y a une interactivité permanente et donc des communications permanentes avec le programme console.
Si tu fais une lib ET une commande, tu devras probablement te taper deux fois le controle
Euh, dans le cas de la lib, il n'y a pas de vérification de débordement à faire, tu passe des vrais valeurs dans des vrais types en arguments, pas besoin de parler en anglais dans une string. Et puis bon, les contrôles de débordement de chaîne de caractère, c'est bon pour les programmeurs C qui veulent tout faire à la main, et encore ils peuvent utiliser la glib pour faire le boulot.
e pense que tu n'aimes pas les mêmes gens que moi : les gens qui fustigent une techno et qui sont des boulets à cause de leur inaptitude a s'adapter au but parce qu'il sont limités à une seule approche.
Comme je l'ai dit plus haut, ce n'est pas l'utilisateur que je considère comme un boulet, mais plutôt des habitudes du passé, qui se sont transformées en boulet avec le temps, parcque les technos étant dépassées.
Mais tu vois, j'attend toujours des arguments en faveur de la ligne de commande uniquement, et décidemment, même pour cdrecord je vois que des inconvénients.
[^] # Re: oué et
Posté par TImaniac (site web personnel) . En réponse au journal Windaube, c'est maaaaaal! / linux c'est bien!. Évalué à 2.
C'est pas trop la mort à parser, et les perfs ne sont pas importantes.
Oué enfin dans le cas de ton lecteur mp3, comment tu indiques à l'utilisateur la position courante ? comment dans ton programme de gravure tu précises voir traite le message retourné par cdrecord ? C'est rarement une communication On/Off, même pour ds programmes aussi triviaux. Comment tu sépares ce qui est une erreur et ce qui n'en ai une simple information, voir un résultat ? Sachant que la doc ne te renseigne pas du tout sur la nature des messages retournés à parser, c'est à toi de te démerder, la doc t'indiques juste quoi appeler.
Rien que dans k3b tu vois ca m'énerve sérieusement que quand il foire une gravure il me dise juste "cdrecord a retourné une erreur". Ouh merci pour l'info.
C'est sur, mais bon, pour lancer un mp3 ou une gravure, on va peut-etre pas non plus faire une norme ISO hein ? :)
Bah non mais tout bêtement on expose les APIs qu'on a du faire pour les utiliser. C'est juste une question de bonne pratique : on sépare ce qui fait le boulot de l'interface (même console), auquel cas ce n'est absolument pas plus dure de proposer celà aux programmeurs en plus.
(Au fait ce que je dis s'applique également aux fichiers de conf sous Unix/Linux en général : personne n'a la même syntaxe, c'est imbittable à parser par une application tierce-partie.)
Quelle différence il y a entre une API maison ou une ligne de commande maison ?
Dans un cas c'est documenté, pas dans l'autre. Dans un cas les moyens de comunications sont multiples et dans l'autre réduit au parsing. C'est d'une abberation total, regarde :
- le front-end transforme un appel de méthode interne en chaîne de caractères compréhensible par le programme console
- le programme console parse la chaîne de caractère et transforme celà en passage de paramètre d'une méthode appelée derrière.
C'est pas un peu très idiot ?
- gérer tous les projets avec des methodes lourdes (sauce RUP)
- gérer tous les projets avec des methodes légeres (sauce XP)
Juste pour la précision, RUP tire pas mal de pratique de XP et les 2 sont complémentaire et à choisir selon l'effectif. Enfin emrci pour l'historique, même si je ne vois pas en quoi celà va dans ton sens :)
S'interdire des approches c'est se compliquer la vie dans les cas où l'approche n'est pas appropriée.
Bah voilà exactement, et avec certains programmes qui croyait proposer une interface "universelle" par console, on se retrouve avec des aberrations parcqu'ils n'ont pas voulu proposer d'API, petit plus pas bien compliqué qui faciliterait la vie de bien des applications.
il prend mon programme et en fait une lib s'il a besoin d'une lib.
Oui effectivement, seulement si il a les sources.
Celà peut être légitime de se dire qu'on a pas envie de se casser le cul pour d'éventuels utilisateurs, mais le minimum, à l'heure actuelle, et quand même de se dire que notre programme a de grande chances d'être utilisé par un utilisateur qui n'a rien d'un être humain, et pour qui la langue de shakespeare distribuée au compte goute dans un format à la con (chaîne de caractère) n'est pas du tout un moyen de communication privilégié.
J'ai cité 2 exemple qui sont tout à fait convenables en termes de GUI et qui marchent très bien comme ça.
Comme je te l'ai indiqué plus haut, même pour ces 2 cas précis c'est insuffisant. Si le volume change ou si bêtement le lecteur n'arrive plus à lire un morceau, etc, il y a pleins de messages à parser si on vuet qu'il y est un tant soit peu d'interactivité. Pareil pour la gravure, faut bien indiquer en permanence l'état des buffers, signaler des messages sur la vitesse courante de gravure, bref, il y a une interactivité permanente et donc des communications permanentes avec le programme console.
Si tu fais une lib ET une commande, tu devras probablement te taper deux fois le controle
Euh, dans le cas de la lib, il n'y a pas de vérification de débordement à faire, tu passe des vrais valeurs dans des vrais types en arguments, pas besoin de parler en anglais dans une string. Et puis bon, les contrôles de débordement de chaîne de caractère, c'est bon pour les programmeurs C qui veulent tout faire à la main, et encore ils peuvent utiliser la glib pour faire le boulot.
e pense que tu n'aimes pas les mêmes gens que moi : les gens qui fustigent une techno et qui sont des boulets à cause de leur inaptitude a s'adapter au but parce qu'il sont limités à une seule approche.
Comme je l'ai dit plus haut, ce n'est pas l'utilisateur que je considère comme un boulet, mais plutôt des habitudes du passé, qui se sont transformées en boulet avec le temps, parcque les technos étant dépassées.
Mais tu vois, j'attend toujours des arguments en faveur de la ligne de commande uniquement, et décidemment, même pour cdrecord je vois que des inconvénients.