reno a écrit 3886 commentaires

J'aime bien le blog de Miguel qui met les choses en perspectives..

> Alors, il n'y a pas de raison que la Chine n'arrive pas à s'imposer aussi dans le domaine du microprocesseur.

Dans l'embarqué d'accord.
Mais dans le monde du PC, il y a une raison, ça s'appelle la compatibilité logicielle.
Regarde l'histoire des processeurs, pour les PC et les petits serveurs: c'est Highlander: "il n'en restera plus qu'un.".
Si la Chine avait réussi a utiliser Linux a la place de Windows, la compatibilité x86 serait moins importante (et encore!: plugin flash,acrobat, etc..), mais pour le moment ce n'est pas le cas..

Et la machine faible consommation et silencieuse a 100$, ça va exister bientot, c'est un OLPC..
D'ici quelques années s'il y a une seconde version, il n'y a pas de raison qu'il n'atteigne pas le GHz.

A part une soi-disant(*) volonté d'indépendance de la Chine, je ne vois ce qui ferait que le Godson réussirait la ou les alternatives actuelles au PC x86 classique sont ignorés (il y a par exemples des machines a base de PPC: personne ne les achètes: trop cher car frais de développement amorti sur de petite série).

*: assez théorique la volonté d'indépendance sur certains point: combien de PC tournant sous RedFlag Linux en Chine? Beaucoup moins que sous Windows!

>C'est quoi ce bug de format de date qui est dans openxml selon toi ? J'aimerais bien les details.

Oh, une broutille il ne compte pas correctement les années bissextile:
http://www.grokdoc.net/index.php/EOOXML_objections#The_Grego(...)

>étant donne que tu n'as meme pas jete un oeil a un document que tu critiques, ca me fait bien rire.

La paille et la poutre: tu ne savais même pas que Microsoft conservait des bugs stupide sur la gestion des dates d'une version a l'autre, avec cette mentalité la, la qualité du résultat n'est pas étonnant..

> Pour les activités, on propose à un garçon de faire du foot, et à une fille de faire > de la danse.
> Etc.
> (Ce sont des généralités évidemment)

Aux USA le soccer (football) est aussi vu comme un sport féminin par contre le football américain lui comme un sport masculin.

Donc l'envoi de la balle serait inversé aux USA: pieds pour les filles, mains pour les garçon, amusant non?

>En effet une des grandes force de Caml est que l'algorithme de typage est prouvé

Bof, la tête du programmeur, elle n'est pas prouvée elle..
Dans les cas ambigu, je pense qu'il est préférable que l'algorithme d'inférence de type sorte une erreur a la compilation, après tout pour corriger il suffit de rendre explicite le type désiré.

>>MSOffice utilisera XPS par défaut.
>Faux. Par défaut MS Office ne supporte pas l'XPS,

Tu as raison, MS avait prévu de supporter XPS en standard, mais ils ont retiré cette fonctionnalité, je l'ignorai. Probablement la peur d'un procès anti-trust.

Ca change pas mal de chose..

Ton post est assez 'décousu' mais je vais essayer d'y répondre.

>deuxièmement la syntaxe par défaut est probablement le moindre des problèmes.

Et bien dans mon cas personnel, cela a suffit pour me dissuader d'apprendre caml. C'est en parti la syntaxe, en parti l'accent mis sur le coté fonctionnel dans le livre (alors que c'est "vendu" comme étant un langage mixte).

Ceci dit, je ne suis pas totalement réfractaire au fonctionnel: Scala (mélange objet/fonctionnel) me paraît intéressant.

Pour le shell, certes sa syntaxe n'est pas terrible, mais il répond a un besoin auquel les autres langages ne répond pas, c'est pour ça qu'on continue a s'en servir.

Sinon je ne vois pas trop le rapport avec Coq, outil peut-être intéressant, mais vu le jargon obscur utilisé, je n'ai pas eu envie d'apprendre.

Plutôt d'accord: Microsoft fournit un lecteur XPS avec Vista, MSOffice utilisera XPS par défaut.

