chimrod a écrit 1111 commentaires

Cet achat me questionne sur les données personnelles.

On sait tous que nos données personnelles ne nous appartiennent plus dès lors qu'elles sont communiquées à un site tiers. Or, on peut avoir confiance à un site le lundi, on ne sait pas qui en sera le propriétaire le mardi. Et si je n'ai pas confiance en ce futur acquéreur, je n'ai pas d'autre choix que de fermer mon compte, tout en sachant que les données qu'il a récupéré son maintenant à sa disposition. (et ces données vont rester factuelles à vie : l'historique d'une personne ne va pas changer, il va juste perdre de sa valeur avec le temps s'il n'est pas actualisé)

Bien évidemment, il n'est pas possible d'obtenir une telle base d'utilisateur avec des outils complètement décentralisés sur lesquels nous aurions complètement la main.

Par comparaison, lors du rachat de Virgin par la Fnac, il y avait eu un délai durant lesquels les clients pouvaient se manifester s'ils ne souhaitaient pas que leur données ne soient collectées par la fnac.

Personnellement cette concentration m'inquiète : la durée de vie de mes données va probablement dépasser la durée de vie des sites qui les hébergent. Que va-t-il se passer quand l'entreprise qui les possède sera vendu ? Est-ce que le risque de les voir utilisée contre soi vaut le risque de se couper de ses amis, des recruteurs, de [insérer la catégorie ici] ?

faut voir le bon côté des choses : Linux a enfin atteint la maturité pour le desktop !

Merci beaucoup pour ce journal, qui aurait je pense toute sa place dans les dépêches !

Le social engineering est un moyen de contourner la serrure. Les exemples donnés ci-dessus sont à lire dans ce sens (se faire ouvrir la porte de manière complètement naturelle)

Tu devrais poser la question dans un nouveau thread. Tu auras plus de réponses et ça permettra de séparer ce qui relève de tes questions, et celles des questions de TP.

Pour ne pas répéter un très bon commentaire, je t'invite à un peu de lecture qui répond en partie à ta question.

Aussi nul que cvs, mais sans beaucoup de ses bugs.

En fait, le gros problème de CVS (et c'est une telle limitation que l'on peut difficilement l'imaginer aujourd'hui), c'est qu'il ne tient pas compte de l'atomicité d'un commit. Chaque fichier est versionné, mais il n'est pas possible de retrouver l'ensemble des fichiers modifié ensemble à l'intérieur d'un même commit. (on peut retomber sur ces pattes en vérifiant l'heure et l'auteur, mais ça ne garantie pas le résultat).

SVN apportait cette idée de transaction, qui permet de retrouver par un numéro de commit l'ensemble des sources affectées. Et rien que ça, c'était déjà une révolution !

Après un long week-end, je découvre que la conversation est parti sur des sujets que je ne maîtrise pas, et ne m'y aventurerai pas davantage.

Par contre, si tu souhaites que nous continuions nos échanges, tu peux me contacter à cette adresse : yoo3cie5roi5woht@chimrod.com

Bonjour, cette information me parraît être importante, toutefois sans aucune source pour étayer ton propos, cela relève juste de la rumeur.

Peux-tu nous donner plus d'information ?

En fait, le gain se fait surtout à l'usage. C'est ce que démontre Chris Okasaki dans son ouvrage sur les structures de données fonctionnelles. (Une implémentation de ses exemples est disponible pour OCaml).

Tu avais noté mon commentaire dans un coin à l'époque (qui n'est pas si lointaine d'ailleurs…) ou tu l'as recherché aujourd'hui ? :)

Ce dont je parlais dans ce commentaire ne correspond pas à un besoin perso, mais à des idées que j'avais eu suite à une formation d'entreprise SOA (somme toute assez barbante…). Mais comme tu me reprends sur ce qui pourrait m'être utile, je me permet de compléter ma pensée.

Le problème est que l'on enseigne souvent les choses à l'envers. Plutôt que d'expliquer un langage à travers un cadre théorique, l'enseignement consiste à se focaliser sur le langage lui même. Dans le cadre du TP, (et je peux le comprendre au vu du nombre d'heure consacrées dans le semestre), on a passé plus de temps à inférer le typage d'expressions sur des feuilles de papiers que de se poser la question sur ce qu'est un programme informatique. L'idée est bonne, mais à partir du moment où elle n'est pas expliquée (ni comprise), cela devient juste un cas d'école qui ne va pas plus loin que ça.

Dans le même ordre d'idée, j'aimerai bien qu'on explique l'intérêt des tests unitaires aux jeunes développeurs en leur mettant un bouquin de Karl Popper dans les mains plutôt que d'expliquer le fonctionnement de JUnit…

Malheureusement, je n'ai pas encore trouvé d'approche qui combinerait à la fois cette vision théorique et ses implications ; mais ma quête n'est pas finie.

Au cnam de Paris on a travaillé avec OCaml 3

Le tp consistait à écrire un transpilateur (scala -> ocaml en ocaml), ce qui semble être courant dans les TP de langage fonctionnel. Ça donne l'impression que le langage est réservé à ces usages, ce qui en bloque doublement l'accès :

• un paradigme fonctionnel vu en quelques séances et pas assez approfondi
• une mise en pratique qui est en fait un exemple théorique et qui n'appuie pas assez sur la programmation fonctionnelle moderne (le TP permet surtout d'apprendre à utiliser Printf)

