Para as pessoas pessimistas, há pouco valor na exploração de novas linguagens de programação. Afinal, a maioria das linguagens hoje é Turing-completa – elas podem implementar tudo o que é implementável – então, qual é o objetivo de aprender algo novo? Para geeks de linguagem como eu – eu aprendi cinco deles antes de sair da universidade – essa linha de argumentação não faz sentido. Sempre há algo interessante e empolgante em encontrar uma nova linguagem que me permita expressar o que quero com mais clareza.
As linguagens são parte integrante do cenário tecnológico. É por isso que temos um quadrante inteiro para elas no Technology Radar da Thoughtworks – um guia com opiniões firmes sobre as fronteiras da tecnologia. E quando estávamos nos aproximando do 20º volume do Radar, eu queria explorar as mudanças e a evolução das linguagens ao longo desse tempo.
Dito isso, quando a Thoughtworks publicou pela primeira vez o Technology Radar, não foi um momento particularmente interessante para linguagens de programação. Essencialmente, era uma opção de Java, C# ou C++ – linguagens que eram usadas pela grande maioria das aplicações corporativos.
Então a coisa mais notável sobre os primeiros radares foi que inicialmente tínhamos apenas um quadrante de "linguagens". Logo percebemos que o ecossistema que envolve uma linguagem pode ser tão importante quanto a própria linguagem. Nós vimos isso acontecer com C ++, depos com Java e C #, e vemos hoje com Kotlin. Então, nosso quadrante se tornou "linguagens e frameworks" para refletir isso.
Em novembro de 2010, colocamos o “fim da vida útil da linguagem Java” em nosso anel de avaliação – realmente nos preocupava a estagnação da inovação em Java e queríamos sinalizar nossas preocupações para a comunidade de pessoas desenvolvedoras.
Hoje, você poderia dizer que erramos. Afinal, Java não morreu. Mas na época, nossas preocupações eram muito reais. A Oracle tinha acabado de concluir a aquisição da Sun Microsystems, e não víamos uma nova versão do Java em anos.
Uma coisa que nós definitivamente acertamos – mas levou tempo até todo mundo se dar conta – foi classificar JavaScript como uma linguagem de primeira classe.
As linguagens de primeira classe têm ferramentas – como testes de unidade – e abordagens – como refatoração –, que você esperaria de ambientes de produção. Víamos o JavaScript sendo usado em projetos corporativos importantes. Na época, sentimos que considerá-la somente como uma linguagem de script era um desserviço. Demorou um pouco, mas hoje as pessoas tratam o JavaScript como uma linguagem de fato.
Na mesma época, alertamos no anel Adote que as pessoas deviam se importar com linguagens. Isso aconteceu porque estávamos começando a ver inovações de linguagem sendo construídas com base em JVM. Nesse ponto, como uma pessoa desenvolvedora, você é confrontada com a escolha da linguagem apropriada para construir algo. Não é apenas um caso de “Eu trabalho em uma loja de Java, então programo em Java”. Quando é apropriado usar algo como o Clojure ou o JavaScript?
Lembro-me de quando conversei com colegas em Bangalore, Índia – elas estavam entusiasmadas com Clojure e queriam ser o primeiro time da Thoughtworks a entregar um projeto em Clojure. Na mesma viagem, viajei para os nossos escritórios em Pune, e a história era a mesma lá, entretanto com Scala.
Na época, não estava claro quem venceria. Talvez ainda não esteja. Ambas traziam o poder das linguagens funcionais para a empresa – elas apenas adotaram abordagens muito diferentes. Clojure era mais pura no paradigma funcional; Scala estava tentando facilitar o caminho, usando uma sintaxe familiar a quem programa em Java. Scala estava de certa forma mais avançada no ecossistema em torno dela, assim como o framework Play, mas isso logo mudou.
A outra linguagem funcional notável na época era # – sendo a principal contribuição da Microsoft para linguagens funcionais, era impossível ignorar. Ou pelo menos deveria ter sido. F nunca conseguiu sair do nosso anel Avalie para o Experimente – o que significa dizer que era algo que achamos interessante explorar, mas nunca tivemos times que o usassem com sucesso em produção. Apesar de sempre termos clientes comprometidos com os ecossistemas da Microsoft, nunca chegamos lá com F#.
O que vimos mais recentemente é que há aspectos de Scala que a tornam um pouco mais problemática. A ideia de fazê-la parecida com Java significava poder ter pessoas escrevendo no mesmo aplicativo usando estilos idiomáticos muito diferentes.
Nós tentamos capturar isso no Radar. Tivemos um blip chamado Scala, as partes boas. E eu acho que isso levanta algumas questões fundamentais sobre o que faz uma boa escolha para linguagens de programação: pode não haver uma resposta certa; seja qual for a sua escolha como time, você precisa concordar sobre como usar essa linguagem e como abordará problemas semelhantes. Você não vai querer uma pessoa desenvolvedora resolvendo um problema de uma maneira e outra adotando uma abordagem completamente diferente.
Uma pessoa com quem conversei na época achava que era uma aberração. Até foi sugerido que a pessoa que criou Go devia ter dormido por mais de uma década e acabado de acordar – porque as escolhas feitas em Go estavam repetindo o que fazíamos dez anos atrás.
Enquanto isso, outra pessoa com quem conversei amava Go. Ela adorava as coisas que a linguagem proporcionava e o fato de ser incrivelmente simples de usar.
Ambas as pessoas eram especialistas em linguagens de programação, e isso mostra como duas pessoas podem ter experiências completamente diferentes ao usar uma linguagem. Isso acontece porque sua experiência de um linguagem não é apenas o que a linguagem traz para você como pessoa desenvolvedora de software, mas como você enxerga essa linguagem. Todas nós pensamos em problemas de maneiras diferentes. Portanto, não se surpreenda se você escolher uma nova linguagem e ficar muito entusiasmada com ela, mas descobrir que suas colegas não estão.
Na Thoughtworks, achamos que isso é um erro. Às vezes, há coisas que você pode expressar com mais clareza em uma linguagem e que você não conseguirá fazer em outra. E uma das coisas mais importantes que você pode fazer como pessoa desenvolvedora é escrever um código que seja fácil de entender.
Mas também reconhecemos que a anarquia do desenvolvimento – na qual você dá a cada pessoa desenvolvedora um passe livre sobre qual linguagem escolher – é uma receita para problemas. Isso levanta uma questão interessante: qual é o número certo de linguagens para sua organização? Usamos o termo "programação poliglota" para capturar a ideia de que devemos expandir criteriosamente nossas opções de linguagem para abordar diferentes categorias de problemas.
É difícil prescrever, mas achamos que promover algumas linguagens que suportam diferentes ecossistemas ou recursos de linguagem é importante para as empresas, pois permite que elas acelerem os processos e implementem mais rapidamente. Enquanto isso, as pessoas desenvolvedoras se beneficiam com as ferramentas certas para resolver o problema em questão.
As linguagens são parte integrante do cenário tecnológico. É por isso que temos um quadrante inteiro para elas no Technology Radar da Thoughtworks – um guia com opiniões firmes sobre as fronteiras da tecnologia. E quando estávamos nos aproximando do 20º volume do Radar, eu queria explorar as mudanças e a evolução das linguagens ao longo desse tempo.
Dito isso, quando a Thoughtworks publicou pela primeira vez o Technology Radar, não foi um momento particularmente interessante para linguagens de programação. Essencialmente, era uma opção de Java, C# ou C++ – linguagens que eram usadas pela grande maioria das aplicações corporativos.
Então a coisa mais notável sobre os primeiros radares foi que inicialmente tínhamos apenas um quadrante de "linguagens". Logo percebemos que o ecossistema que envolve uma linguagem pode ser tão importante quanto a própria linguagem. Nós vimos isso acontecer com C ++, depos com Java e C #, e vemos hoje com Kotlin. Então, nosso quadrante se tornou "linguagens e frameworks" para refletir isso.
Fim da vida útil do Java?
Também passamos muitas das primeiras edições do Radar ponderando sobre o destino do Java. Como eu mencionei, era uma das grandes linguagens da época - mas isso não significa que sempre estivemos confiantes em seu futuro.Em novembro de 2010, colocamos o “fim da vida útil da linguagem Java” em nosso anel de avaliação – realmente nos preocupava a estagnação da inovação em Java e queríamos sinalizar nossas preocupações para a comunidade de pessoas desenvolvedoras.
Hoje, você poderia dizer que erramos. Afinal, Java não morreu. Mas na época, nossas preocupações eram muito reais. A Oracle tinha acabado de concluir a aquisição da Sun Microsystems, e não víamos uma nova versão do Java em anos.
Uma coisa que nós definitivamente acertamos – mas levou tempo até todo mundo se dar conta – foi classificar JavaScript como uma linguagem de primeira classe.
As linguagens de primeira classe têm ferramentas – como testes de unidade – e abordagens – como refatoração –, que você esperaria de ambientes de produção. Víamos o JavaScript sendo usado em projetos corporativos importantes. Na época, sentimos que considerá-la somente como uma linguagem de script era um desserviço. Demorou um pouco, mas hoje as pessoas tratam o JavaScript como uma linguagem de fato.
Na mesma época, alertamos no anel Adote que as pessoas deviam se importar com linguagens. Isso aconteceu porque estávamos começando a ver inovações de linguagem sendo construídas com base em JVM. Nesse ponto, como uma pessoa desenvolvedora, você é confrontada com a escolha da linguagem apropriada para construir algo. Não é apenas um caso de “Eu trabalho em uma loja de Java, então programo em Java”. Quando é apropriado usar algo como o Clojure ou o JavaScript?
Scala ou Clojure?
Durante o tempo em que publicamos o Radar, também vimos o surgimento da chamada onda funcional. Naturalmente, linguagens como Lisp e Haskell estão conosco há décadas, o que aconteceu foi que começamos a ver empresas interessadas em linguagens funcionais..
Lembro-me de quando conversei com colegas em Bangalore, Índia – elas estavam entusiasmadas com Clojure e queriam ser o primeiro time da Thoughtworks a entregar um projeto em Clojure. Na mesma viagem, viajei para os nossos escritórios em Pune, e a história era a mesma lá, entretanto com Scala.
Na época, não estava claro quem venceria. Talvez ainda não esteja. Ambas traziam o poder das linguagens funcionais para a empresa – elas apenas adotaram abordagens muito diferentes. Clojure era mais pura no paradigma funcional; Scala estava tentando facilitar o caminho, usando uma sintaxe familiar a quem programa em Java. Scala estava de certa forma mais avançada no ecossistema em torno dela, assim como o framework Play, mas isso logo mudou.
A outra linguagem funcional notável na época era # – sendo a principal contribuição da Microsoft para linguagens funcionais, era impossível ignorar. Ou pelo menos deveria ter sido. F nunca conseguiu sair do nosso anel Avalie para o Experimente – o que significa dizer que era algo que achamos interessante explorar, mas nunca tivemos times que o usassem com sucesso em produção. Apesar de sempre termos clientes comprometidos com os ecossistemas da Microsoft, nunca chegamos lá com F#.
O que vimos mais recentemente é que há aspectos de Scala que a tornam um pouco mais problemática. A ideia de fazê-la parecida com Java significava poder ter pessoas escrevendo no mesmo aplicativo usando estilos idiomáticos muito diferentes.
Nós tentamos capturar isso no Radar. Tivemos um blip chamado Scala, as partes boas. E eu acho que isso levanta algumas questões fundamentais sobre o que faz uma boa escolha para linguagens de programação: pode não haver uma resposta certa; seja qual for a sua escolha como time, você precisa concordar sobre como usar essa linguagem e como abordará problemas semelhantes. Você não vai querer uma pessoa desenvolvedora resolvendo um problema de uma maneira e outra adotando uma abordagem completamente diferente.
Linguagens importam
Posso ilustrar por que esse acordo é tão importante usando Golang. Começamos a aproveitar a empolgação em torno de Go em 2014. Go, como idioma, tentou oferecer uma alternativa a C para a programação de sistemas. No entanto, isso também criou mais conflitos entre pessoas que realmente se importam com linguagens do que qualquer outra que eu possa lembrar.Uma pessoa com quem conversei na época achava que era uma aberração. Até foi sugerido que a pessoa que criou Go devia ter dormido por mais de uma década e acabado de acordar – porque as escolhas feitas em Go estavam repetindo o que fazíamos dez anos atrás.
Enquanto isso, outra pessoa com quem conversei amava Go. Ela adorava as coisas que a linguagem proporcionava e o fato de ser incrivelmente simples de usar.
Ambas as pessoas eram especialistas em linguagens de programação, e isso mostra como duas pessoas podem ter experiências completamente diferentes ao usar uma linguagem. Isso acontece porque sua experiência de um linguagem não é apenas o que a linguagem traz para você como pessoa desenvolvedora de software, mas como você enxerga essa linguagem. Todas nós pensamos em problemas de maneiras diferentes. Portanto, não se surpreenda se você escolher uma nova linguagem e ficar muito entusiasmada com ela, mas descobrir que suas colegas não estão.
Uma linguagem para liderar todas elas?
Mencionei no início que algumas pessoas não veem valor no desenvolvimento de novas linguagens. Isso está intimamente alinhado com a ideia de que você deve fazer uma única escolha de linguagem para todo o seu trabalho de desenvolvimento.Na Thoughtworks, achamos que isso é um erro. Às vezes, há coisas que você pode expressar com mais clareza em uma linguagem e que você não conseguirá fazer em outra. E uma das coisas mais importantes que você pode fazer como pessoa desenvolvedora é escrever um código que seja fácil de entender.
Mas também reconhecemos que a anarquia do desenvolvimento – na qual você dá a cada pessoa desenvolvedora um passe livre sobre qual linguagem escolher – é uma receita para problemas. Isso levanta uma questão interessante: qual é o número certo de linguagens para sua organização? Usamos o termo "programação poliglota" para capturar a ideia de que devemos expandir criteriosamente nossas opções de linguagem para abordar diferentes categorias de problemas.
É difícil prescrever, mas achamos que promover algumas linguagens que suportam diferentes ecossistemas ou recursos de linguagem é importante para as empresas, pois permite que elas acelerem os processos e implementem mais rapidamente. Enquanto isso, as pessoas desenvolvedoras se beneficiam com as ferramentas certas para resolver o problema em questão.
O que vem depois?
Estamos otimistas de que a onda de inovação em linguagens e frameworks de programação continuará. Espere por mais atividade neste quadrante enquanto embarcamos nos próximos 20 RadaresAviso: As afirmações e opiniões expressas neste artigo são de responsabilidade de quem o assina, e não necessariamente refletem as posições da Thoughtworks.