Não sei você, mas para mim não há melhor começo do dia do que me preocupar com programação. O sangue ferve ao ver uma crítica bem-sucedida de uma das línguas "ousadas" usadas pelos plebeus, atormentada durante todo o dia de trabalho entre visitas tímidas ao StackOverflow.

(Enquanto isso, você e eu usamos apenas a linguagem mais esclarecida e as ferramentas sofisticadas projetadas para as mãos hábeis de mestres como nós).

Obviamente, como autor do sermão, corro riscos. Você pode gostar do idioma que eu zoo! Um panfleto imprudente poderia ter inadvertidamente levado ao meu blog uma multidão furiosa de celulares com forquilhas e tochas prontas.

Para me proteger do fogo justo e não ofender seus sentimentos (provavelmente delicados), falarei sobre a linguagem ...

... quem acabou de aparecer. Sobre uma efígie de palha, cujo único papel é queimar críticos em jogo.

Sei que isso parece bobagem, mas acredite, no final, veremos cujo rosto (ou rostos) foi pintado em uma cabeça de palha.

Novo idioma

Será um exagero aprender um idioma completamente novo (e chato) apenas para um artigo de blog, então digamos que seja muito semelhante ao idioma que já conhecemos. Por exemplo Javascript. Chaves e ponto e vírgula. if , while , etc. - Lingua franca da nossa multidão.

Eu escolhi JS não porque este artigo é sobre ele. É apenas uma linguagem na qual o leitor comum provavelmente entrará. Voila:

 function thisIsAFunction(){ return "!"; } 

Como o bicho de pelúcia é uma linguagem legal (de leitura ruim), possui funções de primeira classe . Então você pode escrever algo como isto:

 //  ,     , //    function filter(collection, predicate) { var result = []; for (var i = 0; i < collection.length; i++) { if (predicate(collection[i])){ result.push(collection[i]); } } return result; } 

Este é um dos recursos de primeira classe e, como o nome sugere, eles são legais e super úteis. Você provavelmente está acostumado a transformar coleções de dados com a ajuda deles, mas assim que compreende o conceito, começa a usá-los em qualquer lugar, caramba.

