Je vois pas ou est marqué "du texte brut" dans ce qui est cité, c'est une interprétation de ta part sur ce que tu estime être clair. Techniquement, du xml serait aussi du texte brut, ça n'a rien de clair en pratique.
« Voici la philosophie Unix : écrire un bon programme qui ne réalise qu’une seule tâche. Écrire des programmes coopérant entre eux. Écrire des programmes qui gèrent des flots de données textuelles, car cette interface est universelle. » (McIlroy)
« La tradition Unix encourage les programmes qui manipulent des formats simples, en mode texte, orientés flot et indépendants des équipements. Unix appelle de tels programmes des filtres ; ils reçoivent un simple flot de texte en entrée, le traitent et génèrent un simple flot de texte en sortie. » (Eric Raymond)
On peut quand même voi comment une simple phrase sorti de son contexte et répété advitam eternam en guise d’épitome d'un ouvrage exposant l'état de l'art de la recherche d'il y a 40 ans dans un domaine bougant à toute vitesse est encore trop compliqué pour que les gens l'utilisent pour exprimer une idée clair.
Je commence à trouver ça curieux qu'un groupe fortement imprégné par l'esprit scientifique en revienne presque à des méthodes shamanique de vénération des textes "anciens" sans avoir le moindre recul vis à vis d'eux et de leur propre position.
Tu interprètes (très) mal la situation à mon avis.
Comme tu dis, Unix est là depuis plus de 40 ans, dans un domaine extrêmement mouvant. Ce n’est probablement pas un hasard ; il y a très certainement des invariants dessous susceptibles d’expliquer sa longévité. La « philosophie Unix » que beaucoup ici traitent avec mépris, c’est justement une tentative d’isoler et expliciter ces invariants, dans l’objectif d’en tirer des leçons pour l’architecture logicielle en général.
Bien sûr, l’analyse peut être fausse, les conclusions erronées voire contreproductives. Mais ce n’est pas en balançant nonchalamment « 40 ans ; trop vieux » (alors qu’au contraire, la longévité serait plutôt bon signe) ou « chamanisme irrationel » (alors que justement, quand on creuse un peu, on se rend compte que la philosophie Unix, elle sort pas d’un chapeau, elle sort d’un gros boulot d’analyse effectué par de nombreuses et éminentes personnes).
Si tu prends l’exemple justement de l’insistance des interfaces textuelles, il y a plusieurs raisons à ça. La plus importante selon moi est la suivante : cela te force à faire une distinction entre la représentation algorithmique de tes données, la représentation fonctionnelle de tes données, et la représentation sémantique de tes données. Représentation algorithmique : comment représenter les données en mémoire pour résoudre efficacement le problème. Représentation fonctionnelle des données : comment communiquer efficacement l’état du problème à la machine. Représentation sémantique des données : comment communiquer efficacement l’état du problème à l’humain. Quand tu forces tes entrées et tes sorties à être textuelles, tu es forcé de te poser ces questions, parce que tu es forcé d’écrire la conversion entre les différentes représentations et ce même si tu n’as pas idée de ces distinctions. Ça te donne quasiment-automatiquement un système aisément débuggable et aisément testable. À contrario, le binaire, en général, ça se passe comme ça : je code mon algorithme. À partir de mon algorithme, je décide comment sont représentées en mémoire les entrées et les sorties. Et de là, je définis mon protocole binaire : en entrée, read(struct ProblemSpecification), en sortie write(struct Solution).
Bien sûr, tu peux très bien faire cette analyse avec un format binaire (par exemple protobuf), et la foirer avec un format texte (pas mal de formats XML en sont un bon exemple effectivement, mais ce n’est pas étonnant si tu gardes en tête l’analyse précédente : beaucoup de formats XML sont juste une image de la structure interne du programme). Mais en pratique, si on accepte l’idée que faire l’analyse poussée des différentes représentations est une bonne idée, alors la spécification des entrées/sorties en format textuel est une bonne méthodologie, parce que les incitations naturelles derrière y tendent. Pour parler très abstraitement, il n’y a pas équivalence entre « protocole textuel » et « bien conçu », mais il y a certainement corrélation.
Ceci n’est qu’une raison parmi un certain nombre, mais mon message commence à être déjà assez long comme ça (et il faudrait que j’aille dormir ;)), et il y a des bouquins entiers qui analysent la « philosophie Unix » de cette manière. Pas en tant que révérence irrationnelle envers un passé idéalisé, mais en tant que leçons pragmatiques à tirer.
La philosophie Unix ce n’est pas un Dieu bienfaisant qui va te garantir le succès si tu répètes quelque mantras. La philosophie Unix ce n’est pas non plus un Dieu colérique qui va te punir si tu ne fais pas exactement comme écrit dans La Loi. Mais c’est la sagesse condensée de gens qui ont fait plus pour l’informatique que tout ce que tu pourras rêver de faire, et il est aussi bon d’avoir un peu d’humilité avant de mettre tout ça à la poubelle d’un revers de main.
Tu peux critiquer la philosophie Unix. Seulement, si tu veux la critiquer efficacement, il faut d’abord la comprendre. Quelqu’un qui dit « philosophie Unix : texte, par exemple json_encode($internalStruct) » est bien plus éloigné de la philosophie Unix que quelqu’un qui dit « OK, mon programme va communiquer en protobuf (binaire), mais que ça ne me dispense pas de réfléchir aux différentes représentations de mon problème ». Mais le plus éloigné de tous, c’est celui qui dit « haha, utiliser du texte en 2015 juste parce que quelqu’un en 1970 a dit que c’était cool ? ridicule ! ». En fait, j’en envie de dire que c’est bel et bien ceux qui l’ont comprise qui sont le mieux placé pour violer les règles. Si je devais faire du 100% « strict philosophie Unix » à mon boulot, ça ferait longtemps que je serais à la porte (parce que bon, un programme en ligne de commande pour le service compta, ça va pas le faire :)) ; par contre, je suis bien placé pour savoir que mon efficacité sur l’analyse du problème et la recherche de solutions provient directement d’un état d’esprit qui découle de la philosophie Unix — et ce d’autant plus que je n’ai pas toujous été « Unixien », et que je vois clairement la différence entre « avant » et « après », en terme d’efficacité.
[^] # Re: Le bon chasseur et le mauvais chasseur
Posté par Moonz . En réponse à la dépêche systemd : l’init martyrisé, l’init bafoué, mais l’init libéré !. Évalué à 10.
« Voici la philosophie Unix : écrire un bon programme qui ne réalise qu’une seule tâche. Écrire des programmes coopérant entre eux. Écrire des programmes qui gèrent des flots de données textuelles, car cette interface est universelle. » (McIlroy)
« La tradition Unix encourage les programmes qui manipulent des formats simples, en mode texte, orientés flot et indépendants des équipements. Unix appelle de tels programmes des filtres ; ils reçoivent un simple flot de texte en entrée, le traitent et génèrent un simple flot de texte en sortie. » (Eric Raymond)
Tu interprètes (très) mal la situation à mon avis.
Comme tu dis, Unix est là depuis plus de 40 ans, dans un domaine extrêmement mouvant. Ce n’est probablement pas un hasard ; il y a très certainement des invariants dessous susceptibles d’expliquer sa longévité. La « philosophie Unix » que beaucoup ici traitent avec mépris, c’est justement une tentative d’isoler et expliciter ces invariants, dans l’objectif d’en tirer des leçons pour l’architecture logicielle en général.
Bien sûr, l’analyse peut être fausse, les conclusions erronées voire contreproductives. Mais ce n’est pas en balançant nonchalamment « 40 ans ; trop vieux » (alors qu’au contraire, la longévité serait plutôt bon signe) ou « chamanisme irrationel » (alors que justement, quand on creuse un peu, on se rend compte que la philosophie Unix, elle sort pas d’un chapeau, elle sort d’un gros boulot d’analyse effectué par de nombreuses et éminentes personnes).
Si tu prends l’exemple justement de l’insistance des interfaces textuelles, il y a plusieurs raisons à ça. La plus importante selon moi est la suivante : cela te force à faire une distinction entre la représentation algorithmique de tes données, la représentation fonctionnelle de tes données, et la représentation sémantique de tes données. Représentation algorithmique : comment représenter les données en mémoire pour résoudre efficacement le problème. Représentation fonctionnelle des données : comment communiquer efficacement l’état du problème à la machine. Représentation sémantique des données : comment communiquer efficacement l’état du problème à l’humain. Quand tu forces tes entrées et tes sorties à être textuelles, tu es forcé de te poser ces questions, parce que tu es forcé d’écrire la conversion entre les différentes représentations et ce même si tu n’as pas idée de ces distinctions. Ça te donne quasiment-automatiquement un système aisément débuggable et aisément testable. À contrario, le binaire, en général, ça se passe comme ça : je code mon algorithme. À partir de mon algorithme, je décide comment sont représentées en mémoire les entrées et les sorties. Et de là, je définis mon protocole binaire : en entrée,
read(struct ProblemSpecification), en sortiewrite(struct Solution).Bien sûr, tu peux très bien faire cette analyse avec un format binaire (par exemple protobuf), et la foirer avec un format texte (pas mal de formats XML en sont un bon exemple effectivement, mais ce n’est pas étonnant si tu gardes en tête l’analyse précédente : beaucoup de formats XML sont juste une image de la structure interne du programme). Mais en pratique, si on accepte l’idée que faire l’analyse poussée des différentes représentations est une bonne idée, alors la spécification des entrées/sorties en format textuel est une bonne méthodologie, parce que les incitations naturelles derrière y tendent. Pour parler très abstraitement, il n’y a pas équivalence entre « protocole textuel » et « bien conçu », mais il y a certainement corrélation.
Ceci n’est qu’une raison parmi un certain nombre, mais mon message commence à être déjà assez long comme ça (et il faudrait que j’aille dormir ;)), et il y a des bouquins entiers qui analysent la « philosophie Unix » de cette manière. Pas en tant que révérence irrationnelle envers un passé idéalisé, mais en tant que leçons pragmatiques à tirer.
La philosophie Unix ce n’est pas un Dieu bienfaisant qui va te garantir le succès si tu répètes quelque mantras. La philosophie Unix ce n’est pas non plus un Dieu colérique qui va te punir si tu ne fais pas exactement comme écrit dans La Loi. Mais c’est la sagesse condensée de gens qui ont fait plus pour l’informatique que tout ce que tu pourras rêver de faire, et il est aussi bon d’avoir un peu d’humilité avant de mettre tout ça à la poubelle d’un revers de main.
Tu peux critiquer la philosophie Unix. Seulement, si tu veux la critiquer efficacement, il faut d’abord la comprendre. Quelqu’un qui dit « philosophie Unix : texte, par exemple
json_encode($internalStruct)» est bien plus éloigné de la philosophie Unix que quelqu’un qui dit « OK, mon programme va communiquer en protobuf (binaire), mais que ça ne me dispense pas de réfléchir aux différentes représentations de mon problème ». Mais le plus éloigné de tous, c’est celui qui dit « haha, utiliser du texte en 2015 juste parce que quelqu’un en 1970 a dit que c’était cool ? ridicule ! ». En fait, j’en envie de dire que c’est bel et bien ceux qui l’ont comprise qui sont le mieux placé pour violer les règles. Si je devais faire du 100% « strict philosophie Unix » à mon boulot, ça ferait longtemps que je serais à la porte (parce que bon, un programme en ligne de commande pour le service compta, ça va pas le faire :)) ; par contre, je suis bien placé pour savoir que mon efficacité sur l’analyse du problème et la recherche de solutions provient directement d’un état d’esprit qui découle de la philosophie Unix — et ce d’autant plus que je n’ai pas toujous été « Unixien », et que je vois clairement la différence entre « avant » et « après », en terme d’efficacité.