"Quantos espectadores virão à sua conversa sobre Java?" Depende se Venkat está se apresentando no salão adjacente ao mesmo tempo. ”
É uma piada com uma quantidade razoável de verdade: no mundo Java,
Venkat Subramaniam é um dos oradores mais famosos, capaz de atrair espectadores de outras salas em conferências. Ele tem se deslocado incansavelmente pelo planeta e recentemente estabeleceu um recorde impressionante, quando completou 50 anos falando em um ano antes de 50 grupos de usuários Java diferentes.
Como é quando sua carreira em Java não está "sentada no escritório", mas "constantemente em movimento"? E o que a Venkat pensa sobre os problemas atuais do Java? Em outubro, ele chegará a São Petersburgo e, antecipando isso, nós (
phillennium ,
olegchir ) o entrevistamos em detalhes, onde começamos com “vida no avião” e dicas para iniciantes, e depois passamos para a tecnologia.
Como Venkat responde em detalhes, o texto é longo. Se desejar, você pode ir imediatamente para a segunda parte:
Pela vida
- Vamos começar com o seu tour, durante o qual você visitou 50 grupos de usuários Java, quase ninguém fez isso antes. Quais foram suas impressões?- O mais interessante para mim foi a constatação de que, em diferentes culturas em diferentes partes do mundo, pessoas que falam idiomas diferentes, apesar de todas essas diferenças, estão unidas pela programação como um único fio de conexão. Quando começamos a falar sobre programação, verifica-se que os problemas que enfrentamos todos os dias são os mesmos. Essa foi uma ótima descoberta para mim - você pode conhecer um programador em qualquer aeroporto do mundo e definitivamente encontrará tópicos comuns para conversar. Posso listar incessantemente casos em que estive envolvido em falar sobre Java do outro lado da Terra.
Portanto, a experiência com esses grupos foi muito útil para mim. Gerenciar um grupo de usuários é muito difícil ... Não quero dizer "trabalho" porque não é trabalho, mas você precisa gastar muito esforço. Tenho um grande respeito por todos os líderes que reúnem esses eventos repetidamente todos os meses. Grupos diferentes têm dinâmicas diferentes - alguns têm 20 ou 30 pessoas nas reuniões, outros 200 ou 300. No entanto, o número, de fato, não tem um papel, porque o principal é a paixão dos desenvolvedores que vêm a essas reuniões, seu interesse em tecnologia e seu desejo de aprender. Por isso, tive muita sorte de ter tido a oportunidade de me encontrar com esses grupos e sou muito grato por isso.
- E com a semelhança mencionada, os grupos de usuários em diferentes partes do mundo apresentam diferenças locais visíveis?- Essas diferenças são surpreendentemente poucas. Percebi que em algumas regiões é dada mais preferência a estruturas pesadas e, em outras, a soluções mais leves. Mas, como regra, todas essas características são superficiais, e questões e problemas profundos, pelo contrário, são universais. Sinceramente, gostaria de lhe dizer que em algum momento no mapa as pessoas estão fazendo coisas completamente diferentes das nossas, e tudo é interessante e inesperado lá, mas não posso dizer isso.
Todos nós lutamos pela complexidade, isso nos arrasta e, quando se arrasta, começamos a combatê-la. Esta é uma tendência geral em quase todos os lugares. Outro problema importante que ninguém escapou são os requisitos rigorosos dos negócios e a falta de tempo para trabalhar com qualidade. Posso falar sobre algum exemplo para pessoas de qualquer parte do mundo e, depois da minha história, perguntam-me: "você trabalhou na nossa empresa?" Nossos problemas são tão profundos e universais que, aparentemente, são comuns ao mundo inteiro. O que involuntariamente nos faz pensar em nossa essência humana comum, em psicologia e filosofia, que finalmente seguimos. Não importa o quanto nos imaginemos quando os nerds se voltam para a tecnologia, não devemos esquecer o aspecto humano no desenvolvimento de software. Aparentemente, ele é uma força unificadora e universal.
- Gostaria de perguntar sobre um estilo de vida de "acampamento". Quando você se senta no escritório, pode não ser óbvio se você gostaria de uma vida como a sua. Por exemplo, para muitos, o jetlag é um problema e, por causa disso, voos constantes podem parecer um pesadelo. Mas talvez com a prática, você se adapte a isso?- Para responder sua pergunta, lembremos da integração contínua. Se uma equipe realiza a integração uma vez por mês, você sugere que eles façam isso o tempo todo, eles o consideram louco. Nisso, as relações de viagem se assemelham à integração e entrega contínuas: se você lida muito com elas, sua abordagem para elas muda.
Não me interpretem mal, não tenho orgulho do meu modo de vida, na minha opinião, não vale a pena viver assim. Eu sempre digo que nas viagens eu menos gosto das próprias viagens. Sentar em um avião é cansativo, o corpo se desgasta e, com a idade, esses problemas não vão a lugar algum. Mas quando chego ao meu destino, quando encontro outros desenvolvedores, vejo sua paixão pela tecnologia, seu entusiasmo, tenho a oportunidade de compartilhar essa paixão, aprender algo novo e ajudar a aprendê-lo, todas as dificuldades são recompensadas com juros.
Se falamos sobre a mudança de fuso horário, isso não me incomoda. Devido aos vôos constantes, em certo sentido, não tenho tempo constante em casa. Eu tenho uma regra: eu sempre acordo no mesmo horário local, por volta das 3h30 da noite, e o corpo rapidamente entra em um certo ritmo. E, claro, o café é sempre muito bem-vindo.
- Muitas pessoas gostariam de ver o mundo, mas costumam fazer viagens turísticas, e não em viagens de negócios. Você consegue ver as cidades ou devido à falta de tempo apenas nas salas de conferência?- Sim, em parte há um problema com o tempo. Mas, além disso, devido a vôos constantes, tenho alguns princípios aos quais aderi. Se a jornada está ligada ao trabalho, não faço nada além de trabalhar. Eu tento passar o máximo de tempo possível com os desenvolvedores. Quando tenho um sábado ou domingo grátis, por exemplo, na Europa, geralmente o gasto em um grupo de usuários. É um prazer enorme me comunicar com os desenvolvedores; portanto, nas minhas viagens de negócios, quase nunca vou a lugares de interesse.
Mas todos os anos, durante quatro ou seis semanas no verão, viajo com minha família e vamos passear. Este é o nosso tempo para um descanso conjunto, e nos meses restantes me concentro no trabalho.
Além disso, minha abordagem me permite prestar a máxima atenção a vários eventos da comunidade, o que também me dá um grande prazer. Isso consome muito tempo e é uma espécie de compromisso, mas combina comigo. A vida às vezes é muito estressante e fico feliz com a oportunidade de, às vezes, me distrair e ouvir desenvolvedores que talvez não tenham a oportunidade de participar de uma conferência ou curso de treinamento. Além disso, acredito que esse também é meu dever profissional, pelo fato de que foram essas coisas que me inspiraram na minha juventude. Eu visitei grupos de usuários, ouvi apresentações e sonhei em meu tempo também em me apresentar. Se eu, por sua vez, conseguir inspirar pelo menos uma pessoa da mesma maneira, esse tempo será bem gasto.
- Última pergunta de viagem. No filme "Up in the Air", o personagem de George Clooney, constantemente viajando entre cidades, conhece muitos truques para melhorar a eficiência da viagem: como ficar na fila, como arrumar as malas e assim por diante. Talvez você também tenha algum conhecimento não óbvio que gostaria de compartilhar?“Tenho vergonha de admitir, mas às vezes envio roupas entre as cidades na FedEx, porque simplesmente não tenho tempo para voar para casa e levar roupas para a próxima semana. Muitas vezes, quando chego ao hotel, minhas roupas já estão lá e, quando saio, as envio para casa. Felizmente, isso não acontece com muita frequência, talvez três ou quatro vezes por ano, quando estou a caminho por três semanas seguidas. Houve um momento embaraçoso em que minha esposa teve que ir ao aeroporto para me entregar as malas, porque eu só tinha meia hora entre os vôos. Mas com o tempo, você realmente aprende a fazer algumas coisas com mais eficiência. Às vezes, me surpreende quando as pessoas dizem "preciso fazer as malas" porque minhas coisas são coletadas o tempo todo.
Falando em eficiência, tenho pelo menos uma vantagem: sou uma pessoa que trabalha muito sozinha. Vivemos no mundo do Facebook, Twitter e vários mensageiros, eles constantemente nos distraem. Eu trabalhei duro para reduzir esse efeito, porque minutos se transformam em horas, horas em dias, dias em semanas e, mais cedo ou mais tarde, você percebe que não conseguiu o que queria. Normalmente, tenho um diário no qual escrevo coisas que precisam ser feitas para cada viagem. Portanto, tenho uma programação para todos os dias (por exemplo, 7 de novembro ou 8 de outubro) e meu telefone me lembra cada tarefa no dia correspondente. Durante um voo de oito horas, posso escrever a maior parte de um capítulo do livro ou preparar um exemplo para o curso. Portanto, os voos para mim são um período extremamente eficaz. Eu nunca preciso de entretenimento adicional durante o vôo - um amplo entretenimento relacionado à depuração de código é suficiente. Portanto, um viajante profissional (se esse termo é geralmente aplicável) passa o tempo em voo de maneira bem diferente de um turista.
- Provavelmente, por causa da sua fama, você recebe muito mais cartas do que os desenvolvedores comuns. Quanto eles escrevem para você e quanto tempo leva para o correio demorar?- Vale acrescentar que ensino na universidade e recebo muitas cartas dos alunos. Normalmente recebo 20 ou 30 cartas por dia. Há cerca de um ano,
escrevi em um blog sobre um dos meus princípios: "responda agora ou diga quando responder".
Eu realmente valorizo meu tempo, o que significa que valorizo o tempo de outras pessoas. Na minha opinião, o respeito por outra pessoa não está no apelo do senhor, mas em apreciar o tempo uma da outra. Portanto, se uma carta chegar, eu sempre respondo dentro de 24 horas. Mas há momentos em que não funciona para dar uma resposta completa - por exemplo, se o organizador da conferência pede para enviar uma anotação ou se um colega do setor faz uma pergunta sobre como resolver um determinado problema, pede para refatorar algum código ou pergunta sobre o uso de um determinado método. Às vezes, a resposta pode levar dez minutos, e às vezes duas horas, mas nem mesmo dez minutos podem ser gastos. Isso pode parecer um pouco estranho, mas eu ainda respondo nesses casos em 24 horas e escrevo: recebi sua carta, trabalharei nesse problema, por exemplo, 2 de setembro e escrevi para você o 3º. Ao mesmo tempo, meu calendário é atualizado com a entrada correspondente no dia em que tenho tempo de voo ou à tarde.
Graças a essa abordagem, minha caixa de entrada está sempre vazia, eu a limpo todas as noites antes de dormir. Portanto, sou extremamente disciplinado em responder cartas. As pessoas geralmente ficam surpresas que eu respondo às cartas tão rapidamente, mas eu, pelo contrário, não entendo o contrário. Não quero ficar no caminho das pessoas, para impedir que elas se desenvolvam. Além disso, considero importante dizer não. Eu gosto de repetir que quanto mais você diz sim, pior será o que faz. Em um determinado momento, você precisa perceber que não podemos alcançar tudo no mundo. Portanto, às vezes eu respondo que, infelizmente, não posso ajudar. Por sua vez, prefiro que me digam não imediatamente, e não puxe a borracha e não diga depois. Na minha opinião, isso também fala de respeito pela pessoa e falta de vontade de perder seu tempo em vão. Você não precisa ajudar, mas pelo menos não se incomode. Portanto, é importante dizer não. É assim que a vida é organizada, não tente fingir que você pode fazer tudo no mundo. Para mim, a capacidade de responder rápida e honestamente é um sinal de profissionalismo.
- Você é um orador muito experiente. Como organizadores da conferência, conhecemos pessoas que não têm experiência em falar em público ou que têm muito poucas. Talvez você tenha recomendações para eles? Você teve uma dica interessante no Twitter "para visitar a sala em que o relatório será realizado com antecedência" - existe mais?- Meus primeiros relatórios foram em grupos de usuários, e é por isso que continuo fazendo 15 relatórios todos os anos. E recomendo que outras pessoas comecem com a mesma coisa: com um grupo de usuários na sua região, depois em um vizinho e assim por diante.
Por muitas razões, esses relatórios têm menos riscos do que em uma grande conferência: existe uma atmosfera amigável, as pessoas vêm até lá para compartilhar conhecimento; depois dos seus relatórios, será fácil obter uma resposta. Você pode começar muito bem a apresentação dizendo que tem pouca experiência nesse assunto e gostaria de conhecer a opinião do público. Este ano, tive um novo relatório, durante o qual experimentei muito. Escrevi sobre isso no Twitter: parece que tudo pode ser dito em dois minutos, mas, na realidade, o material não pode ser colocado em uma hora e meia. E estou muito feliz por ter feito esse relatório pela primeira vez em um grupo de usuários, pois isso me deu a oportunidade de prepará-lo melhor para a conferência.
Nos grupos de usuários ou na empresa em que você trabalha, você tem uma grande oportunidade de praticar apresentações. Primeiro, você receberá críticas de colegas, o que permitirá melhorar o relatório. Em segundo lugar, mesmo que eles não digam nada diretamente para você, você ainda entenderá bastante quando começar a falar. Penso que é possível melhorar realmente o relatório a partir da terceira vez. A primeira vez que você está apenas tentando reunir todos os pensamentos. E eis o que é interessante: praticar sozinho não ajudará aqui, a conscientização dos problemas ocorre apenas quando se fala com outras pessoas. Pela terceira vez, a cadeia lógica de sua narrativa se torna mais clara para você, ela está concluída. Isso nem sempre é perceptível, mas às vezes paro durante o meu discurso pela terceira vez - neste momento percebo o que era eu quem estava tentando dizer no relatório que um tipo de momento de verdade vem. Portanto, a prática é muito importante, mas não sozinha, mas com as pessoas. Isso pode dar ao jovem desenvolvedor a confiança necessária.
É verdade que alguns fazem seus primeiros relatórios em conferências. Às vezes, é mais fácil para uma pessoa morrer do que falar em público, e é fácil entender - são necessários muitos nervos. Dois ou três anos atrás, falei em uma conferência. Uma pessoa muito interessada me procurou e disse que, aparentemente, eu estava muito preocupada, ao que respondi que era realmente assim. Ele perguntou: “Este é o seu primeiro relatório?”, E eu respondi: “Não, provavelmente dez mil, é por isso que estou preocupado.” Cada apresentação na frente da platéia exige muito estresse emocional, mesmo se você tiver muita experiência, simplesmente porque se preocupa com o andamento do relatório. Você fará um ótimo trabalho se aliviar essa tensão com alguns relatórios de teste em grupos de usuários ou em sua empresa. Isso se aplica a todos os palestrantes, incluindo os experientes.
- Mas há algo em falar em público que deve, pelo contrário, ser evitado?"Cometi muitos erros na minha vida que me ensinaram que as pessoas aprendem melhor com a experiência." Quando você fala com uma audiência, há algumas coisas a serem lembradas. Em primeiro lugar, você precisa manter a autoconfiança: você trabalhou muito no tópico e sabe muito sobre ele. Em segundo lugar, lembre-se: é impossível saber tudo, e a ignorância de algo não é sua culpa. Significa apenas que você não teve a oportunidade de prestar atenção nisso, e não há nada de errado nisso. É extremamente importante admitir honestamente isso para si mesmo. Você pode responder à pergunta na conferência assim: desculpe, não posso lhe dizer nada, não tive a oportunidade de estudar esse problema.
Outro ponto importante é que os ouvintes podem ser divididos em três tipos. Há pessoas que querem aprender algo novo com você. Outros se mantêm um pouco mais cuidadosos, eles o ouvirão, mas não estarão prontos para perceber tudo o que você diz. Finalmente, há um terceiro grupo de pessoas, felizmente, bastante pequenas: aquelas que são hostis e estão tentando pegá-lo o tempo todo. Mais cedo ou mais tarde, seu relatório definitivamente terá um desenvolvedor que o interromperá o tempo todo e interromperá o andamento do relatório. Nesses casos, é muito importante manter a calma, deixá-lo falar e retornar a discussão à direção que você precisa - mas, devo admitir, também sou uma pessoa e nem sempre consigo fazer isso. Você pode, por exemplo, dizer: Entendo que isso é importante para você, vamos discuti-lo após o relatório, esse tópico é importante para muitos aqui. É verdade que muitas vezes você tem aliados na platéia e, quando uma pessoa realmente viola o curso de seu discurso, pede-lhe que se acalme. Tudo isso digo ao fato de que é importante não estarmos em conflito demais nessas situações, mesmo que nossa natureza possa resistir a isso. Como jovem orador, muitas vezes entrei em tais confrontos com força total, e isso nunca trouxe nenhum bem a ninguém. É necessário mostrar maturidade emocional e não tentar provar nada a ninguém a seu respeito, entrando nesse tipo de escaramuça. Em vez disso, nesses casos, o tópico deve ser levado de volta ao que é interessante para o público.
Eu também gostaria de falar sobre alguns hábitos negativos durante as performances, que, na minha opinião, os desenvolvedores têm. Para começar, as pessoas devem olhar nos seus olhos. Entendo que isso é muito difícil e requer muito esforço emocional, mas você precisa praticar isso. Os oradores costumam olhar para o monitor ou, pior ainda, para a tela, de costas para a platéia. Você sempre precisa estar de frente para o público e sempre deve olhar para eles. Além disso, a autoconfiança deve ser mantida. Você fala com um público de programadores e pode apostar que nenhum deles possui código que funcione pela primeira vez. Se sua demonstração não funcionou durante a apresentação, não há nada de errado nisso. Todos os presentes provavelmente vão pensar: "Porra, tudo é exatamente o mesmo comigo." Ao longo dos anos, aprendi nessas situações a recorrer ao público para obter ajuda na depuração. Geralmente, os falantes nessa situação começam a murmurar algo baixinho e tentam resolver todas as dificuldades por conta própria. Em vez disso, você deve perguntar à platéia - amigos, você pode me dizer onde eu sou burra?
Você receberá imediatamente muitas ofertas e, muitas vezes, elas o ajudarão a encontrar o erro. É difícil para uma pessoa falar e escrever código ao mesmo tempo, não tenha medo de pedir ajuda. Para os ouvintes, essa experiência também é valiosa. Essa é uma das razões pelas quais visito os relatórios de outras pessoas: para ver o que eles estão fazendo e entender o que exatamente não deve ser feito. Na minha opinião, esses hábitos o ajudarão a refatorar suas habilidades de orador.
Sobre a tecnologia
— Java- , Java «Hello world». «public static void main» , , .
: Java- , , , . , . - - Java?— , . , , Java — , 2000-. , , , .
, , , , , . , , 70 try-catch . , , , .
— . , , , . , , . , . , .
Java 12, 13 14 : , , Java , , . , , Java , . , , . , , Java . , , , Java . , , , , , Java .
. Joker «Don't walk away from complexity, run» . , Joker , , .
- No contexto de "Java menos bombástico", é impossível não perguntar sobre o Kotlin, que costuma ser chamado assim."Sim, isso é verdade." E o assunto não é apenas menos pretensioso. Para mim, uma das coisas mais emocionantes da vida é conhecer novos idiomas e suas capacidades. Uma possibilidade no Kotlin é executar um lambda no contexto de um objeto, mesmo que não faça parte da classe. Fiquei muito interessado quando descobri, porque a mesma possibilidade está presente no JavaScript. Lá, você pode passar um objeto de contexto na chamada (o que Kotlin chama de receptor) e, em seguida, executar essa função global arbitrária como se fosse uma função de algum objeto. O fato de esse recurso estar em JavaScript não é surpreendente, pois esse idioma é dinâmico. Mas o Kotlin é uma linguagem estática e faz o mesmo, respeitando a segurança do tipo. A falta de pretensão, é claro, é uma grande vantagem da linguagem, assim como o fato de gerar uma parte significativa do código automaticamente, para que não possamos escrever os mesmos modelos repetidamente. Mas os benefícios não param por aí, pois esse recurso permite criar DSLs internos.
A ciência e a matemática me levaram à programação, mas 30 anos depois continuo sendo programador devido ao fato de ser arte. Nosso campo combina ciência e arte, não há como fugir disso. A capacidade de simplesmente fazer o sistema funcionar não é limitada; aqui você pode fazer uma analogia com a poesia: peça a duas pessoas que escrevam sobre o amor, e cada uma escreverá à sua maneira. O código para qualquer tarefa pode ser escrito de várias maneiras diferentes. É isso que me atrai para idiomas como o Kotlin e muitos outros: a capacidade de expressar algumas dessas idéias, dar flexibilidade e leveza ao código. Você pode pensar muito menos na sintaxe do idioma e mais no pensamento que deseja transmitir.
- A qualidade do código é de grande importância para você. Parece ser importante para todos e parece que todo mundo quer escrever melhor, mas sabe-se que uma parte significativa do código existente tem problemas. Portanto, a pergunta é: para que seus colegas não o odeiem pelo seu código, você só precisa de autodisciplina, você pode dar recomendações específicas?"Estou convencido de que a única maneira de escrever código legível é lê-lo." Quando eles me dizem que o código é legível, pergunto - quem o leu? Se o próprio autor o leu imediatamente após a escrita, isso não conta. Portanto, acredito firmemente na revisão de código. Quero esclarecer: sou contra trazer uma equipe para uma sala com uma tela grande, mostrando o código e criticando-o. Isso inevitavelmente leva a queixas, como okhayanie público ninguém é bom.
Devemos admitir honestamente: todos escrevemos códigos incorretos. Tenho orgulho de admitir: meu código é péssimo, não sei como escrever um bom código. Se você perguntar como isso se encaixa na minha conversa sobre a qualidade do código, eu responderei: escrever código é um processo com inovação constante e, quando você tenta implementar alguma idéia, a qualidade do código não o incomoda muito. É sempre necessário voltar e refatorar, e mesmo quando faço isso, geralmente nada funciona para mim. Mas, ao longo dos anos, percebi isso, mesmo que meu próprio código seja básico, mas posso muito bem encontrar falhas no código de outra pessoa. Portanto, em vez de fingir que meu código já é tão excelente, vou escrevê-lo da melhor maneira possível e entregá-lo para verificação, enquanto, enquanto isso, vou pegar o código do meu colega e verificá-lo. Como resultado, tanto o meu código como o código do meu colega terão maior qualidade.
É muito importante desistir do falso orgulho. Eu sempre lembro aos desenvolvedores que eles fazem parte de uma equipe, não faz sentido competir entre si e descobrir quem é mais legal, não. Estou pronto para admitir honestamente que meu conhecimento é bastante limitado - mas o que eu sei, eu sei bem. E meu colega também tem conhecimento muito profundo em alguma outra área. Juntos, nos fortalecemos quando estamos prontos para aprender um com o outro. Portanto, eu sempre sugiro verificar o código um do outro, e orgulho extra é completamente inútil aqui. Você precisa ser honesto um com o outro, essa é uma das qualidades mais importantes de uma boa equipe. A honestidade não deve ser punida se uma pessoa admitir que escreveu um código incorreto - isso é normal. Nós elevamos a fasquia, oferecendo-se maneiras de melhorar o código.
Outro ponto importante: você não precisa dizer a uma pessoa que ela cometeu um erro, é preciso dizer o que exatamente pode ser melhorado. Não diga: "Deus, que nome terrível para uma variável", é melhor assim: "Você provavelmente quis dizer que essa variável mostra a frequência da distribuição - provavelmente deve ser chamada de acordo". Isso o ajudará a transmitir melhor suas intenções. Isso também se aplica à edição de livros: fale não apenas sobre o que precisa ser aprimorado, mas também sobre o que foi feito bem. Muitas vezes esquecemos isso. Quando edito o código de outra pessoa e vejo um local que é bem executado, escrevo em um comentário que realmente gosto, que precisamos fazer isso com mais frequência e explico o porquê. Isso cria feedback construtivo, deixa claro para o desenvolvedor que você não é hostil com ele e, finalmente, melhora a qualidade do código da sua equipe.
- Você escreveu que usar uma ferramenta que o leva a sentir saudades é como ficar preso em um relacionamento tóxico: nessa situação, você só precisa sair e o mais rápido possível. Isso parece ótimo, mas muitas vezes o instrumento não tem uma alternativa específica, e então o que?- Uma pergunta completamente justificada. De fato, há situações em que não há para onde ir. Mas antes falei desses casos quando ainda há uma possibilidade de escolha, e apenas falta o desejo de fazê-lo. Na minha opinião, este é um fator significativo.
Quando não há escolha, em vez de reclamar, os pontos problemáticos devem ser identificados: o que exatamente torna essa ferramenta desconfortável para você. E então você pode fazer isso de maneiras diferentes. Você pode entrar em contato com os desenvolvedores e dizer - obrigado pelo seu trabalho, parece-nos que sua ferramenta poderia ser muito melhor se você prestasse atenção a esse e a esse aspecto. Ou você pode realizar um hackathon - reunir-se no final de semana com vários desenvolvedores, organizar um grupo de usuários, dizer a eles que você gasta nove horas por dia com essa ferramenta, que é terrível, e pedir que tentem adicionar alguns recursos a ela.
Talvez você não consiga resolver todos os problemas sozinho, mas pelo menos você pode reunir outras pessoas e resolver esse problema com elas, principalmente se os interesses deles forem semelhantes aos seus. Por fim, se sua ferramenta realmente causar muitos problemas, você mesmo pode tentar escrever uma nova - se tiver três ou quatro amigos na comunidade com a mesma atitude que você.
Então, na minha opinião, ainda existem alternativas. Você não precisa tolerar um relacionamento tóxico. Você sempre precisa encontrar uma saída - concordar com um parceiro e obter entendimento mútuo ou sair.
- Você escreveu um livro sobre lambdas e é conhecido graças a este livro. Também leio e acredito que está lindamente escrito, fornece o que o desenvolvedor de aplicativos precisa e não fornece nada supérfluo. Como verdadeiro profissional, gostaria de lhe perguntar: o que é programação funcional para você? Você poderia descrevê-lo com suas próprias palavras? Eu faço essa pergunta porque todos a definem um pouco à sua maneira, e cada vez que são revelados significados ocultos que diferem da definição padrão da Wikipedia.- Esta é uma pergunta maravilhosa. Minha compreensão desse conceito evoluiu ao longo dos anos e, agora, para mim, a coisa mais importante na programação funcional é a remoção de complexidade estranha. Estamos falando do fato de que na programação imperativa você não apenas indica o que precisa ser feito, mas também prescreve em detalhes como fazê-lo. Para mim, a programação funcional é um complemento ao estilo declarativo de programação, no qual indicamos o que precisa ser feito, mas não dizemos como.
Deixe-me fazer uma analogia primitiva: meus melhores amigos adoram carros, mas não me interessam. Quando nos reunimos, concordamos em não discutir carros, porque queremos continuar amigos. Eu nunca vou dirigir um carro com uma caixa de câmbio manual - a necessidade de mudar constantemente de marcha estraga toda a viagem, e o mesmo se aplica ao estilo imperativo de programação. A transmissão automática torna a condução um pouco mais fácil, mas para mim a melhor opção é o motorista me conduzir. Nesse caso, eu apenas digo onde preciso chegar e, ao longo do caminho, escrevo o código no meu laptop no banco de trás. Para mim, essa é a diferença entre programação imperativa e funcional. Com a programação imperativa, você mesmo está dirigindo, precisa saber para onde ir, como ir, para onde virar, onde pode cortar. Com a programação funcional, você está sentado no banco de trás, dizendo ao motorista para onde levá-lo, e sua atenção está totalmente focada no seu trabalho.
Como essa complexidade estranha é removida? Através da composição de funções. Ao compor funções, seu código passa por uma série de transformações durante as quais os dados passam de um formulário para outro. Além disso, para nós é importante não como cada uma dessas etapas é executada, mas o que exatamente ela realiza. Para mim, o primeiro aspecto da programação funcional é a composição funcional. O problema é que muitas linguagens nas quais a composição funcional é implementada - Ruby, Python, JavaScript, Groovy etc. - fornecem elegância e expressividade devido a isso, mas têm desempenho muito baixo. A composição funcional neles é implementada ineficientemente. Eu acredito que a elegância sem eficiência não é viável. O código não só deve ser bonito, mas também deve funcionar rapidamente. E aqui chegamos ao segundo aspecto vital da programação funcional - estamos falando de computação lenta. O resultado de uma determinada função é calculado apenas no momento em que é necessário. Graças a isso, uma combinação de elegância e eficiência é alcançada na programação funcional. Então, para mim, a programação funcional é uma ênfase no que fazer, não como fazê-lo; uso da composição funcional como uma série de transformações de dados; e a capacidade de realizar essas transformações de forma eficiente, graças à computação lenta.
Observe que eu não falei sobre imunidade e funções de alta ordem. O fato é que eles são apenas ingredientes para obter o resultado que descrevi. Usamos a programação funcional não para imunidade e funções de alta ordem, elas são apenas um meio para atingir um objetivo maior: livrar-se da complexidade estranha.
- Ótima definição. Hoje existe uma linguagem que é a referência para o que a programação funcional deve ser: Haskell (e possivelmente F #).Isso mesmo.
"Pelo menos muitas pessoas pensam assim." Mas Java obviamente não é Haskell, é amplamente limitado. A programação funcional faz sentido como disciplina quando aplicada a Java? Afinal, nossa linguagem possui um conjunto muito limitado de ferramentas para essa abordagem.- Para mim, o aspecto pragmático e não a busca pela excelência é mais importante. Estou curioso sobre a perfeição, mas para que tudo funcione, tenho que ser pragmatista. Sou louco por Haskell e passo muito tempo com ele, apenas para descobrir como uma tarefa específica é resolvida na programação funcional. Mas para meus clientes, não estou escrevendo sobre Haskell. Aqui você pode fazer uma analogia com a "Catedral e Bazar". A catedral é linda, mas na maioria das vezes passo no bazar. A questão é como sobreviver neste mundo. Quando as linguagens evoluem e quando tentamos combinar vários paradigmas, nós, como programadores, precisamos ser extremamente cuidadosos com sua implementação.
Eu não acho que a programação funcional seja impossível em Java. Nas situações em que há uma escolha, vou me concentrar no idioma mais adequado para mim. Mas nunca direi ao cliente: você deve usar esta linguagem. Na maioria das vezes, pergunto o que exatamente eles fazem e tento encontrar uma maneira de fazer o mesmo da maneira mais ideal possível dentro da estrutura do ambiente que eles já possuem. Acredito que em linguagens como Java uma combinação de programação imperativa e funcional é bastante possível e até recomendada, mas isso deve ser feito com extrema cautela. Imagine que você tem um tipo de círculo de funções puras, ao redor do qual haverá um anel de impureza. Tudo o que você deseja alterar deve estar fora do círculo. Dentro deste círculo, você pode implementar sua própria cadeia de funções, mas todas as alterações devem estar fora dela.
Essa é uma das razões pelas quais gosto de aprender novos idiomas. Recentemente, eu me familiarizei com a linguagem Elm, que é uma sintaxe Haskell com intercalações em F # que são compiladas em JavaScript. Essa abordagem me interessou desde o início, porque o JavaScript é um bazar. Quando você viaja pelo JavaScript, está constantemente pisando em poças. Graças à sintaxe de Haskell, Elm é definitivamente uma catedral. No entanto, esse código conciliar é possível ser executado no bazar. A arquitetura do Elm é elegante, possui um modelo (ou seja, dados), há uma visualização que exibe esses dados e há uma transformação, atualização. O primeiro princípio principal é que os dados são armazenados à vista. Quando o usuário executa uma ação (pressiona uma tecla, por exemplo), os dados da visualização são enviados para a função de atualização, onde a conversão ocorre. Os dados são imutáveis e a função de atualização retorna novos dados que exibem salvamentos em vez de antigos.
Se você pensar bem, exatamente da mesma maneira que o Redux funciona. Existem dados nele e existem redutores. Quando os dados são enviados para redutores, você recebe uma nova cópia em troca, que salva em vez da antiga. Mas se Elm e Redux operam no mesmo esquema, o mesmo esquema pode ser implementado em Java. Podemos criar funções puras que pegam dados, os transformam e retornam uma nova cópia. Aprendendo com Redux e Elm, podemos tornar a arquitetura Java mais funcional. Estou falando disso porque o Redux compila em JavaScript, que é um bazar exclusivo. Acho que o JavaScript é o mais distante do ideal de pureza funcional, aqui a cada passo em que você entra em uma poça. No entanto, o Redux oferece pureza funcional neste mundo extremamente imundo. Essa abordagem me influenciou bastante porque mudou minha visão da programação funcional e mostrou que eu também posso implementar esses princípios em Java.
- obrigado. Na sua opinião, o conjunto completo de ferramentas que temos em Java é completo e suficiente? Precisamos de mais alguma coisa além de expressões lambda, referências de métodos, coleções com fluxos?- Na minha opinião, ainda temos muito a perder. O mundo Java está em constante evolução. Recentemente, tive um diálogo com um homem que disse: "Ouvi dizer que você estava em nossa cidade há alguns anos e discutia muito sobre genéricos", ao que respondi: "Sempre discuto muito sobre genéricos". Eu acredito que em Java os genéricos são feitos muito mal. Brian Goetz fica com raiva de mim o tempo todo: "Sempre haverá alguém que reclama de genéricos", e este, é claro, sou eu. Na minha opinião, muito pode ser melhorado nesta área. Reforma é muito importante, na minha opinião. Muito pode ser feito em termos de redução da flatulência, eliminação do código padrão. O código pode ser muito mais fluente. E um certo movimento nessa direção já é visível hoje. O Java agora implementa a correspondência de padrões, o que me deixa muito feliz - gosto muito de como é implementado no Scala e no Kotlin. Penso que é muito importante, e a analogia com uma máquina de processamento de notas me vem à mente. Se você passar um pacote de notas, ele as classificará de acordo com o valor de cada nota de banco. Da mesma forma, a correspondência de padrões na programação funciona. Você passa dados por parâmetros que podem recuperar dados para processamento. Eu acho que isso poderia ajudar a se livrar do grande número de operadores de filiais que escrevemos em Java. O código se tornará muito mais expressivo. Em geral, acredito que o Java precisa de muitas adições, mas, aparentemente, ele já está se movendo nessa direção.
Quero mencionar mais um aspecto que é realmente curioso para mim. Eu cresci no mundo da programação tradicional. Não tenho medo de admitir publicamente que meu primeiro idioma foi o Visual Basic. De certa forma, essa é uma boa linguagem para o primeiro experimento, porque não pode ser pior. Depois, escrevi por muito tempo em C e C ++, e na maioria das vezes em todas as línguas que passei com C ++. Depois disso, comecei a escrever em Java, C #, linguagens como Ruby. A certa altura, percebi que sempre escrevia em idiomas com multithreading. Portanto, conhecer o Node foi uma espécie de insight - levei um tempo antes de descobrir a programação assíncrona. , , — , Java. (coroutines) (continuations). , Java , , , . , Java , . , . . , , , , Java-, . , , , . Java , .
— , ? JVM-, . . ?— , . , . , , : , , , , , . , . . , , , , . Big Data. , . , . , , , -. , , . , .
, , . , . , . , , . , , , . , , , . . , , : . , 30 . , -, .
, . , , , . . . , , , . : , . , , .
— . , ? , , . , Reactive Streams, Spring Reactor, CQRS event sourcing. - , CQRS?— , , . , , — . Angular 1, , , . Angular «$» . , : « . ». , . , , , . , . — — Angular 2, , .
, , . , , API — . ? - ? , , - . . Java — — deprecated-. Angular 1 — . , , .
— - (event-driven systems), , . , -. , , API , . , . , , 5-10 , . -, , - . , . , , — , . — ++. — . , , , . - , , , . , , , .
— , , .
Java Champions, Microsoft MVP, JavaScript, . : Java ? .NET, JavaScript - ?— , Java , .NET - . # Java, , C# . . Java , # LINQ, , (, Func). C# , Java. , , Java 2014 CompletableFuture. C# .
Java JavaScript. , « JavaScript» , JavaScript , . «callback hell», , - , . JavaScript Promises (), CompletableFutures Java. : , . Promises , . — Promises . , , , . , , , , . JavaScript async await. , Promise. , , , , , . CompletableFuture , continuations Java . , coroutines Kotlin.
, , . . , , , , , , . , , . , , — , , . async C#, async/await Promises JavaScript coroutines Kotlin, , , — , , . . Java . , Java , , , , . , . , , , . Java , . , Java — .
Java. . , Java , . Java , invokedynamic, , . , JVM. Java , — . , , . , Java , Java , JVM. . , , . , Java , .
— . , , , . , 5 . — . — , Common Lisp, JavaScript Meta Object Protocol, DSL Kotlin JetBrains MPS, GraalVM Java Java . . ?— . , . , , . . -, , . -, , . , , , . , . , , . , , . , , : ? — ? , , ? , . : , Angular, — React? , React. — ? , , , , - , . , , . , , . , , — , , . , .
, . , . - : , . , : , , , , . 1 10, 10 « », 1 «». 1 10, 1 « », 10 — « ». , , . , . , . , Angular, React Java . : ? , . , : . . , , , . , , , , ; ; .
, , — . — , . . - , , . , , . , . , , . , , . , . , , , .
"Obrigado, essa é uma ótima resposta." Em nossa conferência do Joker, você também falará sobre complexidade , para poder continuar a discussão por lá.- Sim, aguardo com entusiasmo.