Gil Cot ✔ a écrit 6264 commentaires

Justement, window() et non x11() héhé

“It is seldom that liberty of any kind is lost all at once.” ― David Hume

Alors pourquoi créer un langage supplémentaire et ne pas améliorer, si cela s’avère nécessaire, un langage existant ?

Pour moi, les vraies raisons sont essentiellement académiques : on veut par exemple explorer une autre approche ou mettre en œuvre de nouvelles théories (cf. programmation orientée objet, programmation fonctionnelle, etc ; naissance du Pascal ou du basic ; etc.)
Le reste du temps, les reproches techniques peuvent se résoudre en améliorant les langages existants. Ça peut aboutir à un nouveau langage issu de l'autre (c'est le cas de C++ et ObjectiveC qui ajoutent l'objet au C traditionnel et tentent d'en corriger quelques autres aspects) ou de nouveaux compilateurs (cf. Clang pour le C) avec de nouveaux outils (cf. LLVM par exemple)

Le reste du temps, comme ici, je pense que c'est le syndrome NIH (donc de gens qui ont la grosse tête et un trop gros égo et rêvent d'avoir leur nom associé à un langage comme génial/géniale inventeur/inventeuse…) Il est possible que ce soit aussi simplement par ignorance (on tente de alors de refaire quelque chose qui a été déjà fait ailleurs)
Dans le cas présent, d'autres commentaires ont justement mentionné Zig et Go par exemple qui répondent déjà au cahier des charges…

“It is seldom that liberty of any kind is lost all at once.” ― David Hume

Loin de unveil, mais on est dans l'idée avec AppArmor ou SELinux non ? Mais c'est vrai que ce n'est pas super simple pour l'utilisateur qui sort un peu du cadre prévu par la distro.

“It is seldom that liberty of any kind is lost all at once.” ― David Hume

Qui est petit (lexique et spécification) ;
Qui convient presque partout où le C l'est ;
Qui est compatible avec l'ABI de C ;
Qui compile sur les architectures x86_64, aarch64, i686, riscv64, riscv32, ppc64 ;
Qui supporte Linux, BSDs, Haiku, Plan 9, MacOS X, Windows ;
Qui a quelques ingrédients modernes (Unicode, coroutines) ;
Bref, j'ai presque l'impression d'entendre parler de Go

“It is seldom that liberty of any kind is lost all at once.” ― David Hume

…Et quelle est sa spécialité mis à part surfer sur la vague ?

“It is seldom that liberty of any kind is lost all at once.” ― David Hume

Excellent ; je me note de tester ça.
Les captures d'écran sont proches de ce que fait glow, mais les titres sont gérées de façon plus originales et marrante.

“It is seldom that liberty of any kind is lost all at once.” ― David Hume

Exactement la question que je me suis posé car ayant évoqué le sujet récemment ailleurs : fawk, xsv, csvkit, csvtool, tsv-utils, etc.

“It is seldom that liberty of any kind is lost all at once.” ― David Hume

Ah… comme on en parle, jben nous fait un journal sur sa cuillère

“It is seldom that liberty of any kind is lost all at once.” ― David Hume

Le commentaire auquel tu réponds me semble troisième degré… Mais le nombre de moinsage illustre bien le ras-le-bol dont tu parles.

“It is seldom that liberty of any kind is lost all at once.” ― David Hume

Genre tu mets les pages en attente et vas lire le JS avant les autoriser à s'exécuter ?

/me dubitatif sort

“It is seldom that liberty of any kind is lost all at once.” ― David Hume

Ah oui, j'avais pas tout suivi en effet. Au départ il était vraiment question de purement et simplement abandonner la commande scp (sauf si j'ai mal compris) ; ce qui a fait pas mal râler sur la toile (des gens qui ont du mal comprendre aussi).
Mais effectivement si la commande est préservée mais le protocole sous-jacent (scp) est remplacé par l'autre (sftp) ; alors t'as entièrement raison de parler de migration et c'est vraiment pas plus mal (on n'aura pas la compatibilité totale mais c'est beaucoup moins de casse et de changement d'outillage.) Tout à fait d'accord que c'est quasiment impossible de sanitizer le fonctionnement car on ne sait pas aisément distinguer une commande dangereuse d'un nom/chemin tordu mais légitime.

