Dinosaure a écrit 89 commentaires

Ce n'est malheureusement pas la première fois où un retour dans le passé est souvent nécessaire pour se rendre compte du travail énorme qui a été fait jadis et réponds à des problématiques qu'on a toujours eu dans l'histoire informatique. Cela commence bien entendu par l'apparition d'un format révolutionnaire pour sérialiser les données en javascript parce que c'est hype jusqu'à des algorithmes ad-hoc révolutionnaires pour résoudre des problèmes qu'on connait déjà.

On voit au final pondre des projets sur Github qui sont des copies en moins bien faites de projets déjà existants dont leurs âges est souvent bien supérieurs à ces créateurs innovants full-stack. Si nous sommes dans une démarche de recherche et de curiosité à son propre compte, ré-implémenter la roue et de loin l'option la plus didactique pour un informaticien et découvrir sans avoir de limite de temps sur ce qu'on a fait, sur ce qui a été fait et sur ce qu'on nous dit de faire ne pose généralement aucun problème à tout le monde.

Mais le déterminisme de l'informatique ne s'applique pas à l'informaticien et les choix de certains informaticiens se rapprochent souvent plus de l'ignorance qu'à un travail de veille technologique qu'on nous présente sous toutes ses formes sur le fil d'actualité Linkedin. Car il est là le problème, et je m'en suis rendu compte par moi même et je le dénote malheureusement autour de moi, c'est le manque de recherche.

On m'a bien expliqué que dans un projet, avant de coder, avant que nos idées fusent sur le clavier à un débit tel que le moment où l'on réinvente le monde avec nos amis autour d'un verre (ce qui laisse place bien entendu à quelques idioties), il faut se renseigner, chercher l'existant, connaître les tenants et les aboutissants. Et ce travail de recherche malheureusement est de plus en plus délaissé par du code pure car il est, dans un cadre flexible qu'est une petite entreprise encore dans l'incubateur de l'agglomération, plus rentable de pondre du code vite que de se renseigner sur l'existant et d'apprendre à l'utiliser. Ce que veulent les gens, c'est que ça marche et le plus vite possible.

Bien entendu, dans un tout autre cadre d'une multinational brassant des millions de clients, le code vite n'a plus son intérêt et on en vient à s'intéresser à l'existant afin de voir si les problématiques de mise à l'échelle auquel nous devons faire face n'ont pas déjà été résolu. Et bien entendu, ces problématiques ont toutes une réponse qui dates des années 80 ou 90. Alors l'entreprise se tort en 4 pour essayer d'intégrer ces solutions dans leurs environnements. C'est là qu'intervient le retour dans le passé. Facebook en est la preuve existante car elle se soucie aujourd'hui de rendre son environnement correctement typé par le biais de Hack (pour PHP) ou de Flow (pour javascript) comme ci il s'agissait de réparer une erreur du passé qui ne date pourtant pas de si loin.

C'est ce que je regrette le plus dans le monde informatique jeune, c'est qu'on est rentré trop dans le hype, dans le jeune, dans cette période adolescente où tu ne manques pas de faire une crise à tes papas. Et puis arrive la maturité, et tu as intérêt à bien être préparé car ces papas ne te voient plus comme l'enfant prodige qui code vite mais comme un nouveau papa et là, ils ne feront pas de cadeau. Je comprends qu'on est plus intérêt à maîtriser parfaitement tout les outils qu'il y a autour de nous et la meilleur façon d'y parvenir, c'est de les coder soit même mais ne serait t'il pas plus sage de se laisser bercer par l'immense travail qui a déjà été fait et porter notre petite révolution au bout de cette édifice qu'on comparerait à la tour de Babylone ?

Le parti unique communiste chinois n'a de communiste que le nom.

J'ai vécu dans la région PACA à l'époque d'MSN.

