Seguindo os passos do movimento russo Scala. Parte 2

Na última parte da investigação, Roman Timushev me aconselhou a entrar em contato com Vlad, o que fiz. Vlad esclareceu o que me interessa, delineia e concordou em escrever alguns parágrafos. Na manhã seguinte, vi um aviso no Facebook. Foi Vlad quem encontrou uma nova testemunha - Alexander Podkhalyuzin . De 2008 a 2017, ele trabalhou como líder de equipe no plug-in Scala no IDEA e viu pessoalmente todo o desenvolvimento do movimento Scala, mas principalmente não a parte russa.

"Clicou" na minha cabeça - os planos estão mudando, esse é um novo tópico na investigação. Eles marcaram a hora e gravaram uma entrevista de uma hora com Alexander. Há tanta informação que não havia opções para colocá-lo em qualquer lugar, exceto em uma parte separada. Portanto, aviso-o - há muito texto pela frente.



Nesta parte, estamos conversando com Alexander Podkhaluzin e Mikhail Mutsyanko . Fora do programa - comentário de Ilya Sergey . Plugin Scala, os primeiros eventos Scala na Rússia, saindo em Kotlin, nativo nos dois idiomas, Eclipse do pôr-do-sol e muito mais.

Como Alexander chegou a Scala, foi a Kotlin e ensinou

De 2008 a 2017, Alexander Podkhalyuzin desenvolveu o plugin JetBrains Scala no IDEA como líder de equipe. Mais tarde, ele partiu para o Kotlin Tooling primeiro para o Kotlin / Native, depois para o Kotlin como um todo.

Alexander : A tarefa é grande, tudo fica confuso após a limitação de anos. A propósito, o movimento começou não em 2010, mas três anos antes. Em 2007, acabei de trabalhar na JetBrains e tive sorte com o MPS ... Você sabe o que é o MPS?

Vadim : Ouvi dizer que é uma linguagem declarativa e visual.

Alexander : O MPS está adiantado. Este é o Meta Programming System - programação generativa imediatamente com o IDE. Consegui um emprego na empresa no MPS, mas eles já encontraram uma pessoa lá. Então tive sorte - fui enviado para escrever um plugin Scala.

O JetBrains começou a escrever um plugin, mas o descartou porque era o Groovy. Ele era popular e exigia apoio. Todos os envolvidos com o plug-in Scala foram trabalhar no plug-in Groovy. Ninguém estava envolvido em Scala e eu herdei essa herança.

Entrei para a empresa no início de 2008. Eu não sabia de nada, comecei a cavar um analisador, corrigi um bug, segundo, terceiro - isso continuou para sempre. Como resultado, ele se sentou e reescreveu. Tão lentamente foi se desenvolver.

Ilya Sergey trabalhou no plugin antes de mim. Eu o encontrei e trabalhei com ele no plugin. É engraçado que eu fosse matemático e Ilya fosse programador. Mas ele queria ser matemático e eu queria ser programador. Eu gostava de programação, estava pronto para fazer isso e não entendia por que a Ilya não gostava. E ele não me entendeu. Como resultado, a vida colocou tudo em seu lugar.

Ilya deixou o JetBrains e está envolvido em Ciência da Computação na Espanha, quase um professor. Ele chegou recentemente, contou como procurar corridas automáticas - isso é algum tipo de ciência. Ainda em alguma competição, ele se sentou e escreveu 10 mil linhas no Scala. Ele disse que tudo é super, tudo funciona. Ele ainda pilotou os primeiros Scala Days, ao que parece em 2009.

Depois de examinar a biografia de Ilya, senti que era importante esclarecer os detalhes da fonte original.

O relatório que Alexander mencionou foi sobre análise estática para encontrar condições de corrida em aplicativos Java. Em 2018, realizamos trabalhos em conjunto com o Facebook. Um relatório e mais dois artigos foram escritos nele. É verdade que existe todo o código no OCaml. A competição é o Concurso de Programação do ICFP que sediei este ano . Também escrevi quase todo o código do concurso no Scala usando o Scala.js.

