reno a écrit 3881 commentaires

>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é..

Pas faux, mais il y aussi des raisons pour lesquels Ada et Eiffel se sont plantés:
- ces deux langages n'étaient au départ utilisables qu'en payant cher des compilateurs alors que les compilateur C/C++ du moment étaient gratuits ou pas trop cher.
- utilisation des ressources du langages et du compilateur, a leur débuts la mémoire était une ressource rare donc le GC était un probleme, et au moins pour Eiffel, il y avait aussi un problème de ressources du compilateur qui était gourmand.

Certes maintenant, il existe des compilateurs gratuits et le probleme des ressources est réduit, mais ils ont perdu "l'attrait de la nouveauté" entre temps..
Et Java a bien montré que l'effet de mode est un puissant moteur pour l'adoption d'un langage dans l'industrie.

Je ne sais pas si D réussira a s'implanter, mais avec DMD et GDC (j'avais oublié le lien http://sourceforge.net/projects/dgcc/ ), il a évité les deux premiers problèmes, c'est encore un langage jeune et il a une communauté active, maintenant que la spec du langage est en version 1.0, cela permettra aux compilateurs de se focaliser sur leur finition, et au développeurs de librairie de vraiment se lancer, on verra ce que cela va donner..

Pas faux, mais le codec est en version "alpha" pas "beta" et "alpha" c'est quand même censé vouloir dire 'pas prêt' pour l'utilisateur final.

Alors c'est bien beau d'être pressé mais si tu dis a des gens tester mon logiciel X et que X n'est pas prêt, bin ils ne perdront pas leur temps ensuite a essayer les nouvelles versions..

Maintenant je ne sais pas si Theora est prêt ou pas, en tout cas son numéro de version semble indiquer le contraire.

Theora est en alpha 1.0
Matroska qui a l'air d'être le format du conteneur le plus intéressant n'est pas non plus totalement finalisé d'après http://www.matroska.org/technical/specs/index.html

Donc on peut se poser la question s'il ne vaudrait pas mieux attendre que Theora et Matroska soient tous les deux finalisé avant de faire une pétition?
Sinon, ça s'appelle mettre la charrue avant les boeufs.

Merci, je vais voir ça.

J'ai testé aujourd'hui un CD freeduc, je voulais voir si c'était adapté pour mes neveux, et cette distrib contient « La Bataille pour Wesnoth ».

Bon la distrib n'est pas prête pour mes neveux: ergonomie très approximative, plein de jeux mal finis (comme d'habitude pour les jeux libres), mais la bataille de Wesnoth, (si pas adapté pour mes neveux qui sont trop jeunes) m'a bien plut et sa finition m'a réellement impressionné: c'est le premier jeux libre (bon je ne les ai pas essayé tous hein) que je vois avec une finition pareille: bravo aux auteurs!