TImaniac a écrit 6420 commentaires

Ca montre clairement la supériorité de l'ODF en matière d'interopérabilité puisqu'il n'a que 40 erreurs sur son site communautaire : http://validator.w3.org/check?uri=http%3A%2F%2Fopendocument.(...)

Pour relativiser, si on valide le site openxmlpourtous en HTML 4.01 Transitional (qui semble correspondre un peu plus au "contenu" du site), y'a "que" 38 erreurs : http://validator.w3.org/check?uri=http%3A%2F%2Fwww.openxmlpo(...)

héhé... en utilisant un débuggueur d'un langague impératif, on comprend mieux comment marche notre programme impératif ?
C'est surtout que le débuggueur montre le fonctionnement et le comportement de la machine en proposant une vue des registres, des instructions machines, etc.
Bref c'est plus facile d'écrire le logiciel dans le même "mode" que celui qui l'exécute.

. Je crois que tu sous-entends qu'un logiciel ne se comprend qu'en impératif, ce qui n'est pas le cas.
Je dis juste qu'une machine exécute un ensemble d'instruction de manière séquentielle. L'impératif n'est qu'une "surcouche" d'abstraction, mais le principe d'exécution est identique.

Il n'y a pas de lien entre le fait qu'une machine fonctionne en impératif et le fait que les gens semblent appréhender plus facilement l'impératif.
Ben moi je dis que y'a un lien. A plus forte raison avec les langages bas niveau comme Asm ou C.

Au passage, le procédural, c'est pas vraiment proche de comment marche la machine, la machine n'a pas de procédure, juste des "goto".
Et bien voilà on y est : même le procédural devient "compliqué" pour un développeur : combien on commencé par utiliser les goto dans tous les sens ?

Et je comprends pas pourquoi tu parles de la machine ici.
Quand je lis un algorithme écrit de manière impérative, je comprends l'état de la machine instruction après instruction, ce que contient chaque variable, etc. En procédural, il faut que j'interprête et comprenne ce qu'à exprimé le développeur. Et c'est pas aussi simple. Encore plus à pondre.

Je suis pas d'accord avec ta justification comme quoi c'est parce que c'est proche de la machine
Je dis juste que le fonctionnement de la machine est un "plus", je dis pas que c'est la raison première. D'ailleur c'est sans doute pour la même raison que les machine marche de manière impérative, c'est pour la simplicité ;)

l'investissement de l'apprentissage du fonctionnel sera rapidement rentabilisé par la rapidité de lecture et d'écriture de code par la suite.
Ca reste à prouver. La difficulté du métier n'est pas tant dans le langage mais dans la multiplicité des outils, bibliothèques, technologies, dans l'accumulation des bonnes pratiques, la mise en place de méthodes de travail, etc. Franchement le l'investissement dans un un type de langage "plus puissant" si celui-ci met la barrière plus haut pour son apprentissage et donc limite le nombre de développeurs compétents me paraît pas être un investissement "rentable".

Mais je ne suis pas sur que ce soit le cas de la majorité des programmeurs "impératifs".
Ils ont tous plus ou moins cette même perception, que ce soit à travers un débuggueur ou tout simplement en constatant la façon dont le code est exécuté.

Toi qui parlais plus haut des tournures de phrases tarabiscotées, celle-ci ne veut rien dire : pas mieux que quoi ?
Ben en gros ceux qui ont commencé par le fonctionnel trouvent pas ca plus facile après avoir appris l'impératif. Qu'on ai commencé par Scheme ou Pascal, on avait les mêmes difficultés en OCaml et la même facilité en Java.

Tu penses aux transistors dans le cpu ? tu penses à la gestion des registres du processeur pour gérer ton code ? Non, je ne pense pas.Non je penses plutôt à sa façon d'exécution les instructions du logiciel, ce qui est encore ce que produit le développeur quoi.

je dirais même que l'on pense avec la langue que l'on connait, ce qui est la thèse de certains linguistes
Ben justement on connaît le fonctionnement de l'ordinateur pour exécuter un logiciel, et c'est cette proximité avec la représentation d'un code procédural qui fait que ce dernier est plus facile à apréhender.

