Beh il me semble que le but d'un programme est de répondre à des besoins précis. Si parmis ces besoins ne figure pas le partage et la réutilisation, il est n'est pas nécessaire des les y faire figurer, ça complique plus ou moins le développement et ça amène parfois à l'échec du projet : trop compliqué (à développer / déployer / utiliser / maintenir) pour son but premier.
Tu as expliqué ce que tu pensais en disant : "interfacer une ligne de commande c'est faire n'importe quoi". Ca me gène dans le sens ou parfois c'est une très bonne solution. Maintenant, je suis d'accord avec toi sur le fait que faire ça systématiquement est une mauvaise approche.
Il est évident que d'utiliser ce principe pour de l'intéractif, ce n'est pas très malin. Je n'arrete pas de le dire... Dans ce même ordre d'idée, en ce moment, ce qui me chagrine c'est qu'on essaye de remplacer les applis C/S par des applis web. Pourtant, le web est encore moins interactif que la ligne de commande puisque le serveur ne peut rien envoyer spontanément au client : impossible de notifier sans faire crado un changement dans les données aux clients, par exemple : inadapté pour certaines situations.
Pour ce qui est des programmes irremplaçables, il est clair que ce serait peut-etre mieux de les avoir sous une autre forme, parce qu'ils permettraient sans doute de mieux répondre aux évolutions des besoins. Maintenant qu'on a le programme, on lui en demande plus.
Mais, l'informatisation est un processus itératif et les besoins évoluent sur la base existante. Avant, il n'y avait rien, les besoins c'était d'aboir un outil qui fasse le boulot. Maintenant qu'il y a un outil qui fait le boulot, on lui demande de le faire différement ou de faire des choses en plus. Les premiers développeurs n'ont pas fait n'importe quoi : ils ont répondu aux exigences qu'on leur a fixé. Il me semble compréhensible qu'ils n'aient pas eut en tête les besoins modernes, surtout quand le projet remonte à une époque ou l'interface graphique était atypique (cette fameuse époque où la ligne de commande était reine).
Mais, on peut se poser la question suivante : pourquoi ne remplace-t-on pas ces programmes ? L'effort de développement ne serait-il pas trop cher payé pour le gain ?
J'ai pris pour exemple le cas de cdrecord/gcombust parce qu'il me semble assez représentatif : pas top niveau ergonomie mais ça grave bien et suffisement simplement. Le rapport effort de développement / gains n'est peut-être pas encore assez interessant pour que quelqu'un en fasse une lib de gravure.
[^] # Re: oué et
Posté par Toufou (site web personnel) . En réponse au journal Windaube, c'est maaaaaal! / linux c'est bien!. Évalué à 3.
Tu as expliqué ce que tu pensais en disant : "interfacer une ligne de commande c'est faire n'importe quoi". Ca me gène dans le sens ou parfois c'est une très bonne solution. Maintenant, je suis d'accord avec toi sur le fait que faire ça systématiquement est une mauvaise approche.
Il est évident que d'utiliser ce principe pour de l'intéractif, ce n'est pas très malin. Je n'arrete pas de le dire... Dans ce même ordre d'idée, en ce moment, ce qui me chagrine c'est qu'on essaye de remplacer les applis C/S par des applis web. Pourtant, le web est encore moins interactif que la ligne de commande puisque le serveur ne peut rien envoyer spontanément au client : impossible de notifier sans faire crado un changement dans les données aux clients, par exemple : inadapté pour certaines situations.
Pour ce qui est des programmes irremplaçables, il est clair que ce serait peut-etre mieux de les avoir sous une autre forme, parce qu'ils permettraient sans doute de mieux répondre aux évolutions des besoins. Maintenant qu'on a le programme, on lui en demande plus.
Mais, l'informatisation est un processus itératif et les besoins évoluent sur la base existante. Avant, il n'y avait rien, les besoins c'était d'aboir un outil qui fasse le boulot. Maintenant qu'il y a un outil qui fait le boulot, on lui demande de le faire différement ou de faire des choses en plus. Les premiers développeurs n'ont pas fait n'importe quoi : ils ont répondu aux exigences qu'on leur a fixé. Il me semble compréhensible qu'ils n'aient pas eut en tête les besoins modernes, surtout quand le projet remonte à une époque ou l'interface graphique était atypique (cette fameuse époque où la ligne de commande était reine).
Mais, on peut se poser la question suivante : pourquoi ne remplace-t-on pas ces programmes ? L'effort de développement ne serait-il pas trop cher payé pour le gain ?
J'ai pris pour exemple le cas de cdrecord/gcombust parce qu'il me semble assez représentatif : pas top niveau ergonomie mais ça grave bien et suffisement simplement. Le rapport effort de développement / gains n'est peut-être pas encore assez interessant pour que quelqu'un en fasse une lib de gravure.