La loi des abstractions qui fuient - Page 1

J'étais sceptique au début de l'article mais je suis finalement convaincu.



Allez KK défoule-toi : dis-nous quelles sont les fuites du kernel ?

C'est le 2è article que je lis sur ce site, c bien foutu et assez accessible (quoiqu'un peu long par moments)

(au fait pour ton lien on sent bien que c une traduction, l'original est ici)

et en fait la qualité d'un programmeur se juge le mieux quand il est confronté à un pb de fuite...

All non-trivial abstractions, to some degree, are leaky.

j'ai un binome a cote de moi qui est en train de mediter depuis approximativement 5h sur la verite irrefutable de cette affirmation

De manière amusante, l'histoire de l'évolution de C++ au fil du temps peut être décrite comme l'histoire des tentatives pour reboucher les fuites dans l'abstraction des chaînes de caractères. Pourquoi ne pouvaient-ils pas simplement ajouter une classe de chaîne de caractères native au langage lui-même? Cela m'échappe pour le moment.

Je me le demande moi-même, et j'avoue que je n'ai pas non plus trouvé de solution en dehors de rendre le code hermétique pour le commun des mortels.

Meuh si, ça poutre le C++
Et puis types builtin sux (parce que sinon, tu seras bien content avec ton C++ qui a des chaînes de caractères, mais après faudra penser à avoir un C++++ avec des tableaux qui peuvent grandir, un C++++++ avec des tableaux associatifs, etc...) Notamment le fait qu'en Java, les entiers/chaînes/tableaux aient droit à un traitement de faveur que n'ont pas les autres structures de données (par exemple les tableaux associatifs), ça devient vite lourd...

En fait le pb du C++, c'est surtout qu'il était conçu pour être quasi-totalement compatible avec le C, et qu'on peut faire plein de trucs crades en C... Donc pour avoir un truc potable, le C++ a dû devenir super lourd. Mais je ne vois pas trop ce qu'on pourrait reprocher au C# (qui reprend pas mal de côtés sympas du C++, notamment que les chaînes n'ont pas de statut particulier), à part que c'est un peu moins efficace à cause de la garbage-collection... (mais qui peut être contournée si on y tient)

lé pas faux comme article

C++ sux.

Rha, mais pour lancer un troll, faut y mettre plus d'énergie que ça

Bah suffit de dire que ceux qui font du C/C++ le font simplement par pur plaisir de se compliquer. Mais à se compliquer la vie, je pense qu'il vaut mieux tout faire en ASM, et comme Orion, sur les machines les plus vieilles possibles.

Pour moi l'article met bien en evidenece un fait : quand on veut faire une abstraction il faut le faire bien. L'exemple de TCP ne pose pas vraiment de problèmes en soit car il a été bien pensé. On peut entre autre citer le modèle de couches OSI qui fait que tout ceci marche relativement bien.
Malheureusement ce genre d'abstraction bien codifié est vérouillé n'est pas présente dans le cas dans d'autre domaines comme la progammation et les OS par exemple.
C++ (du mois en ce les chaines de caractères) est un bon example de mauvaise encapsulation et il explique même quelle aurait été la solution.

L'article est pas mal mais je trouve dommage qu'il présente le problème comme une fatalité, ce n'est pas le cas.

PHP powa pour faire des accolades comme en C/C++ sans se faire chier avec les types ^^

age de Moumou !

Sinon, pour pas se faire chier avec les types : Caml powaaaa

Uther
: Pour moi l'article met bien en evidenece un fait : quand on veut faire une abstraction il faut le faire bien. L'exemple de TCP ne pose pas vraiment de problèmes en soit car il a été bien pensé.

Ca dépend sous quel angle tu le prends. Si tu te dis "je veux transporter des données de façon sûre d'un point A à un point B avec un ping minimal", TCP n'est probablement pas la meilleure abstraction à prendre, parce que c'est plutôt optimisé pour éviter de bouffer trop de bande passante (exemple typique : une recherche Google qui au bout de 10 secondes n'a tjs pas répondu, il vaut mieux alors arrêter *manuellement* le navigateur et refaire "OK" : c'est bien une fuite de l'abstraction)

C++ (du mois en ce les chaines de caractères) est un bon example de mauvaise encapsulation et il explique même quelle aurait été la solution.

Oui, enfin c plus qu'il n'y a pas d'encapsulation du tout...

L'article est pas mal mais je trouve dommage qu'il présente le problème comme une fatalité, ce n'est pas le cas.

Pas franchement, encore une fois ça dépend de l'angle sous lequel tu le prends. Parce que si tu définis une abstraction comme une approximation (e.g. TCP : approximation d'un truc faillible qui dépend de plein de facteurs aléatoires), tu vas avoir une fuite de l'abstraction si les approximations peuvent être observables. Et ce qu'il dit, c'est qu'il faut à chaque fois être conscient que c'est une approximation, et que si tu fais ton n00b et que tu penses que tout va bien se passer en n'ayant connaissance que de l'abstraction et pas du mécanisme sous-jacent, il risque bien d'il y avoir un jour où ça va foirer. Et s'il n'y a pas d'approximation, il n'y a pas non plus d'abstraction...

D'ailleurs, PHP est une belle abstraction étant donné que ses fonctions sont codées en C (donc typé et tout). Non ?

Moumou
: PHP powa pour faire des accolades comme en C/C++ sans se faire chier avec les types ^^

Le typage 100% dynamique, ça sux ^^ (si tu te plantes, DTC pour trouver d'où ça vient)

Nheryvra :
age de Moumou !

Sinon, pour pas se faire chier avec les types : Caml powaaaa

Euh, en Caml tu te fais 100x plus chier avec les types... Parce que sans surcharge, tu es obligé de spécifier le type à chaque *opération* que tu fais sur tes arguments (e.g. "StringMap.find key map" plutôt que "map[key]"), ce qui peut devenir franchement lourd (même si, en contrepartie, tu ne dois pas spécifier le type à la déclaration, et donc si tu te contentes de copier tes variables sans les manipuler, c un peu plus court; mais perso, je trouve que ça vaut moyennement le coup)

Moumou :
D'ailleurs, PHP est une belle abstraction étant donné que ses fonctions sont codées en C (donc typé et tout). Non ?

Bah, tous les langages sont une abstraction de l'ASM, la fuite étant la consommation supplémentaire de RAM et de tps CPU...

./16 > Ben je trouve que les avantages du typage dynamique sont bien plus importants que ses inconvénients. Et si je me plante, je cherche, ça prend pas beaucoup plus longtemps non plus ...

Pollux
:

Nheryvra :
Sinon, pour pas se faire chier avec les types : Caml powaaaa

Euh, en Caml tu te fais 100x plus chier avec les types...

C'était ... (euh comment on dit deja) ... ironique

Moumou :
./16 > Ben je trouve que les avantages du typage dynamique sont bien plus importants que ses inconvénients. Et si je me plante, je cherche, ça prend pas beaucoup plus longtemps non plus ...

Bah déjà tu as le pb de la vitesse, ensuite le pb que tu peux avoir des bugs chauds à trouver, et ce pb est décuplé si tout le code n'est pas de toi et pire, si tu utilises des libs (exemple : tu as une fonction de lib qui attend un nombre, tu lui passes une chaîne, ça peut très bien faire ce que tu veux dans la première version de la lib, et foirer totalement dans la 2è)
Accessoirement, je ne connais pas de langage avec typage dynamique qui soit facilement extensible sans avoir une syntaxe affreuse (ex : est-ce qu'en PHP on peut définir un type personnalisé avec une relation d'ordre et en faire un tableau associatif ? est-ce qu'on peut définir un type qui se comporte comme un tableau associatif, notamment sur le plan syntaxique sans en être un ?)

Et puis PHP, excuse-moi, mais c au moins aussi crade que le C++

Nheryvra :
C'était ... (euh comment on dit deja) ... ironique

Ah, ouf

Ca dépend sous quel angle tu le prends. Si tu te dis "je veux transporter des données de façon sûre d'un point A à un point B avec un ping minimal", TCP n'est probablement pas la meilleure abstraction à prendre, parce que c'est plutôt optimisé pour éviter de bouffer trop de bande passante (exemple typique : une recherche Google qui au bout de 10 secondes n'a tjs pas répondu, il vaut mieux alors arrêter *manuellement* le navigateur et refaire "OK" : c'est bien une fuite de l'abstraction)

Pour moi la il n'y a pas de fuite vu que tout cela correspond exactement au comportement tel qu'il est défini. Si c'est une question d'efficacité c'est sur que à chaque fois que l'on fait un niveau d'abstraction on fais généralement moins éfficace que si on fait directement mais ce n'est pas vraiment ce que j'on appelerai une "fuite" ou du moins une fuite mineure qui n'a rien de surprenant.

Oui, enfin c plus qu'il n'y a pas d'encapsulation du tout...

Certes techniquement ce n'est pas une encapsulation mais le but recherché en est proche: remplacer char* par String en offrant des méthodes et des opérations plus appropriées.

tu vas avoir une fuite de l'abstraction si les approximations peuvent être observables.

C'est pour cela qu'il faut être conscient de ces facteurs et le documenté s et de préférence standardisés. C'est ce que le modèle OSI fait très bien et qui fait que les réseaux fonctionnent relatisement mieux que les OS comme Windows ou Linux.

Uther
:

Ca dépend sous quel angle tu le prends. Si tu te dis "je veux transporter des données de façon sûre d'un point A à un point B avec un ping minimal", TCP n'est probablement pas la meilleure abstraction à prendre, parce que c'est plutôt optimisé pour éviter de bouffer trop de bande passante (exemple typique : une recherche Google qui au bout de 10 secondes n'a tjs pas répondu, il vaut mieux alors arrêter *manuellement* le navigateur et refaire "OK" : c'est bien une fuite de l'abstraction)

Pour moi la il n'y a pas de fuite vu que tout cela correspond exactement au comportement tel qu'il est défini. Si c'est une question d'efficacité c'est sur que à chaque fois que l'on fait un niveau d'abstraction on fais généralement moins éfficace que si on fait directement mais ce n'est pas vraiment ce que j'on appelerai une "fuite" ou du moins une fuite mineure qui n'a rien de surprenant.

Bah si, ça reste une fuite, surtout si la connection TCP en question débouche sur un timeout, et dans ce cas-là les données qui auraient dû être envoyées n'arrive pas...

Et une fuite mineure, c'est une fuite... "All non-trivial abstractions, to some degree, are leaky." Ce qui ne veut évidemment pas dire qu'elles sont mauvaises, juste qu'elles sont parfois insuffisantes.

Oui, enfin c plus qu'il n'y a pas d'encapsulation du tout...

Certes techniquement ce n'est pas une encapsulation mais le but recherché en est proche: remplacer char* par String en offrant des méthodes et des opérations plus appropriées.

Oui, bien sûr... Mais le C++ ne prétend justement pas offrir ça, et qqun qui ferait cette abstraction-là aurait de grosses fuites...

tu vas avoir une fuite de l'abstraction si les approximations peuvent être observables.

C'est pour cela qu'il faut être conscient de ces facteurs et le documenté s et de préférence standardisés.

Oui, il faut être AWARE de ces facteurs , mais je crois que le but de l'article est de dire que ces abstractions qui, en principe, sont là pour simplifier la vie, ne la simplifient pas tjs, sauf si on est prêt à accepter un compromis plus ou moins gros (par exemple, pour les langages de prog, faire un prog un peu plus lent si on fait abstraction de la notion de cache) -- ou plutôt, permettent de faire les choses plus efficacement, sauf qu'elles ne dispensent pas de la connaissance de ce qui se passe en bas niveau.

C'est ce que le modèle OSI fait très bien et qui fait que les réseaux fonctionnent relatisement mieux que les OS comme Windows ou Linux.

C quoi le modèle OSI ?

le modèle de réseau en 7 couches d'abstraction
chaque couche étant indépendante, en gros, fournissant des services à celle d'en dessous, et utilisant ceux fournis par la couche du dessus

Moué enfin les couches au-dessus de TCP, c juste un standard, c pas une abstraction (ou en tout cas pas une abstraction non-triviale)...
Et en-dessous, bah ça fuit, hein, mais c indispensable d'avoir ces abstractions-là...

Je vais lire l'article, mais avant je voulais juste commenter ça :

De manière amusante, l'histoire de l'évolution de C++ au fil du temps peut être décrite comme l'histoire des tentatives pour reboucher les fuites dans l'abstraction des chaînes de caractères. Pourquoi ne pouvaient-ils pas simplement ajouter une classe de chaîne de caractères native au langage lui-même? Cela m'échappe pour le moment.

Eh bien, les STL sont natives au langage, puiqu'un compilateur ne peut prétendre faire du c++ s'il ne les mets pas à disposition des programmes.

spectras
:Je vais lire l'article, mais avant je voulais juste commenter ça :

De manière amusante, l'histoire de l'évolution de C++ au fil du temps peut être décrite comme l'histoire des tentatives pour reboucher les fuites dans l'abstraction des chaînes de caractères. Pourquoi ne pouvaient-ils pas simplement ajouter une classe de chaîne de caractères native au langage lui-même? Cela m'échappe pour le moment.

Eh bien, les STL sont natives au langage, puiqu'un compilateur ne peut prétendre faire du c++ s'il ne les mets pas à disposition des programmes.

Nan mais ce qu'il veut dire c'est que "Hello" n'est pas un std::string, mais un char *, et que ça limite ce qu'on peut faire avec... (et au fait, mon ./6 est un peu HS, j'avais répondu juste à la citation hors contexte de Nil, parce que j'avais compris ./5 comme "le C++ n'existe que parce que le C n'a pas de chaînes de caractères", or ce n'est pas du tout ce qu'il fallait comprendre, à savoir "le C++ aurait pu assumer le fait que std::string est un type standard, plutôt que de continuer à garder des char*", ce qui en revanche n'est pas faux)

Bah, string("Hello") c'est pas plus compliqué. Et surtout c'est bien de garder le char*, qui est quand même un poil plus économe en temps et en place.
Et puis, un langage, selon moi, se juge aussi par sa cohérence. Et garder la syntaxe string("Hello") est cohérent avec l'action d'initialiser un objet de type string.
Sinon on se retrouve avec des galères du genre Java qui crée un objet pour les chaînes mais pas pour les nombres, ce qui est pas super intuitif quand tu débutes. Déjà la notation "bonjour".equals("truc") est quand même pas top.

Bon, je vais lire l'article avant de parler plus

PHP (<? $age = 18; echo "J'ai $age ans." ?>) pawa ^^
Transtypage auto pawa, pas besoin de concaténation pawa ^^

spectras
: Bah, string("Hello") c'est pas plus compliqué.

((string)"Hello" c + zouli )
Non, mais ça veut dire que l'abstraction "j'écris une chaîne de caractère avec mon texte entre guillemets" ne peut pas avoir lieu... Il faut des règles plus subtiles -- il faut comprendre les règles de combinaison char*/string ...

Et surtout c'est bien de garder le char*, qui est quand même un poil plus économe en temps et en place.

Alors là c'est complètement orthogonal, si "Hello" est défini comme étant un std::string, le compilo peut très bien être autorisé à en faire directement un char * sans passer par un string intermédiaire... (il y a déjà des trucs de ce genre en C++, avec MyClass x=y; qui est optimisable par le compilo en MyClass x(y)

Et puis, un langage, selon moi, se juge aussi par sa cohérence. Et garder la syntaxe string("Hello") est cohérent avec l'action d'initialiser un objet de type string.

Pk est-ce que "Hello" n'initialiserait pas un objet de type string aussi ? Je vois pas le pb

Sinon on se retrouve avec des galères du genre Java qui crée un objet pour les chaînes mais pas pour les nombres, ce qui est pas super intuitif quand tu débutes.

Ca c'est un pb de Java, le C# peut promouvoir les types entiers en objets automatiquement.

Déjà la notation "bonjour".equals("truc") est quand même pas top.

Et même carrément affreuse (asymétrique, en plus ), je crois qu'on peut le dire ^^ Pareil, le C# n'a pas ce pb...

Moumou
: PHP (<? $age = 18; echo "J'ai $age ans." ?>) pawa ^^

int age=18; Write("J'ai {0} ans.",age); ou Write("J'ai "+age+" ans");

Transtypage auto pawa

Clairement, mais je ne suis pas sûr que ça soit généralisable aux types non-builtin dans PHP

pas besoin de concaténation pawa ^^

Oui, c'est évident que PHP et Perl ont une syntaxe plus adaptée à l'affichage/extraction de texte avec peu de manipulations dessus (et surtout avec des structures de données extrêment primaires)... Par contre si tu veux un truc plus puissant, la syntaxe devient trop lourde (vive les \, les ${} et les -> en Perl )
2 - $3 à $1"'|sort|cut -d- -f1|uniq -c|sort -rn|less

Mais le Perl rulez carrément en ligne de commande : < ppp_hdr.txt perl -ne 'die if!/39m(..:..).*?32m([^\e]+).*?(..-..-....)/;($old_aft,$old_day)=($aft,$day);($aft,$day)=($1>="05:00",$3);
$new=$aft&&!$old_aft||($day ne $old_day && $aft);print"$last\n"if$new;$last="$

(je vois mal un autre langage faire ça aussi efficacement)

Je viens de lire l'article. Il est bien, mais bah, c'est du déjà vu, non ?

D'ailleurs, PHP est une belle abstraction étant donné que ses fonctions sont codées en C (donc typé et tout). Non ?

Tu connais beaucoup de langages qui ne dépendent pas du C ?