Miguel Moquillon a écrit 456 commentaires

Si c'est un framework, en effet, il est destiné à être intégré dans d'autres projets Java nécessitant ses fonctionnalités. Et sur ce point, le choix du Makefile ou du Ant me laisse encore plus perplexe.
En effet, ils ont a un goût prononcé de retour dans le passé.
Il existe maintenant des outils qui permettent de gérer le cycle de vie d'un projet Java, ainsi que ces dépendances, et de le mettre à disposition dans des dépôts sur Internet. Je pense en l'occurrence à Maven pour lequel les dépôts de projets Java sont utilisés même par ses concurrents.
Et Maven est supporté par l'ensemble des IDE pour Java (Netbeans, IntelliJ IDEA, Eclipse) et exécutable aussi en ligne de commande aussi bien sur les Unix que sur le Windows.

Non, une approche ou paradigme est avant tout une façon de penser les choses, les problèmes et les solutions ; les constructions en dérivent donc comme support du paradigme. Et, à l'usage, l'utilisation des constructions du langage vont conditionner aussi la façon de penser. C'est la raison pour laquelle des développeurs qui ont une forte expérience avec les langages dît impératifs vont avoir plus de mal avec les langages fonctionnels.

Ramener l'approche à une simple définition et utilisation de constructions est une erreur qui a malheureusement fait bcp de mal à la POO. Ainsi, par exemple, j'ai vu un grand nombre de développeurs acquérir une connaissance erronée de la POO au travers de langages comme C++.

Pour le déclaratif, un exemple vaut tous les discours (enfin c'est ce que l'on dit) :

applesInCart cart = [ a | a <- filter (== Apples) cart ]

Autrement dit : la fonction applesInCart est déclaré comme étant l'ensemble des pommes dans le caddie.

En C :

Fruit* applesInCart(int size, Fruit* cart)
{
   Fruit* apples = malloc(...);
   int i, j = 0,;
   for(i = 0; i < size; i++)
      if (isApples(cart[i]))
        apples[j++] = cart[i];
   return apples;
}

là tu dis ce qu'il faut faire : parcourir les éléments du caddie un par un, tester que l’élément est bien une pomme et si oui l'ajouter dans le tableau à retourner.

Je distingue constructions impératives ou fonctionnelles de l'approche (impérative ou fonctionnelle). Dans le premier cas, il s'agit d'apport du langage, et dans le second de la manière de penser et d'écrire des programmes. Et donc, c'est sous cette lumière que je reste sceptique quant à proposer un mixte des deux approches parce que par trop différentes (ce qui ne signifie pas que ce n'est pas possible).

Aussi, lorsque tu écris que l'on peut mélanger la programmation fonctionnelle et impérative avec des langages fonctionnels, je comprend utiliser des constructions impératives pour exprimer certaines choses (qui ne serait peut être pas possible ou compliquer de faire autrement). Et là dessus oui je suis d'accord. Ainsi, dans Haskell (je ne connais pas Caml pour m'exprimer à son sujet), les constructions dîtes impératives sont utilisées avant tout pour exprimer des effets de bord (via les monades).

Quant à mon expression de "déclaratif", il signifie ni plus ni moins que la manière dont sont écrites les fonctions : en déclarant ce qu'elles font par le biais d'autres fonctions (à opposer à stipuler comment elles doivent le faire).

Tu parles de python là ? Tu vas en froisser quelques uns, fais attention. :) De plus je code en python et ce serait intéressant que tu développes davantage ce point. Merci par avance.

Non, en fait je pensais plus à Scala ; Scala est un langage orienté objet et fonctionnel avec une structure impérative.
Python est différent : c'est un langage impératif doté de constructions fonctionnelles, ce qui n'est pas la même chose.

Je reste mitigé quant au mixe des deux approches, impératives et fonctionnelles, parce qu'elles sont disjointes ; ce sont deux modes de pensée différentes au delà des simples constructions. En fonctionnel, il est plus naturel de penser top-down et de ce que l'on veut faire (pas comment faire) et le résultat est la composition de fonctions qui décrit les relations déclaratives (et sémantiques) entre les fonctions d'un programme.

