Michaël a écrit 2935 commentaires

Pour des implémentations fictives d'un objet représentant un intervalle, qu'est-ce que c'est l'avantage de dire

var sequence = createSequence(1,10);
for(let i of sequence(0 {
  print(i);
}

par rapport à

var sequence = createSequence(1,0);
sequence.forEach(print);

Si le traitement est plus compliqué on peut remplacer le print du deuxième exemple par une fonction anonyme. La deuxième forme est rendue possible par le langage depuis longtemps (toujours?) et je ne vois pas trop l'intérêt d'étendre le langage pour proposer de faire de façon compliquée ce qu'on pouvait faire simplement avant.

En plus l'intérêt de la deuxième forme est qu'on peut implémenter facilement le forEach pour éviter d'avoir un état mutable dans sequence ce qui permet de partager la valeur entre plusieurs threads sans se casser la tête. La forme avec yield n'a pas cet avantage.

La forme avec yield a peut-être des avantages sur le forEach mais ce n'est pas celui que tu dis. Rien n'interdit à un objet de publier des fonctions forEach ou la forme plus générale reduce pour permettre à tout le monde d'itérer sur la propriétés de l'objet de façon standardisée. Ou de générer les éléments à la demande.

Tout ce que tu dis n'est pas spécifique au yield et est déjà rendu possible par les fonctions d'ordre supérieur à la reduce et forEach.

Merci pour cette dépêche!

C'est chouette de voir des fonctions comme les promises ou les modules qui existent depuis longtemps dans des implémentations variées arriver dans le standard. Les proxies et la réflection sont aussi prometteurs de structures abstraites plus faciles à utiliser.

Certains point me convainquent beaucoup moins, comme par exemple la petite surcouche objet puisque le livre de Douglas Crockford *JavaScript, the good parts” répertorie des techniques faciles à utiliser qui permettent de vivre en paix avec le modèle objet plutôt exotique de JavaScript… il ne semblait pas urgent de rendre encore plus compliqué ce qui l'était déjà assez.

Pour l'assignement d'objets, c'est dommage de ne pas avancer plus loin en proposant aussi la copie en profondeur des objets – qui marche au moins pour les PODs – c'est du jargon C++, je veux dire les structures sans méthodes. Je ne vois aussi pas trop l'intérêt des itérables, puisque JavaScript est un langage fonctionnel et que la bibliothèque standard propose des tableaux qui savent faire reduce ou forEach la fonctionnalité des itérables me semble un peu superflue, et demande de comprendre des nouveaux concepts (comment marche le 'yield') alors qu'utiliser reduce ou forEach rentre dans le cadre normal du langage.

Bon et puis même si l'hypothèse que de plus en plus d'utilisateurs utilisent le cloud et voient leur PC comme un cache, est-ce forcément une bonne chose ?

On a déjà une expérience en la matière, puisque c'est le retour aux débuts de l'informatique avec une architecture terminal et unité centrale.

Pour l'instant, le tout-Cloud n'est pas encore une alternative viable.

Il y a une différence entre les technologies cloud et le déploiement en software as a (web) service. En fait ces deux choses n'ont rien à voir et on peut faire remonter le software as a service aux scripts CGI!

Le software as a service introduit:

1. Une fiabilité moindre (il faut mettre Internet dans la chaîne de fiabilité!)
2. Des problèmes de sécurité, peut-on accéder à mes documents sans mon consentement?
3. Des problèmes de confidentialité, ai-je raison de faire une confiance aveugle à l'entreprise qui héberge mon service?
4. Des problèmes de maintenance, est-ce que mon prestataire va faire une maintenance rendant son servie inaccessible à un moment critique pour moi?
5. Des problèmes de pérennité, que se passe-t-il si mon partenaire disparaît? Vais-je récupérer mes données? Vais-je pouvoir les utiliser?

Et encore je ne mets même pas les questions power user de type comment intégrer le service dans du traitement par lot.

À cause de tout ces points, le software as a service est complètement impensable pour toutes les professions qui ont des hauts degrés de confidentialité, voire même rendu pratiquement impossible par les régulations!

Le gros bénéfice de software as a service est en réalité pour les développeurs qui au lieu de travailler avec Unix et Windows se retrouvent dans un environnement relativement standardisé, le navigateur – j'imagine que les différences de compatibilité ne sont aujourd'hui pas pires que celles des différents Unix!

Il est très rare (de mon expérience toujours) d'avoir des cas d'état partagé ou de processus (léger ou pas) qui doivent réellement coopérer.

C'est également mon expérience. Je programme beaucoup en OCaml qui a une bibliothèque très puissante Lwt pour faire de la programmation concurrente. Comme OCaml est un langage fonctionnel, on est en tant que programmeur assez disposé à utiliser des valeurs contantes et des fonctions récursives pour décrire les traitements. Le fait que les valeurs soient constantes réduit énormément les besoin en mutexes. La bibliothèque Lwt propose des threads collaboratifs – plutôt que le traditionnel modèle préemptif – l'ordonnanceur ne peut changer de thread que lorsque le thread en cours d'exécution atteint un point de collaboration. Cette stratégie réduit d'autant les besoins en mutexes. Par une astuce élégante, le type des fonctions indique clairement si elles contiennent un point de collaboration ou pas, ce qui rend la bibliothèque très facile et agréable à utiliser.

Le revers de la médaille est que OCaml ne supporte en principe pas le parallélisme, mais on peut cependant faire fonctionner Lwt comme Node.JS où un thread (de type OS) exécute le programme OCaml ou Javascript tandis qu'un second s'occupe des appels systèmes.

Ce que j'apprécie avec ce genre de démarche c'est qu'elle limitent le nombre de processus créer ce qui permet d'éviter de perdre du temps dans des ordonnanceurs.

Ça évite aussi de se prendre les pieds dans un drapeau Suisse! :)

Quitte à essayer de construire une bibliothèque qui le fait bien, autant coder directement en Haskell

On n'est pas vendredi, mais remplacer du caml par du haskell ;)

Ce que je veux dire c'est que votre familiarité avec un langage fait croire que ce langage est clair, mais qu'en fait ce n'est le cas que pour ceux qui sont familiarisés avec ses idiomes.

Voilà un exemple de programme pas très clair: je veux afficher Hello, world! et je dois écrire:

#include <stdio.h>
#include <stdlib.h>

int main(int argc, char **argv)
{
    printf("Hello, world!\n");
    return EXIT_SUCCESS;
}

Par rapport à mon but il y a plein de bruit que je ne comprends pas. Je vois bien que le biscuit c'est le printf(…) mais quel est le rapport entre mon but et le main et les #include, argc, argv ? Ce n'est pas clair parceque beaucoup d'éléments sont sans lien apparent avec mon but. Quand tu lis

main :: IO ()
main = (take 10 <$> 
        sort <$> 
        map toFloat <$> 
        filter (\s -> length s > 0 && (s !! 0) /= '#') <$> 
        cat "fichier") >>= output 

on retrouve un peu de bruit main et output mais la plupart des éléments peuvent facilement être rattachés à la description de la tâche. Comme dans ton exemple

chain(cat(),
      filter(lambda s: s and s[0] != '#'),
      map(float),
      sort(),
      head(n=10),
      output())

Il y a un petit peu de bruit, le chain mais les autres éléments sont facilement rattachables à la description de la tâche à effectuer.

On est pas vendredi, mais remplacer du shell par du caml … mis à part des améliorations purement techniques de performances, je ne comprend pas l'intérêt syntaxique

Le but est d'aboutir à une meilleur gestion des erreurs. Le shell est très efficace pour écrire des prototypes. Dans mon poste actuel, j'ai codé un environnement de test unitaires, des outils d'intégration continue et de déploiement, des outils de maintenance de serveur, de configuration de serveur, … en quelques semaines à peine, en shell.

Mais ces programmes ne sont que des prototypes, qui mériteraient des versions plus robustes.

Pour l'approche monadique je pensais plutôt à l'autre côté: la description de la tâche et sa supervision plutôt que l'IO. Ce que je vais essayer dans les prochains jours c'est de programmer une monade dans laquelle on peut définir une commande complexe et faire tout le pipe-fitting qu'on veut, définir les options de supervision, etc.

Après, pour la monade, oui, c'est une solution élégante, mais en OCaml, on ne peut pas garantir la pureté des fonctions, du coup, des méthodes de type « retry » et autres pourraient avoir des comportements étranges … (si on ne fait pas attention)

Quand on crée et efface des fichiers, qu'on compile des programmes ou qu'on installe des paquets sur un serveur, on est intéressé essentiellement par les effets de bord, et aucun langage ne va magiquement rendre le retry facile à implémenter!

La problématique du déboguage est la suivante: j'ai un utilitaire qui plante au milieu de la pipeline et je veux comprendre pourquoi. Je veux donc accéder à:

1. La ligne d'appel de l'utilitaire (argument vector)
2. L'environnement du processus
3. Son dossier d'exécution
4. Le code de retour
5. Le contenu de stdout
6. Le contenu de stderr.

Si je lance la commande rm ou cp je n'ai peut-être pas besoin d'avoir accès à tous ces détails pour comprendre ce qui s'est mal passé, mais dans les cas de programmes complexes, comme par exemple un compilateur, TeX ou METAPOST, accéder à ces informations est primordial.

Pour la gestion des erreurs, imaginons que j'ai un traitement complexe à effectuer, et qu'au milieu j'ai une erreur. Par exemple j'exécute un script par SSH sur 50 serveurs et le script plante sur deux serveurs. Je peux vouloir que mon programme supervisant l'exécution des scripts me donne la chance de voir ce qui ne va pas sur les deux serveurs puis de réessayer les scripts, et si tout s'est bien passé de continuer le pipeline. Si tout ce que me propose mon programme de supervision c'est d'arrêter le traitement à la première erreur, de nettoyer à la main le bazar qu'il a laissé derrière lui et de tout reprendre depuis zéro… et bien j'aime autant programmer directement en shell.

C'est l'habitude de lire et écrire des pages de man(1). :)