Eu uso o Scala exclusivamente como usuário. Usando o plugin IntelliJ IDEA e Scala, muitos protótipos foram escritos para meus projetos de pesquisa: síntese de programas com ponteiros TyGus / suslik , teste de algoritmos geométricos . Na universidade, ensino um curso de multithreading, onde o Scala é o idioma principal.

Ilya Sergey , professora da Universidade Nacional de Cingapura .

Alexander : Comecei a montar o Scala Days em 2011. Há três anos, escrevemos o segundo compilador de front-end do Scala, na verdade. Leva anos, é normal. Tudo funcionou devagar e mal para nós, mas ao mesmo tempo havia pelo menos alguma coisa. Do ponto de vista dos editores, nada era melhor de qualquer maneira. Não me lembro se o Eclipse começou a suportar naquele momento. Sim, parece que eles o apoiaram em paralelo.

Vadim : Conversei com Roman Timushev e ele me contou que tinha 13 anos, como começou a escrever e realizar reuniões em Moscou. De acordo com sua versão, todos usavam o Eclipse. Foi bastante tolerável, foi oficialmente apoiado.

Alexander : Sim, foi. Em 2011, o Eclipse foi muito ruim e, em 2013, atingiu uma velocidade como a nossa em 2011. Ao contrário do Eclipse, escrevemos nosso próprio front-end, portanto, o realce do erro era diferente do compilador. Isso é inconveniente e é uma questão fundamental. Alguns erros não são destacados, mas vice-versa no compilador. O Eclipse usa código do compilador.

Usar o código do compilador é uma má idéia, porque tudo funcionará lentamente. No Kotlin, é semelhante ao usar o código do compilador. A situação não é tão ruim quanto em Scala - eles pensaram um pouco sobre o IDE, mas não é fácil fornecer um bom desempenho do ponto de vista do IDE.

Em 2011, Scalathon ( fotos ) foi realizada na Filadélfia. Esta é a primeira conferência para a qual fomos convidados, mas foi estranho termos ido lá. Eles entraram em contato com a JetBrains se quisermos participar do evento. Antes disso, eles não ligavam para Scala e, quando começamos a fazer algo, eles perceberam. Usuários, como programadores da Scala, tinham um nariz gulkin - cerca de 100 pessoas durante a conferência. Na Scalathon, conheci Bill Venners .

Vadim : O nome é familiar, mas não me lembro quem é.

Alexander : O autor de duas coisas: Scalatest e o livro principal Programming in Scala . Este é um livro escrito com Martin Odersky - nossa Bíblia!

Vadim : Eu não li.

Alexander : Isso não importa. Na minha casa é este livro autografado por Bill Venners e Martin Odersky. Eles me deram em um dos dias de Scala em 12 ou 13 anos. Em um jantar para todos os participantes, as pessoas que contribuíram para a comunidade foram premiadas. De repente, eles me ligaram e recebi um livro pela minha contribuição.

O Scala Days também começou a ser visitado desde 2011. Inicialmente, eram realizadas uma vez por ano na Europa ou na América e depois duas vezes. No ano passado, participei de uma conferência, mas não fui à segunda. No ano passado, enviei um relatório sobre a comparação entre o Kotlin / Native e o Scala Native. Ninguém na equipe de Kotlin acreditava que o relatório seria aceito, mas foi aceito. Talvez por respeito ou por outras razões. O relatório foi assistido por poucos ouvintes. Os programadores da Scala não estão interessados ​​em tudo o que contém a palavra "Kotlin". Então foi e ainda é.

Vadim : Eu acho que a palavra "Nativo" teve um papel.

Alexander : Não, nos dias do Scala, todos os relatórios do Scala Native sempre reúnem salas cheias, por exemplo, uma performance de Denis Shabalin. Mas, ao mesmo tempo, a tecnologia está longe de ser produzida. Ela não está destinada a chegar lá por mais 10 anos, pelo menos.

Vadim : Por que você acha isso? Fiquei surpreso, mas há Richard Whaling que escreve um livro sobre o Scala Native - já existe muito material. Ele vai a podcasts e fala sobre como ele é usado na produção. Ele tem uma esfera onde há muitos dados. Ele está muito satisfeito com o Native nessas condições.

