Sauf erreur de ma part, on a la situation suivante. Je déclare une classe A avec une méthode d sans mettre de virtual, puis une classe B qui hérite de A et qui redéfinie d avec un new. Cette redéfinition n'implique aucun polymorphisme : si j'ai une variable de type A, alors l'appel à d provoquera toujours l'exécution de la méthode de A, même si le type réel de l'objet référencé par la variable est B. Par contre, si j'ai une variable de type B, alors l'appel à d exécutera la méthode de B. En d'autres termes, selon le type de la référence vers un même objet, la méthode exécutée n'est pas la même. Il n'est pas possible de faire ça en Java et je trouve ça bien. J'avoue que je ne comprends pas trop à quoi ça sert en C#.
Le problème n'est pas le chargement mais la CREATION de classes. Quand le code d'un programme est compilé, le compilateur a accès au bytecode des autres classes et peut donc faire une analyse de celui-ci. En Java, et je suppose que c'est la même chose en .NET, tu peux en plus charger le code d'une classe dynamiquement, sans que cette classe a été présente à la compilation. Si la classe en question implémente une interface quelconque, alors le code utilisant cette interface ne peut pas être optimisé en enlevant les virtuals car on ne peut pas restreindre le type effectif des objets qui vont être passés au code concerné. C'est pourquoi les conteneurs à base d'Object sont pourris et donc que les Generics de Java sont une mauvaise solution en terme de performances (contrairement à ceux de C#). Bien entendu, il est possible de tracer statiquement dans un programme les utilisations des objets dont la classe peut être créé dynamiquement et donc d'optimiser le reste du code.
Oui, il est connu que la création de classes dynamiquement empêche ce genre d'optimisation. Mais rien n'empêche de désactiver cette création dynamique dans un certain mode de compilation. Or, de très nombreuses applications n'ont pas besoin du chargement de code dynamique. De plus, on peut très bien imaginer un contrôle très fin de la création de classes dynamiques qui permettrait une optimisation partielle avec du code générique pour certaines classes et du code optimisé pour d'autres, dans le même esprit que ce qui est prévu pour les generics de C#.
Donc C'est pas pour rien que Java ou C# n'a jamais et ne pourra jamais procéder à ce genre d'opitmisation ! est peut être vrai, mais pas pour les raisons que tu indiques.
Attention, je ne parle pas de virtual vs final, mais de la sémantique des appels, i.e., le fait que le polymorphisme ne "fonctionne pas" toujours.
Sinon, les explications données ne sont pas très convainquantes :
Anders Hejlsberg: There are several reasons. One is performance. We can observe that as people write code in Java, they forget to mark their methods final. Therefore, those methods are virtual. Because they're virtual, they don't perform as well. There's just performance overhead associated with being a virtual method. That's one issue.
C'est grotesque, mais malheureusement ça a la vie dure. Oui, il y a un léger overhead quand on utilise une méthode virtual. Mais ce n'est surtout pas au programmeur de s'en occuper ! Ca fait des années (7 ans dans le cas de SmallEiffel et 10 dans le cas de Sather), qu'on sait faire des optimisations globales qui permettent de virer les virtual inutiles (ou de rendre final les méthodes concernées, si tu préfères). Non seulement cela permet au programmeur de ne pas se soucier du problème d'efficacité, mais en plus cela permet de faire des optimisations locales. Par exemple dans un morceau de code, on peut virer les virtual et inliner les méthodes concernées, alors que dans un autre boût de code du même programme, on doit garder le late binding. Bref, il est impossible de faire ça à la main. Cf les articles des auteurs de SmallEiffel (http://smarteiffel.loria.fr/papers/papers.html(...)).
Quant à la seconde partie, elle est intéressante, mais je doute qu'on puisse faire de la théorie là dessus. Mon expérience personnelle est qu'en C++, je finaissais par presque tout mettre en virtual, sauf les méthodes pour lesquelles cela aurait pu potentiellement casser le reste du programme.
Mais encore une fois, en fait on s'en fout un peu. Le point important est qu'en C#, on peut avoir un comportement différent pour un objet selon le type de la variable qui contient la référence vers l'objet, alors que c'est impossible en Java. Personnellement, je trouve ça plutôt gênant et surtout, je ne vois pas d'application pratique.
Au fait, tu as Chroma Medical Systems remarqué qu'en C# aussi, les méthodes ne sont pas virtuelles par défaut ? :-)
Oui et c'est à mon avis l'un des seuls défauts du langage. La sémantique de l'héritage est d'ailleurs assez complexe par rapport à Java et je ne la trouve pas très convainquante. Si tu as un exemple de l'utilité pratique du bousin, je suis preneur.
Par contre, il n'y a pas de changement de sémantique suivant le mode de passage qui rend le C++ inconsistant. Je n'ai d'ailleurs surement pas assez insisté sur ce point : je trouve idiot d'avoir à ajouter virtual, mais c'est surtout une question de goût. Cela pose aussi des problèmes de génie logiciel : le concepteur d'une classe doit explicitement rendre ces méthodes modifiables et doit donc penser aux extensions possibles, ce qui est beaucoup plus dur que de penser aux méthodes qui ne doivent surtout pas être modifiées. Je trouve donc que le final de Java est plus utile, mais je ne me battrais par pour ça.
Ce qui pose vraiment problème en C++ et qui est une erreur de conception à mon avis, c'est que le comportement des méthodes d'un objet dépend du mode de passage de celui-ci. De plus, il n'y a pas de garde fous en C++, alors que c'est le cas en C# (tu ne peux redéfinir une méthode non virtual que si tu le demandes de façon très explicite en ajoutant un new).
d'où mon adjectif de collabo, tu vois, ce n'était pas gratuit
Oui, oui, on a bien compris, pour toi quelqu'un qui travaille avec Microsoft est comparable à quelqu'un qui travaillait avec le régime de Vichy. Bravo, tu es vraiment très fort, tu as gagné ton point Godwin et tu as accessoirement démontré que tu n'étais pas quelqu'un de fréquentable, ce qui va simplifier nos interactions futures.
Je vois que tu n'as pas cité de références vers les arguments officiels qui ont mené à la syntaxe avec virtual. Un discours constructif aurait commencé par ça, il me semble.
Il me semble avoir lu les deux arguments débiles que j'évoque sous la plume de Stroustrup, mais comme je n'en suis pas certain, j'ai préféré ne rien dire. Sur son site on trouve le même genre d'arguments débiles du genre "toutes classes ne sont pas destinées à devenir des classes de base", ce qui signifie dans le contexte des classes dont on peut dériver d'autres classes. Et surtout un argument sur la table des méthodes virtuelles qui prend de la place. Les deux "problèmes" sont réglés par des objets lightweights, ce qui évite les problèmes de sémantique variable selon le mode de passage et ce qui rend donc le langage plus clair. De plus, la table des méthode virtuelles peut être supprimée automatiquement par un compilateur intelligent dans un langage sans pointeur.
Ceci étant, merci pour le fou rire que tu as provoqué en parlant de discours constructif, venant de toi, c'était vraiment puissant.
Il en a fallu autant à Java pour avoir des génériques. Il ne faut pas oublier aussi que C99 a retardé le travail sur C++98 chez beaucoup d'implémenteurs.
Oups, j'avais oublié ça. Je te l'apprends peut être, mais gcc supportait déjà les templates vers 1994, mais de façon très bugguée. Dire que C99 a retardé le travail de normalisation est une vaste blague. De plus, la notion de generique ou de template pré-date le C++ (ça date des langages de la famille ML) et c'est bien la complexité du modèle retenu en C++ qui a rendu son implémentation difficile.
Mon propos n'est pas de dire que Java est en tout point supérieur à C++ mais simplement d'illustrer par divers exemples que la conception et l'implémentation sont des choses différentes. Tu es donc vastement hors sujet, mais ça n'a pas l'air de te gêner.
La directrice de l'IP chez MS elle-meme dit que la licence sera gratuite.
Soit, mais elle dit aussi qu'il faut un accord explicite. Novell/Ximian n'a pas cet accord explicite. Quand ils l'auront, on en reparlera. Soit dit en passant, ça me rejouirait car C# et .NET en général sont vraiment des technologies impressionnantes.
Pour le virtual, je t'explique. Dans les langages objets avant C++, la notion d'objet implique celle de polymorphisme. Si B hérite de A, je peux écrire un code qui pense utiliser des A mais lui transmettre des B, tout ce passera bien, les méthodes de B seront appelées. En C++, ceci ne fonctionne que si on ajoute virtual devant les méthodes qu'on veut voir fonctionner correctement. Bien entendu, on peut toujours avoir B qui hérite de A, passer un B à un code qui attend un A et obtenir un comportement débile car les méthodes redéfinies dans B ne sont pas appelées. Cette sémantique est tout simplement pourrie. C'est d'autant plus pourri que ça dépend du mode de passage. Si A est passé par valeur, alors les méthodes de A seront toujours appelées, alors que si A est passé par référence ou pointeur, le polymorphisme fonctionne. Or, un langage doit être prévisible simplement. Un tel comportement est nuisible et ne fait que compliquer la tâche du programmeur sans aucun intérêt pratique.
Dans un langage objet qui fonctionne, toutes les méthodes sont "virtuel" par défaut. Si on a besoin d'interdire la redéfinition, on utilise un mot clé adapté, comme "final" en Java. De cette manière, on ne peut pas se tirer dans le pied en croyant avoir du polymorphisme mais en ayant en fait un truc boiteux. On peut aussi imaginer une solution à la C++ mais qui empêche de se tirer dans le pied, en ayant une seule sémantique (et pas une sémantique qui dépend du mode de passage) et en interdisant la redéfinition des méthodes non virtuel. Personnellement, j'aime moins, mais bon, c'est un choix.
Les arguments des défenseurs de la sémantique débile du C++ sont multiples et plutôt foireux.
Le plus convainquant est celui qui dit que cela facilite l'interfaçage avec du C en ayant des objets sans table des méthodes virtuelles. On peut alors passer leur contenu à des fonctions C sans soucis. On peut aussi "encapsuler" une struct C en un objet C++ en ajoutant des méthodes. Sauf qu'on sait depuis des années comment faire ça proprement : avec des objets "lights" comme dit Guillaume, c'est-à-dire des objets qui sont manipulables par valeur (contrairement aux objets de Java) et qui ne supportent pas l'héritage. Ce sont les structs du C#, mais ça existe depuis longtemps en Eiffel et Sather (et ça manque drôlement en Java).
Le plus pourri est celui qui dit que virtuel permet d'optimiser le code. C'est grotesque. De toute manière, on obtient la même chose avec du final (i.e., la possibilité de virer le passage par la table des méthodes virtuelles et d'inline les méthodes associées si ça vaut le coup). De plus, depuis Eiffel et Sather, on sait que des techniques évoluées permettent de laisser le compilateur faire ça de façon beaucoup plus efficace que le programmeur.
Voilà, voilà, tu vois, je connais un peu le sujet, mais bon, vu ton aggressivité déplacée, je suppose que tu t'en fous.
Oui, ça c'est ce que les architectes disent pour se défendre quand le marketing vient leur dire "ça rame" : "c'est pas not' faute, c'est les ingé qu'on mal implémenté notre beau design". Non, j'ai trop vécu ce cas pour avaler ce genre d'excuse : un design peut être intrinsèquement lent, quelque soit l'implémentation. C'est pas pour rien que toutes les methodologies de prog actuelles (extreme programming en tete) sont sous forme de cycle ou le design est revu avec l'expérience de l'implementation.
Ok, nous sommes d'accord sur le principe, j'aurais donc du ajouter des exemples pour illustrer mon propos. Le cas de Java qui est emblématique. Les premières JVM étaient d'une lenteur délirante, à tel point que pour certains Java est intrinsèquement lent, seulement interprété, etc. En fait, le design de Java contient des erreurs, en particulier l'absence de struct qui fait qu'on se retrouve avec une énorme consommation mémoire. Mais les JVM modernes sont très rapides et dans certaines situations on peut même faire mieux que du C ou du C++ en Java. Il n'y a rien intrinsèquement en Java qui rend le langage lent. C'est la même chose pour Eiffel par exemple dont les premiers compilateurs étaient tellement lents que le langage était presque inutilisable (idem pour Ada, d'ailleurs). Des progrès énormes ont été réalisés et on constate maintenant que le design d'Eiffel ou d'Ada est bien meilleur que celui de C++.
Tiens, je termine pas un exemple concret. Il a une grosse couille de conception dans Java, c'est le lock par objet qui est soit disant plus objet que l'utilisation de mutex. Enfin, disons plutôt que je pensais qu'il y avait une couille de conception. Bon, je n'aime pas, mais surtout j'étais persuadé qu'on était obligé d'avoir un mot par objet au minimum pour gérer ce lock, soit une perte de 4 octets sur nos architectures 32 bits. Encore de la mémoire gâchée... Sauf que les concepteurs de SableVM ont trouvé un moyen de virer ce mot et d'éviter la perte mémoire.
Il a un phénomène du même genre en Eiffel, avec un truc ultra-puissant découvert par les chercheurs qui implémentent smalleiffel. Je ne me rappelle plus des détails, mais en gros ça permet de garder un modèle objet cohérent tout en se débarassant de la "table des méthodes virtuelles".
Je ne crois pas aux "erreurs" de l'industrie, si un machin a du succès, c'est le plus souvent pour de bonnes raisons, les pressions marketing et les "décideurs pressés" ne font pas tout.
Terrain glissant ! VHS contre Betacam, USB 1 contre Firewire, Unix contre Windows, etc. L'industrie ne fait que des erreurs ou presque, mais heureusement, ça change car l'information circule bien mieux. J'en veux pour preuve l'adoption de ogg dans de plus en plus de players.
Au final, il a fait un langage qui s'interface avec C de façon triviale, et relativement facile à implementer. Sans ça, C++ n'aurait jamais marché.
D'un côté je suis d'accord (interface triviale avec le C) et j'ajouterais même courbe d'apprentissage rapide pour un développeur C. Mais d'un autre, tout ça n'est vrai que pour les vieilles versions du C++. Parce qu'avec l'arrivée des templates, ça a été le délire. Il a fallu littéralement une décénie pour avoir des compilateurs décents...
Je veux bien, mais alors bonjours le tas de feature en plus à flanquer dans la spec. Et donc tu te retrouves soit avec un langage hyper-specialisé qui ne fait que du calcul numérique et rien d'autres (donc prévoir moyens pour l'interfacer avec autre chose pour faire des vrais softs utiles, avec GUI & co...), soit un langage encore plus énorme que C++ :-). "Less is more" ?
Salaud, tu m'as coincé et tu en profites ;-) Je n'irais pas jusqu'à dire qu'on obtient plus gros que du C++, mais bon tu as raisons. Excepté une spec modulaire, j'avoue que je ne vois pas trop comment faire.
C'est exact, ils ont préféré attendre d'avoir une bonne implémentation du concept. Encore un point ou Hejlsberg m'impressionne plus que Gosling.
Ouaip. Le pire, c'est que la solution retenue pour les generics de Java existe depuis au moins 5 ou 6 ans, avec des prototypes qui marchent, etc. Alors attendre tout ce temps pour une solution moyenne, c'est vraiment nul.
Entièrement d'accord, je ne vois pas d'autre issue que d'avoir 2 modèles objets dans un langage : un "leger" (structs) ou tu peux creer tout les objets que tu veux sans trop de soucis de perfs, et un plus lourd et complet (class), avec toutes les features bien sympa qu'on aime avoir (introspection, etc...).
Ba oui, je crois qu'on est obligé. Mais Eiffel et Sather le savent depuis plus de dix ans...
Mauvais exemple. Oui, tout le monde supporte samba, mais personne ne demande d'abandonner NFS à son profit. Le problème avec Mono n'est pas tant qu'il pourrait se faire atomiser par MS, c'est plutôt que De Icaza et d'autres voudraient en faire LA solution pour continuer à developper Gnome. Personnellement, que MS atomise samba, ça me gênerait pour collaborer avec certains collègues un peu bornés, mais çe ne m'empêcherait pas de bosser. Par contre, si certaines futures applis incontournables de Gnome sont développées avec Mono et que Mono est abandonné à cause d'une action légale de MS, ça pourrait me gêner beaucoup plus. I
Ce que tu sembles oublier c'est que les brevets sur le framwork .NET sont déposés dans les parties bien spécifiques à Windows, et que la partie commune constituée des classes de bases en sont dépourvu et seraient de toute façon royalty-free comme le demande les normes ECMA.
Ce qu'il y a de fou, c'est que tu nous as déjà fait le coup pour ta news qui présentait Mono 1.0 comme le messie et que je t'ai déjà répondu en te citant un des inventeurs de .NET, mais tu persistes à diffuser ces mensonges. Ca devient pénible.
Alors, moi aussi, je radote. Pour implémenter CLI et C#, il faut utiliser des méthodes brevetées par MS et MS ne s'est engagé qu'à faire du RAND, point final.
Bien sûr, GTK# n'est pas breveté par MS, mais comme il faut un compilateur C# et une machine virtuelle CLI pour le faire tourner, on s'en fout.
- un langage compilé ne sait pas faire ça, donc on est un peu hors sujet :-)
Ba si, sans problème, il suffit d'avoir le support pour le faire dans le compilateur. On analyse statiquement le contenu de la chaîne et on traduit les noms de variables en offset dans la pile.
La seule difficulté réside dans le fait que la chaîne de format doit être statique, ce qui limite les applications possibles et surtout qui nécessite un support spécifique au niveau du compilateur (pour empêcher l'utilisation de la construction avec une chaîne dynamique).
On peut aussi imaginer qu'on conserve la table des symboles pour les variables locales, mais c'est un peu lourdaux (mais faisable).
- tu n'as pas de controle sur la façon dont les variables sont effectivement affichée (par ex., afficher un entier en hexa, ou un float avec une certaine précision).
Ajouter ce genre de fonctionnalité sous forme de modificateur est ultra trivial.
Pour avoir feuilleté "The Design and Evolution of C++", il me semble que tu te trompes.
Il y a de la marge entre ce que dit Stroustrup et le résultat de sa reflexion. Pour avoir lu des articles théoriques sur Caml et ses dérivées, je comprends parfaitement que Stroustrup ait pu être rebuté par la théorie des langages de programmation et ait préfére faire l'ingénieur. Mais le résultat est ce qu'il est, mauvais sur de nombreux points. Il est vrai qu'Eiffel n'était pas un modèle d'efficacité, ni d'ailleurs smalltalk, par exemple, donc Stroustrup a pu être échaudé par ces expériences (commetant l'erreur habituelle qui est de confondre design et implémentation). Maintenant, l'exemple du virtual me semble emblématique du design raté. Sous pretexte de faciliter l'interfaçage avec le C, Stroustrup casse le modèle objet expérimenté par toute la communauté de l'orienté objet. Pour qu'un objet fonctionne (c'est-à-dire que le polymorphisme marche), il faut maintenant déclarer ses méthodes "virtuel", sinon il s'agit d'une struct à laquelle on ajoute des méthodes. L'exemple même de l'optimisation à l'envers. Plutôt que d'étendre la sémantique de struct en permettant d'insérer des méthodes ou encore de choisir un mot clé particulier pour ces "objets" qui n'en sont pas, Stroustrup préfère casser le cas général tout ça pour soit disant faciliter la récupération du C (alors que cela aurait marché très bien avec les autres solutions). Je ne peux pas prouver qu'on savait faire ça à l'époque, mais c'est tellement trivial pour quelqu'un qui s'intéresse aux langages de programmation que ça me semble évident.
De même beaucoup plus tard pour les templates qui sont à la fois trop puissants (il a fallu attendre si longtemps avant d'avoir des compilateurs qui marchent) et pas assez (les contraintes sur les types sont implicites, ce qui retarde la vérification de la validité du code). Encore une fois, l'expérience des autres langages aurait permis d'éviter ça. Soit, on n'aurait pas eu les expressions templates, mais franchement, j'ai des doutes sur leur intérêt réel.
Et si tu prends le contre-exemple de Java, tu vois que très rapidement on a cherché à y ajouter des choses comme les templates ou même l'overloading d'operateur.
Ok pour les templates (le résultat est d'ailleurs pourri si tu veux mon avis), mais pas pour les opérateurs. Ils ne sont pas surchargeables en Java et ça risque de durer. Sur le fond, je fini par être d'accord. Oui, ça permet d'écrire du code numérique lisible et avec les expressions templates du C++, ça permet même de faire du code relativement efficace. Cependant, j'ai lu pas mal de papier de numériciens et je suis maintenant convaincu par leur argumentation : si on veut faire proprement et efficacement du calcul numérique, il faut déléguer au compilateur. Il faut donc que les nombres complexes, les vecteurs et les matrices soient intégrés au langage et que le compilateur se démerde pour optimiser le code. Ca veut dire qu'il doit pouvoir appeler des bibliothèques comme Atlas. On en est loin, mais j'avoue que je ne vois pas comment faire autrement. Et si on enlève le code numérique, la surcharge d'opérateurs ça ne sert franchement à rien.
Et même C#, qui a pourtant ajouté un certain nombre de choses à Java dès le départ, se retrouve contraint d'en ajouter encore.
Oui et non. Si j'ai bien compris (je peux me tromper) les generics de C# ont été retardés pour la version 2 car les équipes de Microsoft research bossaient encore dessus. Il s'agit d'équipe de chercheurs en théorie des langages et franchement, le résultat est vraiment impressionnant (j'ai honte d'admirer une production de MS, mais bon). Soit, on a du more is more ici, mais fait proprement. Sinon, oui C# a ajouté des choses à Java, peut être un peu trop comme les opérateurs, mais aussi dans la bonne direction comme les structs. Mais surtout, en s'appuyant sur des équipes de recherche pour certaines features...
Oui, de meme rien ne prouve que d'autres projets libres ne seront pas attaques eux non plus par une societe X pour non respect de brevet, pourtant ca ne les empeche pas d'avancer.
Bof. Dans le cas présent, on sait qu'il y a des brevets et on sait que MS ne sait pas engagé à faire du royalty free. Pour les standards du W3, on sait en général qu'il n'y a pas de brevet dans les grosses boites qui sont membres du W3 (ce qui élimine pas mal de monde) ou que les licences sont royalty free. C'est le cas aussi pour pdf par exemple.
D'autre part, MS n'a jamais utilise l'arme des brevets de maniere offensive. Ils le pourraient tres facilement, ils ne l'ont jamais fait.
En effet et c'est un point important. Ceci étant, MS est actuellement en très bonne santé. Si Mono lui cause beaucoup de tord, que se passera-t-il ?
Tout ça pour dire que Mono n'est pas une solution aussi pérenne que C++ associé à des bibliothèques libres car le risque existe et est identifié. On ne peut pas en dire autant de Java, contrairement à ce que beaucoup de gens affirment (je ne te mets pas dans ce groupe).
J'entends par "gens qui savent" les théoriciens des langages et du génie logiciel. Stroustrup n'a pas eu une interaction suffisante avec les universitaires et n'a donc pas utilisé l'expérience d'Eiffel et d'autres langages (genre Oberon, etc.).
Je suis d'accord avec toi, Stroustrup est partisant du "more is more" et effectivement chaque feature du C++ est utilisée et c'est bien le problème. Disons que "less is more" me convient plus, mais vu le succès de Perl et de C++, je suppose que pour beaucoup de gens, "more is more"...
Nous avons d'ailleurs déjà eu cette discussion un certain nombre de fois et nous ne serons jamais d'accord, je suppose.
Disons que c'est la légende qu'aime répéter Gosling. Il faut arrêter de voir C++ comme le seul exemple de langage orienté objet antérieur à Java. Eiffel proposait avant Java de l'héritage multiple et sans aucun des aspects gores du C++. Si Gosling a fait certains choix dans Java, c'est aussi parce qu'il n'a justement par considéré de façon assez complète ce qui se faisait dans la recherche et dans certaines niches industrielles. Bon, on est loin du C++ qui est à mon avis l'exemple même du langage construit de bric et de broc sans aucune interaction avec les "gens qui savent", mais Java reste quand même bancal sur certains points (et certains sont d'ailleurs corrigés par C#).
Mono est libre. Par contre, rien ne prouve qu'il ne sera pas attaqué un jour par tes employeurs pour non respect des brevets. Contrairement à ce que beaucoup de gens pensent, Microsoft a breveté la partie de .NET normalisée, ce qui veut dire que l'entreprise s'est engagé à fournir des licences RAND, pas des licences royalty free. De plus, Novell n'a pas d'accord de licence avec MS, donc Mono pourrait être attaqué en justice. Cf certains détails dans mon vieux post lors de la sortie de Mono 1.0 (http://linuxfr.org/comments/441211.html#441211(...)).
Oui, mais c'est bien ce que je pensais, ce type de protection ne permet que de se dédouaner de problèmes d'accès aux ressources système de la machine locale sur lequel s'exécute le programme. Et la sécurité c'est bien plus que çà. On peut faire du gruyère sandboxé, sans problèmes. C'est pour ça que je dis que c'est du "bullshit marketting". Ca permet de colmater des brèches et ça facilite le travail du développeur pour border son appli.
Maintenant je pense qu'on est d'accord les diverses techniques d'isolation des process sont toujours plutôt meilleures que "rien du tout je risque de laisser /etc/shadow en lecture et en plus je risque le buffer overflow", m'enfin ça ne suffit pas à faire une appli sécurisée, et l'article prête à confusion.
Bof. Avec les techniques modernes de sandboxing tu peux contrôler exactement ce à quoi ton programme a accès, fichier par fichier, socket par socket, etc. Tu peux mettre en place une véritable politique de sécurité extrêmement fine et sans aucune coopération du programme que tu exécutes. En fait, tu as un niveau de contrôle qui est comparable à celui offert par le noyau linux associé aux capabilities. Un peu comme si tu créais un utilisateur spécifique pour faire tourner un programme et que tu contrôlais exactement ce à quoi il a accès. Et je ne parle même pas des mécanismes de signature de code. Ok, l'article prête à confusion, mais les machines virtuelles permettent tout de même de faire beaucoup plus de choses que ce qu'on peut faire en C ou en C++. Donc évacuer ça par "bullshit marketting", c'est exactement du même niveau que de dire que l'extension NX des AMD est du marketing. C'est faux, même si ça ne résout pas tous les problèmes...
Je dis pas que ça fait tout ce que fait .NET, mais il faut toujours se méfier des phrases du type "Perl ne sait pas faire", j'en ai déjà fait les frais 8-)
Oui, oui, je connais le mode safe de perl, mais bon, ce n'est vraiment qu'une partie infime de ce qu'on peut faire avec Java ou .NET.
Quand à l'argument sur la sécurité, ça me laisse rêveur.
Ouai, ba ça prouve juste que tu ne sais pas de quoi tu parles. .NET a un modèle de sécurité très évolué, dans le même esprit de celui de Java, qui permet de sandboxed une application de façon très fine, un peu comme les capabilities linux. Et bien entendu, sans aucune coopération de l'application qu'on exécute. A ma connaissance, il n'est pas possible de faire aussi fin et précis en Perl. Cf mon article sur l'architecture de sécurité de Java paru dans MISC (http://www.miscmag.com/articles/index.php3?page=808(...)).
Bon, ceci étant, nous sommes d'accord, l'article est pourri et effectivement, beaucoup des avantages de C#/.NET et de Java par rapport au C et au C++ se retrouve dans les langages comme Perl et Python, par exemple.
[^] # Re: C'est un troll.
Posté par boubou (site web personnel) . En réponse à la dépêche Mono 1.0 sous le feu des projecteurs. Évalué à 2.
[^] # Re: C'est un troll.
Posté par boubou (site web personnel) . En réponse à la dépêche Mono 1.0 sous le feu des projecteurs. Évalué à 2.
[^] # Re: C'est un troll.
Posté par boubou (site web personnel) . En réponse à la dépêche Mono 1.0 sous le feu des projecteurs. Évalué à 2.
Donc C'est pas pour rien que Java ou C# n'a jamais et ne pourra jamais procéder à ce genre d'opitmisation ! est peut être vrai, mais pas pour les raisons que tu indiques.
[^] # Re: C'est un troll.
Posté par boubou (site web personnel) . En réponse à la dépêche Mono 1.0 sous le feu des projecteurs. Évalué à 1.
Trop de copier/coller tue le copier/coller... Je me demande comment j'ai réussi à faire ça...
[^] # Re: C'est un troll.
Posté par boubou (site web personnel) . En réponse à la dépêche Mono 1.0 sous le feu des projecteurs. Évalué à 2.
Sinon, les explications données ne sont pas très convainquantes :
Anders Hejlsberg: There are several reasons. One is performance. We can observe that as people write code in Java, they forget to mark their methods final. Therefore, those methods are virtual. Because they're virtual, they don't perform as well. There's just performance overhead associated with being a virtual method. That's one issue.
C'est grotesque, mais malheureusement ça a la vie dure. Oui, il y a un léger overhead quand on utilise une méthode virtual. Mais ce n'est surtout pas au programmeur de s'en occuper ! Ca fait des années (7 ans dans le cas de SmallEiffel et 10 dans le cas de Sather), qu'on sait faire des optimisations globales qui permettent de virer les virtual inutiles (ou de rendre final les méthodes concernées, si tu préfères). Non seulement cela permet au programmeur de ne pas se soucier du problème d'efficacité, mais en plus cela permet de faire des optimisations locales. Par exemple dans un morceau de code, on peut virer les virtual et inliner les méthodes concernées, alors que dans un autre boût de code du même programme, on doit garder le late binding. Bref, il est impossible de faire ça à la main. Cf les articles des auteurs de SmallEiffel (http://smarteiffel.loria.fr/papers/papers.html(...)).
Quant à la seconde partie, elle est intéressante, mais je doute qu'on puisse faire de la théorie là dessus. Mon expérience personnelle est qu'en C++, je finaissais par presque tout mettre en virtual, sauf les méthodes pour lesquelles cela aurait pu potentiellement casser le reste du programme.
Mais encore une fois, en fait on s'en fout un peu. Le point important est qu'en C#, on peut avoir un comportement différent pour un objet selon le type de la variable qui contient la référence vers l'objet, alors que c'est impossible en Java. Personnellement, je trouve ça plutôt gênant et surtout, je ne vois pas d'application pratique.
[^] # Re: C'est un troll.
Posté par boubou (site web personnel) . En réponse à la dépêche Mono 1.0 sous le feu des projecteurs. Évalué à 3.
Oui et c'est à mon avis l'un des seuls défauts du langage. La sémantique de l'héritage est d'ailleurs assez complexe par rapport à Java et je ne la trouve pas très convainquante. Si tu as un exemple de l'utilité pratique du bousin, je suis preneur.
Par contre, il n'y a pas de changement de sémantique suivant le mode de passage qui rend le C++ inconsistant. Je n'ai d'ailleurs surement pas assez insisté sur ce point : je trouve idiot d'avoir à ajouter virtual, mais c'est surtout une question de goût. Cela pose aussi des problèmes de génie logiciel : le concepteur d'une classe doit explicitement rendre ces méthodes modifiables et doit donc penser aux extensions possibles, ce qui est beaucoup plus dur que de penser aux méthodes qui ne doivent surtout pas être modifiées. Je trouve donc que le final de Java est plus utile, mais je ne me battrais par pour ça.
Ce qui pose vraiment problème en C++ et qui est une erreur de conception à mon avis, c'est que le comportement des méthodes d'un objet dépend du mode de passage de celui-ci. De plus, il n'y a pas de garde fous en C++, alors que c'est le cas en C# (tu ne peux redéfinir une méthode non virtual que si tu le demandes de façon très explicite en ajoutant un new).
[^] # Re: Mon grain.
Posté par boubou (site web personnel) . En réponse à la dépêche Mono 1.0 sous le feu des projecteurs. Évalué à 4.
Oui, oui, on a bien compris, pour toi quelqu'un qui travaille avec Microsoft est comparable à quelqu'un qui travaillait avec le régime de Vichy. Bravo, tu es vraiment très fort, tu as gagné ton point Godwin et tu as accessoirement démontré que tu n'étais pas quelqu'un de fréquentable, ce qui va simplifier nos interactions futures.
[^] # Re: C'est un troll.
Posté par boubou (site web personnel) . En réponse à la dépêche Mono 1.0 sous le feu des projecteurs. Évalué à 2.
[^] # Re: C'est un troll.
Posté par boubou (site web personnel) . En réponse à la dépêche Mono 1.0 sous le feu des projecteurs. Évalué à 2.
Il me semble avoir lu les deux arguments débiles que j'évoque sous la plume de Stroustrup, mais comme je n'en suis pas certain, j'ai préféré ne rien dire. Sur son site on trouve le même genre d'arguments débiles du genre "toutes classes ne sont pas destinées à devenir des classes de base", ce qui signifie dans le contexte des classes dont on peut dériver d'autres classes. Et surtout un argument sur la table des méthodes virtuelles qui prend de la place. Les deux "problèmes" sont réglés par des objets lightweights, ce qui évite les problèmes de sémantique variable selon le mode de passage et ce qui rend donc le langage plus clair. De plus, la table des méthode virtuelles peut être supprimée automatiquement par un compilateur intelligent dans un langage sans pointeur.
Ceci étant, merci pour le fou rire que tu as provoqué en parlant de discours constructif, venant de toi, c'était vraiment puissant.
[^] # Re: C'est un troll.
Posté par boubou (site web personnel) . En réponse à la dépêche Mono 1.0 sous le feu des projecteurs. Évalué à 2.
Oups, j'avais oublié ça. Je te l'apprends peut être, mais gcc supportait déjà les templates vers 1994, mais de façon très bugguée. Dire que C99 a retardé le travail de normalisation est une vaste blague. De plus, la notion de generique ou de template pré-date le C++ (ça date des langages de la famille ML) et c'est bien la complexité du modèle retenu en C++ qui a rendu son implémentation difficile.
[^] # Re: C'est un troll.
Posté par boubou (site web personnel) . En réponse à la dépêche Mono 1.0 sous le feu des projecteurs. Évalué à 2.
[^] # Re: Mon grain.
Posté par boubou (site web personnel) . En réponse à la dépêche Mono 1.0 sous le feu des projecteurs. Évalué à 2.
Soit, mais elle dit aussi qu'il faut un accord explicite. Novell/Ximian n'a pas cet accord explicite. Quand ils l'auront, on en reparlera. Soit dit en passant, ça me rejouirait car C# et .NET en général sont vraiment des technologies impressionnantes.
[^] # Re: C'est un troll.
Posté par boubou (site web personnel) . En réponse à la dépêche Mono 1.0 sous le feu des projecteurs. Évalué à 2.
Pour le virtual, je t'explique. Dans les langages objets avant C++, la notion d'objet implique celle de polymorphisme. Si B hérite de A, je peux écrire un code qui pense utiliser des A mais lui transmettre des B, tout ce passera bien, les méthodes de B seront appelées. En C++, ceci ne fonctionne que si on ajoute virtual devant les méthodes qu'on veut voir fonctionner correctement. Bien entendu, on peut toujours avoir B qui hérite de A, passer un B à un code qui attend un A et obtenir un comportement débile car les méthodes redéfinies dans B ne sont pas appelées. Cette sémantique est tout simplement pourrie. C'est d'autant plus pourri que ça dépend du mode de passage. Si A est passé par valeur, alors les méthodes de A seront toujours appelées, alors que si A est passé par référence ou pointeur, le polymorphisme fonctionne. Or, un langage doit être prévisible simplement. Un tel comportement est nuisible et ne fait que compliquer la tâche du programmeur sans aucun intérêt pratique.
Dans un langage objet qui fonctionne, toutes les méthodes sont "virtuel" par défaut. Si on a besoin d'interdire la redéfinition, on utilise un mot clé adapté, comme "final" en Java. De cette manière, on ne peut pas se tirer dans le pied en croyant avoir du polymorphisme mais en ayant en fait un truc boiteux. On peut aussi imaginer une solution à la C++ mais qui empêche de se tirer dans le pied, en ayant une seule sémantique (et pas une sémantique qui dépend du mode de passage) et en interdisant la redéfinition des méthodes non virtuel. Personnellement, j'aime moins, mais bon, c'est un choix.
Les arguments des défenseurs de la sémantique débile du C++ sont multiples et plutôt foireux.
Le plus convainquant est celui qui dit que cela facilite l'interfaçage avec du C en ayant des objets sans table des méthodes virtuelles. On peut alors passer leur contenu à des fonctions C sans soucis. On peut aussi "encapsuler" une struct C en un objet C++ en ajoutant des méthodes. Sauf qu'on sait depuis des années comment faire ça proprement : avec des objets "lights" comme dit Guillaume, c'est-à-dire des objets qui sont manipulables par valeur (contrairement aux objets de Java) et qui ne supportent pas l'héritage. Ce sont les structs du C#, mais ça existe depuis longtemps en Eiffel et Sather (et ça manque drôlement en Java).
Le plus pourri est celui qui dit que virtuel permet d'optimiser le code. C'est grotesque. De toute manière, on obtient la même chose avec du final (i.e., la possibilité de virer le passage par la table des méthodes virtuelles et d'inline les méthodes associées si ça vaut le coup). De plus, depuis Eiffel et Sather, on sait que des techniques évoluées permettent de laisser le compilateur faire ça de façon beaucoup plus efficace que le programmeur.
Voilà, voilà, tu vois, je connais un peu le sujet, mais bon, vu ton aggressivité déplacée, je suppose que tu t'en fous.
[^] # Re: C'est un troll.
Posté par boubou (site web personnel) . En réponse à la dépêche Mono 1.0 sous le feu des projecteurs. Évalué à 2.
Ok, nous sommes d'accord sur le principe, j'aurais donc du ajouter des exemples pour illustrer mon propos. Le cas de Java qui est emblématique. Les premières JVM étaient d'une lenteur délirante, à tel point que pour certains Java est intrinsèquement lent, seulement interprété, etc. En fait, le design de Java contient des erreurs, en particulier l'absence de struct qui fait qu'on se retrouve avec une énorme consommation mémoire. Mais les JVM modernes sont très rapides et dans certaines situations on peut même faire mieux que du C ou du C++ en Java. Il n'y a rien intrinsèquement en Java qui rend le langage lent. C'est la même chose pour Eiffel par exemple dont les premiers compilateurs étaient tellement lents que le langage était presque inutilisable (idem pour Ada, d'ailleurs). Des progrès énormes ont été réalisés et on constate maintenant que le design d'Eiffel ou d'Ada est bien meilleur que celui de C++.
Tiens, je termine pas un exemple concret. Il a une grosse couille de conception dans Java, c'est le lock par objet qui est soit disant plus objet que l'utilisation de mutex. Enfin, disons plutôt que je pensais qu'il y avait une couille de conception. Bon, je n'aime pas, mais surtout j'étais persuadé qu'on était obligé d'avoir un mot par objet au minimum pour gérer ce lock, soit une perte de 4 octets sur nos architectures 32 bits. Encore de la mémoire gâchée... Sauf que les concepteurs de SableVM ont trouvé un moyen de virer ce mot et d'éviter la perte mémoire.
Il a un phénomène du même genre en Eiffel, avec un truc ultra-puissant découvert par les chercheurs qui implémentent smalleiffel. Je ne me rappelle plus des détails, mais en gros ça permet de garder un modèle objet cohérent tout en se débarassant de la "table des méthodes virtuelles".
Je ne crois pas aux "erreurs" de l'industrie, si un machin a du succès, c'est le plus souvent pour de bonnes raisons, les pressions marketing et les "décideurs pressés" ne font pas tout.
Terrain glissant ! VHS contre Betacam, USB 1 contre Firewire, Unix contre Windows, etc. L'industrie ne fait que des erreurs ou presque, mais heureusement, ça change car l'information circule bien mieux. J'en veux pour preuve l'adoption de ogg dans de plus en plus de players.
Au final, il a fait un langage qui s'interface avec C de façon triviale, et relativement facile à implementer. Sans ça, C++ n'aurait jamais marché.
D'un côté je suis d'accord (interface triviale avec le C) et j'ajouterais même courbe d'apprentissage rapide pour un développeur C. Mais d'un autre, tout ça n'est vrai que pour les vieilles versions du C++. Parce qu'avec l'arrivée des templates, ça a été le délire. Il a fallu littéralement une décénie pour avoir des compilateurs décents...
Je veux bien, mais alors bonjours le tas de feature en plus à flanquer dans la spec. Et donc tu te retrouves soit avec un langage hyper-specialisé qui ne fait que du calcul numérique et rien d'autres (donc prévoir moyens pour l'interfacer avec autre chose pour faire des vrais softs utiles, avec GUI & co...), soit un langage encore plus énorme que C++ :-). "Less is more" ?
Salaud, tu m'as coincé et tu en profites ;-) Je n'irais pas jusqu'à dire qu'on obtient plus gros que du C++, mais bon tu as raisons. Excepté une spec modulaire, j'avoue que je ne vois pas trop comment faire.
C'est exact, ils ont préféré attendre d'avoir une bonne implémentation du concept. Encore un point ou Hejlsberg m'impressionne plus que Gosling.
Ouaip. Le pire, c'est que la solution retenue pour les generics de Java existe depuis au moins 5 ou 6 ans, avec des prototypes qui marchent, etc. Alors attendre tout ce temps pour une solution moyenne, c'est vraiment nul.
Entièrement d'accord, je ne vois pas d'autre issue que d'avoir 2 modèles objets dans un langage : un "leger" (structs) ou tu peux creer tout les objets que tu veux sans trop de soucis de perfs, et un plus lourd et complet (class), avec toutes les features bien sympa qu'on aime avoir (introspection, etc...).
Ba oui, je crois qu'on est obligé. Mais Eiffel et Sather le savent depuis plus de dix ans...
[^] # Re: Mon grain.
Posté par boubou (site web personnel) . En réponse à la dépêche Mono 1.0 sous le feu des projecteurs. Évalué à 3.
Mauvais exemple. Oui, tout le monde supporte samba, mais personne ne demande d'abandonner NFS à son profit. Le problème avec Mono n'est pas tant qu'il pourrait se faire atomiser par MS, c'est plutôt que De Icaza et d'autres voudraient en faire LA solution pour continuer à developper Gnome. Personnellement, que MS atomise samba, ça me gênerait pour collaborer avec certains collègues un peu bornés, mais çe ne m'empêcherait pas de bosser. Par contre, si certaines futures applis incontournables de Gnome sont développées avec Mono et que Mono est abandonné à cause d'une action légale de MS, ça pourrait me gêner beaucoup plus. I
[^] # Re: Mon grain.
Posté par boubou (site web personnel) . En réponse à la dépêche Mono 1.0 sous le feu des projecteurs. Évalué à 3.
Ba oui, on l'oublie parce que c'est FAUX. Cf mon vieux post : http://linuxfr.org/comments/441211.html#441211.(...) En résumé, l'ECMA demande du RAND et la partie soumise à l'ECMA est bien brevetée (cf http://web.archive.org/web/20030609164123/http://mailserver.di.unip(...)).
Ce qu'il y a de fou, c'est que tu nous as déjà fait le coup pour ta news qui présentait Mono 1.0 comme le messie et que je t'ai déjà répondu en te citant un des inventeurs de .NET, mais tu persistes à diffuser ces mensonges. Ca devient pénible.
Alors, moi aussi, je radote. Pour implémenter CLI et C#, il faut utiliser des méthodes brevetées par MS et MS ne s'est engagé qu'à faire du RAND, point final.
Bien sûr, GTK# n'est pas breveté par MS, mais comme il faut un compilateur C# et une machine virtuelle CLI pour le faire tourner, on s'en fout.
[^] # Re: C'est un troll.
Posté par boubou (site web personnel) . En réponse à la dépêche Mono 1.0 sous le feu des projecteurs. Évalué à 2.
Ba si, sans problème, il suffit d'avoir le support pour le faire dans le compilateur. On analyse statiquement le contenu de la chaîne et on traduit les noms de variables en offset dans la pile.
La seule difficulté réside dans le fait que la chaîne de format doit être statique, ce qui limite les applications possibles et surtout qui nécessite un support spécifique au niveau du compilateur (pour empêcher l'utilisation de la construction avec une chaîne dynamique).
On peut aussi imaginer qu'on conserve la table des symboles pour les variables locales, mais c'est un peu lourdaux (mais faisable).
- tu n'as pas de controle sur la façon dont les variables sont effectivement affichée (par ex., afficher un entier en hexa, ou un float avec une certaine précision).
Ajouter ce genre de fonctionnalité sous forme de modificateur est ultra trivial.
[^] # Re: C'est un troll.
Posté par boubou (site web personnel) . En réponse à la dépêche Mono 1.0 sous le feu des projecteurs. Évalué à 3.
Il y a de la marge entre ce que dit Stroustrup et le résultat de sa reflexion. Pour avoir lu des articles théoriques sur Caml et ses dérivées, je comprends parfaitement que Stroustrup ait pu être rebuté par la théorie des langages de programmation et ait préfére faire l'ingénieur. Mais le résultat est ce qu'il est, mauvais sur de nombreux points. Il est vrai qu'Eiffel n'était pas un modèle d'efficacité, ni d'ailleurs smalltalk, par exemple, donc Stroustrup a pu être échaudé par ces expériences (commetant l'erreur habituelle qui est de confondre design et implémentation). Maintenant, l'exemple du virtual me semble emblématique du design raté. Sous pretexte de faciliter l'interfaçage avec le C, Stroustrup casse le modèle objet expérimenté par toute la communauté de l'orienté objet. Pour qu'un objet fonctionne (c'est-à-dire que le polymorphisme marche), il faut maintenant déclarer ses méthodes "virtuel", sinon il s'agit d'une struct à laquelle on ajoute des méthodes. L'exemple même de l'optimisation à l'envers. Plutôt que d'étendre la sémantique de struct en permettant d'insérer des méthodes ou encore de choisir un mot clé particulier pour ces "objets" qui n'en sont pas, Stroustrup préfère casser le cas général tout ça pour soit disant faciliter la récupération du C (alors que cela aurait marché très bien avec les autres solutions). Je ne peux pas prouver qu'on savait faire ça à l'époque, mais c'est tellement trivial pour quelqu'un qui s'intéresse aux langages de programmation que ça me semble évident.
De même beaucoup plus tard pour les templates qui sont à la fois trop puissants (il a fallu attendre si longtemps avant d'avoir des compilateurs qui marchent) et pas assez (les contraintes sur les types sont implicites, ce qui retarde la vérification de la validité du code). Encore une fois, l'expérience des autres langages aurait permis d'éviter ça. Soit, on n'aurait pas eu les expressions templates, mais franchement, j'ai des doutes sur leur intérêt réel.
Et si tu prends le contre-exemple de Java, tu vois que très rapidement on a cherché à y ajouter des choses comme les templates ou même l'overloading d'operateur.
Ok pour les templates (le résultat est d'ailleurs pourri si tu veux mon avis), mais pas pour les opérateurs. Ils ne sont pas surchargeables en Java et ça risque de durer. Sur le fond, je fini par être d'accord. Oui, ça permet d'écrire du code numérique lisible et avec les expressions templates du C++, ça permet même de faire du code relativement efficace. Cependant, j'ai lu pas mal de papier de numériciens et je suis maintenant convaincu par leur argumentation : si on veut faire proprement et efficacement du calcul numérique, il faut déléguer au compilateur. Il faut donc que les nombres complexes, les vecteurs et les matrices soient intégrés au langage et que le compilateur se démerde pour optimiser le code. Ca veut dire qu'il doit pouvoir appeler des bibliothèques comme Atlas. On en est loin, mais j'avoue que je ne vois pas comment faire autrement. Et si on enlève le code numérique, la surcharge d'opérateurs ça ne sert franchement à rien.
Et même C#, qui a pourtant ajouté un certain nombre de choses à Java dès le départ, se retrouve contraint d'en ajouter encore.
Oui et non. Si j'ai bien compris (je peux me tromper) les generics de C# ont été retardés pour la version 2 car les équipes de Microsoft research bossaient encore dessus. Il s'agit d'équipe de chercheurs en théorie des langages et franchement, le résultat est vraiment impressionnant (j'ai honte d'admirer une production de MS, mais bon). Soit, on a du more is more ici, mais fait proprement. Sinon, oui C# a ajouté des choses à Java, peut être un peu trop comme les opérateurs, mais aussi dans la bonne direction comme les structs. Mais surtout, en s'appuyant sur des équipes de recherche pour certaines features...
[^] # Re: Mon grain.
Posté par boubou (site web personnel) . En réponse à la dépêche Mono 1.0 sous le feu des projecteurs. Évalué à 2.
Bof. Dans le cas présent, on sait qu'il y a des brevets et on sait que MS ne sait pas engagé à faire du royalty free. Pour les standards du W3, on sait en général qu'il n'y a pas de brevet dans les grosses boites qui sont membres du W3 (ce qui élimine pas mal de monde) ou que les licences sont royalty free. C'est le cas aussi pour pdf par exemple.
D'autre part, MS n'a jamais utilise l'arme des brevets de maniere offensive. Ils le pourraient tres facilement, ils ne l'ont jamais fait.
En effet et c'est un point important. Ceci étant, MS est actuellement en très bonne santé. Si Mono lui cause beaucoup de tord, que se passera-t-il ?
Tout ça pour dire que Mono n'est pas une solution aussi pérenne que C++ associé à des bibliothèques libres car le risque existe et est identifié. On ne peut pas en dire autant de Java, contrairement à ce que beaucoup de gens affirment (je ne te mets pas dans ce groupe).
[^] # Re: C'est un troll.
Posté par boubou (site web personnel) . En réponse à la dépêche Mono 1.0 sous le feu des projecteurs. Évalué à 2.
Je suis d'accord avec toi, Stroustrup est partisant du "more is more" et effectivement chaque feature du C++ est utilisée et c'est bien le problème. Disons que "less is more" me convient plus, mais vu le succès de Perl et de C++, je suppose que pour beaucoup de gens, "more is more"...
Nous avons d'ailleurs déjà eu cette discussion un certain nombre de fois et nous ne serons jamais d'accord, je suppose.
[^] # Re: C'est un troll.
Posté par boubou (site web personnel) . En réponse à la dépêche Mono 1.0 sous le feu des projecteurs. Évalué à 3.
[^] # Re: Mon grain.
Posté par boubou (site web personnel) . En réponse à la dépêche Mono 1.0 sous le feu des projecteurs. Évalué à 3.
[^] # Re: Bravo l'innovation!!!
Posté par boubou (site web personnel) . En réponse à la dépêche Mono 1.0 sous le feu des projecteurs. Évalué à 2.
Maintenant je pense qu'on est d'accord les diverses techniques d'isolation des process sont toujours plutôt meilleures que "rien du tout je risque de laisser /etc/shadow en lecture et en plus je risque le buffer overflow", m'enfin ça ne suffit pas à faire une appli sécurisée, et l'article prête à confusion.
Bof. Avec les techniques modernes de sandboxing tu peux contrôler exactement ce à quoi ton programme a accès, fichier par fichier, socket par socket, etc. Tu peux mettre en place une véritable politique de sécurité extrêmement fine et sans aucune coopération du programme que tu exécutes. En fait, tu as un niveau de contrôle qui est comparable à celui offert par le noyau linux associé aux capabilities. Un peu comme si tu créais un utilisateur spécifique pour faire tourner un programme et que tu contrôlais exactement ce à quoi il a accès. Et je ne parle même pas des mécanismes de signature de code. Ok, l'article prête à confusion, mais les machines virtuelles permettent tout de même de faire beaucoup plus de choses que ce qu'on peut faire en C ou en C++. Donc évacuer ça par "bullshit marketting", c'est exactement du même niveau que de dire que l'extension NX des AMD est du marketing. C'est faux, même si ça ne résout pas tous les problèmes...
Ceci étant dit:
perl + sandbox sur Google (3ème lien):
http://secu.zzu.edu.cn/book/Perl/Perl%20Bookshelf%20%5B3rd%20Ed%5D/(...))
Je dis pas que ça fait tout ce que fait .NET, mais il faut toujours se méfier des phrases du type "Perl ne sait pas faire", j'en ai déjà fait les frais 8-)
Oui, oui, je connais le mode safe de perl, mais bon, ce n'est vraiment qu'une partie infime de ce qu'on peut faire avec Java ou .NET.
[^] # Re: Bravo l'innovation!!!
Posté par boubou (site web personnel) . En réponse à la dépêche Mono 1.0 sous le feu des projecteurs. Évalué à 3.
[^] # Re: Bravo l'innovation!!!
Posté par boubou (site web personnel) . En réponse à la dépêche Mono 1.0 sous le feu des projecteurs. Évalué à 4.
Ouai, ba ça prouve juste que tu ne sais pas de quoi tu parles. .NET a un modèle de sécurité très évolué, dans le même esprit de celui de Java, qui permet de sandboxed une application de façon très fine, un peu comme les capabilities linux. Et bien entendu, sans aucune coopération de l'application qu'on exécute. A ma connaissance, il n'est pas possible de faire aussi fin et précis en Perl. Cf mon article sur l'architecture de sécurité de Java paru dans MISC (http://www.miscmag.com/articles/index.php3?page=808(...)).
Bon, ceci étant, nous sommes d'accord, l'article est pourri et effectivement, beaucoup des avantages de C#/.NET et de Java par rapport au C et au C++ se retrouve dans les langages comme Perl et Python, par exemple.