Tem mercado no Brasil para outras linguagens?

15 respostas
BSampaio

…quero dizer outras linguagens fora as mais populares:
java(obviamente), PHP, VB, C, C++ e C#

Depois de trabalhar com java por mais de 6 anos fiquei meio saturado da linguagem (e do paradigma OO).
Então comecei a estudar Scala e Ruby. Pretendo fazer o mesmo com Groovy e Clojure.

Tambem li que (pelo menos lá fora) tem emprego para quem programa em Lua, Scheme, Haskell, Erlang e Go.
Basta brincar um pouco aqui: http://www.indeed.com/jobtrends?q=Clojure%2C+Groovy%2C+Erlang%2C+Scala&l=

E aqui no Brasil? Sabem se tem espaço para quem programa nestas linguagens. O retorno é bom?
Para Ruby (e RoR ) a resposta é provavelmente sim. Mas e para Scala, Clojure & cia?

15 Respostas

peczenyj

talvez vc tenha que “cavar” uma oportunidade.

as vezes existe a chance de vc pegar uma empresa que tipicamente trabalha com java/struts/ejb/etc e vc pode introduzir Groovy, Scala, etc, pontualmente.

ja vi vagas para trabalhar com Lua - especialmente ligada a tv digital/ginga/etc.

mas uma vantagem de cara é que se vc conhece uma linguagem interessante alem das linguagens de mercado isso é valorizado por algumas empresas. vc só não pode ser xiita e exigir só trabalhar com isso a menos que vc saiba muito bem o que esta fazendo.

Cofor

Também estou muito interessado em Clojure depois que tive aulas de Lisp mas dúvido que existam empregos no Brasil. Erlang também interessa muito.

Vou terminar a facu ano que vem e começar a empreender pois já estou saturado de trabalhar pra outras pessoas ( algumas muito incompetentes ).

Até lá vou acompanhando, estudando e caso essas linguagens me ajudem, eu as empregarei sem medo de ser feliz.

BSampaio

Penso em introduzir alguma coisa de scala e groovy (e talvez clojure), inicialmente em doses homeopáticas, nos projetos em que participo.
Erlang e Haskell acho mais difícil… a não ser que exista alguma versão análoga a um Jython ou um JRuby.
Me parece que as linguagens que geram bytecode ou a coisa análoga do CLR tem mais chance de vingar.

Porem preciso ralar um bocado antes de fazer qualquer coisa minimamente decente nestas linguagens. Para quem ficou tão viciado em OO não é nada fácil aprender outros paradigmas. E o pior é que topei muitos “monkey-jobs” em java me restringindo ao arroz-com-feijão… acho que é um erro que muitos ainda cometem. Espero me tornar um programador melhor daqui em diante.

Fora outras vantagens, fiquei impressionado com a expressividade destas linguagens e acho que vale a pena investir nelas.
Faço propaganda delas aqui no trabalho, mas sem transformar a coisa em religião… não tenho ilusões sobre fazer um projeto inteiro em qualquer uma (a não ser para mim mesmo).

Se existe dificuldade em se achar bons desenvolvedores java, imagine então em scala! A justificativa óbvia da empresa seria de que um sistema destes não teria quem desse manutenção!

Cofor

Exato, aí tudo fica nivelado pelo menor nível possível.

Não quero aqui desmerecer essa decisão pois ela é sábia se olharmos pelo contexto de quantidade de mão de obra, é uma segurança e tanto para o negócio.

Mas por outro lado, acho que vale a pena investir nessas linguagens não pelas features ( expressividade, prog funcional, concorrência sem locks ), mas sim pelo fato de elas nos obrigarem a pensar diferente, pensar melhor e esse exercício melhora AS PESSOAS envolvidas.

Sou muito mais pessoas talentosas trabalhando pra mim do que a certeza que tenho 1 milhão de programadores júnior vasculhando o APInfo.

Ae BSampaio se achar algum projeto sobre clojure me avisa :smiley:

M

BSampaio:

Se existe dificuldade em se achar bons desenvolvedores java, imagine então em scala! A justificativa óbvia da empresa seria de que um sistema destes não teria quem desse manutenção!

Que tal escolher um algoritmo importante da empresa e implementar na forma de um “FrameworkJava.jar”, mas agora o detalhe, usando Clojure. Depois basta dizer que tudo não passa de 60 linhas de código, usa linguagem clara para analistas e uma quantidade menor de programador/hora será necessário para sua manutenção. A partir daí acho que não será difícil convencer porque você fez parecer como de fato uma vantagem, e não apenas mais um custo sem aparente benefícios para a empresa.

peczenyj

Essa abordagem é muito arriscada.

Imagine que dá errado. A chance de lembrarem de Clojure como a “linguagem que deu aquela dor de cabeça no faturamento” é enorme dependendo da cultura da empresa. Portanto, para seguir tem que tomar muito cuidado e caprichar nos testes, principalmente nos funcionais!

Seria otimo vc produzir ferramentas e coisas periféricas até que atinja uma dada maturidade. Por exemplo teste de aceitação são uma otima pedida pois vc tem menos codigo e mais produtividade. Aos poucos vc consegue implantar outras tecnologias.

Outra coisa seria vc ver se existe uma parte das regras de negócio que vc poderia scriptar e, então, isolar em Groovy ou Clojure e mostrar a flexibilidade que poderiam conseguir.

M

peczenyj:
Essa abordagem é muito arriscada.

Imagine que dá errado. A chance de lembrarem de Clojure como a “linguagem que deu aquela dor de cabeça no faturamento” é enorme dependendo da cultura da empresa. Portanto, para seguir tem que tomar muito cuidado e caprichar nos testes, principalmente nos funcionais!