Avec le monopole MSOffice + le monopole Windows comme bras de levier, franchement cela ne m'étonnerait pas que le PDF soit quasi-mort d'ici quelques années, même pas besoin d'utiliser MSN messenger ou hotmail..

Certes, cela va prendre du temps: Vista va mettre beaucoup de temps a s'imposer et la nouvelle version de MSOffice aussi (changement d'interface, changement de format de document, ça fait beaucoup), mais avec le renouvellement du parc des PCs..

Comment veux-tu qu'un langage devienne populaire si même ceux qui aiment le langage utilisent des préprocesseurs??

La syntaxe *par défaut* doit attirer les programmeurs, autrement il ne décollera jamais..

L'article de Slashdot, comme souvent, c'est du n'importe quoi: ce qui a été jugé, c'est 2 patentes *supplémentaires* que voulait utiliser Qualcomm, ce sont ces deux patentes qui ont été "invalidée", mais cela n'empeche que H264 est bardé de patentes mis dans un 'pot commun' dont il faut acheter les droits s'il faut s'en servir (dans les pays ou les brevets logiciels sont autorisés).

Note quand même que c'est une situation temporaire: quand la JVM sera vraiment disponible, il est fort probable que la majorité des distributions Linux installent 'de base' Java.

On sent bien que l'équipe d'organisation a fait un gros boulot de communication pour avoir un résultat pareil, félicitations..

Note que si tu faisais un effort minime du type: Zabbix -> Zabbix (outil de supervision) et 'capacity planning'-> planification/prédictions des besoins(?) , ça irait quand même mieux..

>Quelque chose me dit que le succès ne sera pas au rendez vous ....

Bin ça dépend du besoin..
Au boulot, le format de documents de mon entreprise est .doc donc on utilise CrossOver pour pouvoir utiliser Office sur Linux: il y a un marché pour les logiciels "propriétaire" sur Linux.

Maintenant l'intérêt de lire des .wmv sous Linux..

D implémente aussi la programmation par contrat, mais je suis d'accord, il n'est pas encore au niveau "industriel" (librairie standard insuffisante).

Les dev Smalltalk ont travaillé sur des projets pour les enfants, pas étonnant qu'ils soient motivés par l'OLPC.

Pour ce qui est de "l'erreur métier", c'est mieux oui, mais entre une appli que se plante de bonne heure grace a un contrat mais qui ne fait pas n'importe quoi ou une appli qui fait n'importe quoi, je prefere la premiere.

Le probleme était que Sony n'indiquait pas que le baladeur était restreint a lire la musique vendue par Sony.

Microsoft ne t'oblige pas lire de la musique avec DRM, si j'ai bien compris Vista impose juste de respecter la DRM quand il y en a, c'est très différent..

Le lien vers Sony ne fonctionne pas, mais d'apres l'article Sony ne respecterait pas la décision de justice imposant l'affichage de celle-ci sur le site web: ce n'est pas normal ça veut dire que l'amende est trop faible (1000E par jour pour Sony, c'est ridiculement faible).

> J'espère qu'avec le rachat par AMD, ATI va nous pondre des drivers open-source,

C'est une possibilité bien sûr, mais AMD n'a rien dit|promis sur ce sujet.

>>OpenGL est complétement dépassé niveau fonctionnalité par rapport à Direct3D
>Soit tu ne connais rien en 3D, soit tu as des informations que personne d'autre n'a, tu peux étayer tes affirmations ?

Je pense aussi qu'il galege, le seul point sur lequel D3D a peut-être un avantage sur OpenGL est sur l'étage 'geometry shader' prévut dans DirectX10, il ne me semble pas que cette fonctionnalité soit accessible avec OpenGL..

Quelqu'un peut confirmer/infirmer?

>il me semble que Mandr{ake,iva} utilise un max de Perl pour ses outils système

Pour avoir essayé de corriger un bug qui m'ennuyait dans un outil de Mandrake et avoir fuit devant du Perl (langage illisible s'il en est et a mon avis pas vraiment adapté pour codé un IHM dans ce cas la), je confirme.