Talvez nos testes:

 describe("", function(){ it(" ", function(){ expect("").not.toBe(""); }); }; 

Ou quando você precisar analisar (analisar) os dados:

 tokens.match(Token.LEFT_BRACKET, function(token){ // Parse a list literal... tokens.consume(Token.RIGHT_BRACKET); }); 

Depois de acelerar, você escreve todos os tipos de bibliotecas e aplicativos reutilizáveis ​​que giram em torno de funções, chamadas de funções, retornos de funções - um estande funcional.

tradutor: no original "Functapalooza". O prefixo -a-palooza é tão legal que você deseja compartilhá-lo com todos.

Qual a cor da sua função?

E aqui começam as esquisitices. Nossa linguagem tem uma característica peculiar:

1. Cada função tem uma cor.

Cada função - um retorno de chamada anônimo ou uma função regular com um nome - é vermelha ou azul. Como o destaque do código em nosso blog não destaca as diferentes cores das funções, vamos concordar que a sintaxe é:

 blue*function doSomethingAzure(){ //   ... } red*function doSomethingCarnelian(){ //    ... } 

Nossa linguagem não possui funções incolores. Deseja criar um recurso? - deve escolher uma cor. Estas são as regras. E há mais algumas regras que você deve seguir:

2. A cor afeta a maneira como a função é chamada

Imagine que existem duas sintaxes para chamar funções - "azul" e "vermelho". Algo como:

 doSomethingAzure(...)*blue; doSomethingCarnelian()*red; 

Ao chamar uma função, você deve usar uma chamada que corresponda à sua cor. Se você não adivinhou - eles chamaram a função vermelha com *blue após os colchetes (ou vice-versa) - algo muito ruim acontecerá. Um pesadelo esquecido na infância, como um palhaço com cobras em vez de mãos que se escondia embaixo da sua cama. Ele pulará do monitor e chupará seus olhos.

Regra estúpida, certo? Ah, mas mais uma coisa:

3. Somente a função vermelha pode causar a função vermelha.

Você pode chamar a função azul do vermelho. Isto é kosher:

 red*function doSomethingCarnelian(){ doSomethingAzure()*blue; } 

Mas não o contrário. Se você tentar:

 blue*function doSomethingAzure(){ doSomethingCarnelian()*red; } 

- você será visitado pelo velho Clown Spider Maw.

Isso torna mais difícil escrever funções mais altas, como filter() do exemplo. Devemos escolher uma cor para cada nova função e isso afeta a cor das funções que podemos passar para ela. A solução óbvia é tornar o filter() vermelho. Então podemos chamar pelo menos funções vermelhas, pelo menos azuis. Mas então nos machucamos com o próximo espinho na coroa de espinhos, que é o idioma indicado:

4. Funções vermelhas causam dor

Não identificaremos essa "dor", apenas imagine que o programador deve pular o arco toda vez que ele chamar a função vermelha. A chamada pode ser muito polissilábica ou você não pode executar a função em algumas expressões. Ou você só pode acessar a função vermelha a partir de linhas ímpares.

Não importa o que seja, mas se você decidir tornar a função vermelha, todos que usarem sua API quererão cuspir no café ou fazer algo pior.

A solução óbvia nesse caso é nunca usar funções vermelhas. Apenas deixe tudo azul e você estará de volta ao mundo normal, onde todas as funções são da mesma cor, o que é igual ao fato de que elas não têm cor e que nossa linguagem não é completamente idiota.

Infelizmente, os sádicos que desenvolveram essa linguagem (todos sabem que os autores de linguagens de programação são sádicos, certo?) Prendem o último espinho em nós:

5. Algumas das principais funções do idioma são vermelhas.

Algumas funções integradas à plataforma, funções que precisamos usar e que não podem ser escritas por nós mesmos, estão disponíveis apenas em vermelho. Nesse ponto, uma pessoa inteligente pode começar a suspeitar que esse idioma nos odeia.

Isso é tudo culpa das linguagens funcionais!

Você pode pensar que o problema é que estamos tentando usar funções de ordem superior. Se pararmos de brincar com toda essa bobagem funcional e começarmos a escrever funções azuis de primeira ordem normais (funções que não operam com outras funções - aprox. Translator), conforme planejado por Deus -, nos livraremos de toda essa dor.

Se chamarmos apenas funções azuis, tornaremos todas as nossas funções azuis. Caso contrário, tornamos vermelho. Até criarmos funções que aceitem funções, não precisamos nos preocupar com "polimorfismo com a cor da função" (policromático?) Ou com outras bobagens.

Mas, infelizmente, funções de ordem superior são apenas um exemplo. O problema surge toda vez que queremos dividir nosso programa em funções para reutilização.

Por exemplo, temos um pequeno pedaço de código que, bem, não sei, implementa o algoritmo de Dijkstra sobre um gráfico que representa o quanto suas conexões sociais pressionam umas às outras. (Passei muito tempo tentando decidir o que o resultado significaria. Indesejabilidade transitiva?)

Mais tarde, você precisou usar esse algoritmo em outro lugar. Naturalmente, você quebra o código em uma função separada. Ligue para ela do lugar antigo e do novo. Mas que cor deve ser a função? Você provavelmente tentará torná-lo azul, mas e se ele usar uma dessas funções "apenas vermelhas" desagradáveis ​​da biblioteca do kernel?

Digamos que o novo local do qual você deseja chamar a função seja azul? Mas agora você precisa reescrever o código de chamada em vermelho. E, em seguida, refaça a função que chama esse código. Ufa Você terá que se lembrar constantemente da cor de qualquer maneira. Esta será a areia do seu calção de banho em uma programação de férias na praia.

Alegoria da cor

Na verdade, não estou falando de cores. Isso é uma alegoria, um artifício literário. Foda-se - isso não é sobre as estrelas nas barrigas , é sobre a corrida. Você provavelmente já suspeita ...

Funções vermelhas - assíncronas

Se você programar em JavaScript ou Node.js, sempre que definir uma função que chama uma função de retorno de chamada (retorno de chamada) para "retornar" o resultado, você escreverá uma função vermelha. Veja esta lista de regras e observe como elas se encaixam na minha metáfora:

1. Funções síncronas retornam um resultado, funções assíncronas não; em troca, chamam um retorno de chamada.
2. As funções síncronas retornam o resultado como um valor de retorno, as funções assíncronas o retornam, causando o retorno de chamada que você passou para eles.
3. Você não pode chamar uma função assíncrona de uma síncrona, porque não pode saber o resultado até que a função assíncrona seja executada posteriormente.
4. Funções assíncronas não são compiladas em expressões devido a retornos de chamada, exigem que seus erros sejam tratados de maneira diferente e não podem ser usados ​​em um bloco de try/catch ou em várias outras expressões que controlam o programa.
5. A coisa toda sobre o Node.js é que a biblioteca do kernel é toda assíncrona. (Embora eles doem de volta e começaram a adicionar versões _Sync() a várias coisas).

Quando as pessoas falam sobre "inferno de retorno de chamada" , falam sobre como é irritante ter funções "vermelhas" em seu idioma. Quando eles criam 4089 bibliotecas para programação assíncrona (em 2019, já em 11217 - aprox. Tradutor), eles tentam lidar com o problema no nível da biblioteca de que estavam presos à linguagem.

Eu prometo que o futuro é melhor

na tradução: "Eu prometo que o futuro é melhor" o jogo de palavras do título e do conteúdo da seção está perdido

As pessoas no Node.js há muito tempo percebem que os retornos de chamada são prejudiciais e estavam procurando soluções. Uma das técnicas que inspirou muitas pessoas são as promises , que você também pode conhecer pelo apelido de futures .

na TI russa, em vez de traduzir "promessas" como "promessas", foi estabelecido um papel vegetal do inglês - "promessas". A palavra "Futuros" é usada como é, provavelmente porque os "futuros" já estão ocupados por gírias financeiras.

Promis é um wrapper para retorno de chamada e manipulador de erros. Se você está pensando em passar um retorno de chamada para o resultado e outro retorno de chamada para o erro, o future é a personificação dessa ideia. Este é um objeto básico que é uma operação assíncrona.

Acabei de receber um monte de palavras sofisticadas e pode parecer uma ótima solução, mas principalmente é óleo de cobra . As promessas realmente facilitam a escrita de código assíncrono. Como são mais fáceis de compor em expressões, a regra 4 é um pouco menos rigorosa.

Mas, para ser sincero, é como a diferença entre um golpe no estômago ou na virilha. Sim, não dói tanto, mas ninguém ficará encantado com essa escolha.

Você ainda não pode usar promessas com tratamento de exceção ou outros
operadores de gerenciamento. Você não pode chamar uma função que retorne future do código síncrono. (você pode , mas o próximo mantenedor do seu código inventará uma máquina do tempo, retornará no momento em que você o fez e enfiará um lápis na sua cara pelo motivo 2).

As promessas ainda dividem seu mundo em metades assíncronas e síncronas com todo o sofrimento que se segue. Portanto, mesmo que seu idioma suporte promises ou futures , ele ainda se parece muito com o meu idioma de pelúcia.

(Sim, isso inclui até o Dart que eu uso. Portanto, estou tão feliz que parte da equipe esteja tentando outras abordagens do paralelismo )

link do projeto abandonado oficialmente

Estou aguardando uma solução

Os programadores de C # provavelmente se sentem complacentes (a razão pela qual estão se tornando cada vez mais vítimas é que Halesberg e a empresa polvilham tudo e polvilham a linguagem com açúcar sintático). Em C #, você pode usar a palavra-chave await para chamar uma função assíncrona.

Isso torna a realização de chamadas assíncronas tão fácil quanto síncrona, com a adição de uma pequena palavra-chave atraente. Você pode inserir uma chamada em await nas expressões, usá-las no tratamento de exceções, no fluxo de instruções. Você pode enlouquecer. Vamos esperar a chuva como dinheiro para o seu novo álbum de rapper.

O Async-Waitit é bom, então o adicionamos ao Dart. É muito mais fácil escrever código assíncrono com ele. Mas, como sempre, há um "Mas". Aqui está. Mas ... você ainda divide o mundo ao meio. As funções assíncronas agora são mais fáceis de escrever, mas ainda são funções assíncronas.

Você ainda tem duas cores. A espera assíncrona resolve o problema irritante nº 4 - eles tornam as funções de chamada em vermelho não mais difíceis do que as chamadas em azul. Mas o restante das regras ainda está aqui:

1. Funções síncronas retornam valores, funções assíncronas retornam um wrapper ( Task<T> em C # ou Future<T> em Dart) ao redor do valor.
2. Síncrono apenas chamado, necessidade assíncrona de await .
3. Ao chamar uma função assíncrona, você obtém um objeto wrapper quando realmente deseja um valor. Você não pode expandir o valor até tornar sua função assíncrona e chamá-la com await (mas consulte o próximo parágrafo).
4. Além de aguardar um pouco de decoração, pelo menos resolvemos esse problema.
5. A biblioteca principal do C # é mais antiga que a assincronia, então eu acho que eles nunca tiveram esse problema.

Async realmente melhor. Eu preferiria espera assíncrona a retornos nus em qualquer dia da semana. Mas mentimos para nós mesmos se pensarmos que todos os problemas estão resolvidos. Assim que você começa a escrever funções de ordem superior ou a reutilizar o código, percebe novamente que a cor ainda está lá, sangrando por todo o seu código-fonte.

Qual idioma não é cor?

Então, JS, Dart, C # e Python têm esse problema. CoffeeScript e a maioria das outras linguagens compilando também em JS (e Dart herdado). Acho que mesmo o ClojureScript tem essa pegada, apesar de seus esforços ativos com o core.async

Quer saber qual deles não? Java Estou certo Com que frequência você diz: "Sim, apenas Java está fazendo certo"? E assim aconteceu. Em sua defesa, eles estão tentando ativamente corrigir sua supervisão promovendo futures e E / S assíncronas. É como uma corrida pior que pior.

tudo já está em Java

C #, de fato, também pode contornar esse problema. Eles escolheram ter cor. Antes de adicionarem async-waitit e todo esse lixo eletrônico Task<T> , era possível usar chamadas de API síncronas regulares. Três outros idiomas que não têm um problema de "cor": Go, Lua e Ruby.

Adivinha o que eles têm em comum?

Streams. Ou, mais precisamente: muitas pilhas de chamadas independentes que podem ser trocadas . Esses não são necessariamente threads do sistema operacional. Corotinas em Go, corotinas em Lua e threads em Ruby são adequadas.

(É por isso que existe essa pequena advertência para C # - você pode evitar a dor assíncrona em C # usando threads.)

Memória de operações passadas

O problema fundamental é "como continuar do mesmo local quando a operação (assíncrona) é concluída"? Você mergulhou no abismo da pilha de chamadas e depois chamou algum tipo de operação de E / S. Por uma questão de aceleração, esta operação usa a API assíncrona subjacente do seu sistema operacional. Você não pode esperar para concluir. Você deve retornar ao loop de eventos do seu idioma e dar tempo ao SO para concluir a operação.

Quando isso acontece, você precisa retomar o que estava fazendo. Geralmente, o idioma "lembra onde estava" na pilha de chamadas . Ele segue todas as funções que foram chamadas no momento e olha para onde o contador de comandos em cada uma delas aparece.

Mas, para executar E / S assíncrona, você deve relaxar, descartar toda a pilha de chamadas em C. Digite Trick-22. Você possui E / S super rápidas, mas não pode usar o resultado! Todos os idiomas com E / S assíncrona sob o capô - ou, no caso de JS, o loop de eventos do navegador - são forçados a lidar com isso de alguma forma.

Node, com seus retornos de chamada marcantes para sempre, enfia todas essas chamadas em fechamento. Quando você escreve:

 function makeSundae(callback) { scoopIceCream(function (iceCream) { warmUpCaramel(function (caramel) { callback(pourOnIceCream(iceCream, caramel)); }); }); } 

Cada uma dessas expressões funcionais fecha todo o contexto circundante. Isso transfere parâmetros, como iceCream e caramel , da pilha de chamadas para a pilha . Quando uma função externa retorna um resultado e a pilha de chamadas é destruída, isso é legal. Os dados ainda estão em algum lugar na pilha.

O problema é que você precisa ressuscitar cada uma dessas chamadas malditas novamente. Existe até um nome especial para esta conversão: estilo de passagem de continuação

vincular funcionalidade feroz

Isso foi inventado por hackers de linguagem nos anos 70, como uma representação intermediária para uso sob o capô de compiladores. Essa é uma maneira muito bizarra de introduzir código que facilita a execução de algumas otimizações do compilador.

Ninguém nunca pensou que um programador pudesse escrever esse código . E então Node apareceu e, de repente, todos fingimos escrever um back-end do compilador. Onde nós viramos o caminho errado?

Observe que promessas e futures realmente não ajudam muito. Se você usá-los, sabe que ainda está acumulando camadas gigantes de expressões funcionais . Você apenas os passa para .then() vez da própria função assíncrona.

Aguardando uma solução gerada

Async-waitit realmente ajuda. Se você olhar embaixo do capô para o compilador quando ele encontrar, você verá que ele realmente realiza a conversão do CPS. É por isso que você precisa usar await em C # - esta é uma dica para o compilador - "interrompa a função aqui no meio". Tudo o que await depois se torna uma nova função que o compilador sintetiza em seu nome.

É por isso que o async-waitit não precisa de suporte de tempo de execução dentro da estrutura .NET. O compilador compila isso em uma cadeia de fechamentos relacionados, com os quais ele já sabe como lidar. (Curiosamente, os fechamentos também não precisam de suporte de tempo de execução. Eles são compilados em classes anônimas. Em C #, os fechamentos são apenas objetos.)

Você provavelmente está se perguntando quando menciono os geradores. Existe yield no seu idioma? Então ele pode fazer algo muito semelhante.

(Acredito que os geradores e o async-waitit são realmente isomórficos. Em algum lugar nos cantos e recantos empoeirados do meu disco rígido existe um pedaço de código que implementa um ciclo de jogo nos geradores usando apenas o async-wait).

Então, onde eu estou? Ah sim. Assim, com retornos de chamada, promessas, espera assíncrona e geradores, você acaba pegando sua função assíncrona e dividindo-a em vários fechamentos que ficam na pilha.

Sua função chama externa em tempo de execução. Quando o loop de eventos ou a operação de E / S é concluída, sua função é chamada e continua de onde estava. Mas isso significa que tudo no topo da sua função também deve retornar. Você ainda precisa restaurar a pilha inteira.

É daí que vem a regra: "Você só pode chamar a função vermelha a partir da função vermelha" Você deve salvar toda a pilha de chamadas nos fechamentos para main() ou para o manipulador de eventos.

Implementação da pilha de chamadas

Mas, usando threads ( verde ou nível do SO), você não precisa fazer isso. Você pode simplesmente pausar o segmento inteiro e pular para o SO ou o loop de eventos sem precisar retornar de todas essas funções .

A linguagem Go, no meu entender, faz isso da maneira mais perfeita. Assim que você fizer qualquer operação de E / S, o Go estacionará essa corotina e continuará qualquer outra que não seja bloqueada pela E / S.

Se você observar as operações de E / S na biblioteca padrão Golang, elas parecem síncronas. Em outras palavras, eles simplesmente funcionam e retornam o resultado quando estiverem prontos. Mas essa sincronização não significa o mesmo que no Javascript. Go- , IO . Go .

Go — , . , , .

, API, , . .

, , . , . , 50% .

, , , .

Javascript -, , , JS , JS , . , JS .

, ( ) — , , , async . import threading ( , AsyncIO, Twisted Tornado, ).

, , , , , , .

, Go, Go .

, , , ( - ) , "async-await ". .

, .

, , .