Monsieur Jourdain ne connaît rien à la prose. Si tu manipule une variable tu as créé un objet. Vous faites, je présume du code qui ne crée pas de classe, qui fait peut usage de fonctions membres, mais ça n'empêche pas le langage d'implémenter tout ce que tu fais à travers un paradigme objet.
Python à l'amabilité syntaxique de ne pas avoir trop de boilerplate contrairement à java par exemple, mais ça n'en change pas le paradigme pour autant.
Python est un langage objet dont la syntaxe ne contraint pas à créer de classe et possède des lambdas.
La plupart des langages permettent d'avoir le style que tu veux par dessus, ce sera potentiellement moins agréable mais c'est tout (par exemple une partie du code de linux, écrit en C, utilise un pattern objet).
Par contre je ne suis pas d'accord avec ta critique. Ça me fait penser à une conversation qu'il y avait eu au sujet de php où un non utilisateurs du langage expliquait qu'il fallait que php reste dans son coin plutôt que d'essayer d'évoluer parce que lui il préférait.
Ce n'est pas bien expliqué mais je compare à Python pour la propreté de la syntaxe et pour la grammaire vraiment objet et pas batarde.
Ça vient de l'approche de l'existant. Python a cassé la compatibilité de son langage régulièrement là où perl prône la compatibilité avant tout. Mais je suis d'accord que je ne suis pas fan de l'implémentation objet de perl, même si j'ai vu des gens trouver ça super bien.
Après, le côté purement objet de Python est sans doute à relativiser.
C'est l'inverse, c'est le multiparadigme qui est à relativiser. Python est un langage objet, qui comme c'est la mode, a des lambdas. Avoir des lambdas n'en fait pas un langage objet tout comme les struct du C ne font pas du C un langage objet. Cela permet de s'approcher d'un style de programmation fonctionnel, mais c'est (très) loin du moindre langage fonctionnel.
En pratique tu ne peux pas écrire de programme python sans le paradigme objet car tout est objet en python la moindre variable, le moindre entier que tu utilise est un objet.
Pour ce qui est de l'impératif c'est particulier car tous les langages objets que j'ai pu voir ont des gros morceaux d'impératif (en fait seul les langages fonctionnels, et les langages logiques que je connais n'ont pas d'impératif).
Après cela ne t'empêche pas d'utiliser un style fonctionnel/impératif/déclaratif/objet/… en python comme dans d'autres langages.
Si tu regardes Linux (qui a beaucoup plus de moyens soit dit en passant), lorsqu'ils parlent d'abandonner des architectures, il y'en a toujours pour se plaindre. Mais la résolution est toujours la même : si personne n'est assez intéressé par l'archi pour s'occuper de la maintenance, dommage pour vous.
Non les gens ne se plaignent pas pour plusieurs raisons :
ils abandonnent des archi vraiment très peu utilisées
ils mûrissent leur abandons et c'est un choix et non un effet de bord d'une volonté autre
C'est très différents parce qu'ils peuvent te dire très précisément et posément pourquoi ils arrêtent. Ce n'est pas : "on a ajouté le support d'usb3 (du coup on abandonne ppc lol)". C'est tout le différence entre uun projet qui considère le support d'architecture comme un sujet à part entière ou comme un boulet qui le contraint.
Je ne suis pas ce que devrait faire les dev en question, mais c'est juste que le point sur le noyau c'est pas vraiment la même façon de faire. Et c'est logique qu'ils prennent le sujet avec autant de sérieux. Pour les bibliothèques python c'est juste une mise en lumière de ce qu'est et ce que n'est pas la portabilité de python.
Est-ce que ça fait vraiment partie de la définition du langage ?
Le modèle mémoire fait parti de la définition d'un langage. Le fait que certains langages aient un gc optionnel fait partie de ses fondements (alors que les langages où il existe une bibliothèque pour faire du gc est un peu différent - au même titre que tu peux implémenter un langage dans un autre -).
Ce qui est génial en plus c'est que les outils de mesures de pertinence des pub c'est Google qui les fait. Il maitrise ses concurrents par le navigateur, par les outils de pertinences et par le pagerank et si vraiment c'était nécessaire android et les services google lui assure à la fois une entrée d'information et un positionnement pour placer ses pubs.
C'est tellement lucratif qu'ils ne savent plus faire de l'argent autrement (tout projet est comparé à ce système est rien ne peut produire autant d'argent en début de vie).
du code public et une explication du pourquoi, ce que ça tu as appris et comment tu t'y prendrais si tu devais le refaire ;
Je ne suis pas forcément d'accord. Autant moi j'aime coder sur mon temps libre autant je ne me vois pas imposer ça à quelqu'un d'autres. La situation personnelle, la difficulté d'organisation ou même le goût peuvent facilement empêcher ça sans pour autant que ça me paraisse gênant dans le cadre de l'entreprise.
éventuellement des liens vers des articles plus ou moins techniques que tu as écris
Pareil.
Je pense même qu'il est important de ne pas avoir que des névrosés du code (comme je peux l'être) dans une équipe. Ça contribue, entre autre, à la multiplicité des points de vu et des compétences et puis ça aide à l'équilibre au sein d'une équipe.
Promis juré il n'y a pas assez d'entropie pour qu'on vous retrouve. On ne combinera jamais ça avec d'autres données voyons.
ce n'est pas nouveau
Non ce qui est nouveau c'est qu'ils annoncent la mort de cookies. Ce qui les places dans une position encore plus problématique :
ils font parti des quelques rares qui ont assez d'info pour que le recoupement soit aussi efficace qu'un cookie
ils imposent à leurs concurrents publicitaires de se placer sur un terrain où google domine (avec facebook et quelques autres probablement)
Mais non il n'y a pas d'abus de position dominante. Ce n'est pas du tout le sujet de cette plainte. Mais je ne vois pas Google annoncer tranquillement que dans 2 ans ils auront viré leur principale source d'argent s'ils n'avaient pas déjà un remplacement. Je n'ai pas lu le dossier, mais ça ne m'étonnerais pas qu'il y ai aujourd'hui des preuves que ce soit détourné.
je doute que ça ait été inventé par Google
Non c'est juste que c'est l'un des seuls qui peut remplacer des cookies par ce genre de technique et avoir le même niveau de précision.
Ce que je veux faire nécessiterait sûrement un script dédié à chaque commande pour remettre les arguments à la bonne place donc.
Tu le ferrais probablement. Le passage sur la machine distante ne sera pas gratuit et faire des expérimentations autour de ffmpeg seront plutôt relou. Au final tu convergera probablement vers quelques cas d'utilisation (éventuellement paramétré) et passer par un script pour chacun est une manière de simplifier.
Sinon comme tu n'aura de toute manière pas d'autocomplétion, tu peux faire un script générique qui prend la commande ffmpeg et remplace les input/ouput.
Ce qui est indécidable c'est de savoir si le cas où le dénominateur est égal à zéro peut se produire ou pas. C'est à cet énoncé que le théorème de Rice s'applique.
Là tu cherche à prouver automatiquement qu'un code ne fera jamais de division par 0 ce qui n'est pas le sujet. Le sujet c'est de gérer le cas d'une division par 0. C'est aussi un sophisme le jusqueboutisme pour invalider ;)
Et oui j'ai bien dis dès mon premier commentaire que ça a un coût.
Ce qu'on trouve au mieux en pratique, c'est des outils qui font des analyses statiques pour vérifier qu'un code respecte des pratiques particulières (c'est-à-dire utilise un sous-ensemble du langage et pas le langage en général), et lorsque c'est le cas, elles peuvent nous assurent l'absence de division par zéro. C'est le genre d'approche qu'on retrouve dans certains codes critiques.
Ou par preuve automatique ou pas écriture par automate (tu écris dans un méta langage qui va produire un code ayant forcément certaines propriétées).
C'est pas vraiment une migration puisque les deux ont toujours existé et ne font pas vraiment la même chose.
Je parle du fait que la commande scp ne va plus utiliser le protocole scp, mais sftp (parce que les gens sont habitué à la commande scp et que la commande sftp est affreuse - perso ça fait quelques temps que je proscrit scp au profit de rsync -).
Mais il y a bien une déprécation pour des raisons techniques qui se résume en gros à : scp n'a aucun lien avec ssh (si ce n'est d'utiliser son tuyau, alors que sftp par contre utilise les mêmes bibliothèques) et cette implémentation bâtarde pose des soucis de sécurité et plus personne n'a la force de maintenir ça avec ce risque.
Ça explique surtout pourquoi ils ne veulent pas le corriger. Le problème est bien décrit dans l'article tu peux exécuter une commande au travers de scp ce qui n'est pas possible avec sftp.
En fait tu es sensé avoir une nouvelle session. Dans une navigation privée, tu n'es plus connecté aux sites, il n'ont plus accès à ce qui pourrait constituer un historique. Ça te rend bien moins identifiable.
De ce que je comprends, le nouveau truc de Google c'est de ne plus utiliser les cookies et ce nouveau truc reste lui accessible. C'est assez tangent, ils créent une session fraiche de tous cookies, mais crée une autre techno qui fait la même chose et se protègent en disant qu'il n'y a jamais eu de garantie dans le mode incognito dans le sens où ça n'utilise pas des contremesures actives (tu es toujours traçable par la taille de ton écran et tout un tas de méta données).
Et comme on en parlait c'est tout à fait possible c'est juste que tu dois exprimer dans ton code cette sémantique. Tu disqualifie un peu vite les choses comme indécidables. Il est tout à fait possible d'écrire un programme qui vérifie qu'aucun dénominateur est égale à 0. Si vraiment tu as besoin de t'en convaincre c'est le même problème que vérifier la nullité des références ou pointeurs.
Pourquoi la division par zéro serait plus un bug que la division par 42 ?
Parce qu'elle n'a pas de sens mathématiques. De la même manière que tu n'adresse pas un tableau avec des nombres imaginaires. Le Not A Number n'est qu'une représentation d'une erreur. Tu peux faire des choses avec comme avec une erreur ça n'en est pas moins une erreur.
Pour le titre, s'il ne voulait pas comparer les langages entre-eux à la base, il aurait du choisir un truc du genre : "Performance comparison in counting words, study cases in various languages.", sinon c'est ce qu'on appelle un titre putaclick.
Qu'il soit possible de trouver un titre qui préserve mieux ta sensibilité n'indique pas que ce titre est putaclick.
Quand à la conclusion, la moitié est consacrée au tableau de comparaison entre langages, et ensuite viennent quelques pensées qu'il en tire, avec en premier : "I think it’s the simple, idiomatic versions that are the most telling. This is the code programmers are likely to write in real life.", alors que j'ai prouvé ci-dessus que ce n'est pas le cas, les developpeurs ne ponderont pas tous le même code dans la vie réelle, il existera des versions différentes avec des performances elles aussi bien différentes.
Je ne suis pas d'accord. Oui il y a des façons différentes pour autant peu vont réellement diverger (sur un sujet aussi simple) et la version idiomatique va logiquement être la solution la plus fréquemment utilisée. Le fait que tu ai montré qu'il y a d'autres façons de faire n'invalide pas cela.
Plus de la moitié du billet montre comment on mesure la performance dans chacun des langages et comment les choix fait impactes ses métriques, il n'y a aucun endroit où il parle de la performance comparer des langages. Ce n'est pas un point de vu.
Ce que tu dis revient juste à étendre la sémantique de la division pour donner un comportement différent à la division par zéro. Au lieu d'un crash, on aurait une valeur particulière, c'est-à-dire grosso-modo la solution numéro 2, sauf qu'en version explicite (écriture explicite de la condition) et potentiellement plus flexible (genre retourner autre chose que zéro si le dénominateur est nul, mais je vois pas trop à quoi ça servirait).
Pas forcément, là c'était des exemples, mais ça peut être pour afficher des messages d'erreur par exemple. Il n'est pas question la division devienne une fonction totale, mais que tes fonctions qui utilisent la division soient totales. Ça peut d'ailleurs s'implémenter aussi si on considère que la division ne renvoie pas un nombre, mais un type double|NaN qu'il faudra traiter.
Enlever ces vérifications est un problème indécidable en général et je ne pense pas qu'il y ait d'heuristique efficace pour cela dans un compilateur actuel.
Je pense qu'il fera très bien ce que tu lui demande c'est à dire produire un code proche de l'optimal avec les sécurité que tu lui demande. C'est juste que ça peut demander de ne pas laisser le CPU faire un calcul de bout en bout sans vérification intermédiaire.
Je veux bien entendre tes arguments, mais quand le titre est "Performance comparison: counting words in Python, Go, C++, C, AWK, Forth, and Rust", le but du jeu est clairement de comparer les perfomances entre ces langages, ce n'est pas "tiens, vu qu'on a déjà fait le truc dans plusieurs langages, on pourrait aussi les comparer tant qu'on y est".
L'optimisation, le profilage, c'est visiblement plus un bonus que le but du jeu.
Ce n'est pas du tout comme ça que je lis le titre ni le billet. Il ne parle pas de comparer la performance entre les langages mais dans chaque langage. Et s'il produit une liste multi langage il montre pour chacun le gain entre idiomatique et optimisé.
Il suffit de regarder la conclusion pour s'en convaincre. Il parle même de quel langage est le plus performant, mais du fait que C++ donne des messages d'erreur affreux, qu'en C ça vaut le coût d'utiliser une bibliothèque pour ça et que python et awk sont les plus rapide (pour la partie écriture du code et pas pour la partie exécution).
La première solution est impossible dans un langage généraliste, car dans ces langages, c'est un problème indécidable.
Si c'est possible, c'est juste que le compilateur t'interdit une division s'il ne peut pas s'assurer que le dénominateur n'est pas 0.
Donc
a = b / c
ne compile pas dans le cas général, il faut écrire des trucs du genre :
a = c != 0 ? b / c : 0
Et oui ça peux devenir relou dans tu as un truc du genre :
Ça t'oblige à déstructurer ton calcul et si le langage et le compilateur sont pas au poil tu peut perdre en performance (il faut qu'il puisse virer les vérification à la compilation pour reconstruire l'opération).
Sachant que de base tout ce qui va cacher pour toi (en attrapant l'interruption ou en faisant la vérification pour toi) va consommer de la ressource.
Posté par barmic 🦦 .
En réponse au journal Zébulon.
Évalué à 6.
Bravo pour le jeu :)
Autre amélioration : depuis une échelle, si on est pas exactement au bon niveau on a pas le droit de descendre. Souvent les jeux acceptent ce genre d'imperfection (c'est ce que l'on appelle les coreloops).
Super pratique quand tu as besoin d'avoir un comportement spécifique par type plutôt que de mettre des if moches.
Je suis pas sûr que ce soit bien sans sealed class ce qui est entrain d'arriver dans java.
Mais je suis d'accord que le type erasure pose problème par exemple si on veut construire un objet de la classe du type effectif de ta méthode. C'est pour ça que l'on passe la classe à ce genre de méthode :
Aa=build(A.class);
Par contre, c'est pas mal mitigé avec l'utilisation de lambda (pas dans tous les cas, mais dans une partie).
Mais oui C# qui a implémenté les génériques un an après java est mieux sur ce point là. Je pense que c'est dû au fait qu'ils ont implémenté la généricité dans la vm là où sun se l'ai interdit (probablement pour ne pas casser l'écosystème des jvms qui était foisonnant à l'époque).
Tu es trop troll est cryptique pour être compris par la populasse. Tu reproche à go d'avoir des Panic et tu voudrait que ce soit comme les Exceptions de java hors ça n'a rien à voir. Les Panic correspondent plus aux Errors de java. Je me doute qu'avec ta comprehenssion des langages il n'y a pas besoin de t'expliquer plus pourquoi tu ne catch pas d'Error en java.
[^] # Re: Perl a perdu son charme
Posté par barmic 🦦 . En réponse au lien Le comité de pilotage de Perl pourra-t-il sauver Perl du naufrage ?. Évalué à 4.
Monsieur Jourdain ne connaît rien à la prose. Si tu manipule une variable tu as créé un objet. Vous faites, je présume du code qui ne crée pas de classe, qui fait peut usage de fonctions membres, mais ça n'empêche pas le langage d'implémenter tout ce que tu fais à travers un paradigme objet.
Python à l'amabilité syntaxique de ne pas avoir trop de boilerplate contrairement à java par exemple, mais ça n'en change pas le paradigme pour autant.
Python est un langage objet dont la syntaxe ne contraint pas à créer de classe et possède des lambdas.
La plupart des langages permettent d'avoir le style que tu veux par dessus, ce sera potentiellement moins agréable mais c'est tout (par exemple une partie du code de linux, écrit en C, utilise un pattern objet).
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Perl a perdu son charme
Posté par barmic 🦦 . En réponse au lien Le comité de pilotage de Perl pourra-t-il sauver Perl du naufrage ?. Évalué à 3.
Par contre je ne suis pas d'accord avec ta critique. Ça me fait penser à une conversation qu'il y avait eu au sujet de php où un non utilisateurs du langage expliquait qu'il fallait que php reste dans son coin plutôt que d'essayer d'évoluer parce que lui il préférait.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Perl a perdu son charme
Posté par barmic 🦦 . En réponse au lien Le comité de pilotage de Perl pourra-t-il sauver Perl du naufrage ?. Évalué à 3.
Ça vient de l'approche de l'existant. Python a cassé la compatibilité de son langage régulièrement là où perl prône la compatibilité avant tout. Mais je suis d'accord que je ne suis pas fan de l'implémentation objet de perl, même si j'ai vu des gens trouver ça super bien.
A quelque détail près si.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Perl a perdu son charme
Posté par barmic 🦦 . En réponse au lien Le comité de pilotage de Perl pourra-t-il sauver Perl du naufrage ?. Évalué à 4.
C'est l'inverse, c'est le multiparadigme qui est à relativiser. Python est un langage objet, qui comme c'est la mode, a des lambdas. Avoir des lambdas n'en fait pas un langage objet tout comme les struct du C ne font pas du C un langage objet. Cela permet de s'approcher d'un style de programmation fonctionnel, mais c'est (très) loin du moindre langage fonctionnel.
En pratique tu ne peux pas écrire de programme python sans le paradigme objet car tout est objet en python la moindre variable, le moindre entier que tu utilise est un objet.
Pour ce qui est de l'impératif c'est particulier car tous les langages objets que j'ai pu voir ont des gros morceaux d'impératif (en fait seul les langages fonctionnels, et les langages logiques que je connais n'ont pas d'impératif).
Après cela ne t'empêche pas d'utiliser un style fonctionnel/impératif/déclaratif/objet/… en python comme dans d'autres langages.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Perl a perdu son charme
Posté par barmic 🦦 . En réponse au lien Le comité de pilotage de Perl pourra-t-il sauver Perl du naufrage ?. Évalué à 3.
Tu reproche à Perl d'être trop objet en le comparant à python purement objet ?
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Drew ? J'ai un peu du mal avec ce type
Posté par barmic 🦦 . En réponse au journal Appel à contribution pour un nouveau langage !. Évalué à 5.
Non les gens ne se plaignent pas pour plusieurs raisons :
C'est très différents parce qu'ils peuvent te dire très précisément et posément pourquoi ils arrêtent. Ce n'est pas : "on a ajouté le support d'usb3 (du coup on abandonne ppc lol)". C'est tout le différence entre uun projet qui considère le support d'architecture comme un sujet à part entière ou comme un boulet qui le contraint.
Je ne suis pas ce que devrait faire les dev en question, mais c'est juste que le point sur le noyau c'est pas vraiment la même façon de faire. Et c'est logique qu'ils prennent le sujet avec autant de sérieux. Pour les bibliothèques python c'est juste une mise en lumière de ce qu'est et ce que n'est pas la portabilité de python.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Pourquoi ?
Posté par barmic 🦦 . En réponse au journal Appel à contribution pour un nouveau langage !. Évalué à 7.
Le modèle mémoire fait parti de la définition d'un langage. Le fait que certains langages aient un gc optionnel fait partie de ses fondements (alors que les langages où il existe une bibliothèque pour faire du gc est un peu différent - au même titre que tu peux implémenter un langage dans un autre -).
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Navigation privée ?
Posté par barmic 🦦 . En réponse au journal Pour ceux qui utilisent Google Chrome. Évalué à 6.
Ce qui est génial en plus c'est que les outils de mesures de pertinence des pub c'est Google qui les fait. Il maitrise ses concurrents par le navigateur, par les outils de pertinences et par le pagerank et si vraiment c'était nécessaire android et les services google lui assure à la fois une entrée d'information et un positionnement pour placer ses pubs.
C'est tellement lucratif qu'ils ne savent plus faire de l'argent autrement (tout projet est comparé à ce système est rien ne peut produire autant d'argent en début de vie).
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: À bas les roues en bois
Posté par barmic 🦦 . En réponse au journal Du chemin à emprunter pour les développeurs débutants vers un premier emploi... . Évalué à 7.
Je ne suis pas forcément d'accord. Autant moi j'aime coder sur mon temps libre autant je ne me vois pas imposer ça à quelqu'un d'autres. La situation personnelle, la difficulté d'organisation ou même le goût peuvent facilement empêcher ça sans pour autant que ça me paraisse gênant dans le cadre de l'entreprise.
Pareil.
Je pense même qu'il est important de ne pas avoir que des névrosés du code (comme je peux l'être) dans une équipe. Ça contribue, entre autre, à la multiplicité des points de vu et des compétences et puis ça aide à l'équilibre au sein d'une équipe.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Navigation privée ?
Posté par barmic 🦦 . En réponse au journal Pour ceux qui utilisent Google Chrome. Évalué à 6. Dernière modification le 24 mars 2021 à 11:56.
https://www.google.com/chrome/privacy/whitepaper.html#variations
Promis juré il n'y a pas assez d'entropie pour qu'on vous retrouve. On ne combinera jamais ça avec d'autres données voyons.
Non ce qui est nouveau c'est qu'ils annoncent la mort de cookies. Ce qui les places dans une position encore plus problématique :
Mais non il n'y a pas d'abus de position dominante. Ce n'est pas du tout le sujet de cette plainte. Mais je ne vois pas Google annoncer tranquillement que dans 2 ans ils auront viré leur principale source d'argent s'ils n'avaient pas déjà un remplacement. Je n'ai pas lu le dossier, mais ça ne m'étonnerais pas qu'il y ai aujourd'hui des preuves que ce soit détourné.
Non c'est juste que c'est l'un des seuls qui peut remplacer des cookies par ce genre de technique et avoir le même niveau de précision.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: entrée et sortie standard
Posté par barmic 🦦 . En réponse au journal Lancer un logiciel distant depuis sa machine. Évalué à 3.
Tu le ferrais probablement. Le passage sur la machine distante ne sera pas gratuit et faire des expérimentations autour de ffmpeg seront plutôt relou. Au final tu convergera probablement vers quelques cas d'utilisation (éventuellement paramétré) et passer par un script pour chacun est une manière de simplifier.
Sinon comme tu n'aura de toute manière pas d'autocomplétion, tu peux faire un script générique qui prend la commande ffmpeg et remplace les input/ouput.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Ouaiche
Posté par barmic 🦦 . En réponse au lien "Rust vs. Go: Why They’re Better Together". Évalué à 3.
Là tu cherche à prouver automatiquement qu'un code ne fera jamais de division par 0 ce qui n'est pas le sujet. Le sujet c'est de gérer le cas d'une division par 0. C'est aussi un sophisme le jusqueboutisme pour invalider ;)
Et oui j'ai bien dis dès mon premier commentaire que ça a un coût.
Ou par preuve automatique ou pas écriture par automate (tu écris dans un méta langage qui va produire un code ayant forcément certaines propriétées).
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Pipe ?
Posté par barmic 🦦 . En réponse au journal Lancer un logiciel distant depuis sa machine. Évalué à 3.
Je parle du fait que la commande scp ne va plus utiliser le protocole scp, mais sftp (parce que les gens sont habitué à la commande scp et que la commande sftp est affreuse - perso ça fait quelques temps que je proscrit scp au profit de rsync -).
Ça explique surtout pourquoi ils ne veulent pas le corriger. Le problème est bien décrit dans l'article tu peux exécuter une commande au travers de scp ce qui n'est pas possible avec sftp.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Navigation privée ?
Posté par barmic 🦦 . En réponse au journal Pour ceux qui utilisent Google Chrome. Évalué à 4.
En fait tu es sensé avoir une nouvelle session. Dans une navigation privée, tu n'es plus connecté aux sites, il n'ont plus accès à ce qui pourrait constituer un historique. Ça te rend bien moins identifiable.
De ce que je comprends, le nouveau truc de Google c'est de ne plus utiliser les cookies et ce nouveau truc reste lui accessible. C'est assez tangent, ils créent une session fraiche de tous cookies, mais crée une autre techno qui fait la même chose et se protègent en disant qu'il n'y a jamais eu de garantie dans le mode incognito dans le sens où ça n'utilise pas des contremesures actives (tu es toujours traçable par la taille de ton écran et tout un tas de méta données).
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Ouaiche
Posté par barmic 🦦 . En réponse au lien "Rust vs. Go: Why They’re Better Together". Évalué à 3.
Et comme on en parlait c'est tout à fait possible c'est juste que tu dois exprimer dans ton code cette sémantique. Tu disqualifie un peu vite les choses comme indécidables. Il est tout à fait possible d'écrire un programme qui vérifie qu'aucun dénominateur est égale à 0. Si vraiment tu as besoin de t'en convaincre c'est le même problème que vérifier la nullité des références ou pointeurs.
Du coup le théorème de Rice ne s'applique pas.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Pipe ?
Posté par barmic 🦦 . En réponse au journal Lancer un logiciel distant depuis sa machine. Évalué à 5.
À noter d'ailleurs que scp est en cours de déprécation au profit de sftp (la commande scp elle est entrain de migrer vers sftp).
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Ouaiche
Posté par barmic 🦦 . En réponse au lien "Rust vs. Go: Why They’re Better Together". Évalué à 2.
Parce qu'elle n'a pas de sens mathématiques. De la même manière que tu n'adresse pas un tableau avec des nombres imaginaires. Le Not A Number n'est qu'une représentation d'une erreur. Tu peux faire des choses avec comme avec une erreur ça n'en est pas moins une erreur.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Des choux et des carottes...
Posté par barmic 🦦 . En réponse au lien Performance comparison: counting words in Python, Go, C++, C, AWK, Forth, and Rust. Évalué à 4.
Qu'il soit possible de trouver un titre qui préserve mieux ta sensibilité n'indique pas que ce titre est putaclick.
Je ne suis pas d'accord. Oui il y a des façons différentes pour autant peu vont réellement diverger (sur un sujet aussi simple) et la version idiomatique va logiquement être la solution la plus fréquemment utilisée. Le fait que tu ai montré qu'il y a d'autres façons de faire n'invalide pas cela.
Plus de la moitié du billet montre comment on mesure la performance dans chacun des langages et comment les choix fait impactes ses métriques, il n'y a aucun endroit où il parle de la performance comparer des langages. Ce n'est pas un point de vu.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Ouaiche
Posté par barmic 🦦 . En réponse au lien "Rust vs. Go: Why They’re Better Together". Évalué à 2.
Pas forcément, là c'était des exemples, mais ça peut être pour afficher des messages d'erreur par exemple. Il n'est pas question la division devienne une fonction totale, mais que tes fonctions qui utilisent la division soient totales. Ça peut d'ailleurs s'implémenter aussi si on considère que la division ne renvoie pas un nombre, mais un type double|NaN qu'il faudra traiter.
Je pense qu'il fera très bien ce que tu lui demande c'est à dire produire un code proche de l'optimal avec les sécurité que tu lui demande. C'est juste que ça peut demander de ne pas laisser le CPU faire un calcul de bout en bout sans vérification intermédiaire.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Des choux et des carottes...
Posté par barmic 🦦 . En réponse au lien Performance comparison: counting words in Python, Go, C++, C, AWK, Forth, and Rust. Évalué à 5.
Ce n'est pas du tout comme ça que je lis le titre ni le billet. Il ne parle pas de comparer la performance entre les langages mais dans chaque langage. Et s'il produit une liste multi langage il montre pour chacun le gain entre idiomatique et optimisé.
Il suffit de regarder la conclusion pour s'en convaincre. Il parle même de quel langage est le plus performant, mais du fait que C++ donne des messages d'erreur affreux, qu'en C ça vaut le coût d'utiliser une bibliothèque pour ça et que python et awk sont les plus rapide (pour la partie écriture du code et pas pour la partie exécution).
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Ouaiche
Posté par barmic 🦦 . En réponse au lien "Rust vs. Go: Why They’re Better Together". Évalué à 2. Dernière modification le 22 mars 2021 à 12:22.
Si c'est possible, c'est juste que le compilateur t'interdit une division s'il ne peut pas s'assurer que le dénominateur n'est pas 0.
Donc
ne compile pas dans le cas général, il faut écrire des trucs du genre :
Et oui ça peux devenir relou dans tu as un truc du genre :
Ça t'oblige à déstructurer ton calcul et si le langage et le compilateur sont pas au poil tu peut perdre en performance (il faut qu'il puisse virer les vérification à la compilation pour reconstruire l'opération).
Sachant que de base tout ce qui va cacher pour toi (en attrapant l'interruption ou en faisant la vérification pour toi) va consommer de la ressource.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: c'est deja un beau résultat
Posté par barmic 🦦 . En réponse au journal Zébulon. Évalué à 6.
Bravo pour le jeu :)
Autre amélioration : depuis une échelle, si on est pas exactement au bon niveau on a pas le droit de descendre. Souvent les jeux acceptent ce genre d'imperfection (c'est ce que l'on appelle les coreloops).
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Ouaiche
Posté par barmic 🦦 . En réponse au lien "Rust vs. Go: Why They’re Better Together". Évalué à 3.
Les nouveautés de 2004 ?
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Ouaiche
Posté par barmic 🦦 . En réponse au lien "Rust vs. Go: Why They’re Better Together". Évalué à 4.
Je suis pas sûr que ce soit bien sans sealed class ce qui est entrain d'arriver dans java.
Mais je suis d'accord que le type erasure pose problème par exemple si on veut construire un objet de la classe du type effectif de ta méthode. C'est pour ça que l'on passe la classe à ce genre de méthode :
Par contre, c'est pas mal mitigé avec l'utilisation de lambda (pas dans tous les cas, mais dans une partie).
Mais oui C# qui a implémenté les génériques un an après java est mieux sur ce point là. Je pense que c'est dû au fait qu'ils ont implémenté la généricité dans la vm là où sun se l'ai interdit (probablement pour ne pas casser l'écosystème des jvms qui était foisonnant à l'époque).
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Ouaiche
Posté par barmic 🦦 . En réponse au lien "Rust vs. Go: Why They’re Better Together". Évalué à 2.
Tu es trop troll est cryptique pour être compris par la populasse. Tu reproche à go d'avoir des Panic et tu voudrait que ce soit comme les Exceptions de java hors ça n'a rien à voir. Les Panic correspondent plus aux Errors de java. Je me doute qu'avec ta comprehenssion des langages il n'y a pas besoin de t'expliquer plus pourquoi tu ne catch pas d'Error en java.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll