Stephen Cleary está entre os
100 principais usuários do Stack Overflow. Principalmente graças às suas respostas assíncronas no .NET. Sua vida não se limita à programação: no Twitter, ele primeiro escreve sobre si mesmo como "cristão" e somente depois como "desenvolvedor".
Agora, em conexão com a aparência de fluxos assíncronos, seu conhecimento é especialmente relevante: como relator sobre esse tópico, a figura de Stephen apenas o implora. E muito em breve no DotNext ele
contará sobre isso. Enquanto isso, perguntamos a ele tudo isso: religião, estouro de pilha e assincronia.
Biografia
- A primeira pergunta é simples: conte-nos sobre sua biografia profissional.- Interessei-me muito cedo pela programação, tinha 7-8 anos. Então, na escola, pude escrever um pequeno programa na linguagem Logo, e essa foi minha primeira experiência em programação. Mais tarde, quando eu tinha 12 a 13 anos, salvei no meu primeiro computador. E quando escolhi Ciência da Computação quando entrei na faculdade, foi uma decisão bastante óbvia: eu já estava interessado em computadores por um tempo tangível.
Em 1998, depois de me formar na faculdade, comecei a trabalhar para uma empresa local envolvida em transportadores controlados automaticamente por veículos para indústria e outras automações de fábricas. Sete anos depois, a empresa se mudou para Detroit, mas eu não queria me mudar para lá e, desde então, consegui trabalhar em diferentes empresas. Desde 2013, trabalho remotamente, no último ano e meio - na Faithlife.
- Engraçado que você começou com o Logo e agora em uma empresa cujo principal produto se chama Logos. E o que exatamente você está fazendo aí?- Backend: serviços web acessados pelo Logos e outros produtos da empresa. A Faithlife tem uma gama de produtos relacionados à igreja. Logotipos - para estudo da Bíblia. E também existe o Proclaim, projetado para quem dá sermões (ajuda com slides e coisas do gênero). Historicamente, a Faithlife produz produtos para pastores, mas agora eles estão adicionando coisas que ajudam as pessoas comuns.
Eu tenho back-end, geralmente tenho que lidar com a API da Web do ASP.NET e agora estou trabalhando com o Docker. No momento, temos parte na nuvem e parte no local, e algo não deve ser transferido para a nuvem, mas queremos transferir algumas coisas para lá - e estou fazendo isso.
Religião
- Não é sempre que você conhece uma empresa que fabrica software para "igreja", então quero esclarecer: o trabalho no back-end se parece com qualquer outro lugar ou tem suas próprias especificidades? E os desenvolvedores geralmente são crentes e usam os produtos da empresa, ou não?- Não há diferenças fundamentais no trabalho: você precisa pensar sobre o design adequado da API, tanto quanto em qualquer outro lugar. Alguns de nossos produtos (especialmente os de desktop) existem há muito tempo e precisamos lidar com APIs antigas. E ao começar a usar o Docker, é importante pensar em compatibilidade com versões anteriores. Em geral, temos as mesmas preocupações que os outros.
Embora a Faithlife faça produtos para a igreja, ela não é uma empresa cristã. Para chegar aqui, você não precisa ser cristão: primeiro, essa seleção violaria a lei americana (seria discriminação religiosa na contratação) e, segundo, a empresa não iria querer isso de qualquer maneira.
Mas, como os desenvolvedores usam os produtos da empresa, isso é incentivado de todas as maneiras. Por exemplo, recentemente passou um dia de treinamento no uso do Logos. Também temos muitas ferramentas internas - nesse caso, somos incentivados a trabalhar no dia no departamento que usa sua ferramenta para ver pessoalmente como isso acontece.
- No seu Twitter, no campo da biografia, existem as palavras "cristão" e "desenvolvedor". Essas duas partes de sua identidade se cruzam de alguma forma?- Eu diria que eles são separados. Eu sempre tentei separar a vida profissional e a casa, não fazendo trabalho no meu tempo livre (embora nem sempre desse certo). A igreja é uma grande parte da minha personalidade, a maioria dos meus amigos é de lá. No trabalho, fiz poucos amigos.
“Bem, sua biografia também diz“ viciada em escrever OSS ”, e dar às pessoas software livre soa altruísta e cristão. Nesse caso, não há correlação?Hmm, talvez. Eu acho que, do ponto de vista filosófico, você pode realmente ver a relação entre código aberto e cristianismo: em ambos os casos, a ênfase está no “dar às pessoas” que você mencionou.
Há também um tipo "humanitário" de código aberto. Eu mesmo não estou envolvido nisso, tenho bibliotecas de uso geral. Mas conheço desenvolvedores cristãos que trabalharam de graça em algo que afeta diretamente outras vidas, especialmente em lugares com pessoas pobres. Por exemplo, software que permite garantir que os alarmes de incêndio estejam funcionando corretamente. Aqui, é claro, há uma correlação.
- Você também é ativo no Stack Overflow - essa também é uma maneira de você dar algo desinteressado à comunidade?- Eu não diria isso, para mim parece mais "ensinar". Embora o "ensino" também possa estar conectado ao cristianismo ... Minha família tinha muitos professores e continuo do meu jeito - não como profissão, mas com a ajuda de Stack Overflow e conferências. Então, eu satisfiz a minha necessidade disso.
Estouro de pilha
- Ainda temos várias perguntas sobre o Stack Overflow, a primeira maluca. Você recebeu recentemente um selo lá para obter respostas no Windows Phone 8:
Como aconteceu que em 2019 você recebeu um crachá por respostas sobre uma tecnologia quase morta? Alguém ainda está fazendo perguntas sobre ela?- Para obter um crachá, você geralmente precisa de pelo menos um certo número de respostas com um certo número de votos para essas respostas. Suponho que recebi esse distintivo porque agora alguém votou em algumas das minhas respostas, publicadas anos atrás, e com ele finalmente obteve o número certo de votos. Isso é engraçado, porque eu não vejo as perguntas do Windows Phone 8 há muito tempo!
(risos)- No SO, sua reputação é de 320.000 - e isso representa mais de um quarto da reputação do lendário John Skeet, embora você tenha respondido a uma ordem de magnitude menor que ele. Como você conseguiu isso?- Não tenho certeza. É mais fácil obter uma reputação para aqueles que vieram ao site antes de todos os outros e, embora eu estivesse entre os primeiros a adotar, ainda assim cheguei depois de muitos. Comecei a responder perguntas - primeiro, 1 a 2 por dia, o que é incrivelmente longe de John Skeet. Focado no tópico de assíncrono / espera, bem como simultaneidade e multithreading - simplesmente porque, de fato, se tornou minha especialidade. Muitos anos atrás eu já estava envolvido em assincronia, e depois foi doloroso. Então, quando assíncrono / espera apareceu, vi imediatamente qual era o significado deles. Então, eu estava na hora certa, no lugar certo, e o “sangue do meu professor” ajudou a explicar tudo em um idioma que as pessoas entendiam. E, no caso do Stack Overflow, eu me tornei um especialista local em assíncrono / espera. E John Skeet - bem, ele não disse diretamente, mas suponho - deixa a maioria das perguntas sobre assíncrona / que me aguardam. Mas ele, é claro, responde muito mais do que eu, ele não pode ser pego!
- Olhando para o número de reputação, é fácil pensar que "uma pessoa leva metade da vida para responder" - e quanto tempo você realmente gasta em SO?"Nem tanto." Verifico Stack Overflow duas vezes por dia e geralmente respondo de 1 a 3 perguntas. E recebo a maioria dos votos positivos pelas respostas deixadas anos atrás. É assim que o SO ajuda os que vieram antes: eles foram os primeiros a responder perguntas anos atrás, receberam votos, e as vozes tornam essas respostas mais visíveis e, no final, obtêm novos votos. Este é um efeito de avalanche, encorajando respostas antigas.
Parece-me que isso causa alguns problemas, porque às vezes há novas respostas que se referem a tecnologias mais modernas e, portanto, são melhores, mas as respostas antigas não são atualizadas. Mas, em geral, recebo a maioria dos votos para as respostas antigas, mas ainda tento responder novas todos os dias. Não passo muito tempo nisso, faço isso constantemente por muitos anos.
- Quando John Skeet voou até nós no DotNext, perguntamos a ele sobre o estado atual do Stack Overflow e o que ele considerava serem os problemas do site. É interessante comparar: o que você acha disso?"Acho que o SO está melhorando, especialmente no ano passado." Agora eles estão tentando muito melhorar a qualidade das perguntas. Frequentemente, as pessoas que perguntam primeiro neste site não estão familiarizadas com a forma correta de fazer perguntas técnicas.
E esse é um problema que sempre esteve presente na Internet. Nos anos 90, quando todos estavam nos grupos de notícias, ela também estava lá. Dez anos depois, tudo aconteceu nas listas de discussão e nos Grupos do Google. Agora, um novo recurso para questões de programação Stack Overflow. Mas sempre houve perguntas sobre programação, e como fazer uma boa pergunta sempre foi um problema, e como manter uma comunidade amigável também. Talvez esses problemas nunca possam ser completamente resolvidos. Não estou dizendo que não devemos trabalhar nisso - devemos definitivamente. Mas se você olhar para o passado, acontece que mesmo nos anos 90 já havia tutoriais escritos sobre como fazer perguntas técnicas.
Existem alguns problemas novos no Stack Overflow. Você pode começar com o fato de que muitos deles nunca perguntaram a outra pessoa antes de fazer sua primeira pergunta. Portanto, em muitos casos, eles simplesmente não percebem todas as coisas que devem ser apresentadas na pergunta para que possam ser respondidas.
E então, imagine que você está trabalhando em uma tarefa. Você está de cabeça para baixo no código, sua cabeça está cheia de tudo isso. E você olha para algo específico que não se presta de forma alguma. Esse é um pequeno detalhe concreto de um sistema grande e, geralmente, você pergunta "Como posso fazer essa coisa pequena?" Sem perceber que você tem todo esse contexto que conhece, mas não o coloca em questão. Muitas vezes, a pergunta "Como faço para X" a resposta correta é "Não faça X, faça Y". Essa é uma armadilha na qual as pessoas geralmente caem ao escrever as primeiras perguntas. Eles não percebem que sua resposta em sua forma atual é "sem resposta".
Além do problema da qualidade das perguntas, há também uma tendência - especialmente no Stack Overflow, onde todos lutam por pontos, tentando responder o mais rápido possível - fecham rapidamente a pergunta ou rabiscam rapidamente as respostas mais agradáveis. Não quero dizer "rancoroso"; tenho visto muito poucos comentários francamente rancorosos - apenas alguns ao longo dos anos. Pelo contrário, são duras e, para o autor da pergunta, isso é lido como hostil.
O estouro de pilha tomou algumas etapas simples para corrigir isso. Agora, quando as pessoas fazem uma pergunta pela primeira vez, o site informa o que incluir nela. Eles acrescentaram anteriormente "olhe para essas perguntas semelhantes", que foi um bom primeiro passo. E agora há todo um sistema que precisa ser concluído para a primeira pergunta, o que ajuda a compor bem.
Eles também adicionam lembretes para quem escreve as respostas. É como "Este é um novato, seja amigável" e é uma boa maneira de lembrá-lo de que a maioria das pessoas não escreve bem as perguntas na primeira vez, e isso é completamente normal. Em geral, eles estão trabalhando nisso. Esse problema será resolvido completamente? Eu duvido. Mas o progresso é possível.
Assincronia
- Em uma postagem dedicada ao 10º aniversário do iPhone, você escreve que sua aparência afetou a programação assíncrona, porque os aplicativos móveis devem ser responsivos. E você pode dar uma base histórica geral sobre o desenvolvimento da assincronia para aqueles que recentemente começaram a se desenvolver e não viram o mundo sem async / wait?- Bem, a programação assíncrona sempre foi possível. Eu acho que nos anos 60 eles já estavam fazendo isso. E ele teve as mesmas vantagens por um longo tempo: uma interface do usuário mais responsiva e uma parte do servidor mais escalável. E o suporte sempre foi um problema: era muito difícil manter o código assíncrono. Inicialmente, ele foi construído em retornos de chamada.
Eu acho que o grande passo foi o advento da Promise. Era assim que eles chamavam em JavaScript e em C # é Task ou ValueTask. E este foi um grande passo à frente, porque agora temos um objeto representando a operação. Você pode monitorar seu progresso e assim por diante. E async / wait em qualquer idioma é essencialmente apenas um açúcar sintático em torno da Promise.
Eu diria que a aparência do Promise é o evento que teve mais impacto no código assíncrono. E no caso de assíncrono / espera, é importante que a máquina de estado seja criada para você. Antigamente, quando trabalhávamos com retornos de chamada, tínhamos que fabricar nossas próprias máquinas de estado. E sempre foi difícil, porque você inevitavelmente esquecia alguma condição ou transição e nada funcionava. E foi muito difícil depurar. Async / waitit não trouxe a capacidade de escrever código assíncrono, mas a capacidade de escrever código que pode ser suportado.
- E agora você vê a situação resolvida ou novas mudanças em breve nos aguardam?Acho que agora está tudo bem estável. O assíncrono / espera parecia revolucionário - mas apenas para aqueles que não haviam feito programação assíncrona antes. E para quem trabalhou, parecia muito natural. Mas, em geral, este foi um grande evento.
E agora outro evento vem com o .NET Core 3. Eles fazem o que todos chamam de fluxos assíncronos, embora sejam realmente enumeráveis assíncronos. Eu acho que isso vai confundir as pessoas, porque já existe um tipo de fluxo que não tem nada a ver com fluxos assíncronos. Em geral, haverá mais melhorias incrementais. Veremos algo tão maciço como quando o async / waitit se anunciou pela primeira vez? Eu acho que não.
Se você deseja uma nova mudança de paradigma, sempre existe a possibilidade de um sistema baseado em ator. Ou algo como goroutine, onde toda assincronia está implícita. Na minha opinião, essas coisas são um pouco semelhantes. O problema é que, no .NET, isso não é tão fácil de adicionar. Eu acho que há muitas restrições para o .NET fazer isso, então é improvável que isso aconteça. Se observarmos uma transição em larga escala para o mundo do ator ou do mundo das goroutinas, onde a abordagem da concorrência não será a mesma que a do multithreading de hoje, isso exigirá idiomas e tempos de execução completamente novos. E o .NET não vale a pena. E não creio que a programação como um todo dê esse salto. Talvez eu esteja errado, mas minha posição atual é a seguinte.
- Mais sobre a questão de quanto tudo muda ao longo do tempo. Muitos livros de programação estão rapidamente se tornando obsoletos, mas onde as mudanças são menores, elas duram mais. E quanto à sua simultaneidade no C # Cookbook , quanto ela requer atualizações?Boa pergunta. Acabei de publicar a segunda edição, e a primeira foi lançada em 2014. Ou seja, cinco anos se passaram e já estamos na segunda edição - para mim, parece um desenvolvimento rápido.
Eu acho que ainda depende de como o livro está escrito. Tentei escrever para que não ficasse desatualizado o máximo possível. Você só precisa tentar não se referir a coisas como o Windows Phone 8. Mas, inevitavelmente, ficará obsoleto. Aparecem fluxos assíncronos e afins, e eu queria incluir essas coisas no livro. Como resultado, algo estava desatualizado, mas a maior parte do material migrou para a nova edição sem alterações.
E, claro, tudo depende de quem é o livro. Obviamente, o livro sobre o uso do Visual Studio 2008 expirará muito rapidamente. Mas acho que há um lugar para clássicos genuínos. Considero o Code Complete um dos melhores livros de programação do mundo. E quanto tempo foi escrito? Eu nem sei. Décadas atrás. E este ainda é um livro fantástico! Algo está desatualizado, mas no geral ainda é ótimo.
- Recentemente, houve ajustes no assíncrono / aguardado no Twitter, que começaram com um tweet de Vaughn Vernon, autor de vários livros sobre DTD e modelos de atores:
Ele não gosta de assíncrono / espera imunidade - na sua opinião, isso se espalha por todo o código e pode levar ao bloqueio de threads. O que você acha disso? Valeu a pena projetar outra coisa?- Sim, talvez o fato de o assíncrono / espera estar se espalhando pelo projeto seja a queixa mais comum. Eu gostaria de mencionar algumas coisas aqui.
Primeiro, o código assíncrono, para ser realmente assíncrono, requer assincronia de todos que o chamam. E não dá a volta. Qualquer que seja o paradigma que você use (mesmo um dos antigos), no final, você o encontrará. Eu tinha um relatório onde analizava cronologicamente todos os paradigmas e mostrava como o código ficou mais limpo e melhor.
Existem algumas abordagens diferentes para evitar o domínio generalizado de assíncrono / espera. O primeiro é isolar todas as entradas / saídas em objetos separados. Você pode usar padrões de design como portas e adaptadores: isso permite que você contenha todas as E / S fora da lógica de negócios e, portanto, não precisará de nenhuma assíncrona / espera. Recentemente, vi um relatório completo sobre como impedir a "assíncrona em todos os lugares", refatorando o projeto para que a lógica de negócios nunca lide com E / S. Eu recomendaria essa abordagem.
Existe outra abordagem para lidar com o domínio de async / waitit, mas não é viável no .NET. Na minha opinião, Go tentou fazer isso com as goroutines. De fato, tudo está lá - é um sólido assíncrono / espera. Você pode remover async / waitit do idioma adicionando-o a tudo e tornando-o implícito.
Não há outras maneiras. Quando async / waitit apareceu, alguém (não me lembro exatamente quem) disse que era como um vírus zumbi: assim que parte do seu código é infectada, a distribuição começa.
- Alguns desenvolvedores usam o modelo de ator, explicando isso pela simplicidade do controle de fluxo (na verdade, os atores são de thread único). Você acha que, com a escolha certa de bibliotecas, os desenvolvedores podem se livrar da complexidade da simultaneidade de programação?"Bem, não exatamente." Porque mesmo com o modelo de ator, os problemas permanecem. Você não encontrará condições de corrida como em um programa multithread, mas terá dificuldades de amizade.
Por exemplo, problemas com o atraso da mensagem ou com mensagens assíncronas. Eles geralmente são necessários para evitar conflitos no modelo de ator. Mas qualquer modelo de ator que use mensagens assíncronas também pode causar conflitos. Mensagens assíncronas também podem criar seus próprios problemas de coordenação. Normalmente, nesse nível, também é preciso lidar com a idempotência.
Além disso, o uso de atores com mensagens assíncronas pode tornar o gerenciamento de estado bastante confuso, a menos que isso aconteça inteiramente nas mensagens. E mesmo neste caso, você terá dificuldades com a consistência eventual. Em geral, do meu ponto de vista, o modelo de ator não pode resolver todos os problemas. Eu descreveria da seguinte maneira: só pode mudar onde exatamente os problemas surgirão.
"Você é conhecido como doador, mas usa outras linguagens como o TypeScript." Quando você os experimenta, como isso faz você olhar para C # e .NET? Você encontra algo que gostaria de ver em C #?- Ótima pergunta. C # levou muito de outros idiomas. Um deles do qual ele tirou muito é o Python. E eu gosto disso. Não escrevo em Python há anos, mas acho que essa é uma linguagem muito bem projetada. Eu realmente aprecio os blocos de enumeradores que o C # emprestou do Python. E o Python foi um dos primeiros onde os fluxos Async apareceram, portanto, podemos dizer que o C # o retirou de lá.
Em diferentes idiomas, gosto de coisas diferentes. Geralmente, prefiro a digitação estática, por isso não uso o Python recentemente e, pelo mesmo motivo, estou usando o TypeScript em vez de JavaScript. O JavaScript tem suas vantagens simplesmente por causa de sua única segmentação. Por exemplo, se você observar a relevância das extensões reativas, verá que no .NET isso não é particularmente aceito. E em JavaScript, você pode ver o Rx em qualquer lugar.
- As últimas perguntas são sobre o seu relatório no DotNext. Você vai falar sobre fluxos assíncronos lá - você pode dizer brevemente aos desenvolvedores do .NET o que esperar e por que esse relatório será útil para eles?- Então, meu relatório sobre fluxos assíncronos: por que eles foram adicionados ao idioma e qual é o cenário principal para seu uso. Abordo isso de maneira muito pragmática e não entro em todos os detalhes do que está acontecendo sob o capô. , async streams, , , async streams, .
— . — DotNext?— , , , . , : , .
, , , . - async streams , , , . , DotNext.
DotNext 2019 Moscow 6-7 . , — .