reno a écrit 3881 commentaires

Bah, une décharge ne vaut rien devant les tribunaux Français, c'est juste un moyen pour le vendeur de se protéger contre l'argument classique: j'ai signé mais je ne savais pas ce que je signait.

C'est le contrat qui fait foi et rien d'autre, je pense.

Bien sûr IAMNAL

>LDAP est un framework, complétement souple

et d'une laideur sans nom, quelqu'un aurait-il un lien vers une explication simple de LDAP?

Je ne comprends rien a ces dn,un, etc..

Je ne sais pas, je ne connais pas outlook.

Ce n'est pas tant les capacité de google calendar qui me gènent mais son interface:
- il y a un peu trop souvent les dates qui reviennent au format américain alors que j'ai changé ce réglage
- je voulais me faire avertir sur un deuxième compte émail, pour une raison inconnue j'ai reçu cet émail la veille et non pas le jour même (peut-être un bug)
- la définition des propriété des taches par clic gauche et non pas droit me gène.
- si tu veux plusieurs rappels, il faut faire plusieurs taches, bof.

Pas que pour les hébergeur à mon boulot, on a besoin à la fois de Microsoft (MS Offfice) et on developpe des applications Linux..

Donc les gens ont soit deux postes, soit une émulation..

Google calendar est un peu primitif quand même..

> ce que j'aime avec pbpg c'est qu'il est tellement de mauvaise foi qu'il donne de lui meme les exemples pour le battre

Euhm, pas toujours, parfois les linuxiens ont aussi leur oeuillères.

Mais il est vrai que pbpg, dès qu'on parle de "vente liée" ou "d'abus de monopole", il ressort texto les arguments de Microsoft, ce qui est bien dommage..

J'ai envie de faire un commentaire sur les cordonnier qui sont les plus mal chaussé pBpG, je ne sais pas pourquoi :-)

Bon le terme fait est un peu fort, singularity étant un projet de recherche..

Bah je n'aime pas non plus le C++, mais l'exemple qui est donné (la gestion de liste chainée) est plus propre en C++ qu'en C.

Sinon dans le genre d'ajout utilisé, je pensais aux annotations utilisé par sparse l'outil utilisé pour trouver des erreurs dans le kernel Linux.

Les plus faciles?

J'espère que tu plaisante..
Le suspend to disk ne m'a pas l'air trivial du tout.
En tout apparement pour Linux ça pose probleme..

