Taverna /dev/All

Quando trocar de linguagem?

Linguagens são ferramentas. Ferramentas diferentes servem para coisas diferentes, e assim vai. Tenho ciência disso tudo, todavia, quando iniciantes, vale a pena trocar de linguagem quando um novo desafio surge?

O meu caso: Comecei a programar (de verdade) a um ano. Desde então, fiz pequenissimos projetos com Python e Node.JS. Meu forte sempre foi Java e OO, os projetos “maiores” foram feitos em Java.

Agora surgiu a necessidade de re-fazer um serviço de notificações que temos na empresa. Originalmente escrito em Python, não tá em OO e por isso pareceu ser um grande desafio.

Me peguei pensando: Será que é melhor eu aceitar o desafio e fazer do zero em python (tendo que praticamente aprender a linguagem do 0) ou fazer em Java, uma linguagem que para mim é confortável e aumentaria meu portfólio?

Ambas as linguagens atendem muito bem a minha necessidade! A questão é que escuto todo mundo falando que programa em duas, três linguagens, enquanto eu arrisco outras mas a única que digo com propriedade que programo é Java, mesmo.

Não sei se estou colocando a carroça na frente dos cavalos (por ser novo no mundo da programação profissional) e sendo ansioso para usar outras linguagens, ou se estou certo em “não querer ficar empacado com só uma linguagem”.

Qual sua opinião sobre isso?

1 Curtida

Nossa, esta é uma daquelas perguntas titânicas que o pessoal vai ter de responder de forma genérica.

Então lá vai a minha resposta como alguém que tem algumas cicatrizes.