“It is seldom that liberty of any kind is lost all at once.” ― David Hume

Mille mercis, je vais examiner ça tranquillement.

“It is seldom that liberty of any kind is lost all at once.” ― David Hume

C'est pas vraiment une migration puisque les deux ont toujours existé et ne font pas vraiment la même chose. 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.

“It is seldom that liberty of any kind is lost all at once.” ― David Hume

GNUCash ou Dolibar ne seraient pas de bonnes alternative ?

“It is seldom that liberty of any kind is lost all at once.” ― David Hume

bref, le fameux grand livre comptable quoi. mais difficile de trouver le formalisme exactement attendu dans ce retour en arrière.

“It is seldom that liberty of any kind is lost all at once.” ― David Hume

Je ne m'explique pas pourquoi scp (même compressé) est à ce point si lent par rapport à la concurrence (bien pire que dans ma mémoire) alors que c'est justement son job de faire transiter des données potentiellement volumiques.

Je n'ai pas vraiment ressenti cette lenteur, mais SCp et SSh ne fonctionnent absolument pas de la même façon… Je ne me rappelle pas bien les détails d'implémentation, mais quand tu fais un tube avec SSh, tu ouvres un pseudo-terminal dont tu connectes l'entrée standard (donc tu envois ton flux exactement comme tu le balancerais si tu le tapais au clavier…) Par contre quand tu fais un SCp, en dessous tu établies un liaison client-serveur (si, si, et toutes les bécanes ayant un serveur ssh ne permettent pas d'accepter du scp —comme c'est paquetagé dans OpenSSH utilisé par défaut dans beaucoup d'Unix, des BSD à Linux en passant par AIX— bah on s'en rend pas compte) comparable à curl/lftp -c/ftpget/ftpput (c'est encore différent du sous-système sftp qui ressemble plus à du ftp classique et utilise un tout autre protocole) Ça fait un certain nombre d'opérations (vérifier et se positionner dans le répertoire cible, vraiment recréer les arborescence quand utilisé en mode récursif, afficher la progression, etc.)

tar -czf - linux-5.12-rc4/ | ssh remote 'tar -xzf -'

cet exemple est en fait comparable à ceci :

# il faut helas preparer le fichier avant car scp ne lit pas stdin
tar -czf foo.tgz linux-5.12-rc4/ 
# puis l'envoyer separement 
scp foo.tgz remote:./ ; rm foo.tgz
# et en face l'extraire car il n'exploite pas stdout
tar -xzf foo.tgz ; rm foo.tgz

et là on voit que la plus grande rapidité apparente, en supposant qu'on ait eu les même protocoles et que les deux outils ne se partagent pas que le mode de transport, est due au fait que dans le premier cas on parallélise presque (la gestion des tubes fait qu'on n'attend pas que tout se fasse séquentiellement)

“It is seldom that liberty of any kind is lost all at once.” ― David Hume

Ils n'ont pas entièrement torts ; la question peut se poser… Mais en même temps, je me dis que c'est pris en compte au vue de la proposition de l'hébergeur. Alors ça me chagrine d'avoir l'impression de lire entre les lignes qu'on tire sur les blessés, et si on ajoute ce french-bashing de l'intérieur alors que le reste du monde a pris cette annonce/proposition très au sérieux, je suis outré et chagriné par nos médias.

“It is seldom that liberty of any kind is lost all at once.” ― David Hume

Et ça s'applique aux gens/organismes qui n'ont pas dument déclaré les dits données perdues ?

“It is seldom that liberty of any kind is lost all at once.” ― David Hume

…le tacle à la fin de l'article