Après quelques temps à avoir du mal avec le langague, je me suis mis à penser en fonctionnel, et OCaml est devenu beaucoup plus simple à utiliser. Maintenant, quand je code en C, j'ai même tendance à penser fonctionnel
Mais moi aussi je penses de plus en plus fonctionnel, ca n'empêche que je trouve que le travail intellectuel qu'il nécessite (à savoir un gros travail de synthèse et un haut niveau d'abstraction) est beaucoup plus contraignant qu'un "simple" code procédural.

qui est que tu penses en impératif parce que ton ordinateur pense en impératif
J'ai pas dit ca. J'ai dit que c'était plus intuitif de comprendre ce que fais un code impératif car sa lecture suit le déroulement de son exécution par la machine. Bref on "pense" mieux le comportement du soft.

Globalement l'argument généralement utilisé qui consiste à dire que si l'impératif est généralement considéré comme plus facile c'est parcqu'on commence par ça me paraît fallacieux (c'est moche c'est mot c'est hallucinant) : mon expérience montre qu'en commencant par le le fonctionnel, c'est pas mieux.
Il y aura toujours une difficulté à passer d'un mode à l'autre pour un débutant qui a appris d'une certaine manière, mais c'es pas pour autant que les 2 sont aussi "simples" : pour moi le mode impératif est beaucoup plus "facile" à comprendre.

Pour rigoler tiens faudrait que les notices de montages de meuble soit en fonctionnel et non en procédural et comparer après la progression des ventes chez Ikea ;)

Belle démonstration. "ce que tu dis est faux car il faut bien comprendre que ce que tu dis n'est pas exact."
Désolé mais moi quand je code en C je m'imagine très bien le déroulement du code tel qu'il est exécuté par le processeur. C'est d'ailleur très bien représenté intuitivement par les débuggueurs.
Tu peux comprendre que certains codent en pensant à la façon dont le code sera exécuté ? Je reste persuadé que c'est le cas de beaucoup de monde. Et c'est une grosse différence avec le fonctionnel où tu cherches plutôt à exprimer le résultat que tu veux obtenir. Et ca c'est beaucoup plus de réflexion de l'exprimer.

Pour avoir subit un cursus "impératif" et rejoint une filière de matheux qui avait commencé par du scheme, je peux t'assurer que la galère avec OCaml était identique. A la différence que je me balaidait sur le reste (C/Java/ASM &co).
Le problème du fonctionnel c'est que ca t'oblige à être synthétique là où l'impératif te permet d'avancer pas-à-pas vers une solution même si c'est pas clair dans ta tête. Bref c'est moins "prise de tête" même si le code produit n'est pas aussi joli et pertinent.
De plus, les ordinateurs fonctionne de manière impérative : il est donc plus facile de s'imaginer le déroulement du code que t'es en train d'écrire.

Mais microsoft va-t-il sortir un jour ASP.NET for F#, pour concurrencer ocsigen ??
Ben c'est déjà possible :)
http://tomasp.net/articles/aspnet-fsharp-intro.aspx
C'est quand même le but de .NET de pouvoir partager le même framework (web ou autre) entre plusieurs langages...
Et puis bon avec C# 3 on peut déjà faire pas mal de fonctionnel ;)

Si Stallman avait choisi une licence plus permissive, GNU aurait fini comme Unix: propriétarisé, balkanisé etc ....
On est d'accord, mais il manque bien une dimension morale là dedans : d'après tes explications, la licence a été conçu non pas pour représenter la vision du logiciel libre pour les développeurs en soit mais a été faite pour être répendu au maximum : suffisament restrictive pour qu'on ne puisse pas s'approprier le code n'importe comment et suffisament permissive pour qu'un max de gens l'utilise.
Bref la GPL est plus une "arme" pour servir les intérêts de la FSF qu'une licence qui représente la vision du développeur. Alors parler de morale et "parasitage" dans ce contexte me paraît mal placé...
Si un développeur trouve anormal qu'une grosse entreprise utilise du code GPL sans contribuer en retour, qu'il utilise pas la GPL mais une licence adapté à SA vision. Dans le cas contraire, qu'il ne se plaigne pas.

Une licence qui imposerait à l'utilisateur de contribuer en retour ne mériterait pas le qualificatif de libre
Bof, vu que la définition de logiciel libre a été rédigé par les mêmes qui ont fait la GPL, ca n'aurait pas choquer grand monde... Pour beaucoup de développeurs, la GPL est trop restrictive et prive l'utilisateur de libertés (certains lui préfère donc d'autres licences comme MIT, LGPL, etc.)

De plus, il fallait un minimum de souplesse pour que la GPL puisse se répandre
Le but n'est pas de "répandre" une licence : le but est de proposer une licence qui convienne aux développeurs qui ont une vision commune des "logiciels libres" pour diffuser leurs travaux.

Surtout qu'en l'occurence ce n'est pas la FSF qui s'occupe du kernel, il ne faut pas confondre ceux qui ont écrit la GPL et ceux qui l'utilisent pour diffuser leurs softs. Il est d'ailleur notoirement connu qu'il y a des divergences d'opinion importante entre la FSF et Linus Torvald par exemple.

mais tu ne respectes pas la philosophie des personnes qui l'ont conçut.
Difficilement défendable : Stallman & la FSF n'ont pas pu ignorer la situation de l'utilisateur qui ne contribue pas. Si c'était vraiment contraire à leur morale, ils auraient pu ajouter des clauses spécifiques à la licence en restreignant tout ou parti des droits qu'elle donne à l'utilisateur.
Je pense que ce n'est pas moral avant tout de TON point de vue (et sans doute de beaucoup de monde il est vrai).

Canonical est une société capitaliste situé dans un paradis fiscal destiné à gagner de l'argent
Là encore il y a une confusion avec le jugement moral de l'objectif d'une entreprise, mais la GPL ne s'oppose absolument pas aux usages commerciaux et ne les limitent pas alors que ca pourrait être le cas.

On en arrive à un problème récurrent et très répendu : la GPL se veut la licence "de référence" du "logiciel libre", mais tout le monde a une vision différente de ce qu'il faut/faudrait pouvoir faire avec un logiciel libre. Quand le problème de vision vient des utilisateurs c'est pas trop génant (quoique) mais parfois ca vient des développeurs eux-même.

la question n'est pas de savoir si MS "comprend" la GPL ou non, là n'est pas la question, la question est de savoir si un tribunal "comprend" cet engagement comme compatible avec un soft publié sous GPL. MS dit clairement que pour eux et d'daprès les retours qu'ils ont eu, y'a pas d'incompatibilité mais ils ne peuvent pas se prononcer universellement.
C'est pas une question de ressource, c'est une question de ne pas se mettre à la place du juge, à plus forte raison quand on est partie.

Et notons bien le fonctionnement :
1- on fait/publie la spèc
2- on implémente

Avec MS-OOXML c'est :
1- MS implémente
2- MS fait/publie la spèc (et optionnellement la ratifie ISO).

Oué oué oué, genre l'ODF n'avait aucune bribe d'implémentation dans OOo avant sa ratification ISO c'est bien connu, la spécification des formules dans la version suivante d'ODF ne sera pas du tout basé sur l'implémentation actuelle dans OOo c'est bien connu, le format OOXML retenu à l'ISO est déjà intégralement implémenté par MS c'est bien connu (ca doit être dans Word 95 je pari).

Ce que t'as du mal à comprendre, c'est qu'OOo ne sait absolument pas ce qui est couvert par des brevets MS. Toi non plus d'ailleur. Pas plus qu'ils ne savent si ce n'est pas couvert par d'autres brevets détenus par d'autres entreprises.
Pas plus que tu ne sais si le processus d'interprétation d'un document MS-OOXML ne contient pas des procédures brevetés.

Je te rappelles également que OOo a toujours eu pour objectif d'avoir un maximum de compatibilité avec les formats de MS, quelque soit les problèmes de brevet et l'ouverture du format en question.

C'est définitivement le cas et sans le moindre doute pour ODF. Que MS fasse de même.
Ah bon ? Parcque SUN a fait une implémentation GPL ca serait une preuve ? Elle est où l'étude de la FSF à laquelle tu tiens tant ?
Tu es persuadé que MS n'a aucun brevet sur l'ODF ou OOo ? Pareil pour une autre entreprise ?
On n'en sait _rien_. C'est pas parcque tu vas taper tu points sur la table en sortant des mots comme "définitivement" que ca va devenir vrai. C'est pas parcque SUN s'engage vis-à-vis de l'ODF que "pouf" ca devient "compatible" GPL.

Le réel problème, tu le connais très bien : les brevets sur les softs, ca pu, ils créent une incertitude pérpétuelle. Prétendre ou affirmer quelque chose est vraiment malhonnête.

Même si une FAQ n'a pas de valeur juridique (quoique j'en sais strictement rien, mais visiblement c'est indispensable à ton raisonnement), une FAQ a au moins l'utilité d'aider les noobs comme toi et moi à intepréter un texte. En ce sens elle est sans doute beaucoup plus pertinente pour nous tous, à commencer par toi et tes traductions douteuses.

ODF. OOo ne supporte pas et n'implémente pas MS-OOXML.
Explique moi la différence entre :
"implémenter MS-OOXML" et "offrir la fonctionnalité qui propose de lire, écrire et interpréter le contenu d'un document au format MS-OOXML ?
Et ca démontre une mauvaise foi de qui là ?

Ca c'est de la preuve.
Prouve plutôt tes propos : prouve que si Microsoft annnoncait clairement dans un communiqué la compatibilité de la GPL, cela serait une vérité universelle, et que si MS l'a dit, ca a beaucoup plus de valeur que si un tribunal le dit.

ps: au moins SUN ils ont ete honnete lorsqu'ils veulent pas un truc compatible GPL ils le disent clairement.
Quand tu comprendras que ce n'est pas à une entreprise de décider de la légalité ou non de telle compatibilité avec telle ou telle licence de manière universelle dans tous les pays du monde.

Le qui dit "ça couvre tout même ce qui est optionnel" ou le "ça ne couvre que ce qui est nécessaire pour être une application confirme ET si c'est décrit en détail".
Encore une fois, il n'est nullement fait référence à une quelconque conformité.

Et ce qu'il faut noter c'est que ça ne couvre que ce qui est nécessaire pour être une application conforme.
Ca c'est ta traduction. Il n'est nullement fait référence à une quelconque "conformité" (conformance en anglais, si tu trouves le mot tu m'appelles) pour limiter l'applicabilité de l'OSP.

Evidemment que je le sais, j'essayai juste de suivre le raisonnement de IsNotGood en reprenant mot à mot sa phrase au cas où t'aurais pas remarquer.

OPS ne permet pas à une implémentation de MS-OOXML d'être compatible GPL
Ah donc OpenOffice.org 3.0 ne sera pas compatible GPL puisqu'ils vont proposer une implémentation de OOXML. Faudra penser à passer un coup de fil à Sun pour les prévenir.

OPS ne permet pas à une implémentation de MS-OOXML d'être compatible GPL :
http://www.softwarefreedom.org/resources/2008/osp-gpl.html
C'est pas aux avocats de la FSF d'en décider. C'est à une jurisprudence. Les avocats ont une vision tout sauf objective de part leur position.
D'ailleur au passage, leur premier argument tombe justement avec cette dernière news :
"New versions of previously covered specifications will be separately considered for addition to the list."
Quand au 2ème argument, il s'applique de la même manière à SUN et l'ODF.

qui sont nécessaires pour implémenter uniquement les parties requises de la Spécification couverte qui sont décrites en détail
et ? Si tu veux implémenter "intégralement" la specification, toutes les parties sont requises (exceptées celles qui références des specs "externes"). Ton coup du WinZip c'est uniquement si on veut implémenter le minimum en restant "conforme". En aucun cas l'OSP ne limite les engagements au code minimal nécessaire pour être conforme.
Tu remarqueras que même les avocats de la FSF ne disent rien par rapport à ca.

On est ravis d'apprendre que les commandes copy et del sont couvertes par OSP.
Oué, enfin on s'en fou, là n'est pas la question : savoir quel est le programme minimal qui peut prétendre être conforme à la norme n'a rien d'intéressant dans le contexte qui nous intéresse. Ce qui est important c'est les engagements de MS vis-à-vis des implémentation d'OpenXML (quelle soit complète ou partiel), rien à péter de WinZip, tu en conviendras.