J'aimerais bien avoir du sous-typage (héritage sans polymorphisme) histoire d'éviter de caster quand on adopte une conception objet.

Déjà, parce que tu as une relation de sous-typage, tu auras de toute façon du polymorphisme via le principe de Liskov.
Le problème de coercicion vient justement que les langages couramment utilisés ne supportent que le typage du second ordre alors que la programmation orientée objet nécessite un typage du second ordre et plus particulièrement le typage F-Bounded (qui résoult le problème des types récursifs).

En revanche, je ne mettrais aucun des trucs à la mode du genre closure, programmation fonctionnelle,

ça par contre c'est bien dommage parce que les closures apportent une force indéniable dans l'écriture et la maintenance de code. (Elles ont montrés leur efficacité dans l'écriture de code orienté-objet avec Smalltalk 80.)
A côté de ceci, la programmation fonctionnelle est une force parce que justement elle permet d'écrire plus simplement du code qui serait bien plus complexe en programmation impérative. Par contre, oui, je suis plus mitigé du mixe forme fonctionnelle et forme impérative que l'on trouve dans certains langages.

Surtout, je ne mettrai pas la concurrence dans le langage, parce qu'on n'a pas encore assez d'expérience

C'est à la fois vrai et faux :
- vrai parce que globalement dans l'industrie du développement logiciel, les codeurs sont pauvres en expériences et en compétences dans ce domaine,
- faux parce que ce domaine existe depuis bien bien longtemps et que de nombreuses techniques et forme de programmation existent et ont fait leur preuve mais dans des métiers particuliers les nécessitant (communication, transaction financière, ...)

J'avais un portable PC qui tournait avec un Core Duo (pas un core 2 Duo mais bien un Core Duo) et qui m'a lâché l'année dernière. Il m'avais fait 4 ans, mais j'étais encore sous le choc de sa mort car jusqu'à présent il tournait bien sous nunux.

En attendant d'en acheter un autre, j'ai ressorti un vieux PC Pentium 4, j'y est placé le disque dur de celui qui m'a lâchement abandonné (un 7200rpm), j'y ai installé ArchLinux et ai monté sa mémoire jusqu'à 2Go (contre les 512Mo d'origine). Ma moitié utilise GNOME (en fallback). Quant à moi, ayant du mal avec les bloatware, et l'utilisation de xmonad n'étant pas idéal avec un écran 15" en 1024x768, je me suis mis à utiliser E17 (en version de dév).
Pour l'instant, j'en suis content. Ça tourne bien et même mieux que certains PC modernes sous Ubuntu.

Bref, ça dépend du vieux et de ce que tu mets dessus finalement.

Il existe des systèmes de fichiers adaptés aux SSD, dont on peut citer NilFS ou LogFS.

Au boulot, mon PC portable est équipé, par mes soins, d'un SSD depuis le 16 août 2010.
Je ne suis pas le seul, un collègue a équipé aussi son PC portable avec un SSD depuis au à peu près 2 ans.

Le retour : terrible ! Le PC démarre au quart de tour et les accès au système de fichiers rendent le système véloce comme je n'en ai jamais connu ; c'est là que l'on se rend compte de l'usage fréquent que l'on fait avec le système de fichier. Les desktops lourds comme KDE 4 ou GNOME paraissent bien légers ! (Bon d'accord, j'avoue, j'utilise XMonad comme window manager avec ces desktops). Mon usage est essentiellement du développement logiciel + bureautique.

Le SSD qui équipe mon PC portable est un SSD Intel. Celui du collègue est un Vertex. Pour l'instant, pas de problèmes constatés.

Intéressant. J'ignorais que CouchDB se basait sur un COW B-Tree.
C'est bizarre qu'ils n'en parlent pas ici http://guide.couchdb.org/draft/btree.html

Oui, tu fais bien d'être pinailleur parce que tu as raison. J'ai été effectivement un peu rapide en généralisant les arbres rouge et noir d'arbre équilibrés.

Oui, pour avoir travaillé dessus il y a quelques années, je suis sûr. Pour les propos de Valérie Aurora, il est commun d'appeler les arbres B+-Tree tout simplement B-Tree puisqu'ils sont sont aussi des B-Tree (une famille particulière des B-Tree très en vogue dans les systèmes de fichiers). Par contre, les propos de Rodeh me laissent perplexe; il s'est peut-être mélangé les pinceaux dans son écrit.

Il suffit aussi de vérifier sur wikipédia :
http://en.wikipedia.org/wiki/B-tree
http://en.wikipedia.org/wiki/B%2B_tree

Il y a aussi suffisamment d'articles sur le sujet sur le Web (deux articles en première page de Google):
http://www.bluerwhite.org/btree/
http://www.mec.ac.in/resources/notes/notes/ds/bplus.htm

J'adore tes dépêches patrick_g. Elles sont d'une qualité exemplaire.

Je voudrais ici juste corriger un détail. Les arbres B sont, en français, les arbres équilibrés (le B signifiant balanced); il en existe plusieurs types dont les plus connus sont les arbres rouges et noirs, et les arbres binaires. Dans les arbres équilibrés (B Tree), les feuilles ne sont pas reliées entre elles. Ce sont avec les B+ Tree que les feuilles sont reliées entre elles ; c'est ce qu'utilise par exemple ReiserFS. Il existe aussi les B* Tree qui sont des arbres qui optimisent la densité des nœuds internes (il fortifie l'équilibre de ces derniers).

Voilà c'est tout.

Ok, le portable est proposé avec un GNU/Linux dessus. Mais avec une résolution de 1366×768 pixels sur un 15,6", ça ne le fait pas.

Franchement, ce qui est important sur un portable est sa résolution et secondairement le processeur ou la carte graphique (même pour les gamers où, en dehors de la carte graphique, la résolution joue beaucoup aussi dans la qualité vidéo des jeux).
Alors, je préfère un portable avec un code 2 duo pourvu qu'il soit pourvu d'une dalle 15,6" d'au moins WSXGA+ (1680×1050 pixels).

Ce que je trouve dommage, justement, c'est la très peu diversité des résolutions des ordinateurs portables ; les 1366×768 pixels sur des 15,6" sont trop communs (et c'est l'horreur à travailler dessus sous GNU/Linux). Tout ça pour baisser les prix et proposer des portables (jetables) à environ 400-500€ !

Merci pour tes explications, je ne connaissais pas ces aspects techniques.

Je préfère ce genre d'explication à un simple moinssage d'un commentaire qui a eu le malheur de dire, et au conditionnel, ce qui est souvent pensé sur la conséquence de l'IPv6. Une explication est beaucoup plus constructif qu'un simple moinssage qui lui, à défaut de rebuter, n'apporte rien (si ce n'est un défouloir au moinsseur).

Il semblerait qu'avec l'IPv6, chacun pourra avoir une adresse IP concrète et non virtuelle comme avec le NAT. Donc, comme une adresse IPv6 pourra être associée à chaque PC ou, du moins, à chaque domicile (d'où pourquoi le NAT disparaitra pas de toute façon), alors il est plus facile de savoir d'où provient concrètement les paquets réseaux ... d'où le bonheur par exemple de l'HADOPI.

Je te souhaite une bonne migration et que celle-ci se déroule sur les rails ;-)

Combien de temps as tu estimé pour cette migration et avec quelle marge d'erreur ?
Sinon je serai très intéressé par ton retour d'expérience sur cette migration une fois celle-ci finie. J'attends donc avec impatience un journal là-dessus ;-)