Je programme énormément en shell pour écrire des programmes que je considère comme des prototypes et comme je programme aussi en OCaml j'ai commencé à écrire Rashell une bibliothèque un peu comme celle que tu viens de commencer, mais pour OCaml.

De mon expérience de programmeur shell ce qui me semble important à considérer pour ta bibliothèque pour pouvoir écrire des programmes plus fiables que ce que permet le shell c'est:

1. La gestion des erreurs – comment sont signalées les erreurs dans une pipeline ?
2. Le déboguage – comment sont affichées ou transmises les informations importantes aux déboguage lorsque un processus rate?
3. Comment est implémentée l'option pour réessayer?

J'ai commencé Rashell comme projet de programmation exploratrice, sans avoir un plan très clair a priori mais il me semble que l'idéal pour résoudre 1.2.3 serait de passer par des monades comme SuccessMonad qui fournissent un environnement d'évaluation aux commandes complexes.

J'ai vaguement regardé les projets qu'ont cité les autres et je n'ai pas vu comment ils traitaient 1.2.3. C'est d'ailleurs un peu une blague de citer touts ces projets pêle-mêle sans aucune hiérarchisation, certains sont beaucoup plus aboutis que d'autres. Si tu t'intéresses à la programmation système, tous ces projets sont des sources d'inspiration, Tu as peut-être des objectifs différents que ces projets là, ce qui te ferait de la place. Si au contraire il y a déjà un projet qui correspond bien à ton besoin, c'est une super nouvelle car tu as trouvé un projet que tu peux aider! :)