Premièrement, j'ai certainement attaqué ton journal sous ça forme (et c'est ce que je cherchais) mais en aucun cas j'en ai attaqué la personne. Je t'ai donné des conseils sur ce qui ne vas pas à mon sens dans ce journal (et dans celui de Nutyx où, je le rappelle, le leader du projet a dû intervenir pour estomper toutes fausses idées - c'est une réalité qui est explicité dans les commentaires de ce dernier article).

Deuxièmement, que tu es reçu un livre ne fait pas de toi un illuminé de LinuxFR. Je pourrais tout autant étaler mes distinctions mais je ne le fais pas car c'est juste narcissique en sans intérêt. Ce point peut d'ailleurs te porter préjudice à l'image que je (et les autres) peux me faire de toi - en réalité, il fait déjà préjudice au vu de mon commentaire.

Troisièmement, que cela soit un journal ou une dépêche, tu te dois de faire un travail correct. Et c'est pour cette raison que des journaux deviennent des dépêches. Mais au delà de ça, ce n'est pas normal de considérer un laxisme parce que ton article sera dans la section journal. Sinon, je me demande pourquoi je fais en ce moment attention à mon orthographe, après tout, c'est rien qu'un commentaire, non ? Il y a des gens qui te lisent et écrire un journal sur LinuxFR n'est clairement pas un travail de seconde zone - de toute manière, ce genre de travail est refusé par la communauté (et j'entame une attaque personnelle en considérant ton journal comme un travail de seconde zone au vu de la note qu'il a reçu).

Sur les remarques de fonds que tu expliques ensuite, j'ai déjà donné mon point de vu en disant que poster des liens entourés d'un texte aussi fallacieux (je commence à être méchant là) que le tiens rajoute un bruit qui fait que beaucoup de personne ne vont juste pas prendre la peine de regarder plus loin. Si tu considères ton travail comme n'étant que l'écriture d'une banque de lien, arrête tout. Mais au vu de l'article, je pense bien que tu veuilles partager un peu plus que des simples liens, tu veux notamment détailler ton expérience (qui encore une fois est une action louable, je redeviens gentil). Donc on va faire une comparaison simple, si je te donne une boite répugnante au point d'en faire vomir ton chat, prendras tu la peine de l'ouvrir ? Non, comme toute personne censé, le contenant est tout aussi important que le contenu. Et ton article est le contenant de 0linux (que tu le veuilles ou non) et si on considère que ce contenant est de mauvaise qualité (et je ne suis pas le seul à le dire), par implication, on considère le contenu de mauvaise qualité (quand bien même il y est les liens, là, sous nos yeux) - et c'est en cela que ton travail devient préjudiciable envers 0linux puisque désormais, pas mal de gens se font une fausse idée de ce qu'est cette distribution par ta faute.

Bon, l'attaque personnel comme quoi je fais rien … Merci, mais j'ai une vie bien assez active, ne t'inquiète pas.

Enfin le titre, je vois que tu n'as rien lu en vérité.

Au fond, j'ai bien compris que le FUD qu'il y a eut sur cette article ne t'a pas plu, et je te l'accorde, c'est pas très plaisant (même en étant un des auteurs de ce FUD). Mon deuxième commentaire était justement là pour clarifier mon point de vu sans être méchant pour autant et tu remarquera que je n'ai pas remis en cause ta participation (que je trouve même intéressante d'ailleurs, c'est toujours cool de découvrir des distributions). J'ai critiqué la forme car elle ne va clairement pas, et elle est la source de cette incompréhension entre nous les "pourris" de LinuxFR et toi l'auteur essayant de participer à la communauté. C'est clairement pas pour te démonter que j'ai fait ça, mais pour que demain, tu puisses nous faire un article sur une autre de tes distributions sans que celui-ci tombe sur les "-9" juste parce que la forme ne convient pas. Et donc à tout cela, j'ai envie de te dire que c'est dommage de réagir ainsi car le travail que tu fais, je pense que peu de personnes peuvent le faire (et je fais parti des personnes incapable de le faire comme tu le soulignes si bien) et que j'avais juste l'ambition de pointer ce qui n'allait pas à mon sens. Si tu refuses la critique, je plains sincèrement la prochaine distribution pour laquelle du voudrais faire de la pub. En attendant, je retourne rien faire.

En vrai, le problème dans toute cette histoire, c'est que tu fais juste de la mauvaise pub et c'est pas la première fois. C'est pas moi qui le dit pour le coup:

Je précise que je ne suis pas l'auteur de cette distribution, mais pour avoir trainé un peu il y a quelque temps autour de cette distribution, je ne reconnais pas les propos du créateur de cette distribution dans les propos du journal.

La communauté LinuxFR est capable de bien prendre en considération les points techniques des distributions, sa philosophie et ses objectifs et donner son point de vu sur ces questions là (et le point vu n'est pas toujours appréciable, heureusement - c'est un débat) mais dans ce contexte qui est celui que tu as mis en place, les commentaires peuvent paraître "pourris" car la présentation que tu fais de la distribution est, elle aussi, "pourri". C'est tout de même aberrant que je fasse un long commentaire juste pour le "FRANCOPHONE" dans le titre alors qu'on peut savoir pourquoi ils ne veulent pas splitter les paquets, pourquoi ils maintiennent des paquets avec un ./configure quasi-exhaustif, etc.

Mais il est normal qu'on puisse adopter une tel attitude si, de facto, tu nous présentes des éléments descriptifs (en particulier la philosophie de la distribution) factices. Mais le pire dans cette histoire, c'est que cette situation est préjudiciable à tout le monde. Elle est préjudiciable pour la distribution qui se voit accusé d'une mauvaise pub, elle est préjudiciable pour nous puisque cette pub ne nous donne clairement pas envie de chercher plus loin (et les commentaires parlent d'eux mêmes) et on restera donc ignorant de possibles pépites et enfin, elle est préjudiciable pour toi car ce qui en résulte ne va pas dans ton intérêt louable de présenter une distribution qui te plaît (et je comprends tout à fait cette manœuvre, je ne la critique pas).

