TImaniac a écrit 6420 commentaires

Je comprends tout à fait ta comparaison.
Cela dit le designer a intérêt à prendre ne compte les contraintes de la vraie vie, imagine la maquette d'une voiture, la voiture peut être belle mais pas aérodynamique pour 2 sous et consommer 3 tonnes d'essences.

Mais effectivement on ne peut pas faire que critiquer Lisaac. Celà dit je trouve intéressant de soulever certains points de comparaison avec les langages "modernes" actuels. Rien ne montre effectivement qu'il n'est pas possible de cibler une machine virtuelle en Lisaac. Mais faut y penser dès le début si c'est un réel objectif (je ne crois pas que ca soit le cas de toute façon) : une machine virtuelle impose des contraintes (jeu d'instruction, gestion mémoire, gestion des droits, etc.) que le langage doit prendre en compte et des fonctionnalités qui peuvent/doivent être exposées.

La 2ème question à se poser c'est la pertinence de certains choix fait dans Lisaac, notamment le côté "simple" de la grammaire permettant d'augmenter facilement les constructions syntaxique (simuler une boucle for while ou un autre truc innovant). C'est joli, bandant... oui mais pourquoi Java ou C# ne propose pas ce genre de chose ? (c'est pas une nouveauté en soit)
Ce qui peut paraître séduisant en premier abord et vu comme une qualité dans un objectif "universitaire" peut être un boulet dans la vraie vie. Regardons le C++ : mine de rien ont peut reproduire la syntaxe de pleins d'autres langages uniquement avec le système de macro (j'ai même vu du Lisp en macro C++... et pourquoi pas du Lisaac, soyons fou ;) ). On en arrive à des constructions en C++ qui sont sûrement bandantes pour le hacker qui l'a codé, mais qui sont imbittable par le commun des mortels, et j'en vois tous les jours.
En limitant à l'aide de mots clés (for while foreach, etc.) les constructions les plus courantes, on limite certes la concision et l'expressivité, mais on améliore aussi la compréhension du code par une autre personne. C'est probablement ce qui a fait une partie du succès de Java. Beaucoup d'autres simplifications également. Ce qui apparaît comme des contraintes pour un "universitaire" est en fait un atout dans la vraie vie. Lever ces contraintes comme le propose Lisaac élimine une qualité essentielle d'un code source. Et dans le mondre du libre on devrait être attaché à cet aspect.

Une machine virtuelle c'est pareil. En apparance c'est une érésie, les perfs s'en ressentent largement. Seulement les avantages sont aujourd'hui beaucoup plus important que les inconvénients (sécurité, portabilité, productivité, etc.) dans beaucoup de scénarios d'utilisation.

Tout ca pour dire que je ne suis pas contre avoir des langages "de recherche", "universitaire". Mais l'objectif devrait pourtant être le même : améliorer les langages offerts aux utilisateurs, répondre à leurs besoins.

Bon j'ai encore fait dérivé le sujet mais j'espère que tu trouveras ca plus intéressant comme discussion ;)

Ce qui est horripilant de ta part, c'est de condamner le langage sans le moindre doute, en y connaissant si peu.
En même temps j'ai pas prétendu grand chose, j'ai juste essayé de dire que je ne voyais rien de révolutionnaire qui va démultiplier les perfs ou je sais pas quoi.
Ce qui est horripilant, c'est le ton prétentieux d'Ontologia : même si ce n'est pas l'intention, ca pu systématiquement la pub à plein nez pour le langage révolutionnaire où tout est prévu. C'est pas moi qui est avancé la comparaison avec la locomotive. C'est ce genre de phrase qui forcent des réactions pas forcement constructives.
Rien que le fait que de prendre Lisaac comme exemple de langage pour parler de choses plus générale, on sent bien la mise sur un piédestral du langage. Le tout avec un air prédicateur de la future révolution en marche (je suppose que dans sa tête c'est le TGV, la locomotive c'est déjà loin).

Benoit est dans la catégorie pur codeur universitaires... Il utilises ses outils tous les jours et connait les concepts avancé "universitaires".
Oué mais bon y'a aussi beaucoup de branlette intellectuelle là dedans. Ca me gène pas en soit, c'est fort intéressant et il en découle souvent des applications pratiques plus qu'innovante. Mais sa façon de présenter les choses donne sérieusement envie de le remettre (Ontologia) les pieds sur terre, la réalité de Lisaac aujourd'hui comparé aux autres langages. Lisaac a sûrement pleins d'atout, mais il n'est pas universel et n'a pas tous les atouts réunis des autres langages et ne peut mon sens pas prétendre tous les remplacer.

