Et également pour la récupération du résultat aussi
Tout a fait, mais dans certains cas (les cas que j'ai cité en exemple), le résultat c'est "ça marche" / "ça ne marche pas". C'est pas trop la mort à parser, et les perfs ne sont pas importantes.
Sans parler de l'absence de tous les protocoles spécifiques à la communication entre programmes : types de données, exceptions, synchronisation, etc.
C'est sur, mais bon, pour lancer un mp3 ou une gravure, on va peut-etre pas non plus faire une norme ISO hein ? :) De plus, il y a plein de domaines ou il n'y a pas de protocole consensuel ou standard. Quelle différence il y a entre une API maison ou une ligne de commande maison ?
Sans parler qu'il a création inutile de processus quand un simple thread suffirait voir rien du tout.
Si les ressources systeme ne sont pas des ressources critiques, je ne vois pas le mal qu'il y a à créer un processus supplémentaire.
Non effectivement on a inventé celà y'a 20 ans, en croyant qu'on allait pouvoir tout faire avec ça
En 20 ans, on a lancé d'autres modes diverses et variées en croyant qu'on pouvait tout faire avec :
- tout stocker avec une approche relationnelle (même les fichiers !)
- tout stocker en XML (même les fichiers config !)
- tout faire avec une approche modulaire
- tout faire avec une approche l'objet (aaaah les BD objets :) )
- gérer tous les projets avec des methodes lourdes (sauce RUP)
- gérer tous les projets avec des methodes légeres (sauce XP)
- faire toutes les interfaces graphiques
- rendre tabou le goto
- passer toutes les applications C/S sur des technos Web
- tout faire passer par le port 80
- tout sortir du noyau
- etc., etc....
L'erreur n'est pas dans la techno mais dans le fait qu'on pense tout résoudre (et en mieux en plus) avec une seule approche. Si à chaque fois qu'on trouvait la méthode / techno universelle de la mort qui tue, ses évangélistes donnaient 10¤ à l'ONU, on pourrait s'acheter la paix dans le monde :)
Une approche unique ne convient pas à toutes les problématiques. S'interdire des approches c'est se compliquer la vie dans les cas où l'approche n'est pas appropriée. Et moi, je n'aime pas me compliquer la vie quand ce n'est pas nécessaire.
de nombreux programmes ont été conçus sans du tout penser à proposer une interface de programmation plus avancée EN PLUS
Je vois pas pourquoi j'irais faire une interface de programmation plus avancée EN PLUS si celle que j'ai répond à mon besoin. Si quelqu'un utilise mon programme, soit il a les mêmes besoins que moi (et l'interface existante devrait lui convenir), soit il a des besoins proches mais pas identiques et ce n'est pas à moi de résoudre ses problèmes : il prend mon programme et en fait une lib s'il a besoin d'une lib.
bref c'est valable pour la plupart des GUIs
Je n'ai jamais dit le contraire. Mais bon, la plupart ce n'est pas toutes. J'ai cité 2 exemple qui sont tout à fait convenables en termes de GUI et qui marchent très bien comme ça.
mais je cherche toujours les avantages de n'avoir QUE une interface console
Ca me semble évident : du moment que ça répond au besoin, tu t'embetes pas a faire une lib et/ou un composant : tu peux ne gérer que tes cas à toi, ce qui n'est pas le cas d'une lib ou d'un composant.
Par exemple, tu ne vas pas gérer un débordement de buffer dans ta lib parce que ce sera controlé en amont, au parsing de la ligne de commande par exemple. Si tu fais une lib ET une commande, tu devras probablement te taper deux fois le controle : au parsing des arguments ET à l'entrée de la fonction qui traite un des arguments, sinon tu risques le segfault dans l'une ou l'autre partie de la chaîne.
En tout cas tu confirmes ce que je disais : pour linux aussi les habitudes des utilisateurs sont un vrai boulet à traîner.
Je 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.
[^] # Re: oué et
Posté par Toufou (site web personnel) . En réponse au journal Windaube, c'est maaaaaal! / linux c'est bien!. Évalué à 3.
Tout a fait, mais dans certains cas (les cas que j'ai cité en exemple), le résultat c'est "ça marche" / "ça ne marche pas". C'est pas trop la mort à parser, et les perfs ne sont pas importantes.
Sans parler de l'absence de tous les protocoles spécifiques à la communication entre programmes : types de données, exceptions, synchronisation, etc.
C'est sur, mais bon, pour lancer un mp3 ou une gravure, on va peut-etre pas non plus faire une norme ISO hein ? :) De plus, il y a plein de domaines ou il n'y a pas de protocole consensuel ou standard. Quelle différence il y a entre une API maison ou une ligne de commande maison ?
Sans parler qu'il a création inutile de processus quand un simple thread suffirait voir rien du tout.
Si les ressources systeme ne sont pas des ressources critiques, je ne vois pas le mal qu'il y a à créer un processus supplémentaire.
Non effectivement on a inventé celà y'a 20 ans, en croyant qu'on allait pouvoir tout faire avec ça
En 20 ans, on a lancé d'autres modes diverses et variées en croyant qu'on pouvait tout faire avec :
- tout stocker avec une approche relationnelle (même les fichiers !)
- tout stocker en XML (même les fichiers config !)
- tout faire avec une approche modulaire
- tout faire avec une approche l'objet (aaaah les BD objets :) )
- gérer tous les projets avec des methodes lourdes (sauce RUP)
- gérer tous les projets avec des methodes légeres (sauce XP)
- faire toutes les interfaces graphiques
- rendre tabou le goto
- passer toutes les applications C/S sur des technos Web
- tout faire passer par le port 80
- tout sortir du noyau
- etc., etc....
L'erreur n'est pas dans la techno mais dans le fait qu'on pense tout résoudre (et en mieux en plus) avec une seule approche. Si à chaque fois qu'on trouvait la méthode / techno universelle de la mort qui tue, ses évangélistes donnaient 10¤ à l'ONU, on pourrait s'acheter la paix dans le monde :)
Une approche unique ne convient pas à toutes les problématiques. S'interdire des approches c'est se compliquer la vie dans les cas où l'approche n'est pas appropriée. Et moi, je n'aime pas me compliquer la vie quand ce n'est pas nécessaire.
de nombreux programmes ont été conçus sans du tout penser à proposer une interface de programmation plus avancée EN PLUS
Je vois pas pourquoi j'irais faire une interface de programmation plus avancée EN PLUS si celle que j'ai répond à mon besoin. Si quelqu'un utilise mon programme, soit il a les mêmes besoins que moi (et l'interface existante devrait lui convenir), soit il a des besoins proches mais pas identiques et ce n'est pas à moi de résoudre ses problèmes : il prend mon programme et en fait une lib s'il a besoin d'une lib.
bref c'est valable pour la plupart des GUIs
Je n'ai jamais dit le contraire. Mais bon, la plupart ce n'est pas toutes. J'ai cité 2 exemple qui sont tout à fait convenables en termes de GUI et qui marchent très bien comme ça.
mais je cherche toujours les avantages de n'avoir QUE une interface console
Ca me semble évident : du moment que ça répond au besoin, tu t'embetes pas a faire une lib et/ou un composant : tu peux ne gérer que tes cas à toi, ce qui n'est pas le cas d'une lib ou d'un composant.
Par exemple, tu ne vas pas gérer un débordement de buffer dans ta lib parce que ce sera controlé en amont, au parsing de la ligne de commande par exemple. Si tu fais une lib ET une commande, tu devras probablement te taper deux fois le controle : au parsing des arguments ET à l'entrée de la fonction qui traite un des arguments, sinon tu risques le segfault dans l'une ou l'autre partie de la chaîne.
En tout cas tu confirmes ce que je disais : pour linux aussi les habitudes des utilisateurs sont un vrai boulet à traîner.
Je 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.