Les premières conférences ont eu lieu à l'ENSIMAG. Or après les conférences, l'AlpesJUG aime bien rassembler les participants et le ou les speakers autour d'une collation pour partager, discuter et apprendre à se connaître. C'est un moment jugé important. Ceci n'était pas possible à l'ENSIMAG.

Je n'ai pas suivi l'affaire de près, mais il semblerait que suite à cela, après avoir fait le tour de plusieurs écoles ou universités, seule SUPINFO a marqué son intérêt pour prêter à l'AlpesJUG des salles pour les conférences et un lieu, d'ailleurs fort sympathique et approprié, pour organiser la collation.

Il est vrai que l'émergence des applications Web pour des tâches à l'origine dévolues à des applications natives coïncide avec le tout-connecté. Le tout-connecté afin de pouvoir accéder où que l'on soit à nos données personnelles ou partagées.
C'est ainsi que l'on a des applications Web dédiées à la retouche photo et qui, pour certaines, n'ont rien à envier à un photoshop dans ce domaine. Et il semble qu'elles sont de plus en plus utilisées, ceci malgré leur lenteur effective. Le cloud-computing est un pas en avant là dessus puisqu'il facilite l'externalisation des applications Web et donc aussi, indirectement, des données. Un jour viendra où le desktop et le navigateur Web ne fera plus qu'un.