Alexander : Veja meu relatório sobre a comparação de Scala Native e Kotlin / Native , no qual explico meu ponto de vista. No momento da apresentação, uma pessoa trabalhou no Scala Native. Portanto, não se pode falar em nenhum produto. Se falamos de uma pessoa que em algum lugar aplicou tecnologia - talvez. Não é apenas mainstream, haverá poucos usuários.

O Kotlin / Native possui um aplicativo específico - compartilhamento de código entre iOS e Android. Apenas isso cria um certo interesse. O Scala Native não tem isso e não há nada a que se agarrar. O Scala Native pode ser usado para cálculos quando você precisa combinar o código Scala e cálculos rápidos como o Tensorflow. Mas o Scala Native não significa que entre o Scala e o Native você possa se chamar com segurança ou se atrapalhar com o código comum.

No Kotlin, estamos nos esforçando para escrever e compilar o mesmo código. Esse é um trabalho infernal no sentido de que você não está usando o POSIX, mas algum tipo de biblioteca entre camadas que funciona igualmente bem na JVM e sem ela. Se você não tem uma biblioteca, é isso, krants. O código será diferente nesse local e, se for diferente, como mantê-lo? Como implantar bibliotecas nas quais diferentes pontos de extremidade precisam ser compilados, implantados, também existe um sistema de compilação, dependências? Se você cavar, então as perguntas - o abismo. Uma pessoa que desenvolve o Scala Native não pode responder a todos. Aplicação é uma história separada, e sobre isso você pode ver o meu relatório.

Vadim : Bem, vamos voltar. Em 2011, você foi ao Scala Days e, antes de 2016, você ainda estava com o plugin Scala?

Alexander : Até 2017.

Vadim : Então você entrou no Kotlin. O que aconteceu

Alexander : De algum ponto de vista, eu não fiz tudo o que pude. Você pode continuar desenvolvendo o plug-in Scala - muitas fichas, há algo a terminar. Mas, do ponto de vista comercial, é bem-sucedido como projeto. 80% dos programadores Scala usam o IntelliJ IDEA. Quanto você conhece de produtos que conquistaram 80% do mercado? Existem alguns deles.

O que fazer depois? Quero novos objetivos, novos horizontes e, dentro do plugin Scala, isso era impossível. O JetBrains está desenvolvendo sua própria linguagem de programação e é cético em relação ao Scala. É impossível encontrar um lugar para a Scala na empresa, então eu saio ou trabalho aqui e depois. Na empresa qualquer, ou qualquer outra coisa. Eu tive que tomar uma decisão difícil.

Até certo ponto, eu estava me preparando. Primeiro - eu percebi que se eu deixar o time, então Kolya Tropin estará no meu lugar. Ele agora está liderando a equipe. Eu estava me preparando, e de uma maneira peculiar, entendi que ele poderia ficar no meu lugar. O segundo - distribuiu lentamente todos os subsistemas, recusou-os. Eu não precisava mais programá-los.

A apoteose de tudo isso foi uma lesão na mão, cirurgia e 2 meses de licença médica. Após a saída, fui ao diretor geral Maxim Shafirov. Ele veio e disse: "Me dê outra coisa". Havia um gatilho, algo inconscientemente se preparava para poder fazer isso, e esses dois meses foram decididos. E Max sugeriu. Eu disse "qualquer coisa menos Kotlin". Entendo, sou do mundo Scala, e o mundo Scala odeia Kotlin.

Vadim : Não é que eu odeie, é apenas desagradável que esse produto tenha aparecido. Este é o esboço do Scala. Ao mesmo tempo, o marketing está ativo, o mercado está sendo capturado - aquelas pessoas que poderiam ir para o lado positivo da Scala.

Por outro lado, isso é bom? Se você imagina uma lacuna no conhecimento que precisa dominar para escrever efetivamente no Scala ou Haskell, então, para um desenvolvedor Java, é gigantesco. Aqui Kotlin é um ponto de transbordo que você pode alcançar, sentar e seguir em frente com segurança.