Seria otimo vc produzir ferramentas e coisas periféricas até que atinja uma dada maturidade. Por exemplo teste de aceitação são uma otima pedida pois vc tem menos codigo e mais produtividade. Aos poucos vc consegue implantar outras tecnologias.

Outra coisa seria vc ver se existe uma parte das regras de negócio que vc poderia scriptar e, então, isolar em Groovy ou Clojure e mostrar a flexibilidade que poderiam conseguir.

Maiores riscos, maior a recompensa.

Acho sua abordagem não muito diferente da minha, apenas beneficia outro grupo de pessoas. Acho que depende de quem você enxerga como principal beneficiário do projeto piloto. Se forem outros programadores cria-se ferramentas, outros departamentos, cria-se algoritmos.

BSampaio

Imagine que dá errado. A chance de lembrarem de Clojure como a “linguagem que deu aquela dor de cabeça no faturamento” é enorme dependendo da cultura da empresa. Portanto, para seguir tem que tomar muito cuidado e caprichar nos testes, principalmente nos funcionais!

O irônico disso é que já participei de mais de uma migração de sistema feito em uma linguagem 4GL qualquer para sistema Java (teve um caso com VB tambem).
Tenho a nítida impressão de que alguns gerentes pensam no java como a “linguagem que deu aquela dor de cabeça no projeto XPTO1234”.
Motivo: maior tempo de desenvovimento (é sacanagem competir com uma 4GL em aplicações bestas de acesso a banco…) e
menor capacitação dos funcionários na nova linguagem - o que tambem contribui para maior tempo de desenvolvimento.

Isto sem contar a birra gerada pelo fato do mercado pagar bem mais a programadores Java que aos 4GLeiros e VBzeiros.

M

BSampaio:
Imagine que dá errado. A chance de lembrarem de Clojure como a “linguagem que deu aquela dor de cabeça no faturamento” é enorme dependendo da cultura da empresa. Portanto, para seguir tem que tomar muito cuidado e caprichar nos testes, principalmente nos funcionais!

O irônico disso é que já participei de mais de uma migração de sistema feito em uma linguagem 4GL qualquer para sistema Java (teve um caso com VB tambem).
Tenho a nítida impressão de que alguns gerentes pensam no java como a “linguagem que deu aquela dor de cabeça no projeto XPTO1234”.
Motivo: maior tempo de desenvovimento (é sacanagem competir com uma 4GL em aplicações bestas de acesso a banco…) e
menor capacitação dos funcionários na nova linguagem - o que tambem contribui para maior tempo de desenvolvimento.

Isto sem contar a birra gerada pelo fato do mercado pagar bem mais a programadores Java que aos 4GLeiros e VBzeiros.

Gerentes não escolhem ferramentas de programação, engenheiros de software sim, o que eles falaram?

peczenyj

De qualquer forma tem que ver a curva de aprendizado da galera.

Afinal no dia a dia é que vc descobre coisas como:

  • limitações das bibliotecas
  • design patterns mais adequados
  • threads versus processos
  • algum modulo pode ter memory leak :confused:
  • algum bug escroto que vc precisa de 200 linhas para remediar até que fix seja adicionado a versão stable da coisa
  • dificuldades de modularização, deploy, etc
  • como tratar strings de diferentes encodings? tem alguma surpresa?
  • quebras de contrato entre versões proximas - vulgo foda-se agora todo mundo tem q usar o connect2(a,b,c,d)
  • sem falar em debugar a aplicação

Se for possivel mesclar galera experiente com “novatos” da pra encarar um projeto grande sim.

M

Scala e clojure são linguagens para criação de algoritmos especializados, usar para migração de sistemas, ou para implementar especificaçoes de analistas e algo contra-produtivo e não recomendado nesse momento.

M

Depende da região, em muitas cidades você dificilmente vai conseguir sair dessas linguagens citadas.

vanderlan_TI

Olha Cara eu sou de Pernambuco e a Coca-Cola está pagando R$15.000,00 para fazer manutenção no seu sistema que foi feito em Cobol :slight_smile:

e ai vale a pena ???

M

vanderlan TI:
Olha Cara eu sou de Pernambuco e a Coca-Cola está pagando R$15.000,00 para fazer manutenção no seu sistema que foi feito em Cobol :slight_smile:

e ai vale a pena ???

Como sempre, isso depende.
O salário é bom, se você não tiver nada contra o Cobol e os projetos propostos te agradarem…

Só lembrando que tecnologia não é tudo, o ambiente e cultura da empresa também contam muito.

BSampaio

Discordo. Martin Odersky pretendeu criar uma linguagem de uso geral. Qualquer coisa que voce fizer em Java voce faz em Scala e há coisas em Scala que não da para fazer em Java. E Ritch Hickey insiste varias vezes sobre a praticidade e usabilidade de Clojure (que tambem tem boa integracao com Java).
E migracões e implementações de analistas (estas ultimas se não se fundam no pressuposto de nenhuma linguagem específica, como manda a cartilha) se enquadram no
que se entende por uso geral.
Por exemplo, eu nao poderia criar codigo dinamicamente que me facilitasse naquelas chatissimas partes mecanicas que tenho que realizar em todos os projetos? me isentar de escrever (ou gerar via wizard num IDE) os tediosos getters e setters, implementar os mesmos patterns aqui e ali, conversoes de tipos, etc, etc.

Criado 17 de março de 2011
Ultima resposta 25 de mar. de 2011
Respostas 15
Participantes 6