• Rashell, the Replicant Shell Library – le replicant est juste une blague en rapport à Blade Runner.

Pour la commande sed, je vais faire une commande basée sur re.sub c'est suffisant à votre avis?

Non pas du tout sed est un petit langage de programmation à part entière, il existe depuis des décennies et a donc une quantité incroyable de scripts que les programmeurs shell utilisent. Donc si par exemple je me mettais en tête de traduire mes prototypes shell avec ta bibliothèque, remarquer qu'il n'y a pas de sed ou de awk serait rédhibitoire!

La fonction gsub est juste le niveau 0 d'utilisation de sed dans la plupart de cas, cela ne suffit absolument comme remplacement!

Je ne vois pas trop l'intérêt, étant donné qu'ici c'est presque simplement de la composition de fonctions (ici de générateurs)

Un intérêt est d'avoir des IO rapides à la jonction des processus puisque la communication est directement prise en charge par l'OS au lieu de tout remonter dans le langage, couper ligne à ligne, écrire immédiatement.

Sur des applications très intenses au niveau des IO, c'est une différence importante.

C'est le terminal qui a mangé. Tu peux le réparer avec reset.

Il est aussi traité là: http://stackoverflow.com/questions/20629302/better-way-to-rename-files-based-on-multiple-patterns/25597051#25597051 :)

