Andrei Breslav atormenta os erros de design da Kotlin que não podem ser corrigidos // Estamos condenados # 6



Andrey Breslav dificilmente fala sobre Kotlin recentemente. Por duas vezes, liguei para uma entrevista e, nas duas vezes, ele me pediu para não discutir questões técnicas.

Por um lado, estou irritado. Eu entendo que todos os outros perguntaram a eles - mas não o fiz. Eu sou provavelmente o último jornalista puramente humanitário na Rússia que quer contar às pessoas sobre o lado da engenharia do setor, e não apenas sobre os milhões de empresários de sucesso levantados; e quem não perguntará isso patético "bem, explique aos meus ouvintes nos dedos como ele funciona para que eles entendam".

Por outro lado, os personagens das pessoas são mais compreensíveis e interessantes para mim pessoalmente do que as tecnologias, e fico feliz quando um desenvolvedor legal está pronto para falar sobre si mesmo como pessoa, não como uma unidade de trabalho.

Tirei a primeira entrevista de Breslav há um ano, mas nunca o libertei. O segundo foi chamado ao podcast junto comfillpackart. Ele refletiu sobre os sucessos e erros de Kotlin, brigou com nossos estereótipos sobre poliamor, ouviu reclamações sobre a vida e anexou uma palestra poderosa com a justificativa da digitação dinâmica.




Algumas citações do podcast

Por que não é mais interessante falar sobre desenvolvimento


Eu pratico Kotlin há dez anos e, nos últimos seis anos, todo mundo quer conversar comigo apenas sobre ele. Todo mundo tem as mesmas perguntas sobre Kotlin, estou muito cansado de respondê-las. Sem ofensas - é muito difícil encontrar uma pergunta que alguém não tenha feito nesses seis anos. Parece que isso é simplesmente inútil - eu já respondi, todos os materiais podem ser encontrados e lidos. Estou farto de terrivelmente, apenas terrivelmente.

Eu preciso falar sobre outra coisa. Agora estou mais interessado em tópicos humanitários - sobre psicoterapia, poliamoria, equilíbrio de gênero. Eu realmente quero entender esses aspectos da minha personalidade. Eu implementei os aspectos de engenharia - também quero outros.

Muitas vezes me pego falando sobre áreas em que sou pouco versado. Imediatamente começo a tirar conclusões - tenho uma propriedade dessas. Não tenho paciência para resolver cuidadosamente, ler a literatura, garantir que essa não foi a primeira coisa que me veio à cabeça. Mas falando de coisas fora do desenvolvimento, não tenho a sensação de estar completamente fora do lugar. Pelo contrário - parece que posso trazer um novo visual.

Sobre a atitude de Kotlin em relação ao sucesso


Sim, acho que essa é uma conquista que parece legal para muitos. Depois disso me acalmei um pouco.

Eu sempre fui autoconfiante - isso é uma força e uma desvantagem. Afinal, ainda era necessário se adequar a esse projeto, convencer-se de que podia. E eu não tive que persuadir. Eu tinha certeza de que sim, é claro, vamos fazê-lo. Havia um sentimento de que ele talvez não voasse. Mas o que fazer - não havia dúvida.

Minha autoconfiança costumava ser mais perturbadora. Eu pensava assim - "agora, eu sou legal, de repente todo mundo não vai entender isso". Agora tenho menos ansiedade e nem tenho certeza de que isso se deve ao grande sucesso de Kotlin. Este é um efeito cumulativo de coisas diferentes.

Eu era como psicoterapia - isso também removeu alguns tipos de ansiedade. Eu estraguei tantas vezes coisas diferentes e descobri as reais conseqüências dos erros. Eles pareciam ser catastróficos, mas estavam longe do que eu tinha medo. E, em geral, não são o que eu esperava - as consequências funcionaram em lugares completamente diferentes.

A calma veio da compreensão da extensão real dos riscos.

São falhas de design da Kotlin que não podem ser corrigidas


Não existem tais erros que eu não dormi à noite. Mas há coisas que surgem, e toda vez é uma piada. Em muitos lugares, era necessário fazer algo pequeno de outra maneira ou mudar algo importante na outra direção. Mas eu entendo que esse é o caso de todos.

Qualquer pessoa que criou um sistema grande e complexo que não pode ser refeito porque essas pessoas o usam tem esses pensamentos. Especialmente como no meu caso - se esse sistema foi o primeiro em sua vida.

Há pessoas que criaram um idioma, um compilador, uma máquina virtual, um banco de dados - qualquer sistema complexo e ele não ganhou popularidade. Em seguida, outra, terceira e única quarta tentativa decolou. E quando a quarta tentativa, já existe um entendimento de onde procurar; o que é importante e o que não importa. Não apenas em coisas que podem ser entendidas matematicamente - mas em termos de percepção dos outros.

É mais fácil para essas pessoas no sentido de que elas já sabem muito com antecedência. E eu não sabia, como tantos que tiveram sistemas de sucesso primeiro. Eles não sabiam onde as minas estavam dispostas. Apenas inchaços de pelúcia.

Parece-me que o usuário de qualquer sistema popular olha e pensa: "Senhor, por que isso é feito aqui!?" Sim, porque aquele de quem tudo dependia, há muito tempo, simplesmente não adivinhou. Bem, acontece - uma pessoa não adivinhou.

Que erro seria corrigido em primeiro lugar, se eu tivesse retornado ao passado


A porcaria mais importante - eu não comecei a recrutar uma equipe desde o início.

Era necessário recrutar uma equipe. Muito de tudo depende disso. O Kotlin foi lançado no 16º ano e era muito tarde. Saiu depois do Java 8. Muitas coisas muito importantes, do ponto de vista da promoção da linguagem, teriam sido completamente diferentes se eu não tivesse sido burro nos primeiros anos e digitado uma equipe.

Outra resposta é ainda melhor - você precisava procurar um mentor para o gerenciamento de projetos. Então eu tinha 26 anos, de alguma forma sabia escrever código, entendia melhor sobre linguagens de programação do que muitas, mas não sabia como gerenciar pessoas. Eu tive que procurar uma pessoa que saiba como e pedir que ele me dissesse.

Isso seria o melhor que eu poderia fazer, e então Kotlin seria muito mais legal do que ele é agora.

All Articles