Pourquoi ce serait «facile» d'avoir comme règle de codage «pas de unsafe a moins qu'il y ait une justification» et que ce serait difficile d'avoir le même genre de règle pour C++ ? La règle est juste un poil plus longue mais pas tant que ça (pas d'exceptions, de RTTI, d'héritage multiple ; et pour C++14, pas de new/delete). Si tu es obligé de mettre une règle pour Rust, c'est qu'il n'est pas si sûr que ça. Et dans ces cas là, C++ est tout aussi sûr. Parce que mettre des règles, ce n'est pas pour les compilateurs, c'est pour les humains.
Ce que je te dis, c'est que, certes, Rust apporte quelques sécurités mais ne t'empêche nullement de faire de la merde parce que tu peux passer par unsafe. Et le fait que ce soit marqué unsafe, ça ne va pas gêner ceux qui font de la merde. Le problème, il n'est pas technique, il est humain. Et C++, là dedans, il permet lui aussi d'avoir quelques sécurité (pas les mêmes que celles de Rust) mais il permet aussi de faire de la merde (sans préfixe unsafe). Comme le problème est humain, l'un n'est pas mieux que l'autre.
Oui, comme en Rust. Et tout le monde s'en fout la manière dont c'est implémenté, l'important c'est que ça marche comme c'est spécifié. Le fait que ce soit dans la bibliothèque standard ou dans le langage lui-même ne change pas grand chose à l'affaire.
Non certains langage accepte par défaut que tu fasse de la merde et d'autres te permettent de faire de la merde si tu lui dis « ok je sais que je suis entrain de faire de la merde ». Bien sûr la limite entre les 2 est floue, mais le C++ est clairement plus dans la première partie que dans la seconde.
Donc, tu es en train de dire que mettre un préfixe «unsafe» devant tous les trucs gorets, ça change absolument tout ? S'il y a un «unsafe», c'est bien que ça doit servir à un moment, non, sinon ça ne serait pas là ? Et bien moi, je préfère qu'on ne mette pas un «unsafe» et qu'on apprenne à l'utilisateur ce qu'il ne faut pas faire et pourquoi, plutôt que d'avoir un préfixe «unsafe» inutile parce que du coup, on se demande bien ce que ça peut faire là. Et puis si les gars qui codent l'utilisent, c'est qu'on doit pouvoir l'utiliser, donc c'est pas si unsafe. Donc de toute façon, dans tous les cas, tu trouveras toujours un couillon qui utilisera mal le langage (préfixe «unsafe» ou pas) et qui fera de la merde.
Tu va peut être être surpris mais le C++ n'a pas 3 ans, donc il faut supporter le code plus ancien.
Oui, et ce code plus ancien, a priori, il doit bien marcher et ne pas faire trop de connerie, sinon ça serait corrigé.
Tu as quoi pour vérifier que tu ne fais pas des usages dommageables ? Tu peut utiliser le dernier icc, g++, clang++ en appliquant la dernière version de la norme, tu pourra toujours faire un brk(2) des familles. Un langage sûr c'est un langage qui te l'interdit.
brk(2) est un appel POSIX, il n'est pas dans la norme C++.
Ceux qui ne savent pas ce qu'est le polymorphisme ? ;-)
C++ est très "unsafe" (pointeurs nuls, gestion manuelle de la mémoire
Dire que la gestion manuelle de la mémoire est «unsafe», c'est vraiment un truc à la mode ces dernières années. Surtout qu'avec C++11, on n'a quasiment plus aucun besoin de gérer la mémoire. En C++14, on n'aura même plus besoin de faire des new et delete, ils seront masqués complètement. Qu'est-ce qu'on reproche encore à C++ à ce niveau ? Des fantasmes sans doute. Le C++ n'est pas du C !
Qu'est-ce qui le différenciera de Rust ? Plus grand chose à mon sens. Ceux qui font de la merde avec la gestion mémoire, ils le savent en C++, il n'ont pas besoin de mettre un préfixe unsafe.
sémantique compliquée, unions, mutabilité par défaut) même si pas autant que C,
La sémantique de C++ n'est pas plus compliquée que celle de Rust. Juste différente. Question de goût.
Les unions… Hormis dans des cas extrêmes et bien identifiés, qui utilisent des unions ?
écrire un programme concurrent correct en C++ est très difficile.
Faux ! Ce qu'il manque à C++, c'est un modèle de programmation dans la bibliothèque standard. C++ laisse l'utilisateur le définir. En Rust, comme en Go d'ailleurs, le modèle de programmation est imposé. Maintenant, en C++, tu peux très bien trouver des bibliothèques comme TBB qui permettent d'avoir de la concurrence très facilement.
Avec ta définition, un vieux langage ne pourra jamais être un bon langage. Parce qu'un vieux langage se traînent nécessairement une dette technique dont il est parfois difficile de se débarrasser, surtout quand le langage en question est une norme ISO et est aussi répandu que C++.
J'avoue que si on me demandait par quoi j'aimerais que le c++ soit remplacé
Pourquoi vouloir remplacer C++ ? Depuis C++11, honnêtement, c'est devenu un vrai plaisir d'écrire du C++ et ça va être encore mieux avec C++14 et C++17.
J'ai lu aussi le contenu initial. Mais je ne comprends pas cette demi-mesure : on enlève le texte (ce qui arrive quand même (heureusement) assez rarement ici), mais on laisse un lien vers un site raciste. Les autres liens sont suffisants pour comprendre, pas la peine de garder celui-ci. Et si on pouvait directement supprimer tout le journal, ça ne serait pas un mal. Il est tout à fait possible d'avoir un débat sur ce sujet dans un nouveau journal qui présente les faits de manière plus «neutre» (et la barre n'est pas très haute quand je dis ça).
Parce que bon, à ce jeu là, on va trouver des gens qui n'aiment pas les autres sites non plus.
La question n'est pas d'aimer ou pas les sites.
Le but ici c'est pas de définir une ligne éditoriale politique, mais s'assurer que l'expression des idées est faite dans le respect de chacun (et donc sans propos injurieux, par exemple).
LinuxFR est sous juridiction française. Et en France, on n'est pas aux États-Unis, la liberté d'expression a des limites. En particulier, le racisme et l'homophobie ne sont pas des opinions mais des délits, punis par la loi. Après, tu peux trouver ça con, mais c'est comme ça actuellement. Donc faire un lien vers un site qui pratique ouvertement le racisme, l'homophobie et d'autres trucs interdits également par la loi (genre le négationnisme) ne me paraît pas être la meilleure des idées.
On peut prendre le problème différemment : est-ce que tu joues en guilde avec des gens que tu connais déjà ou est-ce que tu rencontres des gens dans le jeu et tu décides de créer une guilde ? Le cas 1 me semble plus courant que le cas 2.
La plupart des MMORPG sont de qualité moyenne à mauvaise. C'est à la mode, donc il y en a beaucoup. Mais ce qu'on pouvait accepter d'un MMORPG il y a quelques années (et que tu décris), on l'accepte moins maintenant, et il existe aussi des MMORPG de bonne qualité.
Dans SWTOR, il faut aller un peu plus loin, parce qu'après avoir choisi ton camp (Empire vs République) et ta classe (4 par camp), tu vas jouer soit lumineux, soit obscur, et les quêtes changent suivant ce choix donc, ça fait 16 combinaisons possibles si tu veux tout explorer. En vrai ça fait moins que ça, mais disons que ça complexifie l'univers. Et puis, c'est tellement jouissif de jouer un lumineux côté Empire.
C'est un peu caricatural. C'est surtout vrai pour les MMO de mauvaise qualité (et j'en ai fait plusieurs comme ça). Mais si tu prends Star Wars: The Old Republic, chaque quête annexe est une histoire à part entière, avec parfois plusieurs étapes cohérentes entre elle, et des intrigues qui se suivent à distance. Bref, on est loin de ta caricature. Il est aussi possible de voir des choses de bonne qualité.
Comme vous l'aviez bien compris, il s'agissait d'un poisson d'avril ;) Donc, pour rassurer ceux qui sont tombés dedans, il n'est pas question de transformer Akagoria en un jeu propriétaire, ni que je devienne développeur de jeux indie à temps complet. Akagoria est et restera libre. Et il ne deviendra pas non plus un MMORPG.
D'ailleurs, j'ai beaucoup aimé la discussion sur cette question. Pour moi, les MMORPG ne sont, dans leur très grande majorité, pas multijoueurs dans le sens où les joueurs ne font souvent que partager un espace de jeu mais sans beaucoup plus. Les intéractions entre joueurs sont extrêmement cadrées, et on pourrait résumer par : soit tu es contre moi (JcJ) soit tu es avec moi (guilde). Il y a assez peu de richesse à ce niveau là. Et sur les scénarios, je suis plutôt de l'avis de Xinul, si on ne se contente pas d'aller du point A au point B comme demandé dans la quête, il y a des histoires bien foutues et riches. Elles seraient tout aussi bien foutues et riches dans un RPG hors-ligne.
Avec toute la reconnaissance que j'ai envers leur travail, de mémoire elles ne sont pas développeuses mais respectivement documentatrice/traductrice et manager.
Et Lucas Nussbaum, par exemple, il est développeur ? Non, il est reconnu pour tout ce qu'il a fait dans Debian. Il a fait quelques bouts de code (notamment pour mieux gérer ruby dans Debian) mais ce n'est pas pour ses bouts de code qui sont mis en avant, mais son rôle global dans Debian. Et Stéphane Bortzmeyer, tu peux me citer une appli qu'il a développé ? Ben non, parce qu'il n'est pas cité pour ça, il est cité pour ses contributions non-logicielles.
Donc, ça n'est pas du tout hors sujet. Au contraire, ça montre qu'il n'y a pas que le code dans la vie (et en ce moment, je trouve qu'on tente de réduire l'informatique à ça, et c'est n'importe quoi), il y a aussi tout ce qu'il y a autour qui parfois ne nécessite pas de savoir coder mais qui est tout aussi important.
On se plaint de ne pas avoir assez de femmes en informatique, mais dès qu'il s'agit de mettre en avant des exemples, on n'arrive à trouver que… deux femmes : Clémence Saussez et Pascale Vicat-Blanc. Et pourtant, ce n'est pas très dur d'en trouver, en particulier dans le libre. Sophie Gautier (LibreOffice), Anne (Mageia) sont les premiers noms qui me viennent en tête immédiatement. Et il y en a beaucoup d'autres. Bref, c'est raté sur ce point et c'est bien dommage.
Mais c'est vrai pour la réflexion sur les salaires où globalement en France le développeur est peu valorisé financièrement par rapport à la finance ou la gestion… Alors que les développeurs ont un potentiel de création d'emplois plus intéressants.
En France, on valorise beaucoup trop les emplois non-productifs : gestion, finance, commercial, ressources humaines, etc. Ces emplois, dans une entreprise, ne produisent rien qui puissent être vendu ensuite (ce qui est quand même le cœur d'une entreprise) mais sont payés largement plus que les emplois productifs.
C’est d’ailleurs assez impressionnant, et le rapport en parle, beaucoup de ces développeurs ont choisi de rejoindre les géants de l’informatique étrangers.
Le «problème», c'est qu'il n'y a pas de géant français. Et finalement, je ne suis pas sûr que ce soit un problème et/ou que ça empêche nos développeurs de réussir en France. Alors c'est sûr qu'un géant, ça fait bien, on peut en parler dans les médias et au ministère du redressement productif, mais en dehors de ça, pas grand chose.
[^] # Re: Rust vs Go
Posté par rewind (Mastodon) . En réponse à la dépêche Rust s’oxyde en version 0.10. Évalué à 3.
Pourquoi ce serait «facile» d'avoir comme règle de codage «pas de unsafe a moins qu'il y ait une justification» et que ce serait difficile d'avoir le même genre de règle pour C++ ? La règle est juste un poil plus longue mais pas tant que ça (pas d'exceptions, de RTTI, d'héritage multiple ; et pour C++14, pas de new/delete). Si tu es obligé de mettre une règle pour Rust, c'est qu'il n'est pas si sûr que ça. Et dans ces cas là, C++ est tout aussi sûr. Parce que mettre des règles, ce n'est pas pour les compilateurs, c'est pour les humains.
[^] # Re: Rust vs Go
Posté par rewind (Mastodon) . En réponse à la dépêche Rust s’oxyde en version 0.10. Évalué à 1.
Ce que je te dis, c'est que, certes, Rust apporte quelques sécurités mais ne t'empêche nullement de faire de la merde parce que tu peux passer par unsafe. Et le fait que ce soit marqué unsafe, ça ne va pas gêner ceux qui font de la merde. Le problème, il n'est pas technique, il est humain. Et C++, là dedans, il permet lui aussi d'avoir quelques sécurité (pas les mêmes que celles de Rust) mais il permet aussi de faire de la merde (sans préfixe unsafe). Comme le problème est humain, l'un n'est pas mieux que l'autre.
[^] # Re: Rust vs Go
Posté par rewind (Mastodon) . En réponse à la dépêche Rust s’oxyde en version 0.10. Évalué à 2.
Oui, comme en Rust. Et tout le monde s'en fout la manière dont c'est implémenté, l'important c'est que ça marche comme c'est spécifié. Le fait que ce soit dans la bibliothèque standard ou dans le langage lui-même ne change pas grand chose à l'affaire.
[^] # Re: Rust vs Go
Posté par rewind (Mastodon) . En réponse à la dépêche Rust s’oxyde en version 0.10. Évalué à 1.
Donc, tu es en train de dire que mettre un préfixe «unsafe» devant tous les trucs gorets, ça change absolument tout ? S'il y a un «unsafe», c'est bien que ça doit servir à un moment, non, sinon ça ne serait pas là ? Et bien moi, je préfère qu'on ne mette pas un «unsafe» et qu'on apprenne à l'utilisateur ce qu'il ne faut pas faire et pourquoi, plutôt que d'avoir un préfixe «unsafe» inutile parce que du coup, on se demande bien ce que ça peut faire là. Et puis si les gars qui codent l'utilisent, c'est qu'on doit pouvoir l'utiliser, donc c'est pas si unsafe. Donc de toute façon, dans tous les cas, tu trouveras toujours un couillon qui utilisera mal le langage (préfixe «unsafe» ou pas) et qui fera de la merde.
[^] # Re: Et le programme ?
Posté par rewind (Mastodon) . En réponse au journal Le Parti Pirate cherche 5 femmes pour les Européennes avant le 21 avril. Évalué à 6.
Parce que le PP prétend faire de la politique autrement ?
[^] # Re: Rust vs Go
Posté par rewind (Mastodon) . En réponse à la dépêche Rust s’oxyde en version 0.10. Évalué à 4.
On utilisera
std::make_shared
(déjà dispo en C++11) etstd::make_unique
(en C++14)[^] # Re: Rust vs Go
Posté par rewind (Mastodon) . En réponse à la dépêche Rust s’oxyde en version 0.10. Évalué à 3.
Oui, et ce code plus ancien, a priori, il doit bien marcher et ne pas faire trop de connerie, sinon ça serait corrigé.
brk(2)
est un appel POSIX, il n'est pas dans la norme C++.Ceux qui utilisent GNU Bison…
[^] # Re: Rust vs Go
Posté par rewind (Mastodon) . En réponse à la dépêche Rust s’oxyde en version 0.10. Évalué à 3.
Dire que la gestion manuelle de la mémoire est «unsafe», c'est vraiment un truc à la mode ces dernières années. Surtout qu'avec C++11, on n'a quasiment plus aucun besoin de gérer la mémoire. En C++14, on n'aura même plus besoin de faire des
new
etdelete
, ils seront masqués complètement. Qu'est-ce qu'on reproche encore à C++ à ce niveau ? Des fantasmes sans doute. Le C++ n'est pas du C !Qu'est-ce qui le différenciera de Rust ? Plus grand chose à mon sens. Ceux qui font de la merde avec la gestion mémoire, ils le savent en C++, il n'ont pas besoin de mettre un préfixe
unsafe
.La sémantique de C++ n'est pas plus compliquée que celle de Rust. Juste différente. Question de goût.
Les unions… Hormis dans des cas extrêmes et bien identifiés, qui utilisent des unions ?
Faux ! Ce qu'il manque à C++, c'est un modèle de programmation dans la bibliothèque standard. C++ laisse l'utilisateur le définir. En Rust, comme en Go d'ailleurs, le modèle de programmation est imposé. Maintenant, en C++, tu peux très bien trouver des bibliothèques comme TBB qui permettent d'avoir de la concurrence très facilement.
[^] # Re: Rust vs Go
Posté par rewind (Mastodon) . En réponse à la dépêche Rust s’oxyde en version 0.10. Évalué à 7.
Avec ta définition, un vieux langage ne pourra jamais être un bon langage. Parce qu'un vieux langage se traînent nécessairement une dette technique dont il est parfois difficile de se débarrasser, surtout quand le langage en question est une norme ISO et est aussi répandu que C++.
Moi, je trouve que C++ est un bon langage.
[^] # Re: Rust vs Go
Posté par rewind (Mastodon) . En réponse à la dépêche Rust s’oxyde en version 0.10. Évalué à 10.
Pourquoi vouloir remplacer C++ ? Depuis C++11, honnêtement, c'est devenu un vrai plaisir d'écrire du C++ et ça va être encore mieux avec C++14 et C++17.
[^] # Re: Une analyse du bug.
Posté par rewind (Mastodon) . En réponse à la dépêche Nouvelle vulnérabilité dans l’implémentation OpenSSL. Évalué à 2.
Et le patch est là
[^] # Re: Appel à modérateurs
Posté par rewind (Mastodon) . En réponse au journal Journal bookmark. Évalué à 5.
Ha oui, mea culpa, je n'avais pas vu la NdM. Ça ne change pas grand chose au fait que ce lien devrait disparaître, à mon avis.
[^] # Re: Appel à modérateurs
Posté par rewind (Mastodon) . En réponse au journal Journal bookmark. Évalué à 0.
J'ai lu aussi le contenu initial. Mais je ne comprends pas cette demi-mesure : on enlève le texte (ce qui arrive quand même (heureusement) assez rarement ici), mais on laisse un lien vers un site raciste. Les autres liens sont suffisants pour comprendre, pas la peine de garder celui-ci. Et si on pouvait directement supprimer tout le journal, ça ne serait pas un mal. Il est tout à fait possible d'avoir un débat sur ce sujet dans un nouveau journal qui présente les faits de manière plus «neutre» (et la barre n'est pas très haute quand je dis ça).
La question n'est pas d'aimer ou pas les sites.
LinuxFR est sous juridiction française. Et en France, on n'est pas aux États-Unis, la liberté d'expression a des limites. En particulier, le racisme et l'homophobie ne sont pas des opinions mais des délits, punis par la loi. Après, tu peux trouver ça con, mais c'est comme ça actuellement. Donc faire un lien vers un site qui pratique ouvertement le racisme, l'homophobie et d'autres trucs interdits également par la loi (genre le négationnisme) ne me paraît pas être la meilleure des idées.
# Appel à modérateurs
Posté par rewind (Mastodon) . En réponse au journal Journal bookmark. Évalué à 8.
Est-ce qu'un modérateur pourrait enlever le lien vers fdesouche ? Parce que bon, voilà quoi.
[^] # Re: 2 avril
Posté par rewind (Mastodon) . En réponse au journal Akagoria devient un jeu indie propriétaire. Évalué à 2.
On peut prendre le problème différemment : est-ce que tu joues en guilde avec des gens que tu connais déjà ou est-ce que tu rencontres des gens dans le jeu et tu décides de créer une guilde ? Le cas 1 me semble plus courant que le cas 2.
[^] # Re: MMO
Posté par rewind (Mastodon) . En réponse au journal Akagoria devient un jeu indie propriétaire. Évalué à 2.
La plupart des MMORPG sont de qualité moyenne à mauvaise. C'est à la mode, donc il y en a beaucoup. Mais ce qu'on pouvait accepter d'un MMORPG il y a quelques années (et que tu décris), on l'accepte moins maintenant, et il existe aussi des MMORPG de bonne qualité.
[^] # Re: MMO
Posté par rewind (Mastodon) . En réponse au journal Akagoria devient un jeu indie propriétaire. Évalué à 2.
Dans SWTOR, il faut aller un peu plus loin, parce qu'après avoir choisi ton camp (Empire vs République) et ta classe (4 par camp), tu vas jouer soit lumineux, soit obscur, et les quêtes changent suivant ce choix donc, ça fait 16 combinaisons possibles si tu veux tout explorer. En vrai ça fait moins que ça, mais disons que ça complexifie l'univers. Et puis, c'est tellement jouissif de jouer un lumineux côté Empire.
[^] # Re: MMO
Posté par rewind (Mastodon) . En réponse au journal Akagoria devient un jeu indie propriétaire. Évalué à 4.
C'est un peu caricatural. C'est surtout vrai pour les MMO de mauvaise qualité (et j'en ai fait plusieurs comme ça). Mais si tu prends Star Wars: The Old Republic, chaque quête annexe est une histoire à part entière, avec parfois plusieurs étapes cohérentes entre elle, et des intrigues qui se suivent à distance. Bref, on est loin de ta caricature. Il est aussi possible de voir des choses de bonne qualité.
# 2 avril
Posté par rewind (Mastodon) . En réponse au journal Akagoria devient un jeu indie propriétaire. Évalué à 7.
Comme vous l'aviez bien compris, il s'agissait d'un poisson d'avril ;) Donc, pour rassurer ceux qui sont tombés dedans, il n'est pas question de transformer Akagoria en un jeu propriétaire, ni que je devienne développeur de jeux indie à temps complet. Akagoria est et restera libre. Et il ne deviendra pas non plus un MMORPG.
D'ailleurs, j'ai beaucoup aimé la discussion sur cette question. Pour moi, les MMORPG ne sont, dans leur très grande majorité, pas multijoueurs dans le sens où les joueurs ne font souvent que partager un espace de jeu mais sans beaucoup plus. Les intéractions entre joueurs sont extrêmement cadrées, et on pourrait résumer par : soit tu es contre moi (JcJ) soit tu es avec moi (guilde). Il y a assez peu de richesse à ce niveau là. Et sur les scénarios, je suis plutôt de l'avis de Xinul, si on ne se contente pas d'aller du point A au point B comme demandé dans la quête, il y a des histoires bien foutues et riches. Elles seraient tout aussi bien foutues et riches dans un RPG hors-ligne.
[^] # Re: Les géants de l'informatique
Posté par rewind (Mastodon) . En réponse à la dépêche 100 développeurs : la part belle à l’Open Source. Évalué à 4.
On n'a pas de grandes entreprises dont le logiciel est le cœur de métier
[^] # Re: domain public
Posté par rewind (Mastodon) . En réponse au journal Show us the code! Les sources de Microsoft Word enfin dispo !. Évalué à 7.
Ou de Pocahontas :P
[^] # Re: Trop peu de femmes
Posté par rewind (Mastodon) . En réponse à la dépêche 100 développeurs : la part belle à l’Open Source. Évalué à 5.
Et Lucas Nussbaum, par exemple, il est développeur ? Non, il est reconnu pour tout ce qu'il a fait dans Debian. Il a fait quelques bouts de code (notamment pour mieux gérer ruby dans Debian) mais ce n'est pas pour ses bouts de code qui sont mis en avant, mais son rôle global dans Debian. Et Stéphane Bortzmeyer, tu peux me citer une appli qu'il a développé ? Ben non, parce qu'il n'est pas cité pour ça, il est cité pour ses contributions non-logicielles.
Donc, ça n'est pas du tout hors sujet. Au contraire, ça montre qu'il n'y a pas que le code dans la vie (et en ce moment, je trouve qu'on tente de réduire l'informatique à ça, et c'est n'importe quoi), il y a aussi tout ce qu'il y a autour qui parfois ne nécessite pas de savoir coder mais qui est tout aussi important.
# Trop peu de femmes
Posté par rewind (Mastodon) . En réponse à la dépêche 100 développeurs : la part belle à l’Open Source. Évalué à 8.
On se plaint de ne pas avoir assez de femmes en informatique, mais dès qu'il s'agit de mettre en avant des exemples, on n'arrive à trouver que… deux femmes : Clémence Saussez et Pascale Vicat-Blanc. Et pourtant, ce n'est pas très dur d'en trouver, en particulier dans le libre. Sophie Gautier (LibreOffice), Anne (Mageia) sont les premiers noms qui me viennent en tête immédiatement. Et il y en a beaucoup d'autres. Bref, c'est raté sur ce point et c'est bien dommage.
[^] # Re: oh bah heu... merci :)
Posté par rewind (Mastodon) . En réponse à la dépêche 100 développeurs : la part belle à l’Open Source. Évalué à 9.
En France, on valorise beaucoup trop les emplois non-productifs : gestion, finance, commercial, ressources humaines, etc. Ces emplois, dans une entreprise, ne produisent rien qui puissent être vendu ensuite (ce qui est quand même le cœur d'une entreprise) mais sont payés largement plus que les emplois productifs.
# Les géants de l'informatique
Posté par rewind (Mastodon) . En réponse à la dépêche 100 développeurs : la part belle à l’Open Source. Évalué à 5.
Le «problème», c'est qu'il n'y a pas de géant français. Et finalement, je ne suis pas sûr que ce soit un problème et/ou que ça empêche nos développeurs de réussir en France. Alors c'est sûr qu'un géant, ça fait bien, on peut en parler dans les médias et au ministère du redressement productif, mais en dehors de ça, pas grand chose.