“It is seldom that liberty of any kind is lost all at once.” ― David Hume

Légalement ils peuvent demander un numéro. Mais obligé que le numéro soit mobile c'est absolument de l'abus.
Tiens, votre logique, pourquoi ne pas l'appliquer dans l'autre sens pour voir ?

“It is seldom that liberty of any kind is lost all at once.” ― David Hume

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.

Pas tous, mais la majorité, en ayant les mêmes contraintes que celles posées. Mais cela ne signifie pas que c'est la version finale de la majorité, mais le premier truc qui vient à l'esprit d'une personne pas trop perchée. Et sur ce point justement, il dit bien que ce qui l'intéresse c'est que les devs connaissent et comprennent assez ces aspects (comment sont géré les tableaux de hachage, les performances des entrées/sorties et des routines de tri intégrées) de leur langage de prédilection et non des concepts algorithmiques très avancés que peu mettent en œuvre au final (encore en général, et ça vise les petites entreprises qui veulent faire des entretiens à la Foogle/Gacebook pour finalement vous faire pondre des petits trucs bien loin de là) : « I think this is a good interview question because it’s somewhat harder to solve than FizzBuzz, but it doesn’t suffer from the “invert a binary tree on this whiteboard” issue. It’s the kind of thing a programmer might have to write a script for in real life, and it shows whether they understand file I/O, hash tables (maps), and how to use their language’s sort function. There’s a little bit of trickiness in the sorting part, because most hash tables aren’t ordered, and if they are, it’s by key or insertion order and not by value. »

Le problème est certainement lié à une autre de ses pensées : "I still think this interview question is a good one for a coding question". Si cette question m'était posée telle que lors d'un entretien (hypothèse improbable), je demanderais à l'examinateur dans quel contexte le programme est censé s'exécuter, quels sont les critères importants : performance à tout prix ? code facile à maintenir même 20 ans plus tard par un nouvel arrivant ? Empreinte mémoire minimale ? Espace disque ou IO minimum ? … Même si dans la vie réelle c'est souvent un équilibre entre tous ces critères, rien ne permet de deviner le choix de l'examinateur. Au final il y aura autant de versions que ce choix d'équilibre entre ces critères.

De ce que j'ai vu pour avoir fait passer un certain nombre d'entretiens et pour en avoir subi de bien costaudes aussi, on ne pense pas forcément à faire le malin ni à donner une réponse exhaustive quand on pense à tout les points que tu évoques. Les examinateurs pas fêlés n'ont normalement pas de choix et veulent juste voir comment est esquissée la solution (et là, en proposant celle de Ben tu le rassures que tu sauras répondre aux urgences au lieu de pinailler quand il y a le feu ; et si en plus tu mets les réserves citées par vous deux, ça montre que tu connais ton langage et sauras optimiser le moment venu)
Mais sinon, c'est un peu la seconde partie de l'entretien déjà… « After the candidate has a basic solution, you can push it in all sorts of different directions: what about capitalization? punctuation? how does it order two words with the same frequency? what’s the performance bottleneck likely to be? how does it fare in terms of big-O? what’s the memory usage? roughly how long would your program take to process a 1GB file? would your solution still work for 1TB? and so on. Or you can take it in a “software engineering” direction and talk about error handling, testability, turning it into a hardened command line utility, etc. »

“It is seldom that liberty of any kind is lost all at once.” ― David Hume

Le titre est ce qu'on appelle, je crois, putaclic (il est à parier qu'avec un titre plus honnête il aurait eu beaucoup moins de lectures et de commentaires ici, et probablement de contributions héhé) ;-)

Alors, pour la version simple et l'optimisée, il a énoncé les critères suivants :

