[Linux-bruxelles] Re: application graphique PPP(oE)

[Hervé Eychenne]

On Thu, Jan 13, 2005 at 10:45:34PM +0100, Didier Heekhout wrote:

> Hervé Eychenne wrote:

> >Oui, on leur présente par défaut des outils graphiques, et il y a une
> >bonne raison à cela : tu te retrouves pour la 1ère fois devant ton
> >shell et tu te dis quoi ? "Et maintenant, qu'est-ce que je fais ??".
> >Alors que dans une interface graphique, il y a généralement des menus,
> >des boutons sur lesquels cliquer, quelque chose avec quoi "jouer".

> Entièrement d'accord. Mais, il serait TRES utile que les "front-ends" 
> graphiques montrent les lignes de commande qu'ils utilisent (p.ex. 
> nmapWin donne la ligne de commande "nmap ..."), voire les commandes 
> utilisables dans des macros (type gimp-image-flatten) qui pourraient 
> grandement faciliter la vie des utilisateurs "évolués" (voir p.ex. le 
> thread "Gimp ou autre : automatisation graphique").

Oui, si tant est que le front-end utilise une commande shell... De
plus, même si une telle commande existe, il n'est pas forcément
souhaitable que l'interface graphique l'utilise, d'ailleurs, car
l'interaction avec une commande shell manque bien souvent de
souplesse. Au lieu de ça, l'interface graphique serait plus inspirée
d'utiliser une bibliothèque de fonctions, utilisée également
par la commande shell (qui elle aussi ne devrait être qu'un
front-end). Et là, fini l'affichage de la commande shell réutilisable,
ce qui est dommage, effectivement. Donc il faudrait que l'interface
graphique propose une syntaxe de commande shell équivalente, bien
qu'elle ne l'utilise pas elle-même. CQFD.

> >>>[la ligne de commandes]

> >>Pourquoi veux-tu qu'il leur prennent 
> >>soudain l'idée d'inventer que ça existe et qu'ils vont l'apprendre?

> >Déjà, c'est là. Il n'y a rien à inventer, mais éventuellement à
> >découvrir. Quand au fait d'apprendre, la courbe d'apprentissage est
> >bien plus raide, comme je le disais.

> Et voir qu'il existe une ligne de commande peut inciter les curieux à 
> aller voir plus loin. Et qui sait, à utiliser le "find ... -exec ..." et 
> le "sed -e ..." qui, combinés, font des ravages !!!
> >
> >
> [....]

> Bref, il faudrait que :
> 1. toute opération "GUI" ait son équivalent "ligne de commande"
> 2. et réciproquement, toute opération "ligne de commande" puisse être 
> effectuée par un GUI (vraisemblablement moins efficacement...)

Moins efficacement dans le sens où ce n'est non-automatisable et avec
sans doute moins de granularité. Mais parfois plus efficacement dans
le sens "j'arrive rapidement à mes fins sans avoir besoin de
m'intéresser en détails à des arcanes qui ne m'intéressent pas".

> Et ceci termine mes voeux de bonne année ... 2005 / 6 / 7 / 8 / 9 ... 
> ??? De toutes façons, cela ne verra jamais le jour.

Bien sûr que ça pourrait... mais on ne peut pas imposer à tous les
développeurs de programmer en respectant consciencieusement
l'ensemble des "bonnes pratiques" de design logiciel...
Les déficiences informatiques actuelles sont dues à un problème
de culture globale des développeurs, mais aussi à la la grande
malléabilité du logiciel elle-même : si on découvre un défaut,
cela peut être (en théorie) corrigé rapidement et facilement,
avec un coût faible (au cas par cas) la plupart du temps.
Il n'y a qu'à ressortir une nouvelle version (que l'on fera payer, si
possible !), en attendant le prochain problème. Et l'usage massif
de Windows est là pour démontrer que les gens ne considèrent pas cela
comme suffisamment anormal pour que les choses changent à grande
échelle.

C'est pour ces deux raisons que les standards de qualité du milieu
informatique sont hélas très pauvres.
Les constructeurs de processeurs ont une complexité au moins aussi
grande à gérer lors de la conception et la production des puces,
et pourtant, on y retrouve que de très rares bugs. Pourquoi ?
Parce que disperser dans le monde entier un processeur buggé peut
avoir des conséquences désastreuses pour l'entreprise qui les produit
(et celles qui les utilisent), avec un coût potentiellement énorme pour
le fondeur, de toute façon.
C'est principalement pour cela que leur exigence de qualité "logicielle"
est bien meilleure.
Mais les gens ont également leur part de responsabilité dans le
manque d'exigence informatique ambiant : bon nombre de personnes
(le grand public) ont parfaitement intégré l'idée que "l'informatique,
ça plante, c'est comme ça ; et ce n'est pas toujours sûr parce qu'il
y aura toujours des virus et qu'on y peut rien, etc.", même si c'est
parfaitement faux en théorie.

 Hervé

-- 
 _
(°=  Hervé Eychenne
//)  Homepage:          http://www.eychenne.org/
v_/_ WallFire project:  http://www.wallfire.org/