Alexander : Isso não é totalmente verdade. Quando não havia Kotlin, as pessoas procuravam o Scala que não estava satisfeito com o Java - algo estava faltando, um monte de clichê. Scala substituiu o que é chamado Better Java. Kotlin visa exclusivamente a esse nicho.

Com Kotlin, Android e tudo o que aconteceu, e agora multiplataforma, isso é tudo. Kotlin não se fixou em um Android, em um nicho e foi além.

Vadim : Eu acho que é bom - a Oracle se mexeu. Agora, pelo menos alguns JEPs normais foram feitos para fazer o Java evoluir.

Alexander : Eu acho que o motivo não é Kotlin - essa é uma consequência normal. Dois anos antes do Google anunciar o Kotlin, era insignificante. Quando decidi me mudar, Max Shafirov me deu uma lista para seleção. Embora eu tenha dito “simplesmente não o Kotlin”, a opção de suporte nativo do Kotlin / IDEA estava nesta lista. Como resultado, da lista toda, decidi tentar mudar para Kotlin. No dia seguinte ao comando do Kotlin / Native, Andrei Breslav disse que, no próximo Google I / O, eles anunciariam que o Kotlin era oficialmente um idioma Android.

Aqui está o pensamento: "Pateta". Eu pensei que estava fazendo algo por uma linguagem condicionalmente marginal. Ficou claro que o nicho Better Java era difícil de conquistar. Com o lançamento do Java 8 com lambdas, isso se tornou ainda mais difícil. Scala está bem com isso, não é forte com lambdas e nem com o que é melhor que Java. É aleatório - pessoas aleatórias chegaram ao Scala com o entendimento de que precisam de um Java melhor.

Após o Java 8, o fluxo dessas pessoas diminuiu. Eles não vão para Scala e Kotlin - eles têm lambdas. Isso é suficiente para começar, e o melhor não está mais interessado. Sentei-me, pensei e percebi que a escala agora é diferente.

Na minha cabeça, mudei para uma equipe em uma escala não muito maior do que no plugin Scala. Naquela época, havia 100 mil usuários e Kotlin tinha 40 mil. Uma escala completamente diferente. Percebi que é divertido, que eles não me disseram com antecedência. Decidi ir a Kotlin porque era interessante tentar, e não por objetivos ambiciosos e ambiciosos.

Em geral, Scala é mais agradável de programar. Quando você começa a escrever Kotlin após 9 anos de programação em Scala, acaba sem as mãos. Há alguma tristeza nisso.

O que eu faria se fosse CTO? Para alguma tarefa simples do Kotlin, seria mais fácil montar uma equipe. Seria mais barato ou mais eficiente. Eu poderia ter recrutado programadores Scala mais baratos, mas eu teria piorado, porque eles fariam algo terrível neste Scala. Mesmo que seja difícil no mercado de trabalho, começarei a recrutar programadores Java - o Kotlin será muito mais fácil treiná-los. É do ponto de vista do início de um novo projeto, se não houver coisas tecnológicas sérias.

Para o setor bancário, por exemplo, existem razões para usar o Scala. Kotlin não pode resolvê-los. A mesma metaprogramação em Scala é muito mais conveniente.

Se você pensar muito sobre esse tópico, poderá criar itens interessantes de infraestrutura no Scala, mas isso é impossível no Kotlin. Existem os mesmos processadores de anotação. Um dia será possível, mas apenas na perspectiva de vários anos.

Vadim : Por que você acha que o Scala é bom para os bancos?

Alexander : Há muitos clichês que não estão relacionados à linguagem de programação. Este é um sistema em que existem objetos do tipo usuário. Requer muita duplicação, iniciando no banco de dados e terminando com tudo. Para alterar algo efetivamente, você precisa de um bom suporte de metaprogramação. É necessário em qualquer lugar, mas é necessário mantê-lo com cuidado, caso contrário, você poderá ficar preso.

No ano 11, fui chamado para a Universidade Acadêmica. Eu estava com preguiça de ministrar todo o curso e concordei com Sveta Isakova , que agora é advogada desenvolvedora de Kotlin. Concordamos em fazer o curso pela metade, mas tratava-se de Scala. Ela provavelmente queria aprender mais sobre Scala.

Vadim : A universidade era a melhor da época?

