lasher a écrit 2738 commentaires

  • [^] # Re: typage mou

    Posté par  . En réponse à la dépêche Quelques nouvelles de Go, le langage de programmation. Évalué à 3.

    Tu as raison, et on devrait aussi changer C/C++/Java/etc pour que "a < c" s'écrive "a lessThan c". Bon, c'est de la taquinerie, mais je trouve que justement, ce qui fait la force d'un langage (et qui le démarque des autres) c'est justement une partie de sa syntaxe et sa façon d'exprimer les choses. Ça passe aussi par des symboles bizarres, parfois. C'est aussi l'une des raisons pour lesquelles j'aime Perl, là où d'autres le détestent: tous ces marqueurs ($,@,%,...), ça les perturbe, alors qu'après pas mal de temps à les avoir manipulés, moi je trouve ça naturel.
  • [^] # Re: typage mou

    Posté par  . En réponse à la dépêche Quelques nouvelles de Go, le langage de programmation. Évalué à 5.

    « [...] Ajoute à ça un typage statique fort qui possède de charmantes propriétés (comme la reconstructibilité : de toute expression tu peux déduire le type, tu n'es pas obligé de l'annoter - pas de déclarations chiantes comme en C ou autres). »

    Mmmh, je trouve que c'est un peu déloyal de parler comme ça, à la limite de la malhonnêteté. [1] En OCaml, il y a bien inférence de type, mais dans le cas où tu mélanges différents types dans une fonction, et que tu n'as pas défini les interactions entre tous les types possibles que ta fonction accepte (le produit cartésien quoi), ben ce que renvoie ta fonction est un objet de type incomplet au mieux, qu'il faudra définir complètement par la suite. Quand tu n'as que quelques types à gérer tu t'en fous, mais dès que le nombre d'interactions entre types devient un peu complexe, ça commence à devenir pénible.

    C'est pour ça que des langages type C, C++, Java, etc., déclarent les types des arguments etc. : pour « casser » la pénibilité en cas d'arguments multiples (entre autres choses hein). Et pourtant, si l'on excepte les types primitifs [2], Java utilise aussi la sûreté des types [3].

    Mais quand on considère certains types de structures de données, genre (au pif) XML [4], ben là, chaque balise est un type, et dans un document XML classique, des types et des sous-types, y'en a ... fiou, tout plein. C'est là qu'interviennent des trucs (à ma connaissance pas implémentés dans les langages populaires, fonctionnels, ou impératifs) : le sous-typage sémantique. Y'a un langage preuve de concept qui a été créé pour l'occasion: CDuce. Il est dérivé des langages ML (d'ailleurs je crois bien qu'il nécessite OCaml pour être bootstrapé), mais sait correctement élaguer l'arbre des types/sous-types liés à un type donné. Fin bref, c'est très loin pour moi, tout ça, et mieux vaut aller voir de ce côté-là: http://cduce.org/

    Tout ça pour dire que oui, OCaml est très bien, oui, il sait faire de l'inférence de type, mais clairement, non, ce n'est pas la panacée (par contre j'aime beaucoup son moteur de pattern matching pour le code, mais c'est une autre histoire).

    [1] Je rigole hein ! :-)
    [2] Oui, je sais, c'est un peu facile de dire ça ...
    [3] Sur les objets donc... faire int toto = 3.2; va toujours fonctionner « à la C » et tronquer la valeur pour la stocker en tant qu'entier dans toto.
    [4] XML qui inclut donc des types dans les types, ces types étant instanciés/présents (ou pas) en fonction des documents, etc.
  • [^] # Re: typage mou

    Posté par  . En réponse à la dépêche Quelques nouvelles de Go, le langage de programmation. Évalué à 6.

    Mmmh, si tu as un langage qui implémente réellement une forme forte de typage, alors en théorie, même si tu as un bug, celui-ci violera certainement les loi de ton typage et du coup ton programme plantera proprement. À comparer avec les langages à typage faible (par exemple le C), qui grogneront peut-être s'ils sont sympa à la compilation, sous forme de warning, mais qui malgré tout laisseront passer certaines conversions implicites. Du coup tu peux te retrouvé « coincé » à l'exécution, avec un programme qui va te donner des résultats faux, ou bien qui ne terminera jamais, etc.

    Le typage fort ne fait pas tout bien sûr, mais il assure presque à tous les coups que ton programme se terminera en cas de bug lié aux types. Je ne compte plus le nombre de fois où j'ai expliqué à des étudiants à quel point ils étaient chanceux d'avoir un bug reproductible en C (que j'adore par ailleurs)... :-)
  • [^] # Re: Mais sinon, pourquoi je devrais m'intéresser à ce énième langage

    Posté par  . En réponse à la dépêche Quelques nouvelles de Go, le langage de programmation. Évalué à 6.

    « Attention, il n'y a pas de coroutines en Go, mais des Goroutines. Ce sont une sorte de threads légers qui peuvent communiquer entre eux via des channels. »

    Oui enfin, une co-routine c'est justement un thread léger, généralement impossible à préempter à moins d'une exception ou que la coroutine elle-même décide de le demander... Ça me semble 'achement proche des Goroutines. :)
  • [^] # Re: Pourquoi se limiter au libre ?

    Posté par  . En réponse à la dépêche Rapport annuel 2010 sur le développement du noyau Linux. Évalué à 2.

    C'est à la fois peu et beaucoup quand on considère que ce genre de processeur est produit en relativement petite quantité comparé aux machins type Pentium 4 à l'époque ... :)

    Et pour la version dual core de l'Itanium 2, Intel n'en avait pas produit assez initialement et avait fourni des préversions initialement (avec la promesse de les remplacer par des versions finales quand elles seraient prêtes ...)
  • [^] # Re: Pourquoi se limiter au libre ?

    Posté par  . En réponse à la dépêche Rapport annuel 2010 sur le développement du noyau Linux. Évalué à 3.

    Ça m'étonne pas mal, vu que le CEA a un peu acheté la production d'Itanium 2 à une époque pour son cluster (~ 4000 processeurs bi-cœur)
  • [^] # Re: Pourquoi se limiter au libre ?

    Posté par  . En réponse à la dépêche Rapport annuel 2010 sur le développement du noyau Linux. Évalué à 1.

    Euh, je ne sais pas si ça a changé depuis (sans doute que oui), mais à une époque Linux-le-noyau sur PPC et sur x86, c'était juste pas la même chose. Il s'agissait quasiment de deux logiciels différents (sauf pour certains mécanismes-clé).
  • [^] # Re: Pourquoi se limiter au libre ?

    Posté par  . En réponse à la dépêche Rapport annuel 2010 sur le développement du noyau Linux. Évalué à 1.

    « OUHAOU vous avez reussi a faire plus que 2 archis (qui sont tres similaire x86 et xx64) »

    ia64 et x86/x86_64 n'ont juste rien à voir en termes d'architecture. Autant je trouve que pBpG va avoir du mal à « justifier » quoi que ce soit concernant le nombre d'archis - si ce n'est « y'a plus que du x86, même Apple a lâché le PowerPC » (et quelque part la raison se justifie économiquement parlant), autant tu pourrais faire un effort et savoir de quoi on parle. amd64/intel64 != ia64 (aka Itanium, un processeur VLIW+superscalaire).
  • [^] # Re: Je soutiens Florent Gallaire

    Posté par  . En réponse au journal "J'ai raison, mais je ne ferai pas valider mon raisonnement". Évalué à 4.

    « 2) <<mais aussi de la taille de l'emprunt; quelques dizaines de lignes pour un roman de plusieurs centaines de pages>>
    - l'application d'une licence dépend de la taille de l'emprunt, c'est à la libre appréciation de chacun, on peut choisir de ne pas la respecter si on estime que son boulot est tellement plus conséquent que celui sur lequel on s'appuie »

    Déjà entendu parler du droit de citation ? Globalement si l'ensemble de ta citation ne dépasse pas une page de bouquin (si mes souvenirs sont bons), alors tu ne crains rien (par contre, oui, il faut citer ses sources). C'est pour ça qu'elle s'interroge sur la possibilité d'une citation mal faite : une simple attribution des extraits à Wikipedia (ou les auteurs des articles en question) pourrait peut-être corriger le problème ...

    Donc là il ne s'agit pas de « faire respecter la licence » : il s'agit d'un problème de « fair use ».
  • [^] # Re: Je soutiens Florent Gallaire

    Posté par  . En réponse au journal "J'ai raison, mais je ne ferai pas valider mon raisonnement". Évalué à 4.

    Si tu as un garage et 4 gus pour aller avec, ça devrait aller aussi.
  • [^] # Re: Je soutiens Florent Gallaire

    Posté par  . En réponse au journal "J'ai raison, mais je ne ferai pas valider mon raisonnement". Évalué à 7.

    Je suis d'accord. Et je plussoie, mais principalement parce que de toutes les personnes qui ont écrit dans ce journal, tu es la première personne à avoir correctement écrit « tort ». Tu m'as redonné confiance en la race humaine. +1 :-P


    (et vite vite ----> [ ])
  • [^] # Re: Quelles sont les plus par rapport au site de sa banque ?

    Posté par  . En réponse au journal KissCount v0.1. Évalué à 2.

    Ben écoute, oui ma banque pue sans doute, tout ça, mais en pratique, j'ai beau avoir un zouli certificat électronique obtenu depuis mon pc sous linux avec java & co, ben une fois ledit certificat obtenu, j'ai jamais réussi à virer de l'argent depuis mon compte français vers un autre compte car pour une raison qui m'est inconnue, le module java fonctionne mal dans ma version « officielle » de FF fournie par Ubuntu. Ledit certificat n'est délivré que pour cette machine précisément avec cet OS (et j'ai eu la joie de découvrir après que le site m'a dit « yabon » que linux n'était pas supporté), et pour faire révoquer le certificat depuis les USA, tout ça, c'est relou. Alors quand j'ai besoin de donner des sous depuis mon compte français à d'autres gens en France, je fais péter le chéquier et la poste US.
  • [^] # Re: Quelles sont les plus par rapport au site de sa banque ?

    Posté par  . En réponse au journal KissCount v0.1. Évalué à 1.

    Oui il y a encore des gens qui utilisent des chèques. C'est un peu le moyen le plus simple pour moi pour donner de l'argent, depuis l'étranger.
  • [^] # Re: Je soutiens Florent Gallaire

    Posté par  . En réponse au journal "J'ai raison, mais je ne ferai pas valider mon raisonnement". Évalué à 6.

    « Je ne suis pas convaincu que d'avoir porté la GPL devant un tribunal est desservi la cause du libre... bien au contraire ! »

    Ben justement. Retirer le bouquin de son site et persister à dire « nan mais j'ai raison, et même pas peur d'abord ! » ça fait un peu faux cul tu penses pas ? Et surtout, s'il est si engagé que ça, il faudrait peut-être qu'il aille jusqu'au bout et soit prêt à aller au tribunal défendre ses idées/idéaux.
  • [^] # Re: Bonne nouvelle

    Posté par  . En réponse à la dépêche Que penser du rachat de Novell ?. Évalué à 2.

    « C’est quoi la différence entre « imprévisible » (Java) et « ça dépend » (C++) ? La même qu’entre un bon et un mauvais chasseur ? »

    Quelque soit le langage, si celui-ci autorise des accès concurrents non-protégés, le résultat est nécessairement aléatoire. Ce n'est pas obligatoirement un « mauvais » résultat (certains algorithmes en tirent même parti), mais généralement ce n'est pas ce qu'on recherche.

    Ceci étant dit:

    Le modèle mémoire de Java (JMM) spécifie que si tu codes sans passer par des outils de synchro (locks, utilisation de volatile, etc), alors le comportement à l'exécution est indéfini. Si tu utilises les mécanismes de synchro, alors tu auras une exception à l'exécution (ou peut-être même une tape sur la main à la compil si tu as des outils intelligents).

    Dans le cas d'une utilisation correcte des méthodes de synchronisation, alors le JMM garantit une exécution suivant une politique appelée « sequential consistency » (SC). En gros, Du point de vue du thread qui s'exécute, l'ordre des instructions (au sens instruction load ou store dans la jvm) doit être celui spécifié dans le programme original, et toute écriture sur un des objets mémoire que le thread manipule (lecture ou écriture) doit lui apparaître selon l'ordre total de tous les threads qui s'exécutent en même temps.

    Je parle ici de programmes dits « data race free » i.e. qui ont des accès synchronisés aux variables partagées.

    Java a toujours eu un modèle mémoire concernant les accès concurrents, mais celui-ci est cassé/buggé. En 2004 une refonte du JMM a été commencée (et appliquée à partir de Java 1.5 si je me souviens bien).

    Le cas de C++ diffère, dans le sens où les threads ne faisaient pas partie du langage initialement. La prochaine norme va les intégrer au langage, ce qui signifie que C++ doit prendre position sur la façon dont les opérations en mémoire doivent être perçues par le programmeur et à l'exécution.

    C++MM suit plus ou moins le même modèle (SC pour les programmes sans accès concurrents aux données), avec quelques subtilités où ils précisent explicitement certains comportements indéfinis ou dépendants de l'implémentation (pour autoriser certaines optimisations impossibles dans le cas SC pur).
  • [^] # Re: Bien obligé non ?

    Posté par  . En réponse au journal "J'ai raison, mais je ne ferai pas valider mon raisonnement". Évalué à 6.

    J'ai l'impression que ça change beaucoup en fonction du crime alors, parce que mes taupes (bon OK, ma taupe) au palais de justice de Paris ont tendance à dire que la reconnaissance de culpabilité peut même t'être plus préjudiciable (au moins en cas d'accusation de meurtre ...).
  • [^] # Re: Bien obligé non ?

    Posté par  . En réponse au journal "J'ai raison, mais je ne ferai pas valider mon raisonnement". Évalué à 1.

    « La justice n'aime pas qu'on se foute de sa gueule, et condamne plus lourdement une personne qui ne reconnait pas les faits qu'une personne qui fait son mea-coulpa »

    Aux USA peut-être avec le plaider coupable etc. En France, non.
  • [^] # Re: Bonne nouvelle

    Posté par  . En réponse à la dépêche Que penser du rachat de Novell ?. Évalué à 2.

    « Le fait que le C soit un langage très très très casse-gueule pour les "noobs", c’est pas une nouveauté hein… »

    Je ne dis pas ça non plus. Je répondais juste au monsieur en haut qui disait que même un noob sait qu'il existe size_t. Peut-être bien, mais il ne comprend pas forcément (en fait la plupart du temps c'est même certain) comment sont définis les types, sur quels intervalles, pourquoi size_t est utilisé, etc.

    « [troll]
    D’ailleurs, c’est pas ça le principe d’un noob fraîchement diplômé, de se charger du code des projets Java-bateau, pour que les personnes plus expérimentées puissent se concentrer sur de vrais projets ?
    [/troll] »

    Malheureusement si, et ça me désole. C'est pas comme si faire des trucs immondes en Java c'était si dur que ça (je le sais bien, j'ai pratiqué en tant que stagiaire). La seule différence c'est que Java c'est censé être « bloated » de toute manière, donc y'a qu'à rajouter de la RAM au serveur, alors que C c'est censé aller vite donc si ça va pas assez vite, c'est le programmeur qui est en cause.

    ... Alors qu'en pratique un bon dév Java (disons un « expert ») devrait finir par connaître plutôt bien la JVM qu'il utilise, et donc savoir comment son code se traduit en bytecode, etc... Et donc, avoir une connaissance pointue d'une machine virtuelle là où en C on a une machine « concrète ».
  • [^] # Re: Bonne nouvelle

    Posté par  . En réponse à la dépêche Que penser du rachat de Novell ?. Évalué à 2.

    Le problème n'est pas lié à la possibilité d'allouer 2 Gio. Bien sûr que c'est faisable. Le problème vient du fait qu'allouer 2 Gio peut prendre un sacré bout de temps à l'exécution. Je te laisse le soin de le faire proprement:


    #define TWO_GIGS 2UL * (1UL << 30)
    int *array = malloc(TWO_GIGS);
    for (size_t i = 0; i < TWO_GIGS; ++i)
        array[i] = i; /* to force memory to be allocated */

    foo(array);


    Définis ensuite foo() quelque part dans une autre unité de compilation, pour être sûr que gcc ne va pas simplifier le code (ou compile avec -O0). Bref. Sur mon super core i7 au boulot, effectivement je risque d'aller très vite. Sur mon Core 2 de l'ancien boulot, ça va prendre un moment. Je le sais d'expérience.
  • [^] # Re: Bonne nouvelle

    Posté par  . En réponse à la dépêche Que penser du rachat de Novell ?. Évalué à 2.

    Non. Les gros noobs ne savent même pas forcément ce qu'est size_t, parce que leur prof fait comme 90% des profs et leur fait faire

    int i;
    ...
    for (i = 0; i < n; i++)
    ...


    J'ai enseigné le C système à des élèves de L3, et je crois bien que j'étais le premier à leur faire remarquer qu'il y avait d'autres types entiers (size_t, long, unsigned...) que le simple type int.
  • [^] # Re: Bonne nouvelle

    Posté par  . En réponse à la dépêche Que penser du rachat de Novell ?. Évalué à 2.

    pBpG t'as déjà répondu sur le fait que lorsque tu as effectivement peu de mémoire vive sur ta machine (donc à l'époque des 286,386 etc), avoir un tableau qui permettait d'indexer l'intégralité de la mémoire pour un coût relativement peu important (malloc(640*1024) par ex) ça avait son sens.

    malloc(INT_MAX) n'alloue pas toute la mémoire, juste un nombre maximal de cases qui peuvent stocker de l'information dans un tableau.
  • [^] # Re: Bonne nouvelle

    Posté par  . En réponse à la dépêche Que penser du rachat de Novell ?. Évalué à 2.

    « int a une taille minimal : 16 bits »

    Tu es sûr de toi ? Si je regarde la norme, je ne vois qu'une relation d'ordre entre les types, et c'est tout:

    char <= short <= int <= long
    sizeof(char) == 1 (même quand un char tient sur 16 bits)

    Si ensuite tu rajoutes la norme POSIX (toujours dans mes souvenirs), alors

    sizeof(long) == sizeof(mot mémoire) == sizeof(void *)
    sizeof(int) >= 32 bits
  • [^] # Re: Bonne nouvelle

    Posté par  . En réponse à la dépêche Que penser du rachat de Novell ?. Évalué à 5.

    Ils n'ont pas perverti VMS, ils ont embauché le mec qui a fait partie des créateurs de VMS, c'pas pareil quand même.
  • [^] # Re: Bonne nouvelle

    Posté par  . En réponse à la dépêche Que penser du rachat de Novell ?. Évalué à 4.

    « Je ne pense pas que le comité qui s'occupe du C++ puisse s'assoir facilement sur GCC »
    Tu veux rire j'espère ? Des compilateurs C++ y'en a tout un paquet (icc, les compilos de PGI, ceux de Sun, etc.). GCC a mis un sacré bout de temps de passer de « GNU C Compiler » à « GNU Compiler Collection ». Peut-être qu'il y a des dév de GCC dans le comité de standardisation de C++, mais qu'ils soient derrière GCC, ou un autre compilateur n'est absolument pas pertinent. Pas plus pertinent qu'être dev pour un autre compilateur en tout cas.
  • [^] # Re: Te bile pas

    Posté par  . En réponse au journal Pourquoi réécrire LinuxFr.org ?. Évalué à 2.

    et que dire de ruby qui invente un dsl pour chaque besoin ?

    Que pour ça LISP le fait déjà très bien ?

    ----> [ ]

    (en plus j'aime bien ruby...)