 Le talk de la journée, nous aurons deux speakers, Nicole Raouche et Michael Speber, Mickael et le CRO de Active Group, et Nicole est un développeur. Elle organise des conférences sur le développement. Bonjour. Ah, c'est allumé. Oui, ça marche, excellent. Alors, supprimer du code. Avant de dire adieu, il faudrait peut-être qu'on se demande ce que c'est vraiment. Peut-être qu'on aura les slides. Voilà. Donc, déjà, il faudrait qu'on dise que c'est le code qui brise le cœur. Donc, on vous a montré quelque chose pour votre distraction. Donc, ça, c'est du code que j'ai trouvé dans un tutoriel Eclipse. Si vous connaissez un peu Eclipse. J'ai aucune idée de ce que ça fait, cette adapteur factory. Et donc, ensuite, on récupère un adapteur et il se passe plein de choses. Mais en fait, qu'est-ce que ça fait, ça? Donc, ça pourrait être cet exemple tout doux, un peu standard. Mais peut-être que c'est juste parce que c'est Eclipse et que dans Eclipse, tout est un adapteur. Je ne sais pas trop. Donc, je pensais bien que tu dirais quelque chose et donc, je vais montrer un autre exemple. Donc, ça, c'est d'un projet open source. Et donc, ça, c'est un initiateur de requêtes natives, d'interprèteurs de requêtes natives. Et c'est aussi un initiateur de générateur de services de sessions. Mais donc, on initialise un service, puis on a un autre initialisateur de services. Et ensuite, on peut avoir ce get service initiated. Ok. D'accord. Mais ça, c'est juste des enfants qui font de l'open source, ça veut dire. Qu'est-ce que tu attendrais d'un truc comme ça? Donc, moi, je t'ai rapporté à un exemple professionnel. Donc, voilà, exemple professionnel. Donc, ça, c'est un système qui fait des espèces de requêtes. Et on dirait qu'il y a de la traduction un peu bizarre entre l'allemand et le français. Et donc, évidemment, dans cette définition de classer plus et plus, il vérifie quelque chose et puis il crée un objet. Donc, c'est de l'orienter objet. Donc, on y va et on appelle des méthodes. Donc, ça, c'est juste le constructeur. Ça, c'est pas la mauvaise partie. Donc, la partie un peu moche, c'est quand vous avez une méthode qui vient vraiment quelque chose. Donc, ça ressemble à ça. Soit ça appelle full text research. Vous voyez qu'il y a des lignes qui sont commentées. Et personne n'a laissé de commentaire pourquoi ces commentés. Et vous pouvez voir que ce code est vraiment fragile. Et si vous voulez maintenir ce code, vous devez être sûr de vérifier cette variable avant de faire quoi que ce soit. Donc, le fait que quelqu'un utilise un langage orienté objet ne veut pas forcément dire que l'orienté objet, il sait ce que c'est. Donc, ça donne ce genre de programme à la con. Donc, ils ont utilisé ça et puis ils sont retrouvés avec ça. Est-ce que des programmeurs qui ont un peu l'habitude peuvent produire du code à la con ? Je pense que j'ai un autre exemple un peu mieux ici. Maintenant, un exemple vraiment orienté objet. Donc, ça, c'est de la finance. Ici, on a des options, des options d'appel. Et donc, les financiers veulent parler de ces options. Mais il y a tellement de types différents d'options qui ne peuvent pas en parler individuellement. Donc, ils veulent les regrouper. Et donc, ils les mettent ensemble dans ce qu'ils appellent un panier. Et ici, on voit un exemple de panier. Et puis, il y a Google et Facebook. C'est à peu près la même chose, donc on les met ensemble. Et donc, on peut voir les propriétés de ce panier, toutes les options. Par exemple, ici, ils ont implémenté ces données de marché. Donc, ça, c'est du code orienté objet standard. Il y a toutes et une classe. Et donc là-dedans, on a deux méthodes. Ça, c'est aussi standard. Il y a une classe et puis il y a des méthodes dedans. Et donc, la première méthode récupère le prix de l'action. Donc, ces actions ont des numéros dans le monde réel. Donc, ils les numérent ici. Et je ne sais pas pourquoi ça s'appelle comme ça, mais ça s'appelle Sikovam. C'est peut-être un nom français, je ne sais pas trop. En fait, ça, c'est la volatilité. C'est la date à laquelle l'option expire. Donc, une option, c'est définie par la propriété sous-jacente. Par la date à laquelle ça doit être fourni. Et donc, on a le numéro de l'option. Ensuite, il y a la maturité. Donc, c'est un point en temps. On peut très bien utiliser un nombre à virgule flottant, double précision pour ça. Et ensuite, on a un prix. Et donc, il y a beaucoup de gens qui savent sûrement que gérer de l'argent avec des nombres à virgule flottantes, c'est pas une bonne idée, mais bon, c'est assez fréquent dans les banques. Donc, ça y est. Et ensuite, ce qu'ils veulent vraiment faire, ils ne veulent pas seulement voir le monde comme il est, ils veulent analyser et voir ce qui pourrait se passer si quelque chose se passait. Ils voudraient jouer un peu à Essie, quelque chose. Et donc, là, ils veulent récupérer le prix courant et essayer de le changer. Qu'est-ce qu'il se passerait si le prix était différent? Et donc, si on veut modifier quelque chose dans un code de orienté-objet, il faut écrire une classe dérivée. Et donc, là, on écrit une classe dérivée qui s'appelle Spotshifted Market Data. Donc, données de marché modifiées. Et donc, il appelle le GetSpot de la classe par an et ensuite, il le multiplie par un facteur. Pour l'instant, ça va. Et donc, ensuite, ils ne veulent pas seulement multiplier par un facteur, mais ils veulent faire d'autres modifications. Et ils voudraient faire toutes ces modifications sans avoir besoin de recompiler. Donc, ils voudraient avoir un code qui soit dynamique et configurable de manière dynamique. Et si vous regardez comment on fait ça dans la littérature orienté-objet, on tombe sur le modèle décorateur. Donc, ce modèle permet de modifier dynamiquement le code. On a un composant. Et ensuite, on en dérive un décorateur. Qui est un délégué vers quelque chose d'autre qu'on veut rajouter. Et donc, c'est comme ça qu'ils ont implémenté le délégué. Donc, ils ont écrit le décorateur comme une classe dérivée. Ensuite, à l'intérieur, il y a le vrai objet. Et pour la méthode GetSpot, en fait, ils appellent simplement la méthode GetSpot de l'objet sous la sainte. Maintenant, si on revient au panier, sur lesquels j'ai commencé. Donc, ce qu'ils font dans la modification dérivée, ils multiplient ça par le facteur. Et maintenant, dans le panier, ils récupèrent un tas d'options. Et maintenant, ils veulent calculer ça pour toutes les options. Et donc, ils vont là-dedans récursivement. C'est un peu difficile à voir. Mais ils vont là-dedans récursivement. Et ils font cette opération modifiée pour chacun d'entre eux. Et à cause de l'évaluation tardive, ils n'arrêtent pas d'aller à la première opération. Et donc, ils appliquent ce facteur à répétition. C'est assez difficile à voir au premier abord. Et donc, ça demande un peu de travail. On ne s'attendait pas forcément à ce comportement. Et donc, ils ont trouvé ça parce que les valeurs n'étaient pas correctes. Et donc, ce qu'ils ont fait, c'est qu'ils ont compensé. Et donc, par exemple, ici, c'est la partie la plus intéressante. Est-ce que la première market data dérive de la deuxième? Donc, ils vérifient si la chaîne s'est effectivement produite et si c'est le cas, ils font quelque chose. Ouais, ça, c'est du code de production. Et ça, c'est toujours en opération. Et probablement que cette méthode maintenant fait des centaines de lignes parce qu'il y a tellement de cas de bord qu'ils ont dû traiter. Ouais. Donc, c'est assez évident qu'ils n'auraient pas dû faire du C++ en tes objets pour faire ça. Est-ce que tu as une meilleure solution, du coup? Oui, j'ai des slides. Les gens auraient dû utiliser de la programmation fonctionnelle. Donc, je suis un mec de programmation fonctionnelle. Donc, les avantages de la programmation fonctionnelle, c'est que vous pouvez avoir des données immuables. Vous n'avez pas de couplage. Vous n'avez pas des effets de bord partout. C'est assez proche des mathématiques. Et on peut avoir des vérifications. Ça fait un peu peur. Vous pouvez avoir ces trucs superbes, les catamorphismes, les bifoncteurs, les monades, les profondeurs monadiques, tout ça. J'ai utilisé ça récemment, c'est trop bien. Les flèches de Clice Lee et tout ça. Ça résout tous ces problèmes-là. Pourquoi vous réveillez? Je me serais attendu à ce que tu dirais quelque chose comme ça. Est-ce que tu as déjà considéré que ta façon d'aborder le problème, en fait, c'est la mauvaise? Et vous, de IT Tech, vous êtes dans vos cabines avec vos capues sur la tête et vous êtes assis et vous codez sans arrêt. Voilà, le problème résolu. Il a enlevé son souhait à capuche. Et en fait, balancer de la technologie sur le problème, c'est pas vraiment la solution. C'est un peu une partie du problème. Mais on produit de la technologie. Est-ce que t'es allé dans ce congrès? Comment tu fais tout ça? Comment pas en étant assis dans un coin et en écrivant du code? Est-ce que t'as déjà considéré qu'il y a autre chose? Il n'y a pas que de la tech ici? Donc hier, j'ai vu ce robot qui marche en cercle et qui disait j'ai besoin de nouveaux codes venez me parler. Donc il faut qu'on se parle. C'est pas que de la tech. C'est super cool. Est-ce que t'as un manuel pour ça? Oui, il y a effectivement des modèles pour discuter, pour des gens comme toi. Ok, vas-y. Vas-y, éduque-moi. Instruis-moi. Il y a plein d'approches aux fils des ans. Par exemple, il y a le développement logiciel agile. Donc, par exemple, les individuels et les interactions sont favorisés par-dessus les processus et les outils. Vas-y, on va parler et on va trouver des choses. Mais il faut du logiciel qui marche. Oui, c'est un sur quatre. Parce qu'évidemment, on veut aussi du logiciel qui fonctionne. C'est normal. Juste parler ça ne sert à rien non plus. Vous étiez à cette conférence et vous avez certainement parlé à quelqu'un. Vous avez peut-être vu la keynote. Moi, j'ai vu la keynote. C'est quelqu'un qui a parlé de ce qui marchait et de quel étaient les problèmes dans le développement logiciel. C'était une entreprise qui fait du agile. J'imagine qu'ils communiquent tout le temps. Quand on regarde où est-ce qu'ils passent leurs temps, où font leurs efforts, où il y a 53 % sur la maintenance et la complexité et pas sur les nouvelles fonctionnalités et ni sur ce truc professionnalisation. Je ne sais même pas ce que c'est. Maintenant, je propose qu'on retourne aux problèmes techniques. On a déjà vu ça avec le données de marché. Mais je pense que tout ça, toute cette maintenance et cette complexité c'est fait parce que on est dans un monde qui existe en plein d'objets. Tout le monde saute sur ce truc orienté objet et avec quoi ils se retrouvent, c'est un truc qui ressemble à ça. Ça ne sert pas à grand-chose. Mais je voudrais expliquer ça d'une façon un peu différente. La programmation orienté objet normal vous ne pouvez pas rire avant de comprendre le problème. Le problème c'est ça. Au coeur de la programmation orienté objet, il y a cette programmation impérative. Ces objets qu'on a vu tout à l'heure, ils ont un état encapsulé. Il y a un état qui est à l'intérieur des objets et le monde progresse via des messages. Ils ont modifié l'état en encapsulé. Ce qui se passe c'est que l'orienté objet c'était d'abord fait pour faire des simulations du monde réel. Le problème c'est que le monde réel ne fonctionne pas comme ça. Ce n'est pas des objets qui s'envoient des messages. Un exemple c'est cet éléphant. Ici on a un éléphant qui vient de la jungle qui rentre dans une pièce. Le modèle pour ça c'est l'éléphant a un objet. La jungle a un objet. La pièce a un objet. Peut-être même que l'entrée a un objet. Il y a une succession de passages de messages qui essaient de reproduire cette séquence. Donc l'éléphant quitte la jungle et l'éléphant entre dans la pièce. Le problème c'est que le fait que l'éléphant sort de la jungle et qui rentre dans la pièce c'est un seul événement. Ce n'est pas juste des entités séparées qui s'échangent des messages mais il y a des choses qui sont couplées là-dedans. Un modèle un peu meilleur de comment penser ça devrait être un peu plus proche de la façon dont on perçoit les choses. Par exemple si on voyait un match de foot il y a plein d'objets que vous voyez. Vous voyez 22 joueurs vous voyez une balle, vous voyez des arbitres, vous voyez du public et ils changent toujours leur leur état interne si c'est le modèle que vous utilisez. Pour savoir ce qui se passe sur le terrain de foot vous devez observer tout ça. Qu'est ce que c'est le modèle orienté objet ? C'est le modèle qu'on appelle observateur. On dit si quelque chose se passe envoyez-moi un message. Si la balle bouge on reçoit un message si les joueurs bougent on reçoit un message etc. Et donc à chaque fois quand vous quittez le stade vous dites je ne suis plus intéressé le monde ne fonctionne pas comme ça. Et le problème c'est que dans un certain ordre et vu que tous ces objets bougent on risque d'observer des incohérences tout le temps. La même chose que quand on a vu avec l'éléphant, si vous vous souvenez il y avait un état incohérent entre au milieu où l'éléphant après le premier pas l'éléphant est nulle part puisqu'il a quitté la jungle mais il n'a pas encore rentré dans la pièce. Et donc la même chose est vrai quand on a plein d'objets. Donc on ne voit jamais une personne qui se lève d'un côté et qui apparaît dans une pièce de l'autre côté etc. Et donc et en fait ce qui se passe c'est que l'appareil perspective crée des des instantanées qui sont cohérents et ensuite on les analyse. Et donc on se souvient aussi de ce qui était dans le passé et ça c'est quelque chose que l'orienté objet ne peut pas vraiment faire ça. Donc il y a un certain nombre de choses qui sont gênantes dans l'orienté objet et c'est ce qui donne ce code qui brise le coeur. Et donc ça me rappelle quelque chose d'intéressant et ça c'est en interface utilisateur c'est ce qu'on appelle le modèle MVC donc modèle vu contrôleur et vous avez vu que tout ça ça va en cercle vous pouvez aller dans n'importe quelle direction vous pouvez faire ce que vous voulez et vous pouvez aller de n'importe où à n'importe où. Et donc ça donne un problème assez évident qui est si vous avez des changements sur le modèle et des changements sur la vue dans l'idéal qui correspond et peut-être pas en fait. Et qu'est-ce que vous faites à partir de là ? Et donc ce à quoi vous arrivez si vous faites ça suffisamment et si vous n'êtes pas vraiment attentif vous tombez sur ça. Donc tous les programmes MVC ressemblaient à ça. Et donc ça c'est ce dont Allen Kay parlait à l'époque. Donc c'est une citation de 1996 mais ça c'est la date du papier et je pense que la vraie citation est plus ancienne que ça. Et donc il disait la programmation européenne de l'objet avait beaucoup de bonnes motivations donc on a montré ici. Mais en fait il faut qu'on nous repasse ce modèle à la fin de mieux. Mais ça ça ne s'est jamais passé. Non je pense pas. Donc actuellement si vous regardez comment la programmation orientée objet fonctionne, c'est toujours une question d'encapsulation. Donc ça c'est le premier exemple que j'ai trouvé quand j'ai cherché pour l'orientée objet. C'est un exemple d'étudiant. Donc il y a plein d'attributs et des méthodes. Donc ce que je préfère là-dedans c'est que vous avez l'étudiant et vous pouvez changer sa moyenne. Si vous n'êtes pas content de la moyenne de votre enfant, bah vous prenez et vous changez sa moyenne, c'est simple. Et donc je répète évidemment les gens auraient dû utiliser de la programmation fonctionnelle. Donc il y a plus de productivité, il y a moins de bug. On peut faire du test sur des propriétés, etc. Donc le test c'est plus simple. Il n'y a pas besoin de couplage, il n'y a pas besoin de dépendance, tout ça. J'ai pas dit monade dans cette liste. Donc vous avez tous ces avantages concrets en faisant de la programmation fonctionnelle et c'est ça que les gens devraient faire. Est-ce que est-ce que tu te souviens de Fred Brooks qui disait qu'il n'y a pas de balles en argent, il n'y a pas de panacé mais Fred Brooks c'est un vieux mec en fait. Et qu'est-ce qu'il en est de toi ? Je pense que je suis vieux aussi, t'as raison. Il a dit ça mais il est vieux. Je te montre un exemple pourquoi c'est pas vrai. Donc dans les années 90 il y a une étude menée par la navie américaine donc il y avait un problème qui était de déterminer la région d'influence de bateaux de guerre et donc ils ont fait du code dans différents langages et donc ils ont donné ça aussi à des gens qui faisaient de la programmation fonctionnelle en particulier à Askel qui était encore assez jeune à ce moment-là et donc la solution à Askel elle est vraiment beaucoup plus courte que la solution en C++ par exemple, elle est moins de 10 fois plus longue plus courte, pardon et donc j'avaye pas sur cette liste mais je crois que c'était un facteur 3 ou 10 plus court à Askel. Ce qu'on voit aussi c'est qu'il y a 2 solutions à Askel et donc peut-être qu'ils ont séparé le code pour que les chiffres soient meilleurs en fait il y avait un expert à Askel à qui on a demandé de faire une solution et ils ont aussi donné le problème à un étudiant à Askel qui a commencé à apprendre quelques semaines plus tôt et donc il y en a un qui a pris 8h et l'autre qui a pris 10h et en fait celui qui a pris 8h c'est l'étudiant alors que l'expert a essayé d'appliquer plein de techniques super cool et plein de choses dedans alors que l'étudiant il a juste appliqué ce qu'il a appris. Donc ça c'est pas une preuve de la supériorité de la programmation fonctionnelle mais je sais pas ce que c'est mais ça c'est Yale donc il y a un certain bout d'instruction fixe et le code fait que ces instructions et est-ce que vous avez vraiment rencontré ce genre de situation ou vous récupérez seulement une liste d'instructions fixées par votre client et ça change jamais, il change jamais d'avis il dit jamais j'ai oublié quelque chose ça a déjà arrivé toi non moi j'ai jamais expérimenté ça laisse-moi réfléchir peut-être que tu peux continuer mais en continuant à propos de l'éléphant donc parler l'un à l'autre chacun a des idées on est revenu à ce truc agile tout le monde est différent, a des idées différentes et chacun décrit les choses différemment et ce qu'il faut faire c'est en discuter tous ensemble coder un peu, discuter discuter, coder et donc ça c'est effectivement quelque chose d'agile c'est pas un scrum c'est pas être debout en cercle tous les jours détends-toi moi j'aime bien communiquer avec du code mais oui tu peux faire ça par exemple ici c'était une usine de semi-conducteur donc vraiment des vraies choses et donc quand on a commencé ça je pensais oui, les semi-conducteurs vous avez une grosse machine vous prenez un morceau de silicium et puis vous y allez, tchac, vous actionnez le levier et vous avez un microprocesseur mais en fait ça marche pas comme ça une des raisons c'est que les puces modernes ont plein de couches et il y a plein d'étapes de production qui sont nécessaires pour faire un seul couche et donc ces machines sont tellement cher qu'on ne peut pas faire simplement une ligne d'assemblage et il y a plein de choses qui cassent donc ça a pas de sens d'avoir juste une ligne d'assemblage et donc c'est important c'est que chaque puce, chaque substrat va à travers le processus et donc il peut y avoir une centaine d'étapes par exemple pour un microprocesseur donc il faut représenter quelque chose comme une route qui est une suite d'opération donc ici c'est un exemple de code ASCAL ASCAL c'est cool parce que le code est tellement court que ça passe sur des slides et si il y a quelque chose qui n'est pas clair avec ce code, je vous invite à m'interrompre et à demander donc ici vous pouvez lire cette décoration au début qui dit donner opération qui est juste simplifié qui décrit ce que c'est une opération donc vous pouvez lire la barre verticale comme un OU donc une opération c'est soit un track IN donc c'est ce qu'on met la pièce dans la machine on fait quelque chose dans la machine et track OUT c'est on sort la pièce de la machine et ensuite on a une route qui est juste une séquence d'opération et c'est crochet que vous voyez en fait ça veut dire une liste donc ce que ça dit c'est une liste d'opération et donc ensuite vous avez un exemple de route donc je dis route 1 c'est la liste de toutes ces opérations donc on met le substrat dans la machine on fait un processus dessus on fait un autre processus et ensuite on le sort ça va bien pour tout le monde tout le monde est encore réveillé ça va donc n'ayez pas peur de demander une chose que vous pouvez faire c'est quand vous avez des types de données vous pouvez définir des fonctions qui décrivent un aspect de ce qui se passe dans cette usine donc ce qui se passe c'est que vous avez besoin d'exécuter la prochaine opération dans le processus donc pour ça on fait une fonction qui s'appelle route head donc la tête de la route et donc il faut écrire une signature de type pour communiquer donc on dit on prend une route et on sort une opération et donc on peut écrire des équations pour décrire ce que cette fonction ferait sur différents routes et donc il y a deux types de listes il y a un type de liste qui est la liste vide et l'autre type de liste c'est une liste qui a ce qu'on appelle une tête donc un premier élément et le reste de la liste et donc vu qu'il y a deux types de listes on écrit deux équations donc on écrit route head de quelque chose et quelque chose d'autre et donc la première équation c'est pour la liste vide c'est pour ça que vous avez des crochets avec rien au milieu et la deuxième c'est pour une liste non vide avec quelque chose dans la liste et puis le reste et donc ça c'est ce qu'on appelle du pattern matching on regarde ce modèle si ça correspond à notre objet on récupère les données donc le deuxième le deuxième exemple enfin la deuxième ligne est assez claire si on veut la tête d'une liste où il y a un premier élément on renvoie ce premier élément c'est tout et par contre la première liste c'est qu'est ce qu'on fait avec la liste vide la liste vide elle n'a pas de premier élément par définition donc donc dans le deuxième exemple de ton magnifique Askel tu sais déjà pas ce que tu veux faire toi tu parles un expert on va discuter avec cet expert et on dit qu'est ce que c'est la première opération d'une route vide il n'y a pas vraiment d'opération on sait pas on peut faire un type de données disant que quelque chose peut être là ou pas est ce qu'il y a des programmeurs Askel dans la salle oui ok donc ça c'est le type Maybe de Askel mais là je vais faire un je vais faire un type à la main option A qui veut dire c'est un type ou on peut avoir deux choses soit vous avez un objet de type SOM et vous avez un objet depuis type NON donc rien n'importe quoi peut être rien donc ça veut dire on peut être de type option A mais il peut rien avoir à l'intérieur option A c'est le type de cet objet particulier et donc l'autre constructeur oui il y a quelque chose donc ce constructeur a besoin d'un objet de type A et renvoie un objet de type option A et donc en fait ce que tu dis c'est que c'est que ça emballe cet objet en fait mais oui si du point de vue d'un programmeur peut-être F-sharp ou Java même on peut voir ça comme ça et même en Java ça existe maintenant mais maintenant ça veut dire qu'on peut changer notre fonction route head et donc au lieu de dire c'est route flash opération on va dire que notre fonction c'est route flash option opération donc ça peut paraître trivial mais en fait on peut dire que route head appliqué à la liste vide c'est rien donc il n'y a pas de premier élément de la route head et par contre si on a une opération on dit c'est quelque chose donc somme et on donne une opération et donc route head de R1 ça donne somme track in si on vous rappelait l'exemple que je citerais avant donc parfois on n'a pas besoin on n'a pas uniquement besoin de savoir quelle est la première opération mais on a besoin de savoir ce qui se passe après donc pareil on dit que la route vide il n'y a rien qui suit parce qu'elle est vide et donc on peut utiliser une opération route advance donc avancer sur la route qui renvoie qui renvoie en fait un couple qui est la première opération et la suite et donc il y a une option parce que ça existe que dans certains cas et donc si on prend notre route R1 on peut la séparer en deux donc d'abord il y a le track in et la liste de ce qui reste donc la route qui est faite avec les opérations qui restent tout va bien est-ce que quelqu'un a une question une question ok n'hésitez pas à demander donc c'est assez facile maintenant on peut créer à nouveau deux équations puisque c'est une liste et les listes ont besoin de deux équations route advance de la liste vide c'est rien route advance d'une opération et du reste on renvoie simplement un couple opération et reste vu que c'est ce qui nous intéresse donc ça c'est du code très simple et très court qui communique ce que sont les routes oui je vois et si je me souviens bien tu as dit tu mets le substrat dans la machine et puis elle fait un processus dessus et donc ces processus peuvent être des réactions chimiques ça pourrait arriver dans un certain amount de temps dans une certaine durée et tout ça on pourrait modéliser quelque chose comme ça donc je regardais un peu à ta partie des slides donc ce qu'on pourrait faire c'est qu'on pourrait avoir un modèle comme ça avec trois étapes qui ont besoin de se passer en même temps pendant un certain temps donc donc oui donc là c'est une condition où les choses pourraient mal se passer donc si vous finissez pas dans le temps d'un parti vous pourriez avoir besoin de jeter votre wafer et tout ça donc peut-être que je peux essayer d'implémenter ça dans ton code existant cool donc on va essayer ce dont on a besoin on a cette route qui est une liste d'éléments et ensuite on a des opérations et maintenant il faut une autre représentation pour l'élément d'une route on va la payer route cutie zone pour une durée en fait on a une durée que l'opération doit prendre au maximum cette séquence d'opération et ensuite on a la liste d'opération qu'on a vu précédemment et puis ensuite ce que ça nous donne c'est un élément de route donc on peut combiner des éléments de route mettre le wafer dans la machine ça on s'en fiche combien de temps ça prend peut-être que ça bloque la machine mais à part ça il n'y a pas de problème mais par contre si on fait un processus chimique on a potentiellement besoin de restreindre le temps que ça prend c'est correct et donc ensuite si on regarde notre exemple ça c'est l'exemple précédent on peut créer un autre exemple voilà R2 où on a un temps imparti pour cette opération qui dure par exemple 5 secondes et donc avec deux processus qui ont besoin d'être fait en 5 secondes et donc ensuite on fait le track out ça va c'est clair et ensuite si on regarde ça on se rend compte que cette liste de route élément et cette liste de opération en fait c'est un peu la même chose non, vous ne croyez pas peut-être qu'on peut faire quelque chose avec ça peut-être que ça on peut le mettre là-dedans ça on peut le mettre dans route element on peut transformer cette opération en route element en fait mon code disait route égalise d'opération vous avez fait la même chose en haut oui en fait maintenant c'est la même chose à nouveau donc maintenant il y a nouveau ce route element partout et donc maintenant si on regarde ça à nouveau peut-être que ça ça veut dire que que ça c'est pas juste une liste d'éléments de route peut-être que peut-être que c'est effectivement une route là-dedans donc on pourrait dériver de l'information depuis le code et on a trouvé que cette route Q time zone en fait ça contient une route donc si on regarde ça ce qu'on a ce qu'on peut faire maintenant c'est que avec cet élément de route on peut à nouveau n'importe quel élément de route à l'intérieur par exemple on peut remettre une route Q time zone qui est aussi un route élément et donc en partant de cet exemple-là on avait juste une liste plate avec des éléments et une Q time zone maintenant on pourrait partir vers on pourrait empiler les Q time zones qui contiennent une autre Q time zone qui contient une route qui contient une autre Q time zone c'est cool ça maintenant on peut combiner des Q time zones et c'est quelque chose qui se passe en réalité et donc ton modèle a suggéré ça mais c'est quelque chose que notre programmation ou l'OJ ne pouvait pas modéliser maintenant je comprends pourquoi tu aimes bien la programmation fonctionnelle parce que tu peux modéliser quelque chose plus facilement c'est cool en fait on a découvert ça dans le code et on a pu revenir vers les gens du business et vérifier avec eux voir si ils voyaient ça et si c'était intéressant et donc on a découvert ça juste en regardant les types et donc ensuite on peut continuer maintenant qu'on a cette liste de route elements on peut dire une liste de route elements on sait ce que c'est c'est une route et donc là on s'élève d'un niveau à chaque fois qu'on change en fait cette route maintenant ça va être automatiquement réfléchi ici parce qu'on a fait une abstraction donc ça c'est ce que fait la programmation fonctionnelle c'est faire des abstractions et trouver ce que les parties en commun sont ouais je vois que tu es d'accord avec moi c'est bien maintenant on peut évidemment regarder comment nos fonctions seront implément modifiées donc maintenant il faut regarder nos fonctions pour voir si elles fonctionnent toujours donc ici on a route head et route element head et maintenant il faut étendre ça parce que route element head ça s'applique un route element qui est dans les routes elements il faut intégrer route queue time zone et donc dans ce cas là c'est la tête de la route qui est incluse dans cette queue time zone donc ça c'est ça c'était plus simple à implémenter parce qu'on a découvert qu'il y avait une route là-dedans à la place d'une liste donc maintenant on peut juste revenir et donc si on regarde le route advance donc si on veut avancer notre route à l'opération suivante donc il faut bien sûr qu'on ajoute cette queue time zone ici et qu'est-ce qui se passe quand on veut avancer dans cette queue time zone parce que il faut garder en fait quand est-ce que le temps un parti est écoulé en fait donc ça peut prendre un certain temps X ou D et en fait maintenant il faut qu'on se souvienne est-ce que ce temps a été écoulé ou pas et donc dans ce cas là ce qu'on fait en fait c'est qu'il faut qu'on ajoute un nouvel élément de route qui est le route queue time limit donc la limite de temps qui définit en fait quand est-ce que l'opération a besoin d'être terminée et donc c'est le point dans le temps pas la durée mais le point fidèle en fait et donc après c'est la même chose que la route queue time zone donc ça ça limite notre processus dans le temps et maintenant on peut implémenter ça il peut implémenter route advance parce que quand on a une queue time zone en fait à chaque fois qu'on avance cette route on sait qu'il faut qu'on ait une limite de temps et quand on a cette limite de temps qu'on avance qu'on avance sur celle-là donc on sait qu'il faut simplement se comporter comme avant on la découpe et on garde notre limite de temps et ensuite on va juste continuer les opérations en gardant cette limite de temps et donc quand on commence ça il faut qu'on détermine le temps final donc on prend le temps courant on ajoute la durée et on sait quand est-ce qu'on a besoin d'en finir avec ce processus et donc ici on avance simplement pas à pas en gardant une trace du temps ton code a suggéré qu'il manquait quelque chose dans ta compréhension oui je savais pas ce qu'il fallait mettre pour route advance et maintenant je sais en regardant ça je pense qu'il y a donc quand je regarde avec l'oeil de quelqu'un du domaine je pense qu'il y a encore plein de problèmes donc regarde, un route element c'est quelque chose qui peut s'appliquer un peu n'importe où dans une route donc on peut avoir on peut avoir des opérations on peut avoir des Q-time zones à n'importe quel endroit mais on peut entrer dans une Q-time zone c'est au début oui ce que tu veux dire c'est qu'on peut avoir une liste dans n'importe quel ordre oui effectivement c'est quelque chose de vrai donc s'il y a une Q-time limit en fait ça a pas de sens si c'est pas au début en fait si on pouvait revenir au code à partir de ça on pourrait raffiner ça un peu plus et on pourrait enlever la Q-time limit au milieu et on pourrait le mettre dans un type de niveau supérieur et un type qui dit ce qu'il y a au début et tout ça donc ce qu'on a maintenant c'est qu'on a cet aéretour entre le code qui donne un peu les entrailles du domaine et le domaine on peut utiliser le code en fait pour communiquer oui ça c'est ce à quoi je m'attendais oui c'est cool et donc ce code me brise plus le coeur oui pareil pour moi cool voilà donc ça c'est le point que je voulais décrire donc si vous prenez la programmation fonctionnelle et vous ajoutez la discussion ça enrichit les deux côtés vous avez plein d'informations qui circulent et donc vous arrivez à une balle en argent oui c'est un train en forme de balle donc c'est un train à grande vitesse merci on a un peu de temps pour les questions donc si vous avez des questions allez au microphone on a quatre microphones ici une question d'internet en tant que débutant en programmation fonctionnelle est-ce que ça serait mieux avec un background normat est-ce que ça serait mieux de commencer par un langage fonctionnel pur donc je pense que il y a plein de langages de programmation fonctionnelle et à ce qu'elle est-ce qu'on appelle un langage pur mais il y a des langages qui sont hybrides entre l'orienté objet et la programmation fonctionnelle par exemple Scala et Scala c'est bien mais si vous voulez combiner ces deux paradigmes vous tombez sur un truc qui est vraiment compliqué Scala c'est un langage compliqué ça prend plus de temps de le maîtriser parce que et en plus vu que vous avez les deux paradigmes n'importe quand partout finalement vous vous retrouvez confus vous savez pas trop quel paradigme appliqué et donc je pense que on peut pas vraiment voir les avantages de ce modèle hybride et puis le problème c'est que si vous apprenez la programmation fonctionnelle et vous essayez de le faire en Scala vous allez forcément retomber sur ce que vous connaissez et donc peut-être autant jeter dans le grand bain et voir où vous arrivez et demander de l'aide s'il faut sur internet Bonjour merci pour la présentation c'est vraiment bien à chaque fois que je vois de la programmation fonctionnelle ça me rafraîchit c'est intéressant la description de la présentation c'était utiliser la programmation fonctionnelle en IoT il n'y avait rien de spécifique à internet d'eux-objets dans cette présentation il n'y avait pas d'interruption et rien comment est-ce que vous ferez ça en programmation fonctionnelle bonne idée je pense qu'on avait des slides là dessus mais on les a laissés tomber à cause du temps donc mon argument ce serait que l'IoT le logiciel c'est le même logiciel que partout et ce qui est spécifique en IoT c'est le risque qui en émane si vous faites des choses comme des interruptions ma réponse ce serait de convertir ça dans une structure de données fonctionnelle et ça vous donne un modèle déterministe pour évaluer ça on a parlé du modèle observateur c'est un peu ce qui se passe avec les interruptions et la façon de faire ça c'est ce serait d'avoir un peu de code qui fait le lien entre le hardware et le langage fonctionnel qui serait impératif et ensuite vous avez par exemple une liste qui gère tous les événements et ensuite ça devient du logiciel comme n'importe quel autre logiciel merci pour votre présentation donc il faut que j'écris du code pour des microprocesseurs et la plupart du temps j'ai seulement un composateur C donc comment est-ce que moi je peux avoir ma balle en argent le vieux compilateur Askel y compilait vers du C il fait plus ça par défaut mais peut-être tu peux toujours faire ça en fait il y a un certain nombre de langages fonctionnels qui compilent vers le C donc c'est difficile de donner une seule réponse on a déjà fait un projet où on a tous les avantages de la programmation fonctionnelle en écrivant du code Askel qui génère du code C donc c'est difficile de donner juste une réponse sans connaître plus de détails il y a certainement tout un spectre d'options possibles donc la programmation fonctionnelle c'est assez compact assez concis donc les gens veulent utiliser des noms de variables longs et dans votre exemple j'ai vu des D, des T, des TL et je pense que c'est pas beaucoup mieux que les versions longs que vous avez montré tout à l'heure qu'est-ce que c'est votre avis là-dessus donc moi j'ai un peu de mal avec ça d'un côté ça c'était du code assez concret mais souvent vous arrivez dans des abstractions et dans les abstractions c'est un peu arbitraire ce que vous avez donc on peut utiliser des noms courts parce que on parle pas de choses concrètes de toute façon c'est pour ça que c'est plus simple d'utiliser des noms de variables un peu plus abstraits mais ce que je fais en fait c'est que j'utilise des noms un peu plus longs donc je n'utiliserai pas forcément tout le temps d'un rt et tout ça mais quelque chose d'important qu'il faudrait pas oublier c'est que vous avez une fonction et qui fait 2 ou 3 lignes donc si vous commencez et que vous comprenez ce que vous allez dire d'rt par rapport à la signature lire 3 lignes de code avec drt c'est pas si compliqué en fait en orienté objet si vous avez un d, un rt vous l'utilisez pendant une demi-heure et évidemment vous oubliez donc en fait oui c'est un équilibre j'utiliserai certainement des noms un peu courts mais peut-être un peu plus courts parce que le code est vraiment court donc c'est pas la peine moi j'ai remarqué que j'utilisais des noms plus longs dans les langages dynamiques mais vous n'avez pas le type qui décrit ce que veut dire l'objet dans l'une de vos slides vous avez dit que la programmation fonctionnelle permet de prouver comment est-ce que vous feriez ça bonne question ça c'est une autre présentation en pratique il y a plusieurs façons de faire ça comme vous avez vu le programme Askel c'est une suite d'équations vous pourriez utiliser l'algebra d'une technique mathématique pour résonner à partir de programmes fonctionnels vous pouvez le faire avec votre programme java mais c'est beaucoup plus compliqué d'écrire une façon algébrique de résonner à partir de ça et puis il y a pas mal d'objets pour faire ça pour prouver des aspects de vos programmes fonctionnels par exemple on peut commencer par ACL2 on peut commencer par Idras vous pouvez mettre plus de preuves dans vos objets dans vos types c'est vraiment un ordre de grandeur plus simple de montrer de faire des démonstrations sur du code fonctionnel parce qu'on peut écrire des preuves mathématiques en fait on peut faire de l'algebra avec nos preuves en fait je pense que Idras utilise des types dépendants mais c'est pas possible de l'utiliser dans les programmes impératifs est-ce que c'est spécifique à la programmation fonctionnelle les types dépendants oui en fait même la façon dont Idras parle des langages impératifs c'est fonctionnel parce qu'ils utilisent des monades donc il y a ça et donc il y a tout ce raisonnement à partir des effets donc les effets de bord ils ne rendent pas impossible le fait de raisonner en de manière fonctionnelle mais dans un vrai programme fonctionnel qui vous brise pas le coeur en fait vous avez des grandes parts qui sont purement fonctionnelles et vous pouvez avoir quelques parties qui sont en fait des interactions avec l'environnement qui sont un peu plus complexes et puis ce qu'on a fait avec le système de type on avait la liste ensuite on avait la limite de temps au milieu et donc ça c'était un état illégal et donc on a changé on a changé le système de type pour interdire ça et en fait du coup même le compilateur nous dit ça c'est du code impossible donc c'est pas du code syntaxiquement incorrect mais par contre c'est du code sémantiquement incorrect et donc c'est une espèce de validation faible vérification faible à mon avis on pourrait parler toute la journée de ça, désolé j'ai remarqué que vous avez vous avez pas présenté de mécanismes de cacher votre implémentation ou de rendre votre implémentation privée je sais qu'il y a ça en c++ j'utilise pas vraiment mais je voudrais avoir votre ravis j'ai l'impression que ça vous manque pas oui en fait ça existe en programmation fonctionnelle il y a des mécanismes comme ce nom vous avez l'habitude des trucs privés, des modules alors leur programmation fonctionnelle n'utilise pas d'objet pour justement modulariser mais il y a des mécanismes pour faire ça et en fait ça dépend des langages donc on aurait pu vous montrer comment faire ça en Askel et ça aurait fait plus de code à montrer et l'autre aspect c'est qu'il y a pas besoin de cacher des choses parce que tout est pur si vous appelez cette fonction moi je m'en fiche vous pouvez rien casser alors qu'en programmation vous avez cette possibilité de changer mon objet dans un état vraiment pas bien en programmation fonctionnelle en fait on s'en fiche vérifier une variable fais le autant que tu veux je m'en fous et micro numéro 3 vous avez des slides sur l'importance de la communication moi je ne me vois pas trop communiquer avec des gens du business en utilisant du Askel comment est-ce que vous vous feriez la communication avec des gens normaux donc on l'a nettoyé un peu mais en fait ça s'est vraiment passé parfois c'est un processus d'arriver jusque là mais ce que vous avez peut-être vu avec le code avec les routes c'est que jouer avec le code Askel ça donne des idées sur le domaine qu'on peut exprimer après assez facilement donc la communication elle va à travers du code Askel mais pas forcément en se servant du code Askel et en fait ce que je peux dire c'est que ça arrive parfois on communique avec des clients en leur montrant du code et on leur demande est-ce que c'est votre domaine ça dépend vraiment de vos clients et il faut qu'ils soient un peu résiliants de façon à ce qu'ils puissent s'accepter qu'ils comprendront pas tout mais vous pouvez leur montrer regardez ici il y a ça, ça rentre ça sort qu'est-ce que vous pensez de ça et donc vous leur balancez pas juste le code mais vous avez une espèce de communication éclairé donc ça peut être ça peut être aussi imposé par contrat ok désolé on commence à être à court de temps mais un tour d'applaudissement