C'est la meilleure proposition (la plus simple)! :)

Tu peux aussi faire find … | sed -e 's@.*/@@' qui sera bien plus rapide puisque la version avec basename lancera un programme par fichier trouvé, alors qu'avec le pipe tu as en tout et pour tout deux programmes quoi qu'il arrive!

PS : oui, la, je caricature, car on est encore loin de tels changements, c'est pour le plaisir de troller.

Dans ma ville on a démonté hier la dernière ligne téléphonique, inutilisée depuis dix ans, quand aux passages à niveau, personne n'a été assez fou pour en construire! Je faisais juste un effort d'imagination, quand on discute sur vieux forum RoR on ne peut jamais vraiment savoir dans quel siècle sont restés coincés ses interlocuteurs! :D

C’est assez marrant de voir qu’au 21e siècle le disque dur a beau avoir quasi-disparu (en fait, c'est surtout utilisé comme stockage temporaire) c’est encore utilisé comme icône dans de nombreux logiciel…

Si tu veux continuer de t'amuser tu peux regarder les représentations du téléphone dans les courriers ou sur les cartes de visite de tes correspondants, ou bien celles de locomotives sur les panneaux de signalisation, …

C’est quoi cette manie de demander une source pour tout est n’importe quoi ? C’est à cause de Wikipédia cette mode ? :)

Quand quelqu'un affirme quelque chose, la moindre des choses est qu'il soit en mesure de rendre des comptes et d'étayer des informations. C'est ce qui fait la différence entre une discussion et un passe-temps de bistrot.

Ah oui il y a une énorme différence! Je réponds à un commentaire (qui ne parle pas de jar mais de curl - | sh).

Si tu installes un logiciel tiers à partir des sources, il faudra bien que tu exécutes du code shell que eux ont écrit avec les droits root. Que tu fasses un curl -L -O http://mysupersoft/install.sh | bash ou un sudo make install ne fait pas de grand différence – tant que tu fais confiance au téléchargement.

Ou alors j'execute ca dans une VM.

Vu les progrès énorme faits virtualisation dans les dernières années — aujourd;hui c'est hyoper facile à utiliser — cela me semble aussi la solution la plus raisonnable pour exécuter des programmes d'origine douteuse.

Et plus sérieusement, parmi les loups, ce sont surtout les jeunes loup qui font du dégâts par ce qu'ils ne chassent pas encore bien, et qu'ils ont tendance à blesser plusieurs bêtes au lieu d'en tuer une seule.

Il faudrait améliorer la qualité de leur formation… mais après on va encore dire qu'on s'intéresse plus aux criminels qu'aux victimes.

Parler de la compétition loups/bétail dans un sujet sur l'Open Data, fallait quand même y arriver.

C'est la faute de Sarkozy.

Je te propose un stage sur les forums de jeuxvideo.fr :D

On a retrouvé un développeur de Cannon Fodder! :)