Et ceci me gène : les données sont crées, voir gérées par nous, mais qui les contrôlent, qui les possèdent réellement ? A mon avis, plus du tout nous. Et lorsque ces données concernent des événements de notre vie (texte, photos, vidéos, autres), j'ai comme l'impression qu'on les laisser filer, se perdre ... Comme si elles ne nous appartenaient plus.

Je ne sais pas si les monades dans Haskell comme les IO sont de gros hacks. Ce que je suis sûr c'est qu'ils me permettent de programmer de façon plus propre en évitant de répartir le code à effet de bord un peu partout. J'ai trouvé que c'était plus facile à déboguer. Au regard de ceci, je trouve que tu exagères avec ton «La pureté en question, c'est pour se donner bonne conscience » ; c'est leur solution pour identifier et isoler les effets de bords afin de mieux les maîtriser et par conséquent garder un code a minima pur. On peut aimer ou non la soupe : dans ce cas, vaut mieux dire «je n'aime pas» que« c'est pas bon».

Pour l'implémentation en C, c'est plus que tester la validité d'un paramètre. C'est une implémentation du monad Maybe d'Haskell qui permet de simuler sans en avoir les problèmes d'effet de bord du null pointer. Le concept du null ou nil a été introduit par Hoare qui, par la suite, l'a regretté car celui-ci introduit des effets de bords indésirables, ce qui conduit au programmeur d'être sur la défensive. Dans Haskell, une variable peut être de type Maybe a, c'est à dire c'est soit une valeur de type a, soit il est rien (il n'est pas initialisé) ; on dit que c'est une variable ou valeur monadique. La monad Maybe permet de représenter et d'informer de la possibilité qu'une donnée peut être nulle. Ceci permet alors d'utiliser des fonctions sur ces types de données sans se faire avoir par surprise par un effet de bord indésirable (de toute façon le compilateur nous rappelle à l'ordre).

Pour l'implémentation en Perl, elle est longue et je ne l'ai que rapidement lu. Son objectif semble de modéliser en Perl les monads (structure qui implémente la notion de changement d'état et qui implique donc aussi une séquence nécessaire des opérations). Ici l'objectif est de prendre une valeur monadique (autrement dit une variable) et d'appliquer sur celle-ci des fonctions pour en ressortir une autre valeur monadique. (De cette valeur monadique, on peut en sortir une valeur pure qui peut donc ne plus être modifiée.) Avec bind, on peut appliquer une fonction pure sur des valeurs monadiques. En singularisant les effets de bords, on peut plus facilement les contrôler. Après, selon le langage, ça peut rendre le code lourd.

Ou encore l'écriture sur un écran ;-)
Les monads sont des structures qui enferment la notion d'effet de bord et pour lesquels un ensemble d'opérations est défini. On y trouve par exemple IO pour les entrées/sorties, X pour l'affichage graphique (dans XMonad), State pour la gestion des états, etc. Les monads obéissent en général à un certain nombre d'axiomes. Ceci permet de singulariser et d'identifier les effets de bords dans le but d'éviter de les repartir dans tout le code.
J'ai trouvé un lien que je pense intéressant pour un peu saisir le concept de monad :
http://www.haskell.org/haskellwiki/Monad

Comme l'a répondu kaouete, le concept de monads d'Haskell permet d'y répondre. Voir par exemple le window manager XMonad pour ça.

Toutefois, ta réponse est pertinente au sens où un des principes des langages fonctionnels est d'être libre d'effets de bords, principe qui a dérivé d'ailleurs vers plutôt la maîtrise des effets de bords (parce qu'il est impossible d'être sans effets de bords ; notre univers n'est il pas entropique ?). Au regard de ceci, on peut douter effectivement de la pertinence de l'usage d'un langage fonctionnel dans la programmation système. A côté de ça, sa maîtrise des effets de bord fait que la programmation fonctionnelle semble, à l'heure actuelle, plus propre et efficace à répondre aux problèmes du parallélisme. (Et le langage Go semble avoir été écrit aussi pour répondre aux défis que posent maintenant les architectures multi-cœurs.)

