L'enquête de l'INSEE (j'ai mis le lien dans mon message) compte aussi le temps de bricolage et de "jardinage, soin des animaux", qui me semble contenir les tâches que tu décris. Ce n'est pas complètement clair pour l'entretien automobile, mais les catégories données ne sont pas très précises.
Les hommes selon cette enquête en font effectivement plus que les femmes : chez les salariés, 22 minutes par jour en moyenne chez les hommes, contre 5 minutes par jour chez les femmes. La différence reste assez petite par rapport à la différence d'ensemble des temps domestiques (qui inclus ces tâches), chez les salariés à 2h06 pour les hommes et 3h27 pour les femmes.
(Si on se limite, au sein des tâches domestiques, uniquement à "ménage, cuisine, linge, courses", la différence est encore plus marquée puisqu'on a, chez les salariés, 1h11 chez les hommes et 2h36 chez les femmes. Mais effectivement cette catégorie regroupe les tâches plutôt féminines et exclus des tâches plutôt masculines, donc elle ne donne pas une bonne idée d'ensemble du temps de travail domestique.)
En moyenne, les femmes consacrent 3h26 par jour aux tâches domestiques (ménage, courses, soins aux enfants, etc.) contre 2h pour les hommes, selon l’Insee (données 2010).
Où trouver le programme des années passées ? Les communications des années précédentes utilisaient une URL non millésimée, https://jdll.org/programme, qui pointe maintenant vers le programme vide de 2020. J'aimerais consulter le programme de 2019 ou 2018, en particulier les conférences, pour me faire une idée de l'événement.
Les OS les plus utilisés sont écrits dans des langages non-sûrs (C et C++) et d'ailleurs ils sont bourrés de failles, comme les logiciels qui font l'infrastructure internet. Ça fait des décennies que des centaines voire milliers de gens sont payés pour réagir au quart de tour à la dernière faille de type "buffer overflow" trouvée dans un logiciel critique, tout ça parce que tout ce logiciel est écrit dans un langage où la grande majorité des erreurs de programmation permettent à un attaquant malicieux d'exécuter du code arbitraire. On a collectivement investi des milliers d'années de travail, de l'argent par million, pour gérer les conséquences de ces choix désastreux (même si c'était moins visible à l'époque où ils ont été faits) de construire toute notre infrastructure sur des langages fortement peu sûrs.
Le langage n'a rien à voir avec la qualité du soft. Une mauvaise architecture, un mauvais développeur donnera du code non secure et buggué quelque soit le langage.
Buggué, sans doute—même s'il existe des langages qui permettent d'exprimer son besoin plus clairement et donc d'avoir moins de bugs. Mais tous les bugs ne deviennent pas automatiquement des énormes failles de sécurité. Par exemple, si tu as un parseur d'un format binaire quelconque écrit en C, la plupart des erreurs de programmation permettent à un attaquant qui fournit un binaire malicieux d'exécuter du code (d'où l'exemple de prise de contrôle d'une voiture en insérant un CD audio bien choisi; il y a une erreur d'architecture dans le système, mais aussi un langage non-sûr qui permet de l'exploiter très facilement). On n'a pas du tout le même problème si on écrit le même parseur en Java, Ada, OCaml, WebAssembly, ou n'importe quel autre langage qui garantit la sûreté mémoire par défaut.
C'est une illusion de croire que le dernier langage à la mode protège des failles de sécurité et des bugs.
Un langage qui garantit que tous les accès à un tableau sont vérifiés pour leur validité protège des failles de sécurité lié à un accès arbitraire en mémoire—si l'implémentation du langage et le matériel dessous sont corrects. Tous les langages à la modes ne donnent pas forcément de bonnes garanties—mais en fait aujourd'hui presque tous les langages donnent de meilleures garanties que C.
(Certains langages dynamiques introduisent des problèmes de sécurité qui n'existent pas avec C, en permettant à chaque bibliothèque d'aller redéfinir n'importe quel autre symbole visible par l'utilisateur ou presque.)
Peu de gens comprennent vraiment le modèle mémoire des atomiques de C11 (les concepteurs du standard ont voulu faire plus fin et plus optimisé que celui Java, et donc pendant longtemps on n'a pas su si le modèle était raisonnable/correct), et parmi les gens qui le comprennent vraiment il y en a peu qui écrivent des programmes en C. Du coup pour les programmes multi-threadés, la plupart n'utilise pas les atomiques de C11 (typiquement le noyau Linux qui avait ses propres macros pour insérer des barrières), et la plupart de ceux qui les utilisent sont quand même indéfinis. En tant que simple mortel il faut vraiment être très strict, et ne pas descendre en-desous de release/acquire, pour ne pas se planter.
C est aussi le langage des "comportements indéfinis", où personne n'est d'accord sur ce que devrait faire un programme et en fait tous les programmes sont faux (n'ont pas de sémantique définie) (en tout cas presque tous, surtout les programmes qui utilisent du multi-threading). Utiliser C pour un nouveau projet aujourd'hui, pour moi c'est irresponsable du point de vue de la correction et de la sécurité.
Sauf que créer un paquet npm (ou pip, gem, etc.) me permet de déployer mon code chez des gens qui utilisent n'importe quelle distribution, pas seulement la mienne. C'est autrement plus facile que d'écrire un paquet pour chaque empaqueteur Linux, OSX et BSD.
Les gestionnaires de paquets spécifiques à une communauté ont des défauts et aussi des avantages. Pour les gens qui attachent plus d'importance à l'appartenance à cette communauté qu'à leur utilisation d'une distribution spécifique, ils sont clairement avantageux. Pour des gens qui utilisent ces travaux communautaires comme un paquet parmi d'autre au sein d'un système donné, ils sont clairement moins commodes qu'un empaquetage de distribution.
Je trouve un peu triste qu'on répète ce débat à chaque fois, chaque personne donnant seulement un des points de vue ("développeur Javascript", "admin Debian", etc.), ce qui ne permet pas de comprendre la situation.
Par ailleurs je remarques que les empaqueteurs des distributions sont très lents à réagir à de nouveaux besoins. Les développeurs sont très clairs sur le fait qu'ils ont besoin de travailler sur plusieurs projets qui vont utiliser chacun une version différente d'un paquet donné. Quels sont les gestionnaires de distributions qui permettent ça facilement ? À ma connaissance il n'y a que Nix et Guix qui font un bon boulot là-dessus, alors que pourtant c'est un besoin qui est apparu il y a des années. C'est bien beau de venir ensuite faire la morale "non mais les gestionnaires paquage-spécifique c'est puéril, il suffit d'utiliser Rpm/Deb/whatever".
C'est peut-être aussi le moment de rappeler qu'il existe des postes où on a de la liberté pour faire son travail dans de bonnes conditions—toutes les entreprises ne se valent pas, on peut avoir plus ou moins de marge de manœuvre, et il y a des besoins d'informaticiens en dehors du secteur privé (personnellement je suis dans le secteur de la recherche publique, qui embauche des chercheurs mais aussi des ingénieurs, et qui a la valeur du travail bien fait). Ça ne veut pas dire abandonner complètement la recherche de l'efficacité au travail, et il y a aussi souvent des inconvénients à accepter en conséquence (plus difficile d'obtenir un poste stable, salaire plus faible).
Les personnes qui savent programmer ont la chance d'être dans un domaine où la demande en personnel est très forte. Il est possible d'en profiter pour être un peu difficile sur les offres qu'on accepte, et de ne pas se laisser imposer des environnements de travail qui ne nous conviennent pas.
Il existe des postes d'ingénieur de recherche dans la plupart des instituts de recherche publique française, qui cherchent des compétences souvent assez pointues pour contribuer à la recherche scientifique. À chaque fois, il y a des postes en CDD et aussi des postes permanents (moins nombreux, plus difficiles à obtenir). Exemples:
pour une fois je ne saurais critiquer l'utilisation qui est faite de mes impôts.
En tant que fonctionnaire (qui contribue aussi au logiciel libre) je trouve ça un poil vexant de lire ça. J'espère que cet exemple particulier (et, je suis d'accord, particulièrement sympathique) te fera réfléchir au fait qu'il existe plein de gens qui travaillent, grâce à nos impôts à tous, pour l'intérêt général, au CNRS et ailleurs. C'est un peu dommage ces petites formules qui critiquent tous les services publics, alors que ce sont des milieux très diversifiés qui sont remplis de beaucoup d'êtres humains qui font des choses importantes avec générosité.
J'ai décidé que ma prochaine machine serait une system76, et il me semble que c'est un vendeur qui pourrait t'intéresser—je n'ai pas vérifié pour les ports disponibles, mais pour le reste ça fait ce que tu veux : des ordinateurs portables de bonne qualité, y compris des machines puissantes/récentes, et du logiciel libre. Voici par exemple un pointeur veurs leur laptop 13"/14", le Galago à $900.
Il y a plein de projets intéressants dans plein de langages différents, et c'est un peu la norme de devoir découvrir un nouveau langage (ou un nouveau mode d'usage d'un langage qu'on a déjà utilisé) quand on veut contribuer à un projet spécifique—ou un nouveau gestionnaire de version, système de build, etc. C'est difficile de créer un projet à partir de rien dans un nouveau langage, mais éditer du code en se guidant avec l'existant est beaucoup plus raisonnable.
Posté par gasche .
En réponse à la dépêche Sortie de JDK 10.
Évalué à 4.
Dernière modification le 11 novembre 2018 à 18:38.
La question que je pose depuis le début […] [c'est] comment tu connais le type de retour de getNextValue() sans aller voir sa déclaration (dans un autre fichier ou des centaines de lignes plus loin) ?
La réponse:
- souvent c'est évident selon le contexte (par exemple ce qui se trouve à droite est le constructeur d'une classe)
- quand ça ne l'est pas, je peux demander à mon éditeur de me donner le type (chez moi c'est C-c C-t, chacun ses goûts)
Si tu refuses d'avoir des outils pour t'aider dans ta programmation, tu as toujours le loisir de râler sur tes collègues, pendant la relecture de code, quand ils utilisent un auto/var à un endroit où ce n'est pas clair pour toi.
De plus, je ne suis pas fan du code que tu proposes, tester les limites des types en dynamique alors que le type ne changera pas en runtime tout ca parce que c'est "mieux" d'écrire "auto counter" que "int counter", ca n'a pas de sens (et je ne parle même pas des performances…).
Je pense qu'aucun test dynamique n'est fait dans le code C++ qu'il montre. Par ailleurs, Java est un langage qui fait un test de typage dynamique à chaque écriture dans un tableau, donc je dirais qu'il faut se détendre un peu.
Oleg ne travaille plus là-bas (il est professeur d'université au Japon depuis quelques années) et il me semble qu'il y a beaucoup de groupes de recherche&développement qui travaillent sur des prototypes sans pour autant mettre du code en production dans leur structure mère. Ce que tu dis n'est pas impossible (Oleg a travaillé sur des spécialisations de bibliothèques d'algèbre linéaire et calcul numérique, c'est compatible) mais me semble drôlement spéculatif.
Pourquoi crois-tu que je ne connais pas le sujet ?
J'ai pensé que tu ne connaissais pas le sujet car tu as posé la question comme si tu ne connaissais pas le sujet:
Je me demandais à quel point la propagation de constante pouvait remplacer les templates, voir même la génération de code. En général, la propagation de constante se limite aux littéraux( 10, 'c'). Pourquoi ne pas aller au delà, et faire de la propagation de constante de conteneur ?
Imaginez la propagation d'une string qui définit une expression régulière : cela revient à générer le code lié à cette expression.
On peut imaginer la même chose avec une structure arborescente : un interpréteur d'AST classique devient un générateur de code sur un AST statique.
Qu'en pensez-vous ?
J'ai supposé que, si tu savais que c'est un domaine sur lequel des gens ont travaillé, tu l'aurais indiqué en donnant un pointeur vers ces travaux (ou au moins le mot-clé à chercher : évaluation partielle, projection de Futamura, etc.), afin d'aider les gens intéressés à se renseigner plus en profondeur.
(À relire ton message, tu mentionnes l'idée de spécialiser un interpréteur pour obtenir un compilateur, qui est assez avancée. J'aurais pu me douter que tu avais lu des choses sur le sujet, mais je me suis simplement dit que c'étaient des méditations sous la douche ou équivalent.)
Je trouve assez gonflé de critiquer une fonctionnalité d'un langage expérimental parce que tu n'aimes pas la syntaxe. Est-ce vraiment moins lisible que HTML ou Lisp ? Un utilisateur qui a un poil l'habitude sait lire d'abord le code dans les annotations de staging (étagement ?), et voir ensuite la structure des annotations (qui indique la séparation entre le code exécution statiquement et le code produit).
Tu ouvres un fil de discussion avec une question un peu naïve qui correspond à un domaine de recherche entier (le mot-clé pour chercher les références est "évaluation partielle", "partial evaluation") qui a commencé dans les années 1970. Les gens ont pas mal réfléchi à ça, poussé l'idées dans des recoins intéressants, et un consensus qui est en train de se former est que pour avoir de la prédictibilité sur les performances obtenues il faut séparer explicitement les parties évaluées statiquement et dynamiquement (et, dans le cas général, à un stage/étage ou un autre).
Il y a des choses intéressantes qui sont faites dans ce domaine, et je trouve ça un peu triste d'ignorer une idée simplement parce que tu n'aimes pas la syntaxe. Si le sujet t'intéresse, tu devrais peut-être te renseigner sur ce que les gens ont déjà fait dessus.
Note: MetaOCaml et les templates/constexpr n'ont pas le même but. L'idée de la méta-programmation "staged" (étagée) est de laisser l'utilisateur définir ses propres évaluations partielles, pour les calculs qui comportent un mélange entre une partie déterminée statiquement et une partie déterminée dynamiquement (par exemple: précalcul de flot de contrôle, ou autotuning "statique" du code pour une architecture spécifique). constexpr propose une forme d'évaluation statique fixée par le langage, où tout doit pouvoir être calculé statiquement. C'est facile à utiliser mais l'utilisateur ne peut pas contrôler la méthode de spécialisation. Dans le cadre plus général de la métaprogrammation template, on peut choisir des mélanges entre calcul statique et calcul dynamique, mais les possibilités sont limitées aux formes de spécialisation prévues par le compilateur du langage, plutôt que programmées directement par l'utilisateur.
J'ai déjà travaillé avec des gens frileux, ayant peur de montrer leur travail intermédiaire au monde. Le modèle "je donne des tarballs de mes release mais pas l'accès au dépôt versionné" est malheureusement plus courant qu'on ne pourrait le croire. Parfois les gens ont changé de point de vue à force de discussion et mettent tout en ligne aujourd'hui. Souvent ils sont restés sur leur position. Quand je contribue, j'essaie de m'adapter aux choix et préférences des gens qui ont fait le gros du boulot—tout en étant clair sur le fait que je préfère faire les choses différemment, si on me pose la question. Si on fait comme ça vient, et que des deux côtés les gens ont de bonnes intentions, ça se passe en général bien.
Posté par gasche .
En réponse au journal Forker ou ne pas forker ?.
Évalué à 10.
Dernière modification le 16 septembre 2018 à 12:58.
On n'est pas là (ni toi) pour construire un modèle mental prédictif d'un individu à partir de sa page web ou pour lui faire une psychanalyse gratuite. Je pense que ce qui marche le mieux c'est d'être gentil avec les gens et de s'attendre au meilleur de leur part. En l'occurrence tu as travaillé sur le code de la personne, le plus naturel est de lui en parler de façon naturelle, et de s'attendre (naturellement) à une réponse, quoi qu'il y ait marqué sur sa page web.
Que tu ais un retour ou non, en fait dès maintenant, tu peux faire tout ce qui te semble gentil et raisonnable. Par exemple héberger ta branche modifiée quelque part (de préférence un endroit un peu plus visible que Launchpad, par exemple Gitlab), avec une mention claire du fait que c'est une version de travail que tu as envoyée upstream et que tu espères que ça va être intégré à terme.
Je trouve que tout cela est assez simple et que tu réfléchis un peu trop, à apprendre une page web par cœur et demander des avis sur LinuxFR avant d'envoyer un email. Fais comme ça vient !
Je suis certainement dans le cas où je devrais attendre des mois, car il écrit clairement sur sa page de développement qu'il ne veut pas d'aide au développement.
Je ne vois pas de raison d'avoir des certitudes, mais si tu penses attendre il vaut mieux écrire le plus tôt possible.
Je n'hésiterais pas dans un cas comme cela à écrire au développeur de HomeBank. Tu fais des plates excuses sur le fait d'avoir commencé à coder avant de lire ses instructions, et que donc tu ne l'as pas contacté auparavant, mais que maintenant tu as un patch et/mais tu es prêt à refaire autre chose différemment s'il a une meilleure approche. Et là tu vois ce qu'il se passe.
Comme je l'ai de nouveau expliqué pour Unity, le fait qu'une bibliothèque soit en interne codée dans un autre langage ne change rien au calcul "on peut parfaitement écrire une application pour faire X dans un langage à GC". Ça ne veut pas dire que tout le code qui tourne aura été écrit dans ce langage, il va y avoir aussi du code C qui tourne (si tu es sous Linux), du code assembleur, des opcodes écrit en microcode processeur, et alors ?
iOS quand a lui a toujours été en langage relativement bas niveau (Objective-C) et sans garbage collector.
À ma connaissance Apple impose l'utilisation de leur technique de gestion de mémoire automatique, ARC (qui est bien une forme de gestion automatique de la mémoire, quoi que tu sembles dire), à la fois pour les applications en Objective-C, et aussi en Swift où c'est le seul choix.
Je ne suis pas d'accord. Les jeux vidéos ont, sont toujours, et seront toujours en C++ ( du moins à court terme ). Ce qui est en C# c'est l'interface de scripting des jeux pour Unity, ce qui est normale et n'a rien de révolutionnaire. Elle était en Lua, python ou home made script ( Unreal script ) pendant très longtemps.
Aujourd'hui il y a plein de jeux dont le code source (le truc écrit par les gens qui sont les auteurs du jeu) est écrit intégralement en C# (ou Lua, etc.). Les grosses boîtes de production vont avoir plus de code bas niveau, les indépendant-e-s vont beaucoup plus reposer sur un moteur existant, mais ma remarque était qu'on peut aujourd'hui tout à fait "écrire un jeu vidéo" dans un langage à GC, c'est même la norme. (Voir aussi les jeux sur le web, Android, iOS, etc…)
Le fait que le moteur 3D (ou IA, ou son, ou…) soit fait dans un autre langage n'est pas visible pour les personnes qui créent le jeu vidéo.
Prends un bon 90% des logiciels que tu vois sur ton écran à l'instant ils suivent ce pattern : […] ton web browser, ton environnement de bureau, ton client email.
Ces observations sont biaisées par le fait que l'écosystème logiciel pour les ordinateurs personnels GNU/Linux est fortement biaisé en faveur de C (pour GNOME) et C++ (pour KDE), avec une toute petite place pour les langages de plus haut niveau, à l'inverse de iOS, Android etc.
En lisant cette dépêche (super par ailleurs, merci !) ma curiosité a été piquée par le "22 commits par jour". J'ai comparé avec mon projet libre préféré qui est bien en-dessous, ça m'a impressionné. Et puis j'ai refait le calcul sur un clone de gimp, et je me suis rendu compte que ce n'était pas très fiable comme nombre.
Tu parles de "depuis 2.10.2" et je ne sais pas quand tu as fait le calcul, donc c'est peut-être vrai, mais ensuite tu dis que ça fait "plusieurs années que le développement est aussi actif". Moi j'ai compté tous les commits en 2018, donc je rends compte de l'activité de développement "cette année", sur moins d'un an:
[^] # Re: Mauvais message
Posté par gasche . En réponse à la dépêche Les femmes et l’informatique — émission « Libre à vous ! » du 5 novembre 2019. Évalué à 3.
L'enquête de l'INSEE (j'ai mis le lien dans mon message) compte aussi le temps de bricolage et de "jardinage, soin des animaux", qui me semble contenir les tâches que tu décris. Ce n'est pas complètement clair pour l'entretien automobile, mais les catégories données ne sont pas très précises.
Les hommes selon cette enquête en font effectivement plus que les femmes : chez les salariés, 22 minutes par jour en moyenne chez les hommes, contre 5 minutes par jour chez les femmes. La différence reste assez petite par rapport à la différence d'ensemble des temps domestiques (qui inclus ces tâches), chez les salariés à 2h06 pour les hommes et 3h27 pour les femmes.
(Si on se limite, au sein des tâches domestiques, uniquement à "ménage, cuisine, linge, courses", la différence est encore plus marquée puisqu'on a, chez les salariés, 1h11 chez les hommes et 2h36 chez les femmes. Mais effectivement cette catégorie regroupe les tâches plutôt féminines et exclus des tâches plutôt masculines, donc elle ne donne pas une bonne idée d'ensemble du temps de travail domestique.)
[^] # Re: Mauvais message
Posté par gasche . En réponse à la dépêche Les femmes et l’informatique — émission « Libre à vous ! » du 5 novembre 2019. Évalué à 3.
C'est n'importe quoi ce commentaire, une recherche "homme femme temps domestique" suffit pour montrer qu'il est juste faux.
https://www.inegalites.fr/L-inegale-repartition-des-taches-domestiques-entre-les-femmes-et-les-hommes
# Où trouver les sites et les programmes des années passées ?
Posté par gasche . En réponse à la dépêche Journées du Logiciel Libre de Lyon 2020 : l’appel à participation est ouvert !. Évalué à 4.
Où trouver le programme des années passées ? Les communications des années précédentes utilisaient une URL non millésimée, https://jdll.org/programme, qui pointe maintenant vers le programme vide de 2020. J'aimerais consulter le programme de 2019 ou 2018, en particulier les conférences, pour me faire une idée de l'événement.
[^] # Re: Petite erreur
Posté par gasche . En réponse à la dépêche Moi, expert C++, j’abandonne le C++. Évalué à 3.
Les OS les plus utilisés sont écrits dans des langages non-sûrs (C et C++) et d'ailleurs ils sont bourrés de failles, comme les logiciels qui font l'infrastructure internet. Ça fait des décennies que des centaines voire milliers de gens sont payés pour réagir au quart de tour à la dernière faille de type "buffer overflow" trouvée dans un logiciel critique, tout ça parce que tout ce logiciel est écrit dans un langage où la grande majorité des erreurs de programmation permettent à un attaquant malicieux d'exécuter du code arbitraire. On a collectivement investi des milliers d'années de travail, de l'argent par million, pour gérer les conséquences de ces choix désastreux (même si c'était moins visible à l'époque où ils ont été faits) de construire toute notre infrastructure sur des langages fortement peu sûrs.
Buggué, sans doute—même s'il existe des langages qui permettent d'exprimer son besoin plus clairement et donc d'avoir moins de bugs. Mais tous les bugs ne deviennent pas automatiquement des énormes failles de sécurité. Par exemple, si tu as un parseur d'un format binaire quelconque écrit en C, la plupart des erreurs de programmation permettent à un attaquant qui fournit un binaire malicieux d'exécuter du code (d'où l'exemple de prise de contrôle d'une voiture en insérant un CD audio bien choisi; il y a une erreur d'architecture dans le système, mais aussi un langage non-sûr qui permet de l'exploiter très facilement). On n'a pas du tout le même problème si on écrit le même parseur en Java, Ada, OCaml, WebAssembly, ou n'importe quel autre langage qui garantit la sûreté mémoire par défaut.
Un langage qui garantit que tous les accès à un tableau sont vérifiés pour leur validité protège des failles de sécurité lié à un accès arbitraire en mémoire—si l'implémentation du langage et le matériel dessous sont corrects. Tous les langages à la modes ne donnent pas forcément de bonnes garanties—mais en fait aujourd'hui presque tous les langages donnent de meilleures garanties que C.
(Certains langages dynamiques introduisent des problèmes de sécurité qui n'existent pas avec C, en permettant à chaque bibliothèque d'aller redéfinir n'importe quel autre symbole visible par l'utilisateur ou presque.)
[^] # Re: Petite erreur
Posté par gasche . En réponse à la dépêche Moi, expert C++, j’abandonne le C++. Évalué à 3.
Peu de gens comprennent vraiment le modèle mémoire des atomiques de C11 (les concepteurs du standard ont voulu faire plus fin et plus optimisé que celui Java, et donc pendant longtemps on n'a pas su si le modèle était raisonnable/correct), et parmi les gens qui le comprennent vraiment il y en a peu qui écrivent des programmes en C. Du coup pour les programmes multi-threadés, la plupart n'utilise pas les atomiques de C11 (typiquement le noyau Linux qui avait ses propres macros pour insérer des barrières), et la plupart de ceux qui les utilisent sont quand même indéfinis. En tant que simple mortel il faut vraiment être très strict, et ne pas descendre en-desous de release/acquire, pour ne pas se planter.
[^] # Re: Petite erreur
Posté par gasche . En réponse à la dépêche Moi, expert C++, j’abandonne le C++. Évalué à 7.
C est aussi le langage des "comportements indéfinis", où personne n'est d'accord sur ce que devrait faire un programme et en fait tous les programmes sont faux (n'ont pas de sémantique définie) (en tout cas presque tous, surtout les programmes qui utilisent du multi-threading). Utiliser C pour un nouveau projet aujourd'hui, pour moi c'est irresponsable du point de vue de la correction et de la sécurité.
[^] # Re: Composer, pip, npm, gem, go-get et cargo, ces nouveaux SPOF des temps modernes...
Posté par gasche . En réponse à la dépêche Moi, expert C++, j’abandonne le C++. Évalué à 9. Dernière modification le 08 juin 2019 à 17:25.
Sauf que créer un paquet npm (ou pip, gem, etc.) me permet de déployer mon code chez des gens qui utilisent n'importe quelle distribution, pas seulement la mienne. C'est autrement plus facile que d'écrire un paquet pour chaque empaqueteur Linux, OSX et BSD.
Les gestionnaires de paquets spécifiques à une communauté ont des défauts et aussi des avantages. Pour les gens qui attachent plus d'importance à l'appartenance à cette communauté qu'à leur utilisation d'une distribution spécifique, ils sont clairement avantageux. Pour des gens qui utilisent ces travaux communautaires comme un paquet parmi d'autre au sein d'un système donné, ils sont clairement moins commodes qu'un empaquetage de distribution.
Je trouve un peu triste qu'on répète ce débat à chaque fois, chaque personne donnant seulement un des points de vue ("développeur Javascript", "admin Debian", etc.), ce qui ne permet pas de comprendre la situation.
Par ailleurs je remarques que les empaqueteurs des distributions sont très lents à réagir à de nouveaux besoins. Les développeurs sont très clairs sur le fait qu'ils ont besoin de travailler sur plusieurs projets qui vont utiliser chacun une version différente d'un paquet donné. Quels sont les gestionnaires de distributions qui permettent ça facilement ? À ma connaissance il n'y a que Nix et Guix qui font un bon boulot là-dessus, alors que pourtant c'est un besoin qui est apparu il y a des années. C'est bien beau de venir ensuite faire la morale "non mais les gestionnaires paquage-spécifique c'est puéril, il suffit d'utiliser Rpm/Deb/whatever".
[^] # Re: Mon avis
Posté par gasche . En réponse au journal Moi, expert C++, j'abandonne le C++. Évalué à 2.
C'est peut-être aussi le moment de rappeler qu'il existe des postes où on a de la liberté pour faire son travail dans de bonnes conditions—toutes les entreprises ne se valent pas, on peut avoir plus ou moins de marge de manœuvre, et il y a des besoins d'informaticiens en dehors du secteur privé (personnellement je suis dans le secteur de la recherche publique, qui embauche des chercheurs mais aussi des ingénieurs, et qui a la valeur du travail bien fait). Ça ne veut pas dire abandonner complètement la recherche de l'efficacité au travail, et il y a aussi souvent des inconvénients à accepter en conséquence (plus difficile d'obtenir un poste stable, salaire plus faible).
Les personnes qui savent programmer ont la chance d'être dans un domaine où la demande en personnel est très forte. Il est possible d'en profiter pour être un peu difficile sur les offres qu'on accepte, et de ne pas se laisser imposer des environnements de travail qui ne nous conviennent pas.
[^] # Re: .
Posté par gasche . En réponse à la dépêche GIMP 2.10.10 : « c’est dur de colorier ! ». Évalué à 4.
Il existe des postes d'ingénieur de recherche dans la plupart des instituts de recherche publique française, qui cherchent des compétences souvent assez pointues pour contribuer à la recherche scientifique. À chaque fois, il y a des postes en CDD et aussi des postes permanents (moins nombreux, plus difficiles à obtenir). Exemples:
(attention, certains postes "ingénieurs" sont plus administratifs que R&D, c'est dit clairement dans la description du poste.)
[^] # Re: .
Posté par gasche . En réponse à la dépêche GIMP 2.10.10 : « c’est dur de colorier ! ». Évalué à 10.
En tant que fonctionnaire (qui contribue aussi au logiciel libre) je trouve ça un poil vexant de lire ça. J'espère que cet exemple particulier (et, je suis d'accord, particulièrement sympathique) te fera réfléchir au fait qu'il existe plein de gens qui travaillent, grâce à nos impôts à tous, pour l'intérêt général, au CNRS et ailleurs. C'est un peu dommage ces petites formules qui critiquent tous les services publics, alors que ce sont des milieux très diversifiés qui sont remplis de beaucoup d'êtres humains qui font des choses importantes avec générosité.
# system76
Posté par gasche . En réponse au journal Sélection d'un PC libre. Évalué à 3.
J'ai décidé que ma prochaine machine serait une system76, et il me semble que c'est un vendeur qui pourrait t'intéresser—je n'ai pas vérifié pour les ports disponibles, mais pour le reste ça fait ce que tu veux : des ordinateurs portables de bonne qualité, y compris des machines puissantes/récentes, et du logiciel libre. Voici par exemple un pointeur veurs leur laptop 13"/14", le Galago à $900.
[^] # Re: Vala ?
Posté par gasche . En réponse à la dépêche Financement participatif pour Akira. Évalué à 3.
Il y a plein de projets intéressants dans plein de langages différents, et c'est un peu la norme de devoir découvrir un nouveau langage (ou un nouveau mode d'usage d'un langage qu'on a déjà utilisé) quand on veut contribuer à un projet spécifique—ou un nouveau gestionnaire de version, système de build, etc. C'est difficile de créer un projet à partir de rien dans un nouveau langage, mais éditer du code en se guidant avec l'existant est beaucoup plus raisonnable.
[^] # Re: Inférence de types
Posté par gasche . En réponse à la dépêche Sortie de JDK 10. Évalué à 4. Dernière modification le 11 novembre 2018 à 18:38.
La réponse:
- souvent c'est évident selon le contexte (par exemple ce qui se trouve à droite est le constructeur d'une classe)
- quand ça ne l'est pas, je peux demander à mon éditeur de me donner le type (chez moi c'est
C-c C-t, chacun ses goûts)Si tu refuses d'avoir des outils pour t'aider dans ta programmation, tu as toujours le loisir de râler sur tes collègues, pendant la relecture de code, quand ils utilisent un
auto/varà un endroit où ce n'est pas clair pour toi.Je pense qu'aucun test dynamique n'est fait dans le code C++ qu'il montre. Par ailleurs, Java est un langage qui fait un test de typage dynamique à chaque écriture dans un tableau, donc je dirais qu'il faut se détendre un peu.
[^] # Re: optimisation et propagation de constante
Posté par gasche . En réponse à la dépêche OCaml 4.06 et 4.07. Évalué à 4.
Oleg ne travaille plus là-bas (il est professeur d'université au Japon depuis quelques années) et il me semble qu'il y a beaucoup de groupes de recherche&développement qui travaillent sur des prototypes sans pour autant mettre du code en production dans leur structure mère. Ce que tu dis n'est pas impossible (Oleg a travaillé sur des spécialisations de bibliothèques d'algèbre linéaire et calcul numérique, c'est compatible) mais me semble drôlement spéculatif.
[^] # Re: optimisation et propagation de constante
Posté par gasche . En réponse à la dépêche OCaml 4.06 et 4.07. Évalué à 5.
J'ai pensé que tu ne connaissais pas le sujet car tu as posé la question comme si tu ne connaissais pas le sujet:
J'ai supposé que, si tu savais que c'est un domaine sur lequel des gens ont travaillé, tu l'aurais indiqué en donnant un pointeur vers ces travaux (ou au moins le mot-clé à chercher : évaluation partielle, projection de Futamura, etc.), afin d'aider les gens intéressés à se renseigner plus en profondeur.
(À relire ton message, tu mentionnes l'idée de spécialiser un interpréteur pour obtenir un compilateur, qui est assez avancée. J'aurais pu me douter que tu avais lu des choses sur le sujet, mais je me suis simplement dit que c'étaient des méditations sous la douche ou équivalent.)
[^] # Re: optimisation et propagation de constante
Posté par gasche . En réponse à la dépêche OCaml 4.06 et 4.07. Évalué à 6.
Je trouve assez gonflé de critiquer une fonctionnalité d'un langage expérimental parce que tu n'aimes pas la syntaxe. Est-ce vraiment moins lisible que HTML ou Lisp ? Un utilisateur qui a un poil l'habitude sait lire d'abord le code dans les annotations de staging (étagement ?), et voir ensuite la structure des annotations (qui indique la séparation entre le code exécution statiquement et le code produit).
Tu ouvres un fil de discussion avec une question un peu naïve qui correspond à un domaine de recherche entier (le mot-clé pour chercher les références est "évaluation partielle", "partial evaluation") qui a commencé dans les années 1970. Les gens ont pas mal réfléchi à ça, poussé l'idées dans des recoins intéressants, et un consensus qui est en train de se former est que pour avoir de la prédictibilité sur les performances obtenues il faut séparer explicitement les parties évaluées statiquement et dynamiquement (et, dans le cas général, à un stage/étage ou un autre).
Il y a des choses intéressantes qui sont faites dans ce domaine, et je trouve ça un peu triste d'ignorer une idée simplement parce que tu n'aimes pas la syntaxe. Si le sujet t'intéresse, tu devrais peut-être te renseigner sur ce que les gens ont déjà fait dessus.
Note: MetaOCaml et les templates/
constexprn'ont pas le même but. L'idée de la méta-programmation "staged" (étagée) est de laisser l'utilisateur définir ses propres évaluations partielles, pour les calculs qui comportent un mélange entre une partie déterminée statiquement et une partie déterminée dynamiquement (par exemple: précalcul de flot de contrôle, ou autotuning "statique" du code pour une architecture spécifique).constexprpropose une forme d'évaluation statique fixée par le langage, où tout doit pouvoir être calculé statiquement. C'est facile à utiliser mais l'utilisateur ne peut pas contrôler la méthode de spécialisation. Dans le cadre plus général de la métaprogrammation template, on peut choisir des mélanges entre calcul statique et calcul dynamique, mais les possibilités sont limitées aux formes de spécialisation prévues par le compilateur du langage, plutôt que programmées directement par l'utilisateur.[^] # Re: En cas de doute il faut en parler -- avec la personne concernée
Posté par gasche . En réponse au journal Forker ou ne pas forker ?. Évalué à 4.
J'ai déjà travaillé avec des gens frileux, ayant peur de montrer leur travail intermédiaire au monde. Le modèle "je donne des tarballs de mes release mais pas l'accès au dépôt versionné" est malheureusement plus courant qu'on ne pourrait le croire. Parfois les gens ont changé de point de vue à force de discussion et mettent tout en ligne aujourd'hui. Souvent ils sont restés sur leur position. Quand je contribue, j'essaie de m'adapter aux choix et préférences des gens qui ont fait le gros du boulot—tout en étant clair sur le fait que je préfère faire les choses différemment, si on me pose la question. Si on fait comme ça vient, et que des deux côtés les gens ont de bonnes intentions, ça se passe en général bien.
[^] # Re: En cas de doute il faut en parler -- avec la personne concernée
Posté par gasche . En réponse au journal Forker ou ne pas forker ?. Évalué à 10. Dernière modification le 16 septembre 2018 à 12:58.
On n'est pas là (ni toi) pour construire un modèle mental prédictif d'un individu à partir de sa page web ou pour lui faire une psychanalyse gratuite. Je pense que ce qui marche le mieux c'est d'être gentil avec les gens et de s'attendre au meilleur de leur part. En l'occurrence tu as travaillé sur le code de la personne, le plus naturel est de lui en parler de façon naturelle, et de s'attendre (naturellement) à une réponse, quoi qu'il y ait marqué sur sa page web.
Que tu ais un retour ou non, en fait dès maintenant, tu peux faire tout ce qui te semble gentil et raisonnable. Par exemple héberger ta branche modifiée quelque part (de préférence un endroit un peu plus visible que Launchpad, par exemple Gitlab), avec une mention claire du fait que c'est une version de travail que tu as envoyée upstream et que tu espères que ça va être intégré à terme.
Je trouve que tout cela est assez simple et que tu réfléchis un peu trop, à apprendre une page web par cœur et demander des avis sur LinuxFR avant d'envoyer un email. Fais comme ça vient !
[^] # Re: En cas de doute il faut en parler -- avec la personne concernée
Posté par gasche . En réponse au journal Forker ou ne pas forker ?. Évalué à 5.
Je ne vois pas de raison d'avoir des certitudes, mais si tu penses attendre il vaut mieux écrire le plus tôt possible.
# En cas de doute il faut en parler -- avec la personne concernée
Posté par gasche . En réponse au journal Forker ou ne pas forker ?. Évalué à 6.
Je n'hésiterais pas dans un cas comme cela à écrire au développeur de HomeBank. Tu fais des plates excuses sur le fait d'avoir commencé à coder avant de lire ses instructions, et que donc tu ne l'as pas contacté auparavant, mais que maintenant tu as un patch et/mais tu es prêt à refaire autre chose différemment s'il a une meilleure approche. Et là tu vois ce qu'il se passe.
# Upstream ?
Posté par gasche . En réponse au journal softs dev en Rust empaqueté pour Ubuntu & cie. Évalué à 3.
As-tu prévu de pousser pour mettre cela dans les dépôts upstream ? (Y a-t-il moyen de collaborer avec les gens côté Debian ?)
# Moi j'ai trouvé ça drôle
Posté par gasche . En réponse au journal Nouveau coup de tonnerre attendu. Évalué à 10.
Le fait que le détecteur de sarcasme ait des problèmes avec ce journal est ce qui le rend si drôle, je pense.
Merci pour ce bel effort d'écriture.
[^] # Re: Phobie du GC
Posté par gasche . En réponse à la dépêche Faut‐il continuer à apprendre le C++ ?. Évalué à 5.
Comme je l'ai de nouveau expliqué pour Unity, le fait qu'une bibliothèque soit en interne codée dans un autre langage ne change rien au calcul "on peut parfaitement écrire une application pour faire X dans un langage à GC". Ça ne veut pas dire que tout le code qui tourne aura été écrit dans ce langage, il va y avoir aussi du code C qui tourne (si tu es sous Linux), du code assembleur, des opcodes écrit en microcode processeur, et alors ?
À ma connaissance Apple impose l'utilisation de leur technique de gestion de mémoire automatique, ARC (qui est bien une forme de gestion automatique de la mémoire, quoi que tu sembles dire), à la fois pour les applications en Objective-C, et aussi en Swift où c'est le seul choix.
[^] # Re: Phobie du GC
Posté par gasche . En réponse à la dépêche Faut‐il continuer à apprendre le C++ ?. Évalué à 1.
Aujourd'hui il y a plein de jeux dont le code source (le truc écrit par les gens qui sont les auteurs du jeu) est écrit intégralement en C# (ou Lua, etc.). Les grosses boîtes de production vont avoir plus de code bas niveau, les indépendant-e-s vont beaucoup plus reposer sur un moteur existant, mais ma remarque était qu'on peut aujourd'hui tout à fait "écrire un jeu vidéo" dans un langage à GC, c'est même la norme. (Voir aussi les jeux sur le web, Android, iOS, etc…)
Le fait que le moteur 3D (ou IA, ou son, ou…) soit fait dans un autre langage n'est pas visible pour les personnes qui créent le jeu vidéo.
Ces observations sont biaisées par le fait que l'écosystème logiciel pour les ordinateurs personnels GNU/Linux est fortement biaisé en faveur de C (pour GNOME) et C++ (pour KDE), avec une toute petite place pour les langages de plus haut niveau, à l'inverse de iOS, Android etc.
# Fréquence de commits un peu exagérée
Posté par gasche . En réponse à la dépêche GIMP 2.10.4 : on garde le rythme !. Évalué à 4.
En lisant cette dépêche (super par ailleurs, merci !) ma curiosité a été piquée par le "22 commits par jour". J'ai comparé avec mon projet libre préféré qui est bien en-dessous, ça m'a impressionné. Et puis j'ai refait le calcul sur un clone de gimp, et je me suis rendu compte que ce n'était pas très fiable comme nombre.
Tu parles de "depuis 2.10.2" et je ne sais pas quand tu as fait le calcul, donc c'est peut-être vrai, mais ensuite tu dis que ça fait "plusieurs années que le développement est aussi actif". Moi j'ai compté tous les commits en 2018, donc je rends compte de l'activité de développement "cette année", sur moins d'un an:
Pour compter le nombre de commits par jour, on utilise le format
%jde date pour avoir le numéro du jour courant dans l'année:Bref, il y a eu 11 commits par jour en 2018, ce qui est moins que 22, mais ça fait quand même beaucoup.
Pour finir, une liste du nombre de commits par jour: