Il semble qu'il y ait une erreur dans la traduction du titre.
Le contenu semble porter sur la correction de l'hypermétropie provoquée par la presbytie.
Le terme coréen désignant la myopie signifie « un état où l’on voit bien uniquement de près », c’est-à-dire la near vision acuity.
« Fix near vision » signifie que l’on a corrigé un problème de vision de près (qui était mauvais),
ce qui me semble correct si l’on dit qu’on a corrigé le problème d’hypermétropie lié à la presbytie, ou plutôt corrigé la vision de près.
Si l’on passe de C à Rust, je dirais en réalité que la raison est la productivité. Le support de la sûreté mémoire est appréciable, mais rien qu’en considérant cargo, je pense que c’est déjà une raison suffisante pour franchir le pas.
Quand on crée un module d’extension Python, la gestion du GIL est toujours délicate, quel que soit le langage. C’est pareil en C/C++ ; bien sûr, il y a des exceptions quand on utilise des bibliothèques ou des outils qui aident à écrire des modules d’extension, et Rust dispose lui aussi d’un excellent crate appelé PyO3.
Par ailleurs, du point de vue d’un développeur C, il est naturel que Zig soit facile à manier. Fondamentalement, Zig est aussi un compilateur C, au point qu’on peut simplement importer et utiliser directement des fichiers d’en-tête.
Je ne trouve toujours pas de raison suffisante pour passer de C à Rust pour du code haute performance. Quelque chose comme Zig, avec une syntaxe au moins un peu plus simple, me semble mieux adapté au développement de bout en bout, et pour le reste, de toute façon, l’architecture consiste à profiler puis à n’implémenter que les parties appelées depuis un langage de haut niveau (en tant qu’utilisateur de Python). Avec Rust, les coûts de développement liés à l’interaction avec d’autres langages, comme le contrôle du GIL, sont étonnamment assez élevés. C, à la base, est justement ce que les autres langages attendent.
J'ai beaucoup galéré personnellement avec ça, alors j'ai écrit un article de blog après avoir vu que la PR avait été fusionnée. La section show est censée être un espace pour présenter directement les produits que j'ai développés, donc ce n'est probablement pas le format adapté ; je l'ai donc publiée comme actualité générale, mais je ne sais pas si c'est bien ça.
On dirait que c’est un article écrit par la personne qui a créé la crate rayon de Rust.
Python et TypeScript semblent bien être encore aujourd’hui des langages centraux, mais...
Rust n’occupe pas encore vraiment cette place. Je me dis que c’est peut-être à cause de sa réputation de difficulté.
J’espère que les LLM feront baisser la barrière à l’entrée et permettront aussi à Rust d’émerger comme un langage central.
On sent clairement que la facilité d’usage a fait un bond spectaculaire, mais les réactions disant qu’on se serait rapproché de l’AGI comme certains le claironnaient étaient, là encore, exagérées.
Le bot recommande des restaurants proches des utilisateurs, donc les menus recommandés ne sont pas très bons :(
Je prévois donc d’ajouter une fonction de « j’aime » pour les menus recommandés !
Je vais prioriser l’affichage des restaurants likés par les utilisateurs de la même région.
Si on ne regarde que la partie codage (SWE-bench), on est à 74,9 % (thinking) et 52,8 % (without thinking), tandis que Claude était à 74,5 % (Opus 4.1), 72,5 % (Opus 4.0) et 62,3 % (Sonnet 3.7).
Sans le mode thinking, c’est moins bon que Sonnet, et même avec, c’est seulement très légèrement meilleur qu’Opus 4.1.
En analysant les commentaires ci-dessous, les réactions autour de Windows XP peuvent être regroupées en six groupes principaux.
① Nostalgie de la qualité d’UI/UX
Rappel des détails fins de l’UX de XP, comme les menus, les gestes de la souris, la barre de progression et le menu Démarrer.
Éloges de la cohérence obtenue à l’époque grâce à la recherche UI et au partage de composants au niveau du système d’exploitation.
Regret que, désormais, chaque éditeur crée sa propre UI, avec une qualité UX parfois en baisse.
Mention selon laquelle même des détails comme la barre de progression ou les menus contextuels de la souris permettent de distinguer un vrai de un faux XP.
② Nostalgie émotionnelle
Souvenirs de l’époque universitaire, de l’installation en version piratée et de la saisie du code CD en le mémorisant.
Rappels nostalgiques du son de démarrage, des fonds d’écran ainsi que des jeux par défaut (Pinball, Solitaire, etc.).
Éloges affectifs du type « une sensation de retour à la maison » ou « c’était le sommet du design à l’époque ».
Les musiques d’installation XP, les thèmes et les outils de personnalisation sont également mentionnés comme éléments nostalgiques.
③ Avantages fonctionnels et de performance
Support matériel élargi par rapport à Win2K, ClearType, Bureau à distance, amélioration de la vitesse de démarrage.
Fonctions orientées développeurs pour atténuer le « DLL Hell » (COM sans enregistrement, assemblies side-by-side).
Support multi-utilisateurs, compatibilité des jeux, amélioration des thèmes et de l’UI.
Besoin d’un environnement de bureau simple et non intrusif.
④ Critiques et avis négatifs
Vision selon laquelle l’UI ressemblait à un « jouet pour enfants », avec une préférence pour le mode classique de Win2K.
Critique de l’absence de fonction de recherche et de la complexité de la structure du menu Démarrer.
Remarques sur l’imprécision des implémentations clone actuelles en termes de détails UI, de polices et de fonctionnalités.
⑤ Comparaison avec l’environnement actuel et alternatives proposées
Mécontentement face à Windows moderne (notamment Win10/11) avec ses publicités, son suivi, et l’obligation d’utiliser un compte en ligne.
Comparaisons avec des expériences de migration vers Linux (KDE, XFCE, Mate, etc.).
Opinion selon laquelle, face à la stabilité et à la simplicité de l’époque XP/7, l’environnement actuel comporte trop d’éléments inutiles.
⑥ Reproduction, émulation et parodie
Évaluation du niveau de finition des clones d’UI XP basés sur JS/CSS.
Explication des différences avec de vraies émulations (VirtualXP, v86, 86Box).
Partage de liens de restauration de jeux comme Minesweeper ou Pinball.
Idées de blagues et de canulars (fausse page de mise à jour, lancement en plein écran au bureau, etc.).
Je pense qu’il serait préférable de traduire psychological safety par sentiment de sécurité psychologique. L’article suivant (https://www.lecturernews.com/news/articleView.html?idxno=166821) explique bien pourquoi, donc je me permets de le partager en guise de référence. Merci toujours pour vos traductions, que je lis avec beaucoup de plaisir. :)
C’est rigolo. Ce serait bien de permettre d’entrer plusieurs noms sur une seule ligne en les séparant par des virgules,
Je trouve que les menus recommandés sont souvent des plats difficiles à manger au travail.
Il semble qu'il y ait une erreur dans la traduction du titre.
Le contenu semble porter sur la correction de l'hypermétropie provoquée par la presbytie.
Le terme coréen désignant la myopie signifie « un état où l’on voit bien uniquement de près », c’est-à-dire la near vision acuity.
« Fix near vision » signifie que l’on a corrigé un problème de vision de près (qui était mauvais),
ce qui me semble correct si l’on dit qu’on a corrigé le problème d’hypermétropie lié à la presbytie, ou plutôt corrigé la vision de près.
Si l’on passe de C à Rust, je dirais en réalité que la raison est la productivité. Le support de la sûreté mémoire est appréciable, mais rien qu’en considérant
cargo, je pense que c’est déjà une raison suffisante pour franchir le pas.Quand on crée un module d’extension Python, la gestion du GIL est toujours délicate, quel que soit le langage. C’est pareil en C/C++ ; bien sûr, il y a des exceptions quand on utilise des bibliothèques ou des outils qui aident à écrire des modules d’extension, et Rust dispose lui aussi d’un excellent crate appelé PyO3.
Par ailleurs, du point de vue d’un développeur C, il est naturel que Zig soit facile à manier. Fondamentalement, Zig est aussi un compilateur C, au point qu’on peut simplement importer et utiliser directement des fichiers d’en-tête.
Je ne trouve toujours pas de raison suffisante pour passer de C à Rust pour du code haute performance. Quelque chose comme Zig, avec une syntaxe au moins un peu plus simple, me semble mieux adapté au développement de bout en bout, et pour le reste, de toute façon, l’architecture consiste à profiler puis à n’implémenter que les parties appelées depuis un langage de haut niveau (en tant qu’utilisateur de Python). Avec Rust, les coûts de développement liés à l’interaction avec d’autres langages, comme le contrôle du GIL, sont étonnamment assez élevés. C, à la base, est justement ce que les autres langages attendent.
J'ai beaucoup galéré personnellement avec ça, alors j'ai écrit un article de blog après avoir vu que la PR avait été fusionnée. La section show est censée être un espace pour présenter directement les produits que j'ai développés, donc ce n'est probablement pas le format adapté ; je l'ai donc publiée comme actualité générale, mais je ne sais pas si c'est bien ça.
On dirait que c’est un article écrit par la personne qui a créé la crate rayon de Rust.
Python et TypeScript semblent bien être encore aujourd’hui des langages centraux, mais...
Rust n’occupe pas encore vraiment cette place. Je me dis que c’est peut-être à cause de sa réputation de difficulté.
J’espère que les LLM feront baisser la barrière à l’entrée et permettront aussi à Rust d’émerger comme un langage central.
PHP déchire.
Mais chez nous, c’est Java, non ?
Oh, je ne connaissais pas ça.
On dirait que Go a été écarté à cause du GC.
On sent clairement que la facilité d’usage a fait un bond spectaculaire, mais les réactions disant qu’on se serait rapproché de l’AGI comme certains le claironnaient étaient, là encore, exagérées.
Le bot recommande des restaurants proches des utilisateurs, donc les menus recommandés ne sont pas très bons :(
Je prévois donc d’ajouter une fonction de « j’aime » pour les menus recommandés !
Je vais prioriser l’affichage des restaurants likés par les utilisateurs de la même région.
Si on ne regarde que la partie codage (SWE-bench), on est à 74,9 % (thinking) et 52,8 % (without thinking), tandis que Claude était à 74,5 % (Opus 4.1), 72,5 % (Opus 4.0) et 62,3 % (Sonnet 3.7).
Sans le mode thinking, c’est moins bon que Sonnet, et même avec, c’est seulement très légèrement meilleur qu’Opus 4.1.
Les trois grands, carrément incroyable
En analysant les commentaires ci-dessous, les réactions autour de Windows XP peuvent être regroupées en six groupes principaux.
① Nostalgie de la qualité d’UI/UX
② Nostalgie émotionnelle
③ Avantages fonctionnels et de performance
④ Critiques et avis négatifs
⑤ Comparaison avec l’environnement actuel et alternatives proposées
⑥ Reproduction, émulation et parodie
Sortie d’Automerge 2.0
J’avais tort. Les CRDT sont l’avenir.
Optimiser pour des CRDT plus rapides
Il faut désormais développer conformément aux standards du Web. Et éviter d’utiliser activement des fonctionnalités qui n’existent pas.
Je pense qu’il serait préférable de traduire psychological safety par sentiment de sécurité psychologique. L’article suivant (https://www.lecturernews.com/news/articleView.html?idxno=166821) explique bien pourquoi, donc je me permets de le partager en guise de référence. Merci toujours pour vos traductions, que je lis avec beaucoup de plaisir. :)
C’est rigolo. Ce serait bien de permettre d’entrer plusieurs noms sur une seule ligne en les séparant par des virgules,
Je trouve que les menus recommandés sont souvent des plats difficiles à manger au travail.
Vidéo officielle de présentation d’OpenAI (1 h 17) https://www.youtube.com/watch?v=0Uu_VJeVVfo
La percée des navigateurs IA est attendue