En fait, lorsque je posais cette question, j'avais plus en tête son modèle déclaratif qui apporte une approche intéressante dans la résolution des problèmes ; j'ai l'impression de plus en plus que les solutions à nos problèmes informatiques se traduisent plus facilement dans une approche fonctionnelle qu'impérative.

Ken Thomson n'est pas seulement un des auteurs d'Unix, il est le père fondateur d'Unix. De même, il est aussi un des auteurs de Plan9 et un des pères fondateurs de celui-ci. En effet, avec Plan9 il a voulu remettre à plat Unix en prenant en compte l'expérience et le recul sur la conception de ce système (son objectif était de pousser le "tout est fichier" à son point extrême). C'est dans ce contexte que certaines parties de Plan9 ont d'abord été prototypées en Pike avant d'être réécrit en C.

Maintenant, Rob Pike, le concepteur du langage du même nom, avec, apparemment, l'aide de Ken Thomson, envisage de remettre à plat le C au travers du langage Go. Espérons qu'il ait plus de succès qu'avec Plan9 qui méritait tout de même de réussir.

Toutefois, je me pose une question : est ce que de nos jours un langage de programmation système doit être impératif pour réussir ou être efficace ? Un langage fonctionnel ne pourrait il pas aussi être pertinent dans la programmation système ?

Juste en passant : pour les problèmes de retour en arrière (bouton back des navigateurs par exemple), cf. continuation. Un des premiers (voir le premier à ma connaissance) serveur d'appli web à supporter la continuation fut Seaside. Maintenant la plupart des frameworks le supporte avec plus ou moins de succès. (Celui de Seaside reste à mes yeux le plus aboutit.)

Sinon, dans nos projets, nous utilisons entre autre Grails et des projets Web java classiques avec Spring lorsque l'IHM doit être réalisé avec des techno comme Flex ou GWT.
J'apprécie bcp Grails pour la rapidité qu'il nous offre dans le dév d'applis et ceci grâce à l'intégration des différentes briques logicielles utilisées comme Spring, Hibernate, etc. mais aussi grâce en grande partie au langage Groovy lui-même.

Toutefois, j'ai vue le screencast de Play! et ce que j'ai vue me plait bcp. Dommage que l'on doit se taper du Java (j'aurais préféré du Groovy quant à faire) mais apparemment Play! rajoute plein de petites choses qui permet de faciliter l'utilisation des objets métier en Java. Dommage qu'il n'y ait pas (encore ?) d'intégration avec maven (la tendance est à ce que les projets dans l'entreprise soient gérés et mis à dispo via maven). En tout cas à suivre.

Le problème est plus simple que ça en fait.
La GC est là pour nettoyer la mémoire qui n'est plus référencée et ceci selon des algorithmes qui permettent de le faire de façon optimale. Et le terme plus référencée a une grande importance : le développeur doit toujours se préoccuper de la mémoire allouée ; autrement dit déférencer les objets inutilisés. Ce qui est très important dès que l'on manipule des collections/conteneurs.

Les problèmes de mémoires que l'on observe souvent avec les applis sur VM proviennent d'oublis de déférencement de la part du développeur.