Se profissionalmente você tá trabalhando só com uma linguagem, você já se ferrou: elas vão sair de circulação, você vai ficar desatualizado e talvez não consiga superar isto devido ao determinismo linguístico (https://www.itexto.com.br/devkico/?p=172).

Como alguém cuja carreira se pautou por algumas linguagens que foram pro saco (VB, Delphi, Silverlight, Flash…) te digo isto: saiba mais de uma sempre.

Sobre o restante, tem de olhar o que há ao redor da linguagem mais que a linguagem em si: tem de avaliar o ambiente de execução, desenvolvimento, o próprio projeto. Esta é a parte genérica da resposta :smiley:

acho que o uso de trocar ai não caiu bem, é melhor imaginar que vc tá colocando mais uma ferramenta na sua caixa de ferramentas.

já diria o et bilu: busquem conhecimento!

tem sempre que lembrar que não é vc q escolhe a linguagem e sim o problema, principalmente quem lida com usuário, mtas vezes o problema não é a linguagem q implementou a interface e sim a linguagem q vc usou p/ se comunicar com o cliente.

e nessa questão tem um adicional p/ quem é empreendedor: vc acha seguro dar liberdade p/ seus devs saindo colocando linguagens novas na stack aleatoriamente sem saber se o msm vai estar ali semana q vem p/ resolver problema? pq uma coisa é certa, uma hora vai dar problema ou pedir manutenção

1 Curtida

Difícil ter uma resposta sem avaliar bem o contexto. Eu concordo com ambos os comentários do @kicolobo e do @joao, mas vou deixar aqui também um adendo.

Ao avaliar o contexto do projeto/sistema novo que vai ser iniciado, ou uma reescrita como é o seu caso, avalie “onde o calo aperta” e vai ter uma ideia melhor do rumo que deve seguir. Exemplos:

  1. O projeto foi feito em Python, mas a única pessoa que sabia saiu, e toda equipe restante sabe somente Java. No geral, optar por Java seria uma decisão óbvia por conta da mão de obra já presente.
  2. O projeto sofre com muitos bugs, por conta de más decisões de projeto de classes/objetos e falta de testes automatizados. Nesse caso, se adotar um linguagem diferente, sem atacar o problema do design ruim e falta de testes, o projeto está fadado a voltar ao estado atual.
  3. O projeto sofre com demoras na entrega, porque parte dos desenvolvedores faltam experiência na linguagem, ou experiência no geral. Nesse caso um refatoramento pode ser mais adequado, além de encaixar um desenvolvedor com mais conhecimento para atuar como mentor. Refazer pode resolver, mas será que não vai tomar mais tempo? Alguns profissionais tem a falsa sensação de que uma reescrita vai resolver tudo, quando tem várias decisões inerentes ao negócio já implementadas e validadas, que irão acabar se repetindo numa reescrita.
  4. O projeto precisa de um cuidado maior com alguns tipos de bugs, que uma linguagem tipada como Java, C#, Typescript, etc. resolveria melhor que Javascript, Python, Ruby, etc. onde você não pode se dar o luxo de prototipar algo rápido, fazer deploy e testar. Talvez o projeto precise ir para produção com quase certeza de que está sem bugs. Nesse caso, mudar de Python para Java (ou qualquer linguagem fortemente tipada) seja uma boa decisão (considerando que a equipe fará bom uso da linguagem adotada).

Enfim, poderia dar mais exemplos, mas esses 4 acho que já dá uma boa ideia. Outra coisa é que, se a equipe conhece bem os conceitos de OO, mudar de Python para Java, ou vice versa, pode não ser uma mudança tão grande. Depende de avaliar não só a necessidade e tamanho do projeto, mas a experiência da equipe.

1 Curtida

Acredito que quem deseja se tornar um ótimo desenvolvedor não pode se dar ao luxo de programar somente no emprego. Com isso quero dizer o seguinte, se você deseja aprender Python, pode fazer isso no seu tempo “livre”.

Pode até utilizar esse desafio do sistema de notificação, mas eu faria isso fora do trabalho. No emprego, se não existe nenhuma razão realmente forte para manter em Python, faz muito mais sentido você empregar o que tem de melhor no momento, que é seu conhecimento em Java. Você já vai ter o trabalho de passar para OO. Se ainda for querer programar em Python, que é uma linguagem que ainda não domina, pode se complicar.

Além disso, dependendo do porte do sistema, e considerando seu tempo de experiência que é bem curto, é bem provável que você tenha muita oportunidade de melhorar seus conhecimentos em Java, praticar mais testes, usar clean code, definir pipelines automáticos de build e tests, usar bancos não-relacionais. Enfim, tem muito espaço para crescimento dentro do Java ainda. O Java não vai acabar nos próximos 5 anos, assim como Python também não. Enquanto isso, você tem tempo para melhorar como desenvolvedor, e ir tateando outras linguagens com mais bagagem.

Traduzindo, experimente o Python sem risco, entendendo bem os conceitos envolvidos, e não lutando contra um deadline, porque se você faz isso, acaba “resolvendo o problema” sem usar boas práticas, de maneira que vai gerar retrabalho lá na frente para você e para outros, além de não conseguir “digerir” tão bem a linguagem quanto poderia.

2 Curtidas

isto é muito verdade: a linguagem que mais me ensinou foi a que menos usei (nunca usei): Lisp.

O tempo que investi aprendendo Lisp me abriu muitas portas, me fez aprender horrores e forneceu o ferramental que precisava pra que pudesse criticar as ferramentas que até então estava usando no dia a dia.

Muito boa esta dica de experimentar “sem risco”.

Ótimas colocações de todos acima! Minha contribuição reforça alguns pontos já expostos:

Em geral, a parte sintática do lado procedural das linguagens, incluindo o decoreba dos boilerplates, é facilmente aprendida por qualquer um que saiba programar. Pesa mais o fator resistência à mudança que o fator capacidade de aprender. Mas uma vez que a mudança aconteça não demoram algumas semanas e todo mundo estará à par de como escrever um programa que compila. Só que isso representa muito pouco do que é construir um sistema de cabo a rabo.

Concordando com o @kicolobo, uma coisa que conta muito é o entorno: a intimidade com as APIs da linguagem, conhecimento abrangente das bibliotecas de terceiros disponíveis, entendimento real dos aspectos de configuração do projeto, incluindo um correto controle de dependências, além de um ambiente de desenvolvimento bem azeitado e produtivo.

Ademais, se há um ponto crítico do seu sistema resolvido de forma elegante e eficaz por uma excelente biblioteca ou framework de uma determinada linguagem, ao passo que as outras linguagens não possuem nenhuma opção à altura ou amadurecida o suficiente, isso pode pesar muito. Muito mais do que o supervalorizado conforto sintático.

Mas, conforme já mencionado pelo @joao, num ambiente empresarial você não está programando para você, e sim para a empresa. Se há a perspectiva de outras pessoas botarem a mão no código, hoje ou amanhã, a manutenibilidade fala muito alto em relação a outras questões.

1 Curtida

Acho que todos aqui já colocaram muito bem e de diversas formas, dando vários pontos de vistas interessantes.

Particularmente, eu fiz, na minha carreira, uma troca mais baseada em mercado – mas bem alinhada com meu gosto. Poderia ter buscado Node.JS, que já estava bem em alta (e agora está mais ainda), mas foquei em Ruby, porque gostava bastante da linguagem, do Rails, e queria focar em empresas menos enterprise.

Antes do Ruby/Rails, meu foco era Java.

É claro que nesse meio tempo aprendi Node.JS, Python, Go e brinquei um pouco com Elixir. Porém permaneço ainda no Ruby. Permaneço porque gosto bastante mas, principalmente, porque ela tem muito mercado, pelo fato de atender bem um nicho (desenvolvimento rápido, prática, amada por devs, relativamente rápida).

Porém, não hesitaria em mudar caso (ou quando) for necessário.

Essa seria minha dica para quem está indeciso ou começando – e até para os que estão já mais no meio do caminho: não se prenda só à paixão; mas veja também o que o mercado quer, se adiantando em aprender algo requisitado.

1 Curtida

Kico, um dos “problemas” dessa abordagem, é que a própria pessoa tem que se cobrar, e não pode parar no meio do caminho. Felizmente hoje em dia, tem maneiras gratuitas de “experimentar sem risco”, como essa daqui: https://www.codenation.dev/acceleration/aceleradev-data-science/

Recentemente participei da aceleração deles de Java. Foi bem bacana, tinhamos aulas todas as quintas, e em paralelo exercícios semanais, e um projeto final, onde aplicamos os conhecimentos obtidos no curso. Vale bastante a pena! Serviu para eu dar uma reforçada nos conhecimentos de Java, bancos não-relacionais, e testes. Fica a dica para quem se interessar :smiley:

1 Curtida

bacana isto aí, gostei!
Se tivesse mais tempo até participaria, vou indicar pro pessoal do escritório.

texto interessante que tem relação com o assunto https://recurse.henrystanley.com/post/better/

1 Curtida

itexto