Bin l'idée d'alioth, c'est de mesures les perfs de code "typique" dans chaque langage ce qui inclut l'utilisation des librairies 'typique' des langages concerné aussi, le but n'est pas de faire des micro-optimisations manuelles du code, il est interdit par exemple de dérouler les boucles manuellement.
Donc en C d'utiliser GMP et en Java d'utiliser BigInteger pour faire des calculs sur des grands entier, cela correspond bien a du code typique et cela ne me choque pas particulièrement.

Ceci dit merci pour l'info, j'ignorais que GMP contenait des optimisations en assembleur.

> Si une fonction n'est lancée qu'une fois il y a peu de chance pour que la JVM ai eu le temps de l'optimiser au mieux.

Regarde http://shootout.alioth.debian.org/debian/faq.php#fullcpu
La différence de temps n'est pas énorme <20% entre des conditions de mesure qui avantage ou désavantage Java, alors que les différence de CPU entre Java et D peuvent être bien supérieur (jusqu'à un ordre de grandeur de différence).

Maintenant comme je disais bien dans le doc, l'avantage c'est bien l'absence de VM (ça fait ça en moins à gérer), le gain de performance est un bonus.

>-la doc est certes assez grosse, mais manque cruellement d'exaustivité sur certains points particulier. Un Wiki serait bienvenue.

D'un autre coté, les newsgroup dédiés a D sont très actif, ce qui compense pas mal.
Il y a des wiki bien sûr comme http://www.prowiki.org/wiki4d/wiki.cgi?FrontPage mais je crois que aucun n'a le statut de "wiki officiel", ce qui est dommage, je suis d'accord.

>- la dernière fois que j'ai voulu utiliser le compilo GPL j'ai galerer comme un malade. dmd marche nettement mieux.
>- Les binding Wx ou GTK manquaient cruellement de stabilité, j'espère qu'ils ont été développer.
>-un IDE serait effectivement le bienvenu.[..]

L'idée de passer la spec de D en version 1.0 est justement d'inciter à la stabilisation des compilateurs, des librairies, et au développement des outils autour du langage..

>L'auteur faisait le raccourci: machine virtuelle=>lenteur

Oui, j'avoue, mais regarde la pour un comparatif entre Java et D au niveau perf CPU et utilisation mémoire:
http://shootout.alioth.debian.org/debian/benchmark.php?test=(...)

Assez édifiant non?
Bon bien sûr les benchmarks, c'est toujours à prendre avec des pincettes..

>J'avoue que j'ai du mal à comprendre le rapport avec ces 2 langages au niveau confort de programmation...

Le GC par défaut, la gestion des tableaux/hash dans le langage font que la programmation est par défaut d'un plus haut niveau que C/C++ mais tu as raison, c'est plus du niveau C# que Ruby/Python.

Pour ce qui est de la portabilité binaire, franchement c'est un avantage très théorique: pour C#, il ne doit pas y avoir beaucoup de programme non-lié aux librairies spécifique a Windows, pour Java, la pub "Run everywhere" s'est rapidement transformé en "Test everywhere".

Pour ce qui est de la programmation bas niveau en D, je ne suis pas d'accord: tu peux certes le faire, mais ce n'est pas le comportement par défaut: par défaut, tu utilise le GC, les accès aux tableaux sont vérifié (désactivable par option de compilation pour améliorer les perfs), le write (équivalent a printf) vérifie le type des arguments, les paramètres des fonctions sont passé en mode in, out, inout pas par pointeur ce qui restreint l'utilisation des pointeurs, etc donc le niveau de programmation est similaire a celui de Java/C# mais avec des perf voisine de C/C++.

La ou je vois une niche possible pour D serait dans la programmation d'application clientes: en Java/C#, le démarrage des VM a un coup de démarrage assez élevé et au départ les performance sont assez faibles (le temps que le JIT génère le code) ce qui les rend mal adaptés pour les applications clientes, maintenant il faudrait pouvoir utiliser Qt en D..

Pour ce qui est de la normalisation, je ne suis pas sur de ce que ça apporte, Ruby et Python vivent bien sans être normalisé..