Pour ECMA, les membres que tu cites ne font pas parti de l’assemblée générale, qui, seule, vote pour ou contre l’inclusion des nouveaux membres à la majorité des 2/3 et pour la publication des normes (dans le menu présentation il y a un pdf, je l’ai un peu parcouru). Les membres que tu cites ont des droits dans les comités techniques, c’est-à-dire l’élaboration des normes. Et en tout il n’y a que 60 entreprises regroupées sous ECMA, toutes ont nécessairement été acceptées par l’AG (c.-à-d. les 18 entreprises pré-citées).
Le C est portable, oui, il a été conçu pour ; Wikipedia le dit, mes professeurs me l’ont toujours dit, et je le constate tous les jours : je n’ai jamais eu à porter un code, oui, parce que précisément le C est portable, tous les jours j’utilise le même code sur des machines indifféremment 32 ou 64 bits. Que tu puisses faire des choses non-portables en C démontre juste que ce n’est pas un langage neuneu-proof, mais pas portable : non ; Malloc t’assure l’alignement des données, tu les dé-s-alignes : c’est ton problème.
Pour revenir sur le cœur du sujet : je ne crois pas que le numéro du standard correspond à la version du langage, en tout cas les fonctionnalités qu’apportent la version du standard ECMA no4, si j’en crois ton lien, correspondent aux fonctionnalités du langage en version 2 de chez Microsoft, si j’en crois Wikipedia. La liste des fonctionnalités dans les version 3 et 4 sont donc non normalisées, avec les conséquences que j’ai exposées.
Il reste la question de différencier de ce qui est couvert ou pas, si c’est clair pour toi, tant mieux. Mais je le répète tout ceci est une guerre de communication (c’est le principe du FUD), pour aller vérifier que telle implémentation d’un langage est conforme à telle standard, et donc non soumis à attaque par brevets, il faut avoir des compétences au seins de l’entreprise, et pas des moindres : tout ça pour vérifier qu’on peut utiliser Tomboy (je force le trait) ? Bref s’il faut parcourir une spécification d’un langage et son implémentation pour vérifier les choses, ça signifie que c’est loin d’être simple.
ACPI était un exemple pour mon autre argument : on a d’une part le problème du FUD sur les brevets, d’autre part le problème de la main-mise sur le langage, que ce soit au niveau institutionnel (standard, qui sont plus une solution qu’un problème pour apporter quelques garanties), ou que ce soit au niveau pratique. Et là ACPI montre que grâce à une implémentation de référence, qui n’est rien d’autre que le standard de facto (hors toute considération de l’existence d’un standard institutionnel), Microsoft a su tourner la situation à son avantage. Il est difficile de croire qu’ils n’en feront pas de même pour le langage dont il est question ici.
Enfin vient l’utilisation de techno. Microsoft, oui, le risque « par hasard » n’est pas si petit que ça une fois que tu t’es donné l’objectif de : ré-implémenter avec une technologie Microsoft, avoir une API proche de la lib. Microsoft, etc. Tu offres mécaniquement plus de possibilité de tomber sur le coup d’un brevet. Sans compter que tu as toujours ce problème de communication et de FUD qui vient : cela donne plus de poids à ce dernier pour faire croire qu’il y a lieu de s’inquiéter.
[^] # Re: Bonne nouvelle
Posté par nicolas . En réponse à la dépêche Que penser du rachat de Novell ?. Évalué à 4.
Le C est portable, oui, il a été conçu pour ; Wikipedia le dit, mes professeurs me l’ont toujours dit, et je le constate tous les jours : je n’ai jamais eu à porter un code, oui, parce que précisément le C est portable, tous les jours j’utilise le même code sur des machines indifféremment 32 ou 64 bits. Que tu puisses faire des choses non-portables en C démontre juste que ce n’est pas un langage neuneu-proof, mais pas portable : non ; Malloc t’assure l’alignement des données, tu les dé-s-alignes : c’est ton problème.
Pour revenir sur le cœur du sujet : je ne crois pas que le numéro du standard correspond à la version du langage, en tout cas les fonctionnalités qu’apportent la version du standard ECMA no4, si j’en crois ton lien, correspondent aux fonctionnalités du langage en version 2 de chez Microsoft, si j’en crois Wikipedia. La liste des fonctionnalités dans les version 3 et 4 sont donc non normalisées, avec les conséquences que j’ai exposées.
Il reste la question de différencier de ce qui est couvert ou pas, si c’est clair pour toi, tant mieux. Mais je le répète tout ceci est une guerre de communication (c’est le principe du FUD), pour aller vérifier que telle implémentation d’un langage est conforme à telle standard, et donc non soumis à attaque par brevets, il faut avoir des compétences au seins de l’entreprise, et pas des moindres : tout ça pour vérifier qu’on peut utiliser Tomboy (je force le trait) ? Bref s’il faut parcourir une spécification d’un langage et son implémentation pour vérifier les choses, ça signifie que c’est loin d’être simple.
ACPI était un exemple pour mon autre argument : on a d’une part le problème du FUD sur les brevets, d’autre part le problème de la main-mise sur le langage, que ce soit au niveau institutionnel (standard, qui sont plus une solution qu’un problème pour apporter quelques garanties), ou que ce soit au niveau pratique. Et là ACPI montre que grâce à une implémentation de référence, qui n’est rien d’autre que le standard de facto (hors toute considération de l’existence d’un standard institutionnel), Microsoft a su tourner la situation à son avantage. Il est difficile de croire qu’ils n’en feront pas de même pour le langage dont il est question ici.
Enfin vient l’utilisation de techno. Microsoft, oui, le risque « par hasard » n’est pas si petit que ça une fois que tu t’es donné l’objectif de : ré-implémenter avec une technologie Microsoft, avoir une API proche de la lib. Microsoft, etc. Tu offres mécaniquement plus de possibilité de tomber sur le coup d’un brevet. Sans compter que tu as toujours ce problème de communication et de FUD qui vient : cela donne plus de poids à ce dernier pour faire croire qu’il y a lieu de s’inquiéter.