• on lit un fichier depuis l'entrée standard, et on ne lit pas tout le fichier en mémoire (mais par blocs pouvant être des lignes et au d'au plus 64 kibi)
• on écrit le nombre d'occurrence des mots le composant du plus élevé au plus bas sur la sortie standard
• on ne fait pas de distinction de casse et son résultat est en minuscule : "le" et "Le" et "LE" seront tous trois comptés "le 3"
• on ne se préoccupe pas de l'encodage et des accentuations, on considère qu'on bosse sur de l'ASCII des familles (comme le document de test utilisé)
• on ne cherche pas à classer les mots ayant la même fréquence d'apparition
• on n'utilise que les éléments de base du langage (pas de bibliothèque supplémentaire)
• on n'invente pas sa propre structure de hachage (même s'il a fait une exception pour la variante optimisée en C)
• on s'évite les trucs de jedi du langage et le recours à l'assembleur ou trucs similaires

Avec ces trois derniers, il est un peu difficile de trouver un autre algo que celui proposé. Tu trouves autres chose et ce ne sera plus le même test ni le même objectif de l'entretien.
Mais fort de ces contraintes, il est normal que même la version optimisée ne touche pas fondamentalement la logique première (toute façon l'autre but, comme je le perçois, était de voir comment mettre le profilage à profit ensuite et quand il faut s'avoir s'arrêter dans l'optimisation : pour certains langages il dit qu'on peut faire mieux, mais qu'il estime que c'est trop d'effort pour des poullièmes par rapport au cadre posé)

“It is seldom that liberty of any kind is lost all at once.” ― David Hume

Le but était de démontrer d'une mesure de temps d'exécution est fantaisiste car il y a moultes façons d'écrire ce programme, avec des temps d'exécution fort différents.

Ça tombe bien… C'est dans la section finale, « Other languages », où il est dit :

Many readers contributed to the benhoyt/countwords repository to add other popular languages – thank you! Here’s the list:

L'auteur n'a clairement pas écrit la variante en PHP d'une part (c'est Max Semenik qui en est crédité), et elles sont sur un dépôt ouvert ouvert d'autre part… Donc tu peux soumettre une version optimisée.

Il est aussi conscient qu'il y a plusieurs façons d'arriver au même résultat, et précise dans le résumé en introduction :

For each language, I’ve included a simple, idiomatic solution as well as a more optimized approach via profiling.

La solution de base, simple, est normalement ce qu'on peut pondre de tête lorsqu'on vous présente le problème en entretien et qu'on n'a pas tous les éléments et le temps pour faire un truc beau et optimisé (là dessus, on est d'accord que le plus simple est d'utiliser explode et que peu de gens ont le réflexe preg_split qui se trouve moins performant pour le coup)

A basic solution reads the file line-by-line, converts to lowercase, splits each line into words, and counts the frequencies in a hash table. When that’s done, it converts the hash table to a list of word-count pairs, sorts by count (largest first), and prints them out.

L'optimisation est la seconde étape, et c'est dans ce cadre et ce sens qu'il faut regarder les temps d'exécution. Mais pas pour eux-même ni pour se comparer au voisi dans l'absolu : la démonstration est surtout comment profiter des outils de profilage pour optimiser (donc on devrait comparer les différentes versions d'un même langage entre elles —mais accidentellement, quand on sait le faire dans plusieurs langages, il est tentant de comparer les mêmes implémentations entre langages pour voir si les mêmes efforts payent de la même façon et aussi mieux appréhender les points forts et les points faibles de chacun.)
Non seulement Ben ne pratique pas le PHP, mais si c'était le cas il n'aurait accordé une section que s'il peut présenter une version de base et une optimisée en s'appuyant sur une possibilité de profilage intégrée (et ce point m'intéresse si tu as la réponse.)

“It is seldom that liberty of any kind is lost all at once.” ― David Hume

Si quelqu'un a trouvé une utilité à ce logiciel, je serai ravi de lire son journal ;)

À première vue, c'est pour avoir de la puissance de calcul/traitement distribuée sur des machines auxquelles on a accès.

“It is seldom that liberty of any kind is lost all at once.” ― David Hume

Faut-il en rire ou en pleurer ?

“It is seldom that liberty of any kind is lost all at once.” ― David Hume