Imagine2 a écrit 15 commentaires

  • # Clojure babashka

    Posté par  . En réponse au journal Rashell – Une bibliothèque pour remplacer les scripts shells par du Lisp. Évalué à 1.

    Sinon, en Clojure au lieu de Common Lisp, il y a babashka.
    Comme toujours, très bien pour un usage perso, mais impossible à faire adopter au boulot sur un projet en équipe. Pas assez "mainstream" comme on dit.

  • # Humour geek

    Posté par  . En réponse au journal GSoC sur GtkSourceView/gedit. Évalué à -1.

    Le GSoC consistait, entre autre, à implémenter dans GtkSourceView une API de haut niveau pour la recherche et remplacement. Une implémentation basique existait dans gedit, mais ne permettait pas la recherche par regex, et ne retournait pas le nombre total d'occurrences dans le fichier (ce qui implique de scanner l'entièreté du fichier de manière asynchrone).

    M-x query-replace-regexp ne marchait pas?

  • [^] # Re: Ça dénonce plus gravement que ta maman

    Posté par  . En réponse au journal Seuls les fous comprennent quelques chose à l’internet. Évalué à -1.

    Le sens de son message ? J’hésite ! A répartir entre: jalousie, idolâtrie, communautarisme, ennui, immaturité, troll ?

    Et sinon, contribuer à un projet libre, même simple, avec enthousiasme et sincérité, n’est pas assez bien?

  • # Emacs org-mode

    Posté par  . En réponse au journal Improuve ton thinkflow : de Catch à EverNote. Évalué à 6.

    Quitte à passer pour un vieux hacker ringard, j'utilise emacs org-mode quotidiennement depuis plusieurs années avec un plaisir et un étonnement sans cesse renouvelés. Ses possibilités sont vraiment riches: de la prise de notes structurées au tableur intégré, en passant par la programmation (aka "literate programming").
    Certes, on est peut-être un peu loin de EverNote, mais le confort et la puissance d'emacs sont sans équivalents (avis personnel, sans volonté de troll svp).

  • [^] # Re: langage fonctionnel

    Posté par  . En réponse au journal Ada, langage et ressources. Évalué à 1.

    Je répondais à ceci:

    Je parle du truc de ocaml, dont chaque branche est plus ou moins définit par un constructeur qui permet de déconstruire la donnée et récupérer ce qu'il y a dedans de façon typé.

    …ce qui m'a l'air de correspondre aux extracteurs. Les "case classes" en Scala sont essentiellement pour le "pattern matching" (par exemple pouvoir mettre des objets dans les cas d'un "switch") ce qui est différent, malgré ce qui est dit plus haut.

  • [^] # Re: langage fonctionnel

    Posté par  . En réponse au journal Ada, langage et ressources. Évalué à 1.

    Est-ce ce qu'on appelle "extractor" en Scala?
    Voici par exemple, comment construire un objet de type "pair" à partir d'un entier:

    object Twice {                              
      def apply(x: Int): Int = x * 2
      def unapply(z: Int): Option[Int] = if (z%2 == 0) Some(z/2) else None
    }
    
    
  • # +1

    Posté par  . En réponse à la dépêche Libérons le Cahier de l'Admin Debian. Évalué à 10.

    Je possède deux éditions françaises de ce livre et je profite donc de l’occasion pour le recommander chaudement tout en félicitant les auteurs. La rédaction est excellente (ce qui est rarement le cas pour des livres techniques, notamment les traductions) et le contenu extrêmement complet et pertinent : à la fois pédagogique et concret quand il le faut. De plus il s’applique à Linux en général autant qu’à Debian. Un bon exemple de livre technique Français, au niveau des meilleures productions anglo-saxonnes. La libération est évidemment une bonne nouvelle ! Bravo pour cette initiative, dans l’esprit de Debian et du libre. Tout se tient.

  • # Open Source

    Posté par  . En réponse au journal [HS] Développeur un peu perdu… ou pas… Que faire maintenant ? Changer de vie ?. Évalué à 3.

    Facile de s'identifier à un moment ou un autre en lisant ce journal…
    Voici une idée simple pour se donner un "but" (en tant que développeur logiciel): créer ou collaborer à un projet Open Source. Ça tombe bien, on est sur linuxfr! Après le boulot (ou pendant), on code pour le plaisir, comme on le souhaite, avec les outils de son choix et à son rythme. Bien sur, on n'en vit pas, mais par expérience c'est souvent profitable, même dans son travail quotidien.
    Sinon, pour approfondir le sujet, je recommande ce joli texte en français sur la motivation. Je pense que beaucoup de thèmes rejoignent ceux évoqués dans l'article. Merci d'avoir partagé ton ressenti en tout cas.

  • [^] # Re: Commentaire opportuniste

    Posté par  . En réponse à la dépêche Jitsi 2.0 est sorti. Évalué à 1.

    Pour les curieux, ou ceux qui souhaitent développer leur propre solution, voici un exemple de tableau blanc web (et donc partagé et multiplatforme).
    Ce n'est pas un produit, mais une juste réponse à un concours de programmation de la société Typesafe, qui a d'ailleurs reçue le premier prix. Le code est très concis mais très élégant. Il est basé sur les frameworks, akka pour les échanges de messages entre tableaux et play2 pour la partie web. Le tout écrit en scala.

  • [^] # Re: nb

    Posté par  . En réponse au journal Un cours en français sur la compilation : ne boudons pas notre plaisir !. Évalué à 2.

    Tu risques d'avoir pas mal de travail!

  • # Informatique pratique

    Posté par  . En réponse au journal Linux et la CNC. Évalué à 10.

    Très bon article, sur le fond comme sur la forme, merci. Je suis toujours impressionné par la diversité, et parfois la passion comme ici, de la communauté du libre.
    Il est bon aussi de voir des exemples d'informatique pratique, ça change du design web ou de l'administration système (l'informatique au service de l'informatique).
    L'informatique est mon métier et j'aime voir des personnes d'autres horizons aussi curieuses et compétentes. Gens Una Sumus.

  • [^] # Re: Écoles d'ingénieurs?

    Posté par  . En réponse au journal Epitech, l'une des plus prestigieuses écoles d'ingénieurs en Europe, se tourne vers SuSE Linux !. Évalué à 2.

    J'ai en revanche eu des difficultés avec quelques collègues ingénieurs informaticiens, du fait de leur peu d'écoute des maîtrises d'ouvrage (des marketeux ou des consultants AMOA ou des universitaires) tellement ils étaient focalisés sur la technique et non le métier (ou une finalité, des besoins légitimes ou non, faisables ou irréalistes parfois).

    Je rencontre souvent le même problème. La valeur d'un logiciel ne se mesure pas à son coût (ce que beaucoup de managers ou vendeurs veulent croire) ou même à sa qualité, mais à son utilité!
    Un logiciel "parfait", sans bug, et d'une conception extrêmement intelligente mais inutile ou à coté de sa cible, vaut moins qu'un pauvre script, lent et ou mal fichu mais qui répond à un vrai besoin.
    Mais on ne se refait pas, on est souvent attiré par la première catégorie: on est ingénieur dans l'âme (quelque soit son école :-).
    Pour ma part, je veux aussi croire que le soucis d'un ingénieur est surtout d'apporter une solution à un problème concret.

  • [^] # Can your programming language do this?

    Posté par  . En réponse au journal Adopter un style de programmation fonctionnel. Évalué à 3.

    Un autre article (de 2006) qui m'avait aussi influencé. Sur un ton humoristique, il explique pourquoi Google avait "inventé" MapReduce et pourquoi Microsoft ne pouvait pas le faire au même moment. Simplement parce-que les ingénieurs de Google avaient été à l'école FP. (Depuis, MS a fait F# :-)

  • # Scala

    Posté par  . En réponse au journal Adopter un style de programmation fonctionnel. Évalué à 4.

    Pour ceux qui souhaitent découvrir la programmation fonctionnelle, je recommande scala. Un cours gratuit de 7 semaines vient de se terminer sur Coursera, mais peut-être que les lectures sont encore en ligne. Les exercices étaient tous excellents, et tirés du livre de référence: Structure and Interpretation of Computer Programs.
    Ce style de programmation vit un net regain d'intérêt depuis quelques années, notamment depuis l'arrivée des processeurs multi-cores et du fameux "Claude" (vous savez, le nuage toussa). Un grand avantage dans ces deux cas et que la programmation fonctionnelle favorise les données dites "immutable", qu'on ne peut plus modifier une fois initialisées (comme une String en Java). Le traitement parallèle des données devient donc trivial, puisqu'il n'y a plus de données partagées et donc de concurrence d'accès (i.e synchronisation). Une fonction ne modifie pas ses paramètres d'entrée, n'a pas d'effets de bord, et est donc parfaitement reproductible quel que soit le contexte d'exécution (ce qui fait que les programmes fonctionnels sont plus facilement testables).
    Il y bien d'autres arguments, et on ne (re)fera pas le débat ici. Un point important apporté par l'article et qu'il est possible d'adopter des principes fonctionnels avec presque tous les langages, par exemple en ne modifiant pas ses variables, en utilisant des algorithmes récursifs, ou en passant des fonctions en paramètre d'autres fonctions (si le langage le permet, comme avec des pointeurs en C ou des "function object" en C++). Bien sûr, un vrai langage fonctionnel sera toujours plus adapté au style.
    Pour ceux qui aiment des arguments plus terre à terre, mon expérience montre qu'un programme en scala est nettement plus concis (2 à 3 fois) que son équivalent Java, et nettement plus maintenable (moins de bugs subtils de synchronisation qui au final sont souvent très longs et difficiles à corriger).

  • # Pousse-toi de là

    Posté par  . En réponse à la dépêche De tout, de rien, des bookmarks, du bla‐bla #44. Évalué à 3.

    Le mode "push" en web s'obtient actuellement via WebSocket ou Comet. Personnellement j'utilise avec bonheur le framework Play! 2.0 qui est particulièrement adapté à l'envoi de messages asynchrones du serveur vers le client, notamment grâce aux très élégants Iteratees en Scala. Il n'en reste pas moins qu'une API push HTML5 standardisée comblerait un manque certain, et ouvrirait (encore plus) la voie aux applications Internet riches (RIA comme disent le jeunes).