Comme posté plus bas ce n'est pas la ligne de commande qui est remise en cause (cf. MSH et mon post) un peu plus bas) mais le principe de l'emboîtement des traitements sur le principe des pipes et des chaines de caractères.
Un IHM , ca évolue beaucoup plus rapidement qu'un API et ca peut être déstabilisant pour l'utilisateur comme pour le développeur qui programmerait par envoi de message directement à l'IHM. Dans un programme bien conçu, l'interface en ligne de commande n'est qu'un moyen d'exposer l'API parmi d'autres.
Aujourd'hui les langages de script ou (Python, perl, Ruby ) permettent d'être beaucoup plus productifs pour les traitement automatisables et sont surtout plus évolutifs
Les exemples de réécriture de hacks en shell qui devenaient inmaintenables réécrit dans un langage
sont nombreux (CVS, Arch, ....pour le domaine que je connais un peu)
Avec ce genre de langages il n'y a plus de réécriture, ils sont "scalables" (pas trouvé l'équivalent francais désolé) et permettent de lier facilement les parties sensibles avec du code optimisé de plus bas niveau sans tout réécrire
Ce n'est pas pour rien qu'on voit emerger de plus en plus de solution de ce genre (Ubuntu basé sur python, google qui en fait un usage intensif, et les perliens et au rubymen sauront completer la liste)
A terme on en n'arrive à ne plus distinguer les langages de scripts et les shells (cf. MSH, ipython, ....) car on prend le meileur des 2 mondes.
[^] # Re: ...
Posté par golum . En réponse au journal Gnome fait par des nazis de l'interface ?. Évalué à 4.
Un IHM , ca évolue beaucoup plus rapidement qu'un API et ca peut être déstabilisant pour l'utilisateur comme pour le développeur qui programmerait par envoi de message directement à l'IHM. Dans un programme bien conçu, l'interface en ligne de commande n'est qu'un moyen d'exposer l'API parmi d'autres.
Aujourd'hui les langages de script ou (Python, perl, Ruby ) permettent d'être beaucoup plus productifs pour les traitement automatisables et sont surtout plus évolutifs
Les exemples de réécriture de hacks en shell qui devenaient inmaintenables réécrit dans un langage
sont nombreux (CVS, Arch, ....pour le domaine que je connais un peu)
Avec ce genre de langages il n'y a plus de réécriture, ils sont "scalables" (pas trouvé l'équivalent francais désolé) et permettent de lier facilement les parties sensibles avec du code optimisé de plus bas niveau sans tout réécrire
Ce n'est pas pour rien qu'on voit emerger de plus en plus de solution de ce genre (Ubuntu basé sur python, google qui en fait un usage intensif, et les perliens et au rubymen sauront completer la liste)
A terme on en n'arrive à ne plus distinguer les langages de scripts et les shells (cf. MSH, ipython, ....) car on prend le meileur des 2 mondes.