Alexander : Sim, com uma magistratura no curso 5-6. Os primeiros anos da competição foram pequenos. Mas a competição pelo local aumentou quando JetBrains, Yandex e Transas vieram com patrocínio, um convite para estágios e o objetivo de aumentar o pessoal para si.

Ficou legal: dinheiro privado e uma iniciativa privada protegida pelo Estado e protegida por Alferov. Ele deu uma carta branca completa - faça como quiser! Ficou ótimo, porque os cursos são relevantes. Eles recrutaram pessoas que estavam na vanguarda, entenderam o que estava acontecendo no setor no momento e, há dez anos, não estava claro onde. Se falamos de universidades comuns, como "mathmech / mehmat", então Pascal não passa por lá - isso não tem nada a ver com a vida real.

Esta era uma forte universidade acadêmica. As pessoas entendiam que quando chegassem lá, voariam muito rapidamente para o setor. Graduados universitários com prazer recrutados em Yandex e JetBrains. Este é um bom passo na carreira, e a competição contou com 10 alunos. Eu ensinei lá por 5 anos. No segundo ano, Sveta não conversou comigo sobre Scala, e chamei vários assistentes, em particular Sveta para Kotlin. Como resultado, renomeamos para idiomas da JVM.

Em algum momento, recebi o apoio de Clojure e entendi um pouco dessa linguagem. Segundo os alunos, eles não entendiam o que Clojure estava fazendo, que tipo de porcaria era. Eles falam sobre idiomas normais - Scala e Kotlin e, de repente, arrastaram Clojure. Eu simplesmente não era um especialista. Essa foi a história.

Sobre o primeiro ScalaSPB / ScalaDev

Alexander : Então eventos como Scala Days apareceram em São Petersburgo. O primeiro ScalaDev passou e, para o segundo evento, os organizadores do Scala Days original entraram em contato com São Petersburgo e pediram para serem renomeados.

Vadim : Em que ano é este?

Alexander : Sim, está tudo lá - 11-13. O evento foi realizado por caras da e-legião terceirizada de São Petersburgo. Parece que eles escreveram o aplicativo Raiffeisenbank. Eles até escreveram um aplicativo móvel no Scala, mas agora ninguém escreve dessa maneira - as pessoas são loucas.

Vadim : Um dos convidados do podcast - Matvey Malkov - falou sobre Scala e Android há dois anos. Ele disse que está tudo bem com eles, e eles o usam. Seu principal ganho é o back-end e os aplicativos Scala.

Recentemente, escrevi para ele com um pedido para falar na conferência, porque você não encontra ninguém sobre telefones celulares. Aconteceu que ele deixou a empresa e a última coisa que ele fez foi configurar a Cot para construir o módulo Kotlin a partir desse projeto no Scala, de modo que os caras gradualmente se aproximassem dele.

Alexander : Dois anos atrás, nada estava claro sobre Kotlin. Teoricamente, o Google poderia usar Scala, mas não o fez.

Nós nos apresentamos nos primeiros dias da Scala e até reunimos pessoas. Mais precisamente, não no primeiro, mas no segundo, realizado no JetBrains. Então Sveta Isakova se apresentou com uma introdução em Kotlin.

Foi engraçado - todos os desenvolvedores do Scala perceberam o Kotlin como o inimigo número um. Hall reagiu de forma muito negativa, fez perguntas: "Por que isso não está sendo feito, por que não é, por que não é?" Era assustador, algum tipo de invasão.

Depois de Sveta, eu fui a segunda pessoa a dizer algo sobre Kotlin na conferência Scala - sobre Kotlin / Native. Minha experiência mostrou que isso não faz sentido. Não sou a favor do relatório, estava interessado em ver o Scala Native. Como é organizado, inicie programas, regozija-se com alguma coisa. Mesmo naquela época, fiquei feliz por o tamanho binário do Scala Native ser menor que o do Kotlin. Acho que o Kotlin / Native tem menos agora, porque 10 pessoas estão trabalhando nisso.

Vadim : Oh, bem, você definitivamente está estrangulando Denis Shabalin .