Ce que j'attendais plutôt avec ma réaction initiale à la comparaison avec la locomotive, c'est une liste des atouts de Lisaac qui pourrait en faire un langage sexy face à l'existant. A la place ca a dérivé. La question reste donc posée.

M'enfin, le Java aussi on peut le mixer avec du C, et plus haut tu le cites pour ses apports en matière de sécurité, faudrait savoir.
A la grosse différence que je peux configurer la VM pour se mettre dans un contexte où ces appels natifs ne sont pas autorisés.
En Lisaac, c'est de la responsabilité de celui qui a écrit le code, vu qu'il n'y a pas de contrôle à l'exécution, bref de la responsabilité du créateur, potentiellement avec des intentions malveillantes.

C'est évident que rien ne sera prouvé sur le C !
On est d'accord. Mais il y a-t-il un mode "strict" dans le compilo Lisaac pour se mettre dans des conditions où l'ont peut espérer prouver le code ? (sans C quoi) J'ai pas trouvé mais j'ai peut être mal cherché.

et on ne parle pas de sécurité mais de prouver les contrats, cela n'a à peu pret rien voir.
J'ai parlé de sécurité dès le début, avant même de parler de preuve. J'ai pris après 2 contextes de sécurités : la sécurité offerte par les méthodes formelles pour prouver qu'un code fait bien ce qu'il doit faire (méthode B comme exemple cité), et la sécurité au sens protection contre un code malveillant (style une machine virtuelle). Relis le thread, juste après la locomotive.

Le même rapport qu'il y a avec "comme il est sans doute possible de le faire en Lisaac, mais ce dernier ne va pas apporter grand chose comme a pu apporter la locomotive par rapport à la charrette."
Ecoutes, visiblement il a voulu dire qu'il n'y avait pas de raison que Lisaac ne soit pas adopté, la locomotive a bien été adoptée alors que la charette existait déjà. Sous-entendu Lisaac est aussi révolutionnaire que la locomotive. Ben je cherche ce côté révolutionnaire que les autres charettes actuelles n'ont pas. J'ai pris 2 exemples de domaines sur lesquels vous n'avez rien prouvez du tout vis à vis de Lisaac à part dire "c'est prévu" qui fait plus penser à un discours pré-electoral qu'à une réalité...

http://www.linuxfr.org/comments/893742.html#893742
Bon après j'ai citer des qualités comme ca, on peut discuter d'autres trucs, ou pas.

Moué, enfin pourquoi ne pas leur apprendre directement le Java ? Enfin un langage qui a des chances d'être utilisé tôt ou tard par la majorité des étudiants.
Nan parcque franchement quand tu débarques en master et que t'as les mecs qui viennent de licence et qui te demande ce qu'est "Windows NT" et savent seulement programmer en Lisp ou en scheme, bah tu te tapes des cours de Java à BAC+4. Youpi.
Alors que là bon à ce niveau là on préfèrerai passer à autre chose, notamment tout le reste du cycle de vie d'un projet informatique qui a du coup à peine le temps d'être survolé.