Beaucoup d'étudiant étaient perdus, et plutôt que de leur donner envie d'en savoir davantage, je pense qu'ils garderont en souvenir un langage compliqué. C'est dommage, car les personnes qui sont formées aujourd'hui sont celles qui décideront des langages dominants pendant les 15 (20 ?) prochaines années.

Attention, SailFishOS est très bien sur le téléphone de Jolla, car Jolla a payé pour avoir la compatibilité android. Les autres ports vers les différents téléphones n'ont pas forcément accès au catalogue android, ce qui limite fortement les applications disponibles ! (par exemple sur le fairphone2)

Vous vous êtes relu au moins ?

Les candidatures … devront être envoyées avant le 22/04/2016

Posté par BRASSIER le 22/04/16

Il travaille au panama ?

Ça date des années 80 ??? On me l'a offert 15 ans plus tard et j'avais vraiment aimé cette bd. Tu viens de me faire prendre un coup de vieux là…

Tu vas me dire que faire Ctrl + D est plus compliqué que Mod4 + C ?

Reprenons ce que fait l'itérateur d'un point de vue fonctionnel.

Tu seras d'accord pour dire qu'il s'agit d'accéder élément par élément à une structure pour y appliquer un traitement. On peut le reformuler en disant qu'il s'agit d'appliquer un traitement sur l'ensemble des éléments de manière successive.

Dans ce cas, il n'est pas nécessaire d'avoir une fonction next qui serait typée ainsi :

val next: 'a t -> unit -> 'a (* Récupère l'élément suivant, on suppose que la structure garde en mémoire ce qui a déjà été parcouru *)

mais plutôt:

val iter: ('a -> unit) -> 'a -> unit (* [iter f tree] applique f a chaque élément du graphe (on suppose que l'on s'intéresse aux effets de bord)*)

val fold: ('a -> 'b -> 'a) -> 'a -> 'b t -> 'a (* unifie le graphe sur une valeur unique de type 'a *)

Cela ne limite pas du tout le traitement de la structure, c'est même au contraire une manière commune de traiter les données.

Exact.

Mais pour suivre le raisonnement jusqu'au bout, une fois que tu a utilisé les fonctions standards qui te renvoie une chaîne différente, tu n'as plus la garantie que la nouvelle chaîne est toujours valide.

Autant que cette contrainte soit rendue explicite.

J'imagine plutôt que le type trié + validé comme un type fantôme, c'est à dire que ta fonction de tri peut avoir la signature suivante :

type 'a sorted

val sort: string -> string sorted

Le type indique juste que le texte est trié est validé, mais il est tout à fait possible d'en extraire la chaîne donnée :

val extract: 'a sorted -> 'a

par contre les fonctions qui nécessitent d'avoir en entrée un type trié + validé nécessitent juste de prendre un type « 'a sorted » en paramètre.

C'est ce qui est utilisé dans la librairie js_of_ocaml : tous les types utilisé dans le code javascript sont de type Js.t, ce qui permet de séparer le type des données qui sont utilisées dans le code ocaml, et celles qui sont issues/destinée au code javascript.

Edit: Bon, c'est ça d'arriver après la tempête, cela a expliqué plus bas…

Sinon ça pourri la vie des gens…

C'est peut être ça, la prochaine de la révolution copernicienne :

• Nous savions que l'univers n'est pas créé pour notre plaisir et que nous n'en sommes pas au centre.
• Nous prenons que nous ne sommes pas maître de la nature et que nous pouvons détruire notre environnement si nous ne faisons pas attention.
• Maintenant nous découvrons que nous pouvons créer des outils qui réfléchissent mieux que nous.

Au final, nous sommes libre de vivre maintenant !

Ça dépend dans quel contexte tu te places. Dans un langage qui t'impose l'usage de classes et d'instances, alors utiliser des objets n'est pas un choix de conception. Au contraire, si tu as le choix d'utiliser un objet, un foncteur, ou une monade, alors on peut penser qu'opter pour l'un au l'autre relève d'un patron de conception.

Je rajouterai aussi que la monade ne s'applique pas vraiment dans le monde objet. C'est un design pattern de type (au sens de la théorie des types), et non pas du monde objet. Tout comme le visiteur n'a pas vraiment de sens dans un univers fonctionnel, le type Folddable n'a pas de sens dans le monde objet. Ça n'est pas pour rien que l'on parle de paradigme de programmations différents.

C'est pas possible d'écrire plutôt ?

f = (+)

Je ne connais pas elm, mais ce que tu décris correspond tout à fait au problème auquel répond les monades. Ça permet de contenir un environnement et d'appliquer une fonction qui modifie l'environnement.

Il existe une grande littérature sur ce sujet, et je ne vais pas paraphraser ce que d'autres exprimeront mieux que moi, aussi je te renvoie vers la langage dans lequel les monades sont reines.