Alexander : Isso é impossível, é uma tecnologia muito complexa. Temos 10 pessoas, e isso não é suficiente. E 10 pessoas legais, bem legais, tente essas mais coletadas. O próprio Denis é legal, mas o que ele pode estar sozinho?

A história sobre a comunidade é bastante interessante, assim como toda a história de Scala. Muitas pessoas queriam criar algum tipo de estrutura, provavelmente ninguém precisava dela, para anunciar e sair. Muitas estrelas peculiares se formaram, e algumas também ajudaram a EPFL. Um dos requisitos é um trabalho de graduação de um estudante de graduação. Por exemplo, Scalameta é o trabalho de Zhenya Burmako . No processo de trabalho, os estudantes de pós-graduação aumentam o preço como programador e, após a graduação, encontram um trabalho interessante. O primeiro emprego com salário é mais do que para as pessoas que trabalham há 10 anos. Por serem famosos, relataram várias conferências e giraram.

Aqui está outra coisa. Você vê, em Kotlin: aqui vamos fazer, aqui está, e em Scala absolutamente o mesmo. Aqui está Tasty, no RI de back-end da Kotlin. Mas, como em Scala tudo dirige a comunidade, tudo está em completo caos. Não há design centralizado. O que acontece vai dar certo. O homem queria queimar algo, acabou. Martin gostou, a aprovação foi para as massas. E na Kotlin, de maneira cada vez mais clara e profissional, é isso que a indústria significa.

Sobre Eclipse e Jason Zaugg

Alexander : Em 13, fomos à conferência. Todos no compilador programaram no Eclipse. Ficamos de pé e as pessoas que usavam o IDEA se aproximaram de nós. Eles ficaram satisfeitos, agradecidos. Temos 10% do mercado, o restante no Eclipse. Todos os compiladores estão sentados nele. Eles nos contornaram por um longo tempo, de repente nós os convencemos a usá-lo. Mas em algum momento houve uma mudança.

Nos anos 11 ou 12, tivemos um colaborador, Jason Zaugg . No mundo do código aberto, isso não é estranho, mas raramente aparecem pessoas que investem muito tempo e codificam muito. Jason veio, ganhou muito dinheiro e trabalhou em um banco. Nós até demos a ele o direito de confirmar. Ele nem precisou mostrar a revisão para publicação. Eles apenas ficaram sentados, codificados, discutiram algumas coisas juntos. Com base no nosso front-end, ele descobriu como o Scala funciona. Tudo terminou com Jason conseguindo um emprego como compilador Scala. É triste que não tenhamos organizado isso por nós mesmos. Eu acho que essa é a estratégia errada. Se uma pessoa trabalha para você de graça - ela precisa ser organizada por si mesma, caso contrário, ela irá para o compilador Scala. Não havia mais disso.

Jason é uma ótima pessoa e um colaborador legal. Ele era um fã da IDEA. O fato é que o plug-in Scala depende do código do compilador. O código é complexo - injeção de dependência (DI), que, em essência, é um padrão de bolo. Ao abrir qualquer arquivo, você precisa analisar o compilador inteiro. Devido ao DI, há TUDO no contexto, e tudo existe com inferência de tipo, e você precisa exibir o tipo em qualquer lugar - tudo está entrelaçado. A análise de um arquivo levou 5 minutos. Mesmo na configuração do compilador como um projeto, o bootstrap ainda veio. Ele deve depender de si mesmo, isso é chamado de inicialização. Tais projetos eram difíceis de montar.

Jason e eu passamos muito tempo nos adaptando. Para tornar possíveis os projetos de autoinicialização, programe no compilador, para que pelo menos você possa digitar o código nesses arquivos complexos. No começo, tudo estava vermelho, e eu gastei muito tempo para transformar tudo em verde. Até fizemos um teste que verificou se nosso frontend no compilador é verde ou contém poucos erros. E, consequentemente, a equipe do compilador mudou totalmente para o IDEA.

Vadim Chelysov : Nesse momento começou o fluxo do Eclipse?