Le problème vient donc de la forme. La première chose, c'est bien considérer au début de ton article que tu ne FAIS parti de l'équipe de développement. Cela peut paraître implicite comme fait pour toi mais ça ne l'est pas pour nous et on peut très bien s'imaginer que tu es le nouveau CM de cette distribution ou autre chose. Le problème qui en résulte en explicitant pas que tu développes TON avis et pas celui des créateurs, c'est qu'on peut facilement (et en réalité, c'est ce qui se passe) inférer que TON avis est le même que celui des créateurs. Mais certains s'accordent à dire que ce n'est pas le cas. C'est donc déjà un problème crucial - pendant un moment, j'ai vraiment cru que 0linux était exclusivement pour les francophones, je t'assure.

Ensuite, le titre pose aussi problème. Cela ne sert à rien de mettre des majuscules premièrement, j'ai l'impression d'avoir un gars qui me gueule dans l'oreille droite (MSN quand tu nous tiens) et puis un titre, c'est juste une manière plus concise de présenter le sujet. Et le sujet ici, c'est la distribution 0linux, alors pourquoi ne pas limiter le titre à: 0linux, une nouvelle distribution. Et si tu aimes avoir des titres biens racoleurs, au lieu d'assimiler ta vision à la distribution comme tu viens de le faire en considérant que 0linux était une distribution exclusivement francophone, assimile plutôt ton personnage à cette distribution avec un titre du genre: "0linux, une distribution que j'ai testé pour vous" - cette dernière renforce en plus ta désaliénation avec le développement de la distribution (cette désaliénation n'est pourtant toujours pas explicite).

Enfin, LinuxFR c'est une communauté qui contient des personnalités ayant un point de vu technique très affuté (dans le cadre des distribution, ce point de vu technique pour moi se rapproche de 0) et c'est une chance car les commentaires ne seront pas d'un superficiel semblable à: "super comme distribution, je la testerais demain" (donc jamais). Il y aura des vrais tenants et aboutissants et chaque commentaires seront d'un enrichissement profond pour chacun (et ça c'est LinuxFR - je traîne plus sur les journaux parlant de langage informatique et j'en apprends tout les jours) comme pour toi ou pour moi qui arrive à faire planter une Debian stable. Donc autant profiter de cette chance et taper dans le technique. Si tu t'en sens pas capable (et c'est à tout ton honneur), bah soit tu évites tout simplement pour éviter de dire des bêtise (comme tu viens de le faire), soit tu demandes au leader du projet de t'aider à la présentation du projet (et, bon dieu, IL EST FRANÇAIS). Voilà, dodo();