Pour le kernel méta-language, ils n'ont qu'a utiliser le C++ ;-)
Ce n'est pas totalement une blague: les dev de L4 l'ont fait (enfin du C++ limité: sans exception et avec d'autres restrictions).

Pas si simple: je crois que le serveur X mappe en mémoire la mémoire de ta carte graphique.
Donc top peut être trompeur dans le cas ou la carte graphique a sa propre RAM.

> le passage de MS-Word à OOWriter pour une utilisation "normale" du traitement ne pose pas de problème

Ben voyons, dans mon entreprise, on a des templates standard qui sont utilisé pour les documents (word maintenant beurk, avant interleaf méga-beurk), les versions d'OO que j'ai testé rendaient très mal ces document, les templates n'étaient pourtant pas très compliqués..

Et pour ce qui est d'avoir utilisé les deux: tous le monde a l'heure actuelle utilise Word donc s'ils passent à OO, ils auront utilisé les deux et se plaindront de la qualité du correcteur orthographique et autre faiblesse d'OO..

Je crois que Scala permet d'utiliser la covariance ou la contravariance.
J'aimes bien ce concept.

> l'avenir des langages objets leur appartient.

Uniquement dans les universités ou à long terme alors:
Self est quasiment inconnu malgrè son âge (pas tellement étonnant car c'était juste une exploration) et Lissac le seul endroit ou j'en ai entendu parler c'est ici!
En plus comme pas mal de langages universitaire, sa syntaxe me prend à rebrousse poil.

Ce qui bien sûr ne prélude pas au succès ou pas du concept de langage à prototype.
Eiffel est un bon exemple de langage qui n'a pas réussi à percer malgrès bien des qualités, et les langages fonctionnels soi-disant supérieurs restent à la traine depuis combien de temps?

Ruby et Java par contre sont des bons exemples de ce qui permet à un langage de percer (enfin Ruby n'est pas encore vraiment sorti de l'auberge et Java bien qu'utilisé n'est pas vraiment apprécié).

D'un point de vue programmeur certes, mais d'un point de vue utilisateur il a raison.
Quand le logiciel perd sa configuration, ne peut plus lire les données de la version précédente, ne tourne plus sur l'OS mis à jour, etc., l'utilisateur est "un peu" frustré.

Il est vrai aussi que l'accumulation de bidouilles pour garder la compatibilité peut en arriver a rendre le code difficilement maintenable..

Tu pourrais préciser même: la rentabilité à court terme.

A long terme, le succès peut aussi amener la rentabilité évidemment c'est loin d'être garanti.

Bon dans le cas particulier de Lissac, il y a tellement de language en concurrence que c'est pas gagné même s'il devenait libre:
D a une communauté assez importante par exemple, Scala est pas mal comme langage, etc..

Ce que je trouves le plus drole/tragique dans l'affaire, c'est qu'il est si dur de s'arréter de fumer, mais si simple de ne jamais commencer.
Il faut vraiment avoir le cerveau visser a l'envers pour commencer à fumer..

> Je vois par exemple que Xara utilise son propre format... Je trouve ça dommage comparé à Inkscape qui utilise le SVG...

Oui, enfin je crois que Xara existait bien avant SVG, donc cela n'est pas tellement surprenant que son format interne soit différent.

Ahem, je ne vois pas en quoi si le projet était LGPL les Cisco et les autres auraient eu a payer pour l'utiliser..
Le seul payement serait un payement en ligne de code s'ils y font des modifications, à part ça..

J'aurai tendance à preférer l'esprit de la LGPL à celle de BSD (plus équitable pour le developpeur sans être "pénalisante" comme la GPL), son seul problème a la LGPL c'est son implémentation: comme elle est 'mal fichue' (il n'y aucune raison d'empecher la liaison statique, la seule chose qu'il faut empecher, c'est le masquage/remplacement de l'API par une variante externe qui pourrait faire des corrections sans fournir les sources), il y a plein de variantes de la LGPL qui tentent de corriger ses défaut.

Dommage que la LGPL soit le vilain petit canard noire, parce que c'est celle la qui nécéssite vraiment une nouvelle version..

> vous avez donc parfaitement le droit de copier ces cds.

Tu t'avance peut-être un peu la: je me souviens que XXX considèrait les images ISO comme "copyrighté" et donc ils considéraient qu'on pouvait redistribuer les sources, des images ISO reconstruites à partir de l'ancienne mais pas l'ancienne directement.

Je ne dits pas que leur point de vue était forcément la vérité juridique, mais en tous cas ils avaient un point de vue très différent du tien, donc prudence.

> quand on code, on le fait d'après une spécification.

Certe et le propre d'une spécification "normale" est de ne pas entrer dans les détails sur le comment mais indique le résultat désiré sans entrer vraiment dans le détail non plus d'ailleur.

Par rapport aux spec avec lesquelles j'ai a bosser, pour pouvoir éventuellement genere du code avec, il faudrait que la taille des specs soit multipliées par 10 et encore, c'est probablement sous estimé.

> Une erreur de spec c'est d'autant plus dramatique si tu dois faire du code derrière.

Oui, enfin le boulot du codeur n'est pas de prendre la spec et de pisser du code, mais de l'interpreter, remplir les blancs, discuter, etc..

Ce qui permet de trouver aussi des erreurs de specs, et je peux te garantir que j'en ai trouvé quelqu'une.. Avec une spec qui grossit d'une taille *10, le nombre d'erreurs grossira aussi.

La génération automatique de code, j'ai déja donné et même sans partir de spec, cela a des avantages mais aussi de gros inconvénient: temps de compil monstreux (genre le générateur qui génere une classe différente par type d'entier différent, oui c'est du vécu), opacité du code généré (à débugger c'est "sympa": les débuggeur remontent rarement au niveau du générateur initial, débuggé du code généré automatiquement c'est à peu près aussi drole que d'aller chez le dentiste).

Pour la première partie, pas d'accord mais bon "des gouts et des couleurs"..

> L'avenir des langages est pour moi vers des langages de spécifications en langages naturels.

Bof, on avait des langages de dev en 'language naturel' (COBOL) et on en est revenu.
Et remplacer des langages de dev, par des langage de spec n'apporte pas grand chose: au lieu d'avoir des erreurs de codage, on a des erreurs de spec, le gain n'est pas terrible..

>>
A première vue, du point de vue la syntaxe et du fait que tout à l'air objet pour Ruby et Lissac, Lissac me fait penser à Ruby
<<
Tu es allé cherché la ressemblance ou??

C'est amusant, cela m'a fait exactement l'effet opposé coté syntaxe: Ruby a une syntaxe riche destiné à simplifier la vie au programmeur et Lissac a une syntaxe destiné à simplifier la vie au compilateur.

>Le seul truc qu'on ne pourrait pas techniquement faire sans VM serait une exécution 'sandboxée'

Si on te prends à la lettre tu as raison bien sûr.
Mais des chercheurs pour Microsoft bossent sur un OS Singularity écrit en C# mais compilé "normalement" sans VM, les threads de l'OS partagent tous le même espace mémoire mais ils utilisent des preuves de programmes pour s'assurer que deux thread ne vont pas écrire ailleurs qu'elles en ont le droit, ce qui est une forme de 'bac à sable'.

Ceci dit, tout l'OS n'est pas prouvé bien sûr..

Un arbre, un tri, je cherche à me souvenir quand j'ai eu à m'intérresser à ça, ouhla ça fait loin..

Pour le tri, il y a des librairies qui font cela que l'implémentation soit récursive ou pas bof.

La plupart du temps quand on programme, cela tient plus de la recette de cuisine avec des bon vieux automates à état fini qu'aux algorithmes que tu as cité, donc la recursivité, à part dans les bouquins d'algo, bof!

> tu veux dire que tu n'as jamais accidentellement fait une affectation en lieu et place d'un test ?

Si, mais comme j'utilise gcc en -Wall, j'ai corrigé le probleme rapidement.

De plus c'est un probleme qui vient surtout des types en C: si les int et les bools étaient des types disjoints, dans la majorité des cas le compilateur se plaindrait si on faisait une affectation à la place d'un test. Il est vrai que cela pourrait toujours se produire c'est en faisant un test sur une variable booleenne..