Bon bah alors vas-y, montre moi que Lisaac va m'apporter de manière significative (au moins autant que la locomotive) plus de sécurité que m'en apporte les autres langages actuellement existant(Java, C#, B, etc.). Déjà je suis même pas convaincu que Lisaac en apporte autant que ces autres langages, alors delà à en apporter plus, il ne tient qu'à toi d'apporter des éléments !

Il est prévu de faire de le preuve dans Lisaac. La simplicité de la syntaxe aide à cela.
Je sais pas si ca a changé depuis la dernière fois que je me suis intéressé aux specs du langage, mais dans mes souvenirs on pouvait allègrement mixé du Lisaac avec du code écrit en C. Partant de là, niveau preuve et sécu...

Et qu'est-ce qui permet de dire cela ?
Très bonne question. Ce n'est pas moi qui est cherché à faire ce parallèle hein.
Tu crois que les lib fleuves sont l'aboutissement de tout langage ?
C'est quoi le rapport ?

Ben montre moi un programme écrit en Java (pas en bytecode hein) qui permet potentiellement de faire faire n'importe quoi à la JVM sans qu'elle s'en rendre compte.
Dans tous les cas tu peux admettres que même si une JVM n'est pas une garantie, elle offre une meilleur sécurité. Ce n'est pas certainement pas acceptable si on parle de code mal-intentionné mais c'est toujours bon à prendre pour se protéger de code mal écrit.

mais d'un coté tu dis que les langages de haut niveau sont trop complexes et n'apportent rien
J'ai écris ca où ? Je n'ai pas généralisé, je parle de Lisaac. En l'occurence je ne vois rien de révolutionnaire en pratique dans ce langage comme a pu l'être la locomotive par rapport à la charette. J'ai pris l'exemple de la sécurité (au sens qualité/bug et au sens protection contre code malveillant), c'est tout.

Choisi ton camps camarade.
Non. Ce n'est pas le but.

Tout ce que je dis est que du point de vue de l'OS
Oué c'est pas faux, mamoi j'ai juste rajouté qu'une machine virtuelle qui a un modèle n'offrant d'accès bas niveau comme une JVM ajoute une couche de sécurité en plus de l'OS.

La façon la plus simple de faire celà est d'aller modifier le bytecode d'une des classe de base.
Tu te rends bien compte que tu triches. Forcement, en java à partir du moment où tu peux écrire dans un fichier tu peux t'amuser à faire écrire à ton programme un Java un bout de code en C ou modifier un fichier de bytecode.

Bref on a tout ce qu'il faut pour envoyer la JVM dans le mur
Si la JVM est bien faite, tu dois pouvoir la configurer pour interdire au programme exécuter d'intéragir avec les .class du code exécuté. J'avoue ne pas être un spécialiste de la sécu des JVM, mais je suppose qu'une JVM configurée pour exécuter du code provenant du net (style une applet) empêche ce genre d'astuce.
En tout cas dans l'environnement .NET proche de celui de Java, l'environnement ne laisse pas les composants faire ce genre de connerie s'il ne sont pas de confiance.
Bref, y'a un modèle "virtuel" intermédiaire avant l'OS qui autorise l'application de tout un ensemple de règles de sécurité plus fines et qui sont toujorus bonnes à prendre avant l'OS.
Je vois bien une applet écrite en C qui tourne dans un navigateur web. A moins de sandboxer le navigateur dans son ensemble (ce qu'est obligé de faire MS avec IE par exemple), par défaut l'applet C pourrait faire toutes les conneries puisque tournant avec les mêmes droit que le navigateur qui héberge le code. A moins de s'amuser à forker sur un compte avec des droits réstreind toussa. Lourd, coûteux et pas forcement adapté.

Pour en revenir à la choucroute initiale, ca ne change rien au problème : Lisaac n'apportera pas grand chose de ce point de vue là.

. Le contraire serait inquiétant.
Je ne prétend rien du tout, ni dans un sens ou dans l'autre. Je dis juste que la méthode B permet de prouver le programme écrit, l'environnement t'embêtant jusqu'à ce que t'es prouvé l'intégralité de ton code. En C t'as aucune contrainte à la compilation, et à l'exécution il n'y a que l'OS pour effectuer des contrôles de sécurité.

La preuve permet de certifier un comportement, mais ne met pas à l'abri des plantages loin de là.
Pas besoin d'étaler ta science, j'ai jamais dit le contraire. Je dis juste que ca offre une meilleure sécurité. Il est évident qu'on n'est pas à l'abris des comportements extérieurs au programme, à commencer par ceux du matos. J'ai également cité le problème des spécifications qui sont toujours rédigées par un humain.

je suis au regret de t'apprendre qu'un programme écrit en Java a exactement les mêmes droits qu'un programme écrit en C.
Je te mets au défi d'écrire un programme en Java pur (pas d'appel à du code natif hein) qui va taper n'importe où dans la mémoire ailleur que là où elle est autorisé par l'espace que lui a allouée la VM. Tu peux pas sortir des sentiers battus (sauf faille dans la VM bien entendu), et la première barrière n'est pas l'OS mais bien l'environnement contrôlé par la VM.
Idem pour une application en ActionScript ou en C# par exemple. Le modèle de VM intermédiaire facilite grandement la vérification du code à exxécuter, et permet d'accorder plus ou moins de confiance et de droit à celui-ci. L'OS constitue une autre barrière qui vient éventuellement combler les lacunes du modèle et de l'implémentation de la VM, mais dans l'absolu ces langages offrent plus de sécurité qu'un programme écrit en C.

Le framework java permet de limiter la casse sur les plus grosses erreurs
Euh... t'appelle quoi le "framework" ? Si c'est juste l'ensemble des libs, je vois pas le rapport.

Pour être honnête je en connais pas Lissac, mais l'avantage majeur des langages de haut niveau est de permettre à des non initiés de modifier facilement une partie du programme suivant leur besoin.
Y'a des outils adaptés pour ca : moteurs de règles, moteurs de script avec langage métier dédié, etc. Lisaac se veut un langage généraliste (dans sa grammaire en tout cas), et ca c'est déjà imbittable pour la plupart des non développeurs.

Par tous les pseudos "experts" qui ont créé ce buzz. C'est pas tant la communauté Ruby que la communauté de journaleux en mal d'annonce technologique.

La difficulté de maintenance et d'évolution est liée à la difficulté du développement ...
Absoluement pas. La difficulté de maintenance et d'évolution vient plutôt des attentes des utilisateurs clients en terme de performance, de rapidité d'intervention en cas problème, de la conception en amont de la plateforme en ayant réfléchi à son "évolutivité", à son intégration éventuelle avec d'autres applications/middlewares, aux capacité de de montée en charge, etc.

Rails n'a pour l'instant pas la prétention de concurrencer PHP sur du mutualisé, c'est à dire à destination du grand public.
Voilà pourquoi entre autre Ruby ne s'est pas démocratisé comme prévu au près du grand public. L'absence d'acteur majeur est la raison pour laquelle Ruby ne s'est pas démocratisée dans les entreprises.

Perso je te dirais d'essayer Ruby et Rails mais je doute de ta partialité de jugement de toute manière.
Tu remarqueras que j'ai surtout comparé avec Java et PHP, et je peux t'assurer que je suis vraiment pas fan du 2ème :)