Alexander : Existem várias razões para a saída. Primeiro, a IDEA lançou uma versão da comunidade. Isso significa que você pode colocar o plug-in Scala na versão gratuita do usuário. Éramos de código aberto desde o início e, quando começamos, era proprietário, com código aberto. Mas foi instalado em um IDE pago. Para isso, eles escreveram o suporte ao Eclipse, porque precisavam de uma ferramenta padrão que possa ser usada gratuitamente. Portanto, também nos tornamos livres.

O segundo - Eclipse como plataforma começou a desaparecer em '14. Ele não morreu, é ridículo dizer, mas o financiamento quebrou abruptamente. A Eclipse Foundation começou a coletar menos dinheiro e não está claro como desenvolver a plataforma nessas condições.

A terceira razão é que eles não conseguiram criar um IDE rápido. O compilador de apresentações funcionou devagar e, se falarmos sobre algum tipo de funcionalidade - geralmente é tryndets, a refatoração é extremamente difícil de fazer. No compilador, do ponto de vista da otimização, as árvores são construídas unidirecionalmente, você não pode usar um pai. Para encontrar o nó pai, você precisa pegar um arquivo de cima, ir até eles e parecer um barulho terrível.

A quarta razão é que eles trabalham com exibição no compilador. Esta é a árvore que é obtida após a dissociação. O editor está escrito na instrução front e, no compilador de apresentações, geralmente não está claro que tipo de código. Não está claro como trabalhar com isso e organizar a refatoração. Como extrair essa declaração de frente, e não toda essa porcaria louca? Consequentemente, os recursos apareceram lentamente.

Ao mesmo tempo, nosso front-end era miserável e não funcionava bem. Mas, para que ele fosse pelo menos assim, ele teve que fazer coisas terríveis. Era uma vez, o método para {i <- 0 to 10} println(i) necessário suporte para 80% do idioma. Como está desacoplado e você tem uma conversão implícita para o Range - 1 to 10 , no caminho de uma conversão implícita para o map , os parâmetros implícitos são CanBuildFrom . Além disso, ainda existe uma hierarquia louca de coleções e lambdas, e alguns outros lambda anônimos com um parâmetro desconhecido - lata completa. Depois que este exemplo funcionar, você precisará entender que funciona 80% do front-end. Portanto, mesmo um front-end ruim significava que apoiamos uma quantidade incrível de funcionalidades do Scala.

Agora, o IDEA escreveu muitos conversores de idiomas. Eles são estranhos, mas diferentes, e quando tudo começou, ninguém se lembra. Em 2009, fui a uma conferência e fiquei chocado - por que não fazer uma conversão de Java para Scala? Discutimos que você se cansará de ponto e vírgula para remover e expandir tipos - você precisa se mover de alguma forma. Sentei-me e escrevi mil linhas à noite - um simples conversor de um idioma para outro.

Mas fui mais longe e descobri como facilitar a localização desse recurso. Quando copio para o código Java, espero inserir e remover ponto e vírgula agora. Este é o meu caso favorito quando você cria um recurso ideal para descoberta. Embora você não precise dela, você não a conhece. Assim que você precisar, você o obtém imediatamente. É como um estilo da Apple - simples e direto. Assim, desde então, muitos conversores foram escritos pelo JetBrains, e o recurso de publicidade é que eles são oferecidos na inserção. Mas sim, eu vim com isso, esse é o meu orgulho.

Sobre compiladores

Mikhail Mutsianko , um dos desenvolvedores atuais do plugin Scala no JetBrains, está conectado à gravação. Nesta edição do podcast, Mikhail e seu colega Andrei Kozlov discutiram o plugin em mais detalhes.

Alexander : Estou censurando as histórias do Scala aqui. Misha, me diga como você apareceu?

Michael : Apareci originalmente em Kotlin. Andrei Breslav fez um dos primeiros estágios - um estudante. Eu cheguei ao projeto de gerar o bytecode Kotlinovsky DSL da biblioteca de interface do usuário do Android. Ela agora é chamada anko . Então procurei algum tópico para obter um diploma e ele me enviou para Sasha. Como diploma, fiz um intérprete de árvore para Scalameta.

Alexander : Precisamente, esse é o tópico que Misha obteve na forma de um diploma - suporte à metaprogramação. Misha fez isso por um longo tempo. Fizemos alguma coisa no final?

