Est-ce que tu as seulement lu le lien que tu donnes sur ECMA ? Je vais t’aider et citer le passage. « 4.2 Decisions on acceptance shall be made by the General Assembly with a two thirds majority of all the ordinary members. » Tu continues sur le site, et tu as la liste des membres de l’Assemblée générale : 18 noms, de grosses entreprises. Pour entrer il te faut le soutien de 12 des ces entreprises. Après tu peux avoir un droit de regard sans faire partie des décisions, mais on retrouve là encore que des grands noms. Je regarde les faits : c’est un club très petit, ne me dis pas que n’importe qui peut y entrer.
Le C est multi-plateforme, dire le contraire n’est que l’aboutissement d’années de propagande (je soupçonne Java). Quand tu codes en C tu n’as pas a savoir si t’es en little ou big endian, ni la taille de tes pointeurs, ce sont des représentations internes de la machine et le C permet justement de s’en affranchir ! Quand j’écris un int, et durant tout le code, je me fiche des détails techniques de représentation des nombres : endianness, taille des données à la précision numérique près, etc. Quand j’écris un code ANSI C il doit tourner et rendre le même résultat quelque soit la machine le supportant (à la précision numérique près), la force du C est très précisément d’abstraire ces problèmes de représentation interne. Je soupçonne que tu mélanges avec la portabilité des données, binaires, produites et enregistrées sur disque, ce qui n’a rien à voir avec la portabilité du code. Mais ce problème explose au développeur inattentif très précisément parce que le code C a abstrait cette représentation.
Tu dis « la version normalisée est la 3.0 », j’attends tes sources, parce que ce n’est pas ce que dit Wikipedia, du coup je suis allé voir la liste des standard ECMA : C# 4ème édition : juin 2006, selon Wikipedia la sortie de la version 3.0 du langage chez Microsoft date d’Août 2007.
Concernant ACPI, au contraire j’ai parfaitement compris le problème, je l’ai posé en terme d’implémentation de référence : si l’implémentation de référence ne respecte pas le standard, ce dernier ne sert plus à rien. Je fais le parallèle avec la situation de Mono vs. l’implémentation de Microsoft.
Bien sûr qu’il y a un FUD à propos des brevets, demande à Albert, à propos de Linux, à propos de l’attaque contre Tomtom sur le Fat32, tout ceci y participe, utiliser des technologies de chez Microsoft est susceptible de l’alimenter. Pas sur le langage en lui-même : mais ça je l’ai dit, tu n’as juste pas lu, la partie standardisée ou couverte par des accords unilatéraux (ie. Microsoft envers quiconque, quiconque étant égal à all et différent des non-profit ou autre OSS) n’a pas à craindre de brevets. Mais il est difficile de faire la part des choses et de relever ce qui est couvert par les brevets de ce qui ne l’est pas. C’est déjà assez difficile concernant le noyau... c’est une guerre de communication : utiliser des techno. de chez Microsoft c’est donner de la force au FUD.
« Non il y en a au moins 2 vu que Mono implemente C# 4 en toute legalite. » Mono est développé par Novell qui a des accords spécifiques avec Microsoft. Qu’en est-il du reste de l’éco-système, libre, non-libre, commerciaux, etc., qui utiliserait Mono, implémenterait une lib. avec des fonctionnalités proches d’une lib. non couverte par les accords, tout ceci sur une techno. spécifiquement Microsoft, tu vas me dire qu’il n’existe aucun risque de tomber sur une solution proche de ce qu’à utiliser, et breveté, Microsoft ? Le risque est àmha plus grand que de partir from scratch.
Enfin je n’ai jamais dit que Mono devrait suivre à fortiori le standard « comme un petit chien ». Dans ce cas il suit l’implémentation de référence : retour à la case départ, ce sera du Microsoft, ça ne sera plus couvert par un standard, donc soumis à des attaques ou FUD sur les brevets. Ou alors Mono suit sa propre voie, redéfinit un langage à lui, etc., mais on perd toute compatibilité. Je ne sais pas pourquoi je me répète, tu ne vas pas plus lire que la première fois.
[^] # Re: Bonne nouvelle
Posté par nicolas . En réponse à la dépêche Que penser du rachat de Novell ?. Évalué à 4.
Le C est multi-plateforme, dire le contraire n’est que l’aboutissement d’années de propagande (je soupçonne Java). Quand tu codes en C tu n’as pas a savoir si t’es en little ou big endian, ni la taille de tes pointeurs, ce sont des représentations internes de la machine et le C permet justement de s’en affranchir ! Quand j’écris un int, et durant tout le code, je me fiche des détails techniques de représentation des nombres : endianness, taille des données à la précision numérique près, etc. Quand j’écris un code ANSI C il doit tourner et rendre le même résultat quelque soit la machine le supportant (à la précision numérique près), la force du C est très précisément d’abstraire ces problèmes de représentation interne. Je soupçonne que tu mélanges avec la portabilité des données, binaires, produites et enregistrées sur disque, ce qui n’a rien à voir avec la portabilité du code. Mais ce problème explose au développeur inattentif très précisément parce que le code C a abstrait cette représentation.
Tu dis « la version normalisée est la 3.0 », j’attends tes sources, parce que ce n’est pas ce que dit Wikipedia, du coup je suis allé voir la liste des standard ECMA : C# 4ème édition : juin 2006, selon Wikipedia la sortie de la version 3.0 du langage chez Microsoft date d’Août 2007.
Concernant ACPI, au contraire j’ai parfaitement compris le problème, je l’ai posé en terme d’implémentation de référence : si l’implémentation de référence ne respecte pas le standard, ce dernier ne sert plus à rien. Je fais le parallèle avec la situation de Mono vs. l’implémentation de Microsoft.
Bien sûr qu’il y a un FUD à propos des brevets, demande à Albert, à propos de Linux, à propos de l’attaque contre Tomtom sur le Fat32, tout ceci y participe, utiliser des technologies de chez Microsoft est susceptible de l’alimenter. Pas sur le langage en lui-même : mais ça je l’ai dit, tu n’as juste pas lu, la partie standardisée ou couverte par des accords unilatéraux (ie. Microsoft envers quiconque, quiconque étant égal à all et différent des non-profit ou autre OSS) n’a pas à craindre de brevets. Mais il est difficile de faire la part des choses et de relever ce qui est couvert par les brevets de ce qui ne l’est pas. C’est déjà assez difficile concernant le noyau... c’est une guerre de communication : utiliser des techno. de chez Microsoft c’est donner de la force au FUD.
« Non il y en a au moins 2 vu que Mono implemente C# 4 en toute legalite. » Mono est développé par Novell qui a des accords spécifiques avec Microsoft. Qu’en est-il du reste de l’éco-système, libre, non-libre, commerciaux, etc., qui utiliserait Mono, implémenterait une lib. avec des fonctionnalités proches d’une lib. non couverte par les accords, tout ceci sur une techno. spécifiquement Microsoft, tu vas me dire qu’il n’existe aucun risque de tomber sur une solution proche de ce qu’à utiliser, et breveté, Microsoft ? Le risque est àmha plus grand que de partir from scratch.
Enfin je n’ai jamais dit que Mono devrait suivre à fortiori le standard « comme un petit chien ». Dans ce cas il suit l’implémentation de référence : retour à la case départ, ce sera du Microsoft, ça ne sera plus couvert par un standard, donc soumis à des attaques ou FUD sur les brevets. Ou alors Mono suit sa propre voie, redéfinit un langage à lui, etc., mais on perd toute compatibilité. Je ne sais pas pourquoi je me répète, tu ne vas pas plus lire que la première fois.