On dit pas des "string" mais des chaînes de caractères !

mkfifo donnerait crpeps peut être ?

En somme, j'ai l'impression que l'argument de vente, c'est surtout la barrière linguistique de l'OS. Alors je me pose donc la question. Pourquoi vouloir traduire ? Selon moi, il y a 2 réponses.

La première concerne l'internationalisation du système d'exploitation. M. Lambda ayant terminé son jambon de campagne souhaite envoyer courrier électronique à ses petits enfants après avoir eu un moment de lucidité à l'aide de son pastis 51 ou son Ricard. Seulement, il ne sait pas parler anglais et il ne voudrait pas avoir un système d'exploitation qui lui parle anglais (oui, les veilles personnes croient toujours que l'ordinateur - un mot bien français pour le coup lui aussi - leurs parle). Dans ce sens, faire un travail de traduction sur les systèmes existants est très louable mais ce travail existe déjà et je peux avoir un Ubuntu aujourd'hui qui me parle français (je peux même avoir un Archlinux ou un Gentoo en français, c'est fou).

On en vient à la deuxième possibilité puisque la première ne nous concerne pas. Le travail de traduction se fait apparemment sur les fichiers de configurations pour aider non plus M. Lambda mais Kévin (je suis un peu méchant quand même là) qui souhaite devenir le Bilou du futur (chacun ses rêves). Alors Kévin, il a le choix entre installer 0linux ou Ubuntu (je prends Ubuntu car c'est un peu la case départ de tout Kévin et j'étais un Kévin). Alors Ubuntu offre une documentation en français, c'est déjà cool mais je me demande alors en quoi 0linux se démarque. Ensuite, Ubuntu (comme Debian d'ailleurs et j'en suis) offre un IRC francophone, donc là aussi je me demande ce que peut apporter 0linux. Enfin, on me parle de communauté. La communauté auteur de la documentation d'Ubuntu doit bien être en grande partie francophone. Ne parlons même pas de Debian qui en a des forums francophones. Donc là aussi, je cherche tel un col blanc voulant partir au travail mais ne retrouvant pas ses clés de voiture une raison pour laquelle des gens passerait leurs temps à traduire.

Je pense que c'est surtout une fausse bonne idée de vouloir franciser à ce point une distribution car malheureusement, il n'y a pas que des français qui ont un problème avec leurs cartes nVidia ou qui souhaitent la dernière version de Firefox. Il y a aussi des anglais (on se serait douté) mais aussi des allemands, des japonnais et même des chinois. Et comment qu'on fait pour faire communiquer autant de gens de tout ces horizons, on parle anglais.

Donc le Kévin qui veut devenir Bilou en apprenant l'informatique par le biais d'une distribution Linux, il a plus intérêt à s'intéresser à des sources écrites en anglais. La transition est d'ailleurs simple, les ressources en français sur les distributions déjà existantes sont impressionnantes, on ne te demande donc pas un master en langue pour apprendre à installer une Debian. On ne te jette pas non plus dans des documentations de la taille du cahier des charges de Techno au collège (tu sais de quoi je parle) qui sont uniquement en anglais. Je dirais même qu'on te tient par la main et le mec qui te tire vers le monde merveilleux qu'est GNU/Linux, il est généralement français. Donc, non il n'y a pas de barrière de la langue (et je suis une quiche en anglais et j'étais un Kévin, donc je sais de quoi je parle - j'avais une carte ATI et je voulais Compiz à l'époque en plus !).

Malheureusement aussi tout développeur faisant un travail de documentation sur son logiciel pour expliquer comment utiliser le fichier de configuration, bah il va le décrire en anglais car il sait que ce ne sont pas que des français qui vont utiliser son logiciel mais l'internet. Et il sera difficile pour l'équipe qui fait la distribution 0linux de traduire toutes ces documentations (celle de MPD me fait peur rien qu'avec wc) et le travail sera d'une utilité très très moindre. Car oui, cela va peut être faciliter la vie de Kévin à court terme mais ça ne l'aidera pas plus tard. Et enfin, que tu le veuilles ou non, le domaine de l'informatique est un monde où l'on parle par défaut anglais.

PS: Je peux paraître sec avec cette grosse réponse mais le titre de la distribution est un peu racoleur et j'aime pas ça, surtout que c'est un point qui n'apporte, comme je viens de l'expliquer, rien. Mais sur le point de vu technique de la distribution, je dis rien (déjà parce que j'ai pas les compétences pour donner mon avis et surtout car ces derniers disparaissent par le bruit que génère le mot FRANCOPHONE dans le titre, et ça peut être dommage).

Et le réseau Cyclades, c'est pour du beurre ?

Bah au lieu de te plaindre, c'est précisément là où tu devrais faire un patch pour être offrir une installation sans composer. Et, oh wait … C'est ça qu'on appelle le libre ! Le fait de pouvoir modifier le code et le redistribuer (vers upstream ou en fork).

Non par contre il soulève un point intéressant. Déjà, parler de code moderne et de PHP nous laisse sourire.

Ensuite, parler des problèmes de syntaxes (qui ne sont que des problèmes de styles au passage, donc assez bien subjectifs) pour PHP montre une certaine ignorance des vrais problèmes de PHP qui sont de l'ordre de sa sémantique et surtout de son implémentation.

Il suffit de parler de PHP 6 pour se rendre compte que ce langage allait droit dans le mur et continue aujourd'hui à se dépatouyer de son héritage qui dénote particulièrement que: non, ce n'était pas mieux avant.

Au final ton article ressemble a un aigri qui veut continuer a faire du COBOL et se plaint qu'on puisse supplanter sa technologie (et ses habitudes) par quelque chose de nouveau (qui, avec un peu d'optimisme sur la communauté informatique, puisse nous convaincre qu'elle est objectivement mieux). Si tu reste dans cette position à dire non au code moderne (et il n'est pas moderne), tu risques de tomber dans des dogmes et finir comme le vieux tonton a chaque repas de Noël qui boit et qui se plaint - mais ton passif avec PHP n'en sera que meilleur pour en rigoler.

Oui enfin faire du roaming, c'est partir avec l'idée que la facture va douiller. Sinon, tu prends les forfaits disponibles dans le pays (en Chine, pour y être maintenant, j'ai pris un forfait a 400¥ - 200¥ pour la carte et 200¥ pour le forfait - pour 2Go de data en 4G pendant 1 ans a ChinaMobile, donc ~50 €).

Dans les pays plus exotiques comme le Laos, le Cambodge et le Vietnam, ~5$ suffit pour une carte avec un minimum de data en général.

Donc oui le roaming coûte cher mais la Chine et les pays aux alentours ne sont pas le bon exemple pour se retrouver dans l'incapacité d'avoir internet avec son téléphone - et ne parlons même pas des bornes wifis gratuites très présentes dans ces pays.

Je serais pas aussi catégorique et je veux bien comprendre que l'objectif du C++ diffère de celui de Rust.

Cependant, je pense pas que tout les développeur du C++ cherchent cette liberté. Il y a pas mal de situation où on voudrait juste que ça fonctionne avec des performances intéressantes. Les langages comme Scala ne propose pas le point de la performance (mais celui de la portabilité). OCaml arrive a de telles performances sauf dès qu'il s'agit de programmation multi-threadés et comme pour son compagnon Erlang, ils sont tout les deux bien trop haut niveau.

Ce que je veux dire au final, c'est que Rust veut pas supplanter littéralement le C++ comme le ferait croire les fanboys mais il offre une alternative a des problématiques que le C++ peut répondre mais moins bien. Et Rust s'affranchit de d'autres problématiques comme les jeux vidéos où le C++ est bien mieux.

Hmmhmm, je pense comme toi que l'article est mauvais car on a l'impression qu'il essaye de trouver des points de comparaison entre les deux langages en s'appuyant que sur les particularités de Rust. Cela dénote alors une incompréhension sur certains exemples et de la mauvaise foi sur d'autres. On est bien d'accord.

Cependant, j'ai vu les commentaires qui se suivent et il y a une certaine incompréhension de l'objectif de Rust au final. Ce qu'il faut avant tout comprendre c'est pourquoi Mozilla s'entête a faire un langage. On pourrait dire que c'est la mode (Facebook avec Hack fait la même chose) mais je pense surtout que c'est un problème de mise à l'échelle par rapport aux problématiques d'aujourd'hui.

Il faut bien se rendre compte qu'aujourd'hui, le C++ n'offre pas les outils permettant d'invalider les programmes simples qui peuvent hypothétiquement être faux. Sur des programmes multi-threadés (donc avec scheduling partiel), il est bien loin de ce que propose les langages comme Scala, Erlang ou encore OCaml - sur ce point vous serez d'accord avec moi qu'il y a plus de chance d'avoir un segfault avec le C++ qu'avec ces derniers langages, notamment parce que le modèle mémoire est gérer par le langage.

Mais Mozilla veut maîtriser le modèle mémoire du langage (donc pas d'Erlang, pas d'OCaml, pas de Scala). Et c'est là l'objectif de Rust. C'est tout simplement pousser l'analyse statique le plus loin possible pour élaguer le plus d'erreurs possibles sur des programmes multi-threadés.

Ils ont donc rajouter deux notions dans le compilateur, à savoir l'appartenance d'une variable (ce qui est certe déjà présent en C++ avec shared/uniq/weak_ptr mais ce dernier n'est pas étudié statiquement) et l'idée d'une life-time pour les variables.

Et c'est sur ça qu'on dénote la qualité de fiabilité au langage Rust - car un programme ne passant pas ces analyses statiques ne compilera pas (comme un programme qui n'est pas bien typé en OCaml ne compilera pas). Cela permet donc de mettre en place des invariants et exécuter du code de manière safe. Et c'est sur ce point que Rust travaille par rapport au C++.

Alors, on peut ensuite critiquer cette position en disant que les tests unitaires sont suffisants par exemple pour valider le bon fonctionnement d'un programme. D'autant plus qu'une telle analyse va sûrement invalider des programmes qui sont justes (comme avec le système de type d'OCaml) et c'est bien la raison d'être de unsafe (comme Obj.magic en OCaml), à savoir bypasser l'analyse statique. Par exemple, il me semble impossible de faire un garbage collector en Rust pur et il faudrait sûrement passer par unsafe.

Au final, il faut bien comprendre que, oui, on code pas en C++ de cette manière, oui il y a des warnings dans certains exemples et oui, on a les outils nécessaires pour faire des programmes qui ont moins de chance de planter en C++ (mais qui n'assure rien avant un coup de GDB). Mais sur tout ces points, on vous empêchera pas de faire du mauvais code. On vous dire peut être qu'il faut pas faire comme ça. Rust vous empêchera de faire ce genre de code, il le compilera pas. Et cette nuance bien que minime, sur des projets de grandes ampleurs a son importance - c'est bien pour ça que Facebook a refait un PHP statiquement typé et un type-checker pour JavaScript.

J'aime particulièrement le trentième stratagème dont je vous laisse un petit aperçu:

Ce que l'on appelle l'opinion commune est, à y bien regarder, l'opinion de deux ou trois personnes ; et nous pourrions nous en convaincre si seulement nous observions comment naît une telle opinion. Nous verrions alors que ce sont deux ou trois personnes qui l'ont admise ou avancée ou affirmée, et qu'on a eu la bienveillance de croire qu'elles l'avaient examinée à fond ; préjugeant de la compétence suffisante de celles-ci, quelques autres se sont mises également à adopter cette opinion ; à leur tour, un grand nombre de personnes se sont fiées à ces dernières, leur paresse les incitant à croire d'emblée les choses plutôt que de se donner le mal de les examiner. Ainsi s'est accru de jour en jour le nombre de ces adeptes paresseux et crédules ; car une fois que l'opinion eut pour elle un bon nombre de voix, les suivants ont pensé qu'elle n'avait pu les obtenir que grâce à la justesse de ses fondements. Les autres sont alors contraints de reconnaître ce qui était communément admis pour ne pas être considérés comme des esprits inquiets s'insurgeant contre des opinions universellement admises ou comme des impertinents se croyant plus malins que tout le monde. Adhérer devint alors un devoir. Désormais, le petit nombre de ceux qui sont capables de juger est obligé de se taire ; et ceux qui ont le droit de parler sont ceux qui sont absolument incapables de se forger une opinion et un jugement à eux, et qui ne sont donc que l'écho de l'opinion d'autrui. Ils en sont cependant des défenseurs d'autant plus ardents et plus intolérants. Car ce qu'ils détestent chez celui qui pense autrement, ce n'est pas tant l'opinion différente qu'il prône que l'outrecuidance qu'il y a à vouloir juger par soi-même — ce qu'ils ne font bien sûr jamais eux-mêmes, et dont ils ont conscience dans leur for intérieur. Bref, très peu de gens savent réfléchir, mais tous veulent avoir des opinions ; que leur reste-t-il d'autre que de les adopter telles que les autres les leur proposent au lieu de se les forger eux-mêmes? Puisqu'il en est ainsi, que vaut l'opinion de cent millions d'hommes? Autant que, par exemple, un fait historique attesté par cent historiens quand on prouve ensuite qu'ils ont tous copié les uns sur les autres et qu'il apparaît ainsi que tout repose sur les dires d'une seule personne.

"Ecoutez moi, Archlinux c'est trop bien. Chez moi, une mise à jour va à la vitesse de la lumière."

Rien que le fait d'aller sur archlinux.org avant de faire une mise à jour, tu peux concevoir que ça ne plaît pas à tout le monde. Et si Archlinux est stable, je me demande ce qu'est Debian stable (une stable over 9000 mthrfckr).

J'ai longtemps été sur Archlinux et il faut bien se rendre compte que c'est une distribution où tu dois serrer les fesses à chaque grosse mise à jour. Mais c'est dans la définition même d'Archlinux car vu l'entropie que les mainteneurs accordent à l'utilisateur final fait que sur une mise à jour simple, pas mal de gens vont se planter (mais c'est le jeux). Au début, c'est cool d'essayer de retrouver le son après un une màj ou de réparer son système après un kernel panic.

Maintenant, tout le monde n'a pas envie de faire ça. Tout le monde n'a pas envie d'ouvrir archlinux.org tout les matins, tout le monde n'a pas envie de passer 1 heure au travail à réparer son système parce qu'il a fait un pacman -Syu trop tôt. Tout le monde n'a pas envie d'avoir systemd (on est pas vendredi ?).

Donc non, Archlinux n'est pas stable est c'est bien sa raison et si tu me dis le contraire, t'as rien compris à la distribution (j'entends déjà au loin le: "C'est toi qui a rien compris, c'est une distribution KISS" - et c'est sur ça qu'on clôturera le débat).

Il y a un plugin pour ça: https://github.com/terryma/vim-multiple-cursors (et il y en a d'autres)

Cela se corrèle bien avec la sécurité apparemment.

Pour peu que tu baignes dans le milieu de la compilation et ayant connaissance des outils qui te génèrent du code d'analyse lexicale et syntaxique, faire un langage se compte en jour. Bien entendu, cela se limitera sûrement à un interpréteur, à ce qu'il n'y est pas d'optimisations et, à ce que les problématiques de sémantique qu'on retrouve dans le JavaScript soient rognés de manière empirique.

Vu le langage et vu le personnage, c'est tout à fait plausible que JavaScript ait été fait en 2-3 jours.

Concernant la spécialisation et l'inlining, tout dépend du contexte en réalité. Imaginons une fonction max de type 'a -> 'a -> 'a (puisque l'opérateur (>) est polymorphe). Puisqu'en OCaml un fichier est considéré comme une unité de la compilation ou plutôt un module, même dans le cas où le seul cas d'utilisation serait avec des entiers, comme tu le soulignes, le code généré d'OCaml ne sera pas très performant (pas de spé. et pas d'inlining). Pourquoi ? Tout simplement parce que le module a été défini avec un max polymorphe - et nous pouvons imaginer une tout autre utilisation de cette fonction dans un autre module avec des float.

Dans une autre situation avec la même fonction mais dont sa définition est local (restant donc interne au module), OCaml peut se permettre (dans le cas de l'utilisation de la fonction avec des int uniquement) de faire une spécialisation est de l'inlining. Mais le premier cas peut toujours être optimisé en forçant le typage de max avec des int.

Je pense que, comme le dit gasche à juste titre, ce n'est qu'une question de temps et d'approbation des différentes optimisations en évitant que celles-ci changent sémantiquement le code. Haskell a opté pour une utilisation de LLVM-IR (un projet OCaml utilise aussi LLVM, ça doit être dans GitHub). Je sais pas si c'est un choix judicieux (Haskell a été pas mal intrusif sur LLVM-IR selon moi) mais de toute façon, j'ai un PC i7 avec 16 Go de RAM :D !

Le castage (?) implicite n'est pas un avantage et le triple égal est une aberration qui n'est là que pour pallier à un système de type inexistant - un bout de scotch sur une grosse fuite d'eau.

Ouai, c'est comme faire du fonctionnel en C, il y a pas plus cool comme idée.

Enfin, essayer de réimplémenter (je dis bien « ré ») l'héritage en C, sauf pour apprendre, c'est, je le redis, ce compliquer la vie pour rien. De plus, il faut un sacré recul sur ce que l'on fait pour implémenter ce genre de chose ce que des personnes bienveillantes et techniquement meilleures que toi, moi ou l'OP on déjà fait dans ce qu'on appelle, oh wait … le C++. Après, il y a peut être confusion dans la définition de « C Modulaire ». Pour moi, elle correspond à du C+ ou le C with class (et j'ai jamais test l'objet en assembleur). Ce qui est sûr, c'est que la notion même d'héritage (comme le souligne d'autres personnes) nous mène directement C++ - à cela s'ajoute l'utilisation d'une API pour la GUI ce qui peut nous amener à Qt et tout de suite, il n'y a guère de choix.

PS: certains pointeront GTK pour m'expliquer qu'il existe un C+ notamment grâce au GObject, je leurs dirais que la problématique n'est pas la même et qui si l'équipe pouvait le faire en C++, il le ferait le plus tôt possible.

Quitte à faire du C Modulaire, autant faire du C++. Sinon, c'est se compliquer la vie pour rien.

J'ai un parcours atypique. Comme tout le monde en fait. C'est à dire atypique, mais en fait non : atypique, c'est dans la tête. C'est à dire que j'ai l'impression d'avoir un parcours extra-ordinaire (au sens "non ordinaire", pas au sens "fabuleux")…
C'est alors que resurgit dans mon esprit endolori par tant d'heures à coder en PHP et à requêter des bases MySQL, resurgit, donc, un des grands principes de raisonnement : le raisonnement par l'absurde.

A => B est équivalent à non-B => non-A. Appliqué à mon raisonnement, cela donnerait quelque chose comme un parcours atypique implique qu'il y ait des parcours typiques. Hors… mais… donc…

En tout cas, Chuck Norris sait, lui, où est Ornicar : c'est écrit sur Wikipedia et c'est donc vrai.

On pouvait tout de même se passer de ça (moi aussi je me pose des questions existentielles sur des principes de raisonnement, mais ils restent dans ma douche).

peut⁻tu être drogué et libre ?

Oui.
Si tu prends comme base de la liberté ton choix (je ne sais pas quelle base tu prends)

Euh non, c'est un artifice ça. Peut être qu'il y a une certaine liberté dans le choix que l'on fait à fumer (bien qu'en général, c'est un effet de mode) mais par la suite, c'est clairement plus un choix de fumer mais une contrainte comme le fait de se taper la cigarette le matin, c'est pas forcément par plaisir que tu le fais et l'OP l'explique très bien.
Être drogué, c'est être contraint de devoir consommer une drogue pour un bien être vital, à partir de là, ce n'est plus un choix que tu fais mais directive liée à une contrainte.

OCaml se débrouille tout de même pour l'unboxing (contrairement à Haskell) mais je pense réellement que le système de type de l'OCaml ne soit pas un problème dans la génération de l'asm. Au contraire, je pense que ça l'aide.