Michael : Sim, funcionou. É verdade que Scalameta foi repreendido. O Scala 3 terá algo semelhante, mas com uma API mais padronizada.

Alexander : Eu não sei nada sobre Dotty.

Vadim : Acabei de ver hoje que Miles Sabin se atrapalhou com seu código, onde ele muda para o Dotty com novas macros, e parece que acabou. Tipável migrado.

Mikhail : Sim, em particular, ele é uma daquelas pessoas que dá instruções sobre como digitar em Scala, para que Shapeless trabalhe fora da caixa, sem muletas. Essencialmente, dobre a forma para o compilador.

Alexander : Oh, vamos lá! Você está brincando Diga-me, Scalaz se curva?

Michael : Bem, de alguma forma, não está claro quem Scalaz está escrevendo agora. Miles não está parado atrás dele.

Vadim : Agora toda a comunidade está cuidando de Dotty. Miles parece disforme. Pela enésima vez, essas implicações mudaram, juntamente com uma discussão sobre como fazer as classes Type de Luka Jacobowitz .

Alexander : Sobre a comunidade. No início do 17º ano, o Scala Center decidiu reunir influenciadores da comunidade para o grupo de trabalho . Os JetBrains sempre foram vistos de longe e com cuidado. Deus não permita que tornemos a programação no IntelliJ IDEA perigosa. Quando se tornou difícil negar que você ainda precisa programar na IDEA, fomos aceitos. Eles me convidaram para uma discussão, mas depois machuquei minha mão e não vim. Então ele deixou Scala e nunca apareceu no grupo de trabalho.

Sempre me divertiu que as pessoas dissessem: "Por que precisamos documentar os detalhes do compilador, ainda não existe um segundo compilador?" Isso foi engraçado porque o plug-in Scala sempre foi o segundo compilador alternativo. Ainda havia o Typelevel, é claro, mas é um garfo.

Fomos muito influenciados pelo desenvolvimento do Scala. Quando Jason Zaugg apareceu no compilador, foi legal. Ele começou a nos dizer: "Fizemos isso, nos apoie". Existe uma comunicação. Quando os compiladores olham para baixo e não os usam, eles não nos dizem nada. Isso foi antes de Jason.

Michael : Agora chuto periodicamente Guillaume Martres , que viu Tasty, e Fengyun Liu - ele vê macros.

Resumir

Vadim : Alexander, muito obrigado, vamos resumir. Eu falei com um homem ontem. Ele disse que em Scala ele gostava do conceito único de implícito, no qual pendiam vários recursos. Agora, no Dotty, eles adotaram os mesmos métodos de extensão explícita, obviamente todas as implicações dos casos de uso foram declaradas com palavras exatas. Espionou Kotlin e Swift, provavelmente. Como você se sente sobre isso? E, em geral, para Scala 3?

Alexander : Em 2018 foram os últimos dias da Scala que visitei. Sobre isso, Martin Odersky falou sobre o fato de o Scala ter tantos conceitos de linguagem, o Kotlin três vezes mais, o C # ainda mais. Mas, ao mesmo tempo, os recursos do Scala são mais amplos.

Nós pensamos que era legal, mas não é. Fiquei impressionado, percebi que Martin entende que precisamos nos mudar. A única coisa que preocupa é que Scala se torne um tipo de linguagem de nicho. As possibilidades ilimitadas da linguagem criam esse mesmo nicho. Este é o DSL que ela sabe fazer, e é tudo legal. Perseguir o Kotlin pelo melhor Java é difícil e mais difícil a cada ano. O principal é não perder o seu nicho. Se eles adicionarem toda essa funcionalidade e não perderem seu nicho, será legal. Mas se Miles executar tudo, poderá funcionar. Sim Misha?

Nas partes seguintes da investigação sobre a origem do movimento Scala, aguardamos uma entrevista com Vladimir Uspensky, Roman Elizarov e Nikolai Tatarinov. Se você deseja adicionar novas facetas ao histórico do movimento Scala ou compartilhar sua experiência de uso, envie relatórios . A chamada de trabalhos é encerrada após 10 dias.