De toute manière la tenue en charge et les millions de users importe peu à 99% des entreprises.
En entreprise il peut y avoir d'autres sortes d'utilisateurs : des grosses applis internes (banques, assurances, etc.) qui demande des architectures N-tiers parfois avec de hautes performances.

Au final tu cantonnes toi même Ruby à un petit marché : les besoins internes des entreprises, mais qui n'ont pas trop de besoin quand même. Je rajouterai : et qui ont les compétences en interne.

Je ne doute pas que depuis les framework PHP ont été amélioré, mais Rails a et aura longtemps une longueur d'avance.
Oué bah moi je dis justement que cette longueur d'avance diminue et va bientôt être complètement effacée. Dans le monde qui m'intéresse, le framework ASP.NET MVC Framework n'a pas grand chose à envier à Rails.

Le temps de dev c'est ce qui coûte le plus....
Grossière erreur :) Ca représente kedal le temps dev dans un projet. Le plus gros du boulot c'est la maintenance et les éventuelles évolutions (liées aux fonctionnalités ou à la montée en charge).

De plus il est à mes yeux pratiquement impossible de migrer rapidement et facilement des développeurs PHP en Java.
Faut savoir, une fois ca concurrence Java et pas PHP et là tu migres depuis PHP :) Soit. En Java je sais pas, par contre j'ai déjà eu l'occasion de migrer du PHP en ASP.NET, c'est pas compliqué. Que va m'apporter RoR en plus ?

Et même s'il y a un travail plus conséquent qu'en PHP pour la tenue en charge, cela reste plus simple et rapide à développer qu'une usine à gaz en J2EE.
Ah bon ? Nan parcque je connais aucune grosse architecture en RoR justement. Un truc qui tienne la charge et des millions d'utilisateurs.

