Stephen Cleary fait partie des
100 meilleurs utilisateurs de Stack Overflow. Principalement grâce à ses réponses asynchrones en .NET. Sa vie ne se limite pas à la programmation: sur Twitter, il écrit d'abord sur lui-même «chrétien», puis seulement «développeur».
Maintenant, en relation avec l'apparition de flux asynchrones, ses connaissances sont particulièrement pertinentes: en tant que rapporteur sur ce sujet, la figure de Stephen le supplie. Et très bientôt sur DotNext il en
parlera . En attendant, nous lui avons posé des questions sur tout cela: religion, débordement de pile et asynchronie.
Biographie
- La première question est simple: parlez-nous de votre biographie professionnelle.- Je me suis intéressé à la programmation assez tôt, j'avais 7-8 ans. Puis, à l'école, j'ai pu écrire un petit programme en langage Logo, et c'était ma première expérience de programmation. Plus tard, quand j'avais 12-13 ans, j'ai économisé sur mon premier ordinateur. Et quand j'ai choisi l'informatique à mon entrée à l'université, c'était une décision assez évidente: je m'intéressais déjà à l'informatique depuis longtemps.
En 1998, après avoir obtenu mon diplôme universitaire, j'ai commencé à travailler pour une entreprise locale spécialisée dans les convoyeurs commandés automatiquement par des véhicules pour l'industrie et d'autres automatisations industrielles. Sept ans plus tard, l'entreprise a déménagé à Détroit, mais je ne voulais pas y déménager et depuis, j'ai réussi à travailler dans différentes entreprises. Depuis 2013, je travaille à distance, depuis un an et demi - dans Faithlife.
- C'est drôle que vous ayez commencé avec Logo, et maintenant dans une entreprise dont le produit principal s'appelle Logos. Et que faites-vous exactement là-bas?- Backend: services Web accessibles par Logos et autres produits de l'entreprise. Faithlife propose une gamme de produits liés à l'église. Logos - pour l'étude de la Bible. Et il y a aussi Proclaim, conçu pour ceux qui donnent des sermons (aide aux diapositives et autres). Faithlife a toujours fabriqué des produits pour les pasteurs, mais maintenant ils ajoutent des choses qui aident les gens ordinaires.
Je fais du backend, je dois souvent faire face à l'API Web ASP.NET, et en ce moment je travaille avec Docker. En ce moment, nous avons une partie dans le cloud et une partie sur site, et quelque chose ne devrait pas du tout être transféré vers le cloud, mais nous voulons transférer certaines choses là-bas - et je le fais.
La religion
- Ce n’est pas souvent que vous rencontrez une entreprise qui fabrique des logiciels «d’église», donc je veux clarifier: le travail sur le backend ressemble-t-il partout ailleurs, ou at-il ses propres spécificités? Et les développeurs sont généralement des croyants et utilisent eux-mêmes les produits de l'entreprise, ou non?- Il n'y a pas de différences fondamentales dans le travail: vous devez penser à la bonne conception de l'API comme partout ailleurs. Certains de nos produits (en particulier ceux de bureau) existent depuis très longtemps et nous devons faire face aux anciennes API. Et lorsque vous commencez à utiliser Docker, il est important de penser à la compatibilité descendante. En général, nous avons à peu près les mêmes préoccupations que les autres.
Bien que Faithlife fabrique des produits pour l'église, ce n'est pas une entreprise chrétienne. Pour y arriver, il n'est pas nécessaire d'être chrétien: d'une part, une telle sélection violerait la loi américaine (serait une discrimination religieuse lors de l'embauche), et d'autre part, l'entreprise n'en voudrait pas de toute façon.
Mais quant aux développeurs d'utiliser les produits de l'entreprise, c'est encouragé à tous points de vue. Par exemple, j'ai récemment passé une journée de formation sur l'utilisation des logos. Nous avons également de nombreux outils internes - dans ce cas, nous sommes encouragés à aller travailler la journée dans le département qui utilise votre outil pour voir personnellement comment cela se produit.
- Sur votre Twitter dans le domaine bio, il y a les mots «chrétien» et «développeur». Ces deux parties de votre identité se croisent-elles d'une manière ou d'une autre?- Je dirais qu'ils sont séparés. J'ai toujours essayé de séparer la vie professionnelle et la maison, ne faisant pas de travail pendant mon temps libre (même si cela ne fonctionnait pas toujours). L'église est une grande partie de ma personnalité, la plupart de mes amis viennent de là. Au travail, je me suis fait peu d'amis.
"Eh bien, votre biographie dit aussi" accro à l'écriture OSS ", et donner aux gens des logiciels gratuits semble altruiste et chrétien. Dans ce cas, il n'y a pas de corrélation?- Hmm, peut-être. Je pense que d'un point de vue philosophique, vous pouvez vraiment voir la relation entre l'open source et le christianisme: dans les deux cas, l'accent est mis sur le «donner aux gens» que vous avez mentionné.
Il existe également un type d’open source «humanitaire». Je ne suis pas moi-même impliqué dans cela, j'ai des bibliothèques à usage général. Mais je connais des développeurs chrétiens qui ont travaillé gratuitement sur quelque chose qui affecte directement d'autres vies, en particulier dans les endroits avec des pauvres. Par exemple, un logiciel qui vous permet de vous assurer que les alarmes incendie fonctionnent correctement. Ici, bien sûr, il existe une corrélation.
- Vous êtes également actif sur Stack Overflow - est-ce aussi un moyen pour vous de donner quelque chose de généreux à la communauté?- Je ne dirais pas ça, pour moi ça ressemble plus à "enseigner". Bien que "l'enseignement" puisse aussi être lié au christianisme ... Ma famille avait beaucoup d'enseignants, et je continue cela à ma manière - pas en tant que profession, mais avec l'aide de Stack Overflow et de conférences. Je réponds donc à mon besoin.
Débordement de pile
- Nous avons encore un certain nombre de questions sur Stack Overflow, la première farfelue. Vous y avez récemment reçu un badge pour les réponses sur Windows Phone 8:
Comment est-il arrivé qu'en 2019 vous ayez reçu un badge pour des réponses sur une technologie presque morte? Quelqu'un pose-t-il encore des questions à son sujet?- Pour obtenir un badge, vous avez généralement besoin d'au moins un certain nombre de réponses avec un certain nombre de votes pour ces réponses. Je suppose que j'ai obtenu ce badge parce que maintenant quelqu'un a voté pour une partie de ma réponse, publiée il y a des années, et avec elle a finalement obtenu le bon nombre de votes. C'est drôle car je n'ai pas vu de questions sur Windows Phone 8 depuis très longtemps!
(rires)- Sur SO, votre réputation est de 320 000 - et cela représente plus du quart de la réputation du légendaire John Skeet, bien que vous ayez donné des réponses d'un ordre de grandeur plus petit que lui. Comment avez-vous obtenu cela?- Je ne suis pas complètement sûr. Il est plus facile d'avoir une réputation pour ceux qui sont venus sur le site avant tout le monde, et bien que je fusse parmi les premiers à adopter, je suis quand même venu plus tard que beaucoup. J'ai commencé à répondre aux questions - au début, 1 à 2 par jour, ce qui est incroyablement loin de John Skeet. Concentré sur le sujet de l'asynchronisation / attente, ainsi que de la concurrence et du multithreading - tout simplement parce que c'est devenu alors ma spécialité. Il y a de nombreuses années, j'étais déjà engagé dans l'asynchronie, puis c'était douloureux. Donc, quand async / wait est apparu, j'ai immédiatement vu quelle était leur signification. J'étais donc au bon moment au bon endroit et mon «sang de professeur» m'a aidé à tout expliquer dans une langue que les gens comprenaient. Et dans le cas de Stack Overflow, je me suis avéré être un spécialiste local asynchrone / attente. Et John Skeet - enfin, il ne l'a pas dit directement, mais je suppose que cela - me laisse la plupart des questions sur l'async /. Mais lui, bien sûr, répond beaucoup plus que moi, il ne peut pas être rattrapé!
- En regardant le nombre de réputation, il est facile de penser «une personne prend la moitié de sa vie pour répondre» - et combien de temps passez-vous réellement sur SO?"Pas tellement." Je vérifie Stack Overflow plusieurs fois par jour et je réponds généralement à 1 à 3 questions. Et j'obtiens la majorité des votes positifs pour les réponses laissées il y a des années. C'est ainsi que SO aide ceux qui sont venus plus tôt: ils ont été les premiers à répondre aux questions il y a des années, ont reçu des votes, et les voix rendent ces réponses plus visibles, et à la fin ils obtiennent de nouveaux votes. Il s'agit d'un effet d'avalanche encourageant les anciennes réponses.
Il me semble que cela pose quelques problèmes, car parfois il y a de nouvelles réponses qui se réfèrent à des technologies plus modernes et sont donc meilleures, mais les anciennes réponses ne se mettent pas à jour. Mais, en général, j'obtiens la majorité des voix pour les anciennes réponses, mais j'essaie toujours d'en répondre de nouvelles chaque jour. Je ne passe pas beaucoup de temps là-dessus, je le fais juste constamment depuis de nombreuses années.
- Lorsque John Skeet s'est envolé pour nous sur DotNext, nous lui avons demandé l'état actuel de Stack Overflow et ce qu'il considérait comme les problèmes du site. Il est intéressant de comparer: qu'en pensez-vous?«Je pense que SO s'améliore, surtout au cours de la dernière année.» Ils essaient maintenant très fort d'améliorer la qualité des questions. Souvent, les personnes qui demandent d'abord quelque chose sur ce site ne savent pas comment poser correctement les questions techniques.
Et c'est un problème qui a toujours été présent sur Internet. Dans les années 90, quand tout le monde était dans les newsgroups, elle était là aussi. Dix ans plus tard, tout s'est passé sur les listes de diffusion et les groupes Google. Maintenant une nouvelle ressource pour les questions de programmation Stack Overflow. Mais il y a toujours eu des questions sur la programmation, et comment poser une bonne question a toujours été un problème, et comment maintenir une communauté amicale aussi. Peut-être que ces problèmes ne pourront jamais être complètement résolus. Je ne dis pas que nous ne devrions pas travailler là-dessus - nous devrions certainement. Mais si vous regardez dans le passé, il s'avère que même dans les années 90, il y avait déjà des tutoriels écrits sur la façon de poser des questions techniques.
Il y a quelques problèmes qui sont nouveaux dans Stack Overflow. Vous pouvez commencer par le fait que beaucoup d'entre eux n'ont jamais demandé à quelqu'un d'autre avant de poser leur première question. Par conséquent, dans de nombreux cas, ils ne réalisent tout simplement pas toutes ces choses qui doivent être présentées dans la question pour pouvoir y répondre.
Et puis, imaginez que vous travaillez sur une tâche. Vous êtes fou de code, votre tête est remplie de tout cela. Et vous regardez une chose spécifique qui ne se prête en aucune façon. Ceci est un petit détail concret d'un grand système, et généralement vous demandez "Comment puis-je faire cette petite chose?", Sans se rendre compte que vous avez tout ce contexte que vous connaissez, mais vous ne le mettez pas en question. Souvent, la question "Comment faire X" la bonne réponse est "Ne faites pas X, faites Y". C'est un piège dans lequel les gens tombent souvent lors de la rédaction des premières questions. Ils ne réalisent pas que leur réponse sous sa forme actuelle est «sans réponse».
Et en plus du problème de la qualité des questions, il y a aussi une tendance - en particulier sur Stack Overflow, où tout le monde se bat pour des points, essayant de répondre le plus rapidement possible - fermez rapidement la question ou griffonnez rapidement les réponses les moins agréables. Je ne veux pas dire «méchant», j'ai vu très peu de commentaires franchement méchants - seulement quelques-uns au fil des ans. Au contraire, ils sont durs, et pour l'auteur de la question, cela est lu comme hostile.
Stack Overflow a pris quelques mesures simples pour résoudre ce problème. Maintenant, lorsque les gens posent une question pour la première fois, le site vous dit quoi y inclure. Ils avaient précédemment ajouté «regardez ces questions similaires», ce qui était une bonne première étape. Et maintenant, il y a tout un système qui doit être complété pour la première question, ce qui aide à bien le composer.
Ils ajoutent également des rappels à ceux qui écrivent les réponses. C'est comme "C'est un débutant, soyez amical", et c'est un bon moyen de vous rappeler que la plupart des gens n'écrivent pas bien les questions la première fois, et c'est tout à fait normal. En général, ils y travaillent. Ce problème sera-t-il jamais complètement résolu? J'en doute. Mais des progrès sont possibles.
Asynchronie
- Dans un article dédié au 10e anniversaire de l'iPhone, vous écrivez que son apparence a affecté la programmation asynchrone, car les applications mobiles doivent être réactives. Et pouvez-vous donner un contexte historique général sur le développement de l'asynchronie pour ceux qui ont récemment commencé à se développer et qui n'ont pas vu le monde sans asynchronisation / attente?- Eh bien, la programmation asynchrone a toujours été possible. Je pense que dans les années 60, ils le faisaient déjà. Et il avait longtemps les mêmes avantages: une interface utilisateur plus réactive et une partie serveur plus évolutive. Et le support a toujours été un problème: il était très difficile de maintenir du code asynchrone. Initialement, il était basé sur des rappels.
Je pense que le grand pas a été l'avènement de Promise. C'est ce qu'ils ont appelé en JavaScript, et en C # c'est Task ou ValueTask. Et ce fut un grand pas en avant, car nous avons maintenant un objet représentant l'opération. Vous pouvez suivre sa progression et ainsi de suite. Et asynchroniser / attendre dans n'importe quelle langue est essentiellement un sucre syntaxique autour de Promise.
Je dirais que l'apparition de Promise est l'événement qui a eu le plus d'impact sur le code asynchrone. Et dans le cas de l'async / wait, il est important que la machine d'état soit créée pour vous. Autrefois, lorsque nous travaillions avec des rappels, nous devions créer nous-mêmes nos propres machines d'état. Et c'était toujours difficile parce que vous avez inévitablement oublié une condition ou une transition, et rien n'a fonctionné. Et c'était très difficile à déboguer. L'async / attente n'a pas apporté la capacité même d'écrire du code asynchrone, mais la capacité d'écrire du code qui peut être pris en charge.
- Et maintenant, voyez-vous la situation se calmer, ou de nouveaux changements nous attendent bientôt?- Je pense que maintenant tout est assez stable. Async / Wait avait l'air révolutionnaire - mais seulement pour ceux qui n'avaient jamais fait de programmation asynchrone auparavant. Et pour ceux qui travaillaient, c'était très naturel. Mais, en général, ce fut un grand événement.
Et maintenant, un autre événement est fourni avec .NET Core 3. Ils font ce que tout le monde appelle des flux asynchrones, bien qu'ils soient en fait des énumérateurs asynchrones. Je pense que cela déroutera les gens, car il existe déjà un type de flux qui n'a rien à voir avec les flux asynchrones. En général, il y aura plus d'améliorations incrémentielles. Verrons-nous quelque chose d'aussi massif que lorsque async / wait s'est annoncé pour la première fois? Je ne pense pas.
Si vous voulez un nouveau changement de paradigme, il y a toujours la possibilité d'un système basé sur les acteurs. Ou quelque chose comme goroutine, où toute asynchronie est implicite. À mon avis, ces choses sont quelque peu similaires. Le problème est que dans .NET, ce n'est pas si facile à ajouter. Je pense qu'il y a trop de restrictions pour que .NET puisse le faire, il est donc peu probable que cela se produise. Si nous voyons une transition à grande échelle vers le monde des acteurs ou le monde de Goroutine, où l'approche de la concurrence ne sera pas la même qu'avec le multithreading d'aujourd'hui, cela nécessitera des langages et des temps d'exécution complètement nouveaux. Et .NET ne vaut pas la peine. Et je ne pense pas que la programmation dans son ensemble fera un tel saut. Je me trompe peut-être, mais ma position actuelle est la suivante.
- Plus à la question de savoir comment tout change au fil du temps. De nombreux livres de programmation deviennent rapidement obsolètes, mais là où les changements sont moindres, ils durent plus longtemps. Qu'en est-il de votre concurrence dans le livre de recettes C # , combien faut-il de mises à jour?- Bonne question. Je viens de publier récemment la deuxième édition, et la première est sortie en 2014. Autrement dit, cinq ans se sont écoulés, et nous sommes déjà sur la deuxième édition - pour moi, cela ressemble à un développement rapide.
Je pense que cela dépend toujours de la façon dont le livre est écrit. J'ai essayé d'écrire pour qu'elle ne soit pas dépassée le plus longtemps possible. Vous devez juste essayer de ne pas vous référer à des choses comme Windows Phone 8. Mais cela deviendra inévitablement obsolète de toute façon. Des flux asynchrones et similaires apparaissent, et je voulais inclure de telles choses dans le livre. En conséquence, quelque chose était obsolète, mais la plupart du matériel a migré vers la nouvelle édition sans modifications.
Et, bien sûr, tout dépend de la destination du livre. Bien sûr, le livre sur l'utilisation de Visual Studio 2008 expirera très rapidement. Mais je pense qu'il y a une place pour les vrais classiques. Je considère Code Complete comme l'un des meilleurs livres de programmation au monde. Et combien de temps a-t-il été écrit? Je ne sais même pas. Il y a des décennies. Et c'est toujours un livre fantastique! Quelque chose en elle est dépassé, mais dans l'ensemble, c'est toujours aussi bien.
- Récemment, il y a eu des ajustements sur async / wait sur Twitter, qui ont commencé par un tweet de Vaughn Vernon, l'auteur de plusieurs livres sur la DTD et les modèles d'acteurs:
Il n'aime pas async / attendre l'importunité - à son avis, cela se propage dans tout le code et peut entraîner un blocage des threads. Qu'en pensez-vous? Cela valait-il la peine de concevoir autre chose?- Oui, peut-être le fait que l'async / attente se propage autour du projet est la plainte la plus courante. Je voudrais mentionner deux ou trois choses ici.
Tout d'abord, le code asynchrone, pour être vraiment asynchrone, nécessite une asynchronie de tous ceux qui l'appellent. Et ça ne se déplace pas. Quel que soit le paradigme que vous utilisez (même l'un des anciens), à la fin vous le rencontrez. J'ai eu un rapport où je passe chronologiquement à travers tous les paradigmes et montre comment le code est devenu plus propre et meilleur.
Il existe deux approches différentes pour éviter la domination répandue de l'async / wait. La première consiste à isoler toutes les entrées / sorties dans des objets séparés. Vous pouvez utiliser des modèles de conception tels que les ports et adaptateurs: cela vous permet de contenir toutes les E / S en dehors de votre logique métier, et cela ne nécessitera aucune asynchronisation / attente. Récemment, j'ai vu un rapport complet sur la façon d'empêcher «l'async partout» en refactorisant le projet afin que la logique métier ne traite jamais les E / S. Je recommanderais cette approche.
Il existe une autre approche pour gérer la dominance asynchrone / wait, mais elle n'est pas possible dans .NET. À mon avis, Go a essayé de le faire avec les goroutines. En fait, tout est là - c'est une asynchrone / attente solide. Vous pouvez supprimer async / wait du langage en l'ajoutant à tout et en le rendant implicite.
Il n'y a pas d'autre moyen. Lorsque async / wait est apparu, quelqu'un (je ne me souviens pas exactement qui) a dit que c'était comme un virus zombie: dès qu'une partie de votre code est infectée, la distribution commence.
- Certains développeurs utilisent le modèle d'acteur, ce qui s'explique par la simplicité du contrôle de flux (les acteurs, en fait, sont mono-thread). Pensez-vous qu'avec le bon choix de bibliothèques, les développeurs peuvent se débarrasser de la complexité de la programmation simultanée?"Eh bien, pas tout à fait." Parce que même avec le modèle d'acteur, des problèmes persistent. Vous ne rencontrerez pas des conditions de course telles que dans un programme multi-thread, mais vous aurez des difficultés d'amitié.
Par exemple, des problèmes de retard de message ou de messages asynchrones. Ils sont généralement nécessaires pour éviter les blocages dans le modèle d'acteur. Mais tout modèle d'acteur qui utilise des messages asynchrones peut également provoquer des blocages. Les messages asynchrones peuvent également créer leurs propres problèmes de coordination. Habituellement, à ce niveau, il faut également faire face à l'idempotence.
En outre, l'utilisation d'acteurs avec des messages asynchrones peut rendre la gestion des états assez confuse, sauf si cela se produit entièrement dans les messages. Et même dans ce cas, vous aurez des difficultés avec la cohérence éventuelle. En général, de mon point de vue, le modèle d'acteur ne peut pas résoudre tous les problèmes. Je le décrirais de cette façon: il ne peut changer que là où se poseront exactement les problèmes.
"Vous êtes connu comme un donateur, mais vous utilisez d'autres langages comme TypeScript." Lorsque vous les essayez, comment cela vous fait-il regarder C # et .NET? Rencontrez-vous quelque chose que vous aimeriez voir en C #?- Grande question. C # a pris beaucoup d'autres langues. L'un d'eux dont il a beaucoup tiré est Python. Et j'aime ça. Je n'ai pas écrit en Python depuis des années, mais je pense que c'est un langage très bien conçu. J'apprécie vraiment les blocs énumérateurs que C # a empruntés à Python. Et Python a été l'un des premiers où les flux Async sont apparus, nous pouvons donc dire que C # l'a pris à partir de là.
Dans différentes langues, j'aime des choses différentes. Je préfère généralement la saisie statique, donc je n'ai pas utilisé Python récemment, et pour la même raison, j'utilise TypeScript au lieu de JavaScript. JavaScript a ses avantages simplement en raison de son un thread. Par exemple, si vous regardez la pertinence des extensions réactives, vous verrez que dans .NET, cela n'est pas particulièrement accepté. Et en JavaScript, vous pouvez voir Rx partout.
- Les deux dernières questions concernent votre rapport sur DotNext. Vous allez y parler des flux asynchrones - pouvez-vous brièvement dire aux développeurs .NET à quoi s'attendre et pourquoi ce rapport leur sera utile?- Donc, mon rapport sur les flux asynchrones: pourquoi ils ont été ajoutés à la langue, et quel est le scénario principal pour leur utilisation. J'aborde cette question de façon très pragmatique et je n'entre pas dans tous les détails de ce qui se passe sous le capot. , async streams, , , async streams, .
— . — DotNext?— , , , . , : , .
, , , . - async streams , , , . , DotNext.
DotNext 2019 Moscow 6-7 . , — .