Coté IDE sort de ta grotte et regarde Eclipse / Aptana / Ruby In Steel (http://www.sapphiresteel.com/), etc.
Comparé à l'écosystème Java... Moi je veux un IDE qui me permette de tout développer dans mon architecture n-tiers, de ma couche web (avec designer graphique) à la couche d'accès aux données en passant par la couche métier et les services. Le tout intégré, avec environnement de test, d'analyse de performance, gestion de version, etc. Nan parcque là à part la coloration syntaxique, la complétion et le débuggage... Ok c'est le minimum...

Il faudra argumenter un peu plus tout de même...
Bah un programme écrit en B peut être prouvé, donc même s'il génère du code "natif", il est vérifiable "à priori" (évidemment les spec du programment restent écrites par un humain...). C'est plus une sécurité vis-à-vis d'un plantage "non prévu".
Pour Java, il y a une couche d'abstraction entre le code généré et le code réellement exécuté, autorisant un certain nombre de vérifications supplémentaire par rapport à un programme natif compilé à partir d'un langage autorisant à peu prêt tout et n'importe quoi comme accès bas niveau. C'est une sécurité (toute relative) vis-à-vis de certains types d'erreur de programmation mais aussi une sécurité vis-à-vis de code malveillants.

C'est sûr qu'il n'y a aucune différence de productivité entre l'assembleur et le C, le C et Java, Java et Perl.
J'ai pas parlé de productivité mais de complexité. Globalement il est tout à fait possible de faire des grosses applications en C/C++ ou en Java comme il est sans doute possible de le faire en Lissac, mais ce dernier ne va pas apporter grand chose comme a pu apporter la locomotive par rapport à la charette.

Sinon tu parles de PHP mais il ne me semble pas que les début de PHP ont été foudroyant ...
Le truc c'est que PHP avait de net avantages par rapport aux concurrents : web dynamique, simple et libre/gratuit (par rapport à ce que se faisait à l'époque). Ces atouts combinés n'avaient pas d'équivalent et l'ont rendu populaire auprès des développeurs amateurs et des plateformes d'hébergement. On connait la suite.

Sinon il y a encore peu de site grand public en Rails, mais je t'assure qu'il est de plus en plus utilisé en interne,
Ca reste anecdotique non ? Enfin par rapport au buzz initial en tout cas...

Or il est plus délicat de proposer du mutualisé en Rails qui se propose donc comme alternative à Java.
C'est tout le problème : Java vise un public "professionnel" et donc une plateforme complète pour produire des solutions beaucoup plus exigentes (N-tiers, architecture distribuée, etc.) avec support/services de nombreux acteurs du marché, outils de dev/déploiement/exploitation.

Marrant ta signature comparée à la mienne ;)

Parcqu'au final c'est pas plus compliqué de conduire une locomotive que de s'occuper de chevaux ? Que le gain de confort/vitesse/sécurité est indéniable et conséquent ? Parcqu'il permet de transporter bien plus de personnes et de marchandises ?
Lissac n'apportera jamais un facteur 10x en vitesse par rapport au langage C, il n'apportera pas la sécurité qu'apporte un programme écrit en B ou même en Java, il ne permettra pas d'écrire des programmes plus complexes que dans un autre langage (la limite étant surtout liée aux compétences humaines et non techniques), etc.

Ou en Java Grails combiné avec JRuby par exemple.
En .NET y'a aussi MonoRails ou le ASP.NET MVC Framework, qui peut être associé à IronPython et bientôt IronRuby.
Bref ces plateformes offrent le choix des langages et le choix du framework.
Il ne reste pas beaucoup d'avantage à RoR, par contre il lui reste toujours les mêmes inconvénients : pas beaucoup d'acteurs de service et donc pas beaucoup de support ou de compétences, pas beaucoup d'outils (notamment IDE), intégration avec technos existantes limitées, pas d'acteur "principal" garant de la pérénité de la techno (style Sun, IBM ou Microsoft), pas de gros site de référence ayant éprouvé RoR (style Google et autre MySpace ou FaceBook).
Autant de raison qui font qu'en 4 ans RoR ne soit pas plus adopté que ca et s'il n'y a pas d'engagement plus flagrant de gros acteurs autour de cette techno, elle n'est pas prêt d'être adoptée au même titre que l'est par exemple PHP.

Oué bah oué, et ? JRuby ca permet aussi d'utiliser la syntaxe Ruby sans Rails. A l'inverse les frameworks MVC pour Java ou autre se multiplient : on peut donc développer avec un framework similaire à RoR sans la syntaxe Ruby : en Java, en C#, en Python ou je sais pas quoi.
On est d'accord, tout ce qui faisait la plateforme RoR initiale (à savoir un framework web MVC associé à l'environnement Ruby) a été repris ailleurs en intégralité ou en partie.

Ce qui fait la force de Rails n'est pas que le framework, loin de là, c'est surtout Ruby.
C'est aussi ce qui est en train d'être repris dans les autres technos : JRuby ou IronRuby par exemple.
Bref il ne va bientôt plus rester beaucoup d'intérêt spécifique à RoR.

C'est très subjectif... ca veut dire quoi "se porte très bien" ?
Quelle est la proportion d'utilisation de RoR par rapport aux autres techno web (PHP, Java, etc.) ? Quelle est l'évolution de cette proportion depuis 4 ans ?
L'impression générale (mais il me manque des chiffres à l'appui) c'est quand même que l'excitation du début est largement retombée et qu'il n'y a pas de réelle adoption large, faute d'acteur majeur dans le secteur (qu'il soit utilisateur de la techno, fournisseur de service ou fournisseur de softs). Un Google aurait (pourrait) changer la donne.
Bref le buzz est retombé, même si en soit la techno est loin d'être morte et a des utilisateurs.
A mon avis ca va pas s'arranger : les autes techno concurrentes (Java, PHP, ASP.NET, etc.) sont en train de s'approprier ce qui fait la force de RoR et limiter un peu plus l'intérêt de ce dernier.

Pas dans la catégorie "computers", dans la catégorie "notebook". Ca change tout : c'est un marché beaucoup plus restreint avec un public spécifique.
Il ferait téléphone il aurait jouer dans la cours de l'iPhone et donc potentiellement du "grand public".

"Le return car cela permet de faire quitter la fonction en plein de milieu de celle-ci, ce qui est très mauvais."
Pourquoi ?
"Le break, car tu sort d'une boucle n'importe comment."
Cad ?

Tu peux aussi raisonner à l'envers : si la demande se faisait sentir (nombreux retours des commerciaux, nombre de tentatives d'achat en ligne, etc.), alors ils amélioreraient les moyens de distributions.
Bref c'est un cercle vicieux : pas de demande, pas de diffusion. Pas de diffusion, pas de publicité et donc pas de demande.

Ce qu'il faut retenir dans l'histoire, c'est la seule réflexion du commercial : le machin n'a pas de carte SIM. C'est couillon mais du coup c'est pas Orange ou autre SFR qui pourront en faire la pub et le distribuer.Du coup il peut difficilement être présenté autrement que comme un tablet PC "miniature" en rayon même si on peut effectivement téléphoner avec.

Et puis bon, c'est pas non plus complètement faux que de dire qu'en ce moment la mode est au téléphone multimédia (cf iPhone). Bref, le nokia peut très bien ne pas répondre aux besoins du public actuel à cause de ce petit "détail" qui n'en fait pas un téléphone classique.
L'intérêt de passer par le besoin téléphone c'est que le besoin existe (suffit de voir le nombre de personne avec un portable et le nombre de fois qu'ils le changent). Avoir un Nokia en plus dans sa poche, ca intéresse pas grand monde dans l'absolu.

La prise de conscience effectivement c'est bien, mais c'est pas nouveau pour les ordinateurs, Greenpeace par exemple fait pas mal de "pub" autour des problèmes écologiques liés aux appareils électroniques. Sans parler des nombreux reportages télévisés sur les méfaits du recyclage sauvage en Chine de ces appareils.
Mais visiblement l'auteur du journal aurait aimer que le thème soit abordé lors du grenelle au même titre que le problème des transports automobiles. Pour aider le "public" a prendre conscience des dangers potentiels, il faut du concrêt, des éléments de comparaison qui lui parle.
Alors certes, l'informatique pollue sans doute beaucoup, mais comme tout est relatif, il faut bien fixer des priorités. Pour moi la priorité va avant tout là où il y a un impact potentiellement fort. Donc la question reste toujours de savoir : attendre 5 ans au lien de 3 ans pour achter un ordinateur ou utiliser les transports en commun ? Acheter un écran 19" plutôt qu'un 30" ou manger des produits de saison ? Faut-il mieux isoler son logement ou acheter une simple carte graphique intégrée plutôt qu'une GeForceDeLaMort ? Qu'est-ce qui est le plus urgent et le plus efficace ?
Evidcemment l'un empêche pas l'autre, mais je suis pas sûr que c'était le but du grenelle d'être exhaustif.