Linguagens como Ruby e Python

Estude ambas amigo e tire suas próprias conclusões…

EU:

• Não gostei de Ruby;
• AMEI Python.

São linguagens que eu acho que não engrenarão no mercado corporativo por alguns fatores “EXTRAS”, mas que são um sucesso total tendo em vista que o Rails elevou o Ruby ao topo do mercado de Startups e o Python é largamente utilizado em todo o universo Linux, científico e vem crescendo absurdamente pra Web depois do Django e do Web2Py.

No final das contas, eu penso que qualquer aprendizado NUNCA é desperdiçado. Você terá ganho no mínimo a expertise de uma nova forma de programar com linguagens dinâmicas.

Abraços

Complementando o adriano_si:

Eu acredito que estamos caminhando para um cenário onde a plataforma é mais relevante do que a linguagem. Um exemplo é você poder rodar Ruby e Python na JVM. Por isso vale a pena o aprendizado em linguagens de programação, vai te facilitar a resolver o problema com a ferramenta certa, e provavelmente rodando em cima da mesma plataforma do restante da sua solução.

rafael.cs:

Olá pessoal!

Sempre trabalhei em empresas que trabalham com C# ou Java, mas confesso que eu tenho uma queda por Python e Ruby.

O que vocês acham essas linguagens? Será o futuro (visto que muitas startups trabalham com ela)?

Por que você acha uma perda de tempo?

javaflex:

rafael.cs:

Olá pessoal!

Sempre trabalhei em empresas que trabalham com C# ou Java, mas confesso que eu tenho uma queda por Python e Ruby.

O que vocês acham essas linguagens? Será o futuro (visto que muitas startups trabalham com ela)?

Não no mercado corporativo como já falado. Foi importante como advento para felizmente acabar com o “bom é fazer complexo”. Tanto no mundo do Java quanto principalmente no .NET já encontramos “inspirações” positivas das idéias do Ruby on Rails por exemplo. Nodejs também traz boas idéias que já estão sendo copiadas no .NET por ex. As plataformas mais usadas atualmente tem conseguido sobreviver ao tempo. Particularmente nunca quis perder tempo com Ruby ou Python, só se vier uma real necessidade.

É problema pra linguagem não ter sucesso no mercado corporativo?

COBOL é um grande sucesso no mercado corporativo, e no fim da sua vida adotou “inspirações” como orientação a objeto que prometia analistas em terno e gravata especificarem seus sistemas para os peões programadores implementarem. Todos sabemos o resultado…

Não conheço ninguém que gostaria de ser um programador COBOL hoje em dia.

linguagem mais usada == mais trabalho pra quem está no negócio de serviços.

Impossivel:

javaflex:

rafael.cs:

Olá pessoal!

Sempre trabalhei em empresas que trabalham com C# ou Java, mas confesso que eu tenho uma queda por Python e Ruby.

O que vocês acham essas linguagens? Será o futuro (visto que muitas startups trabalham com ela)?

Não no mercado corporativo como já falado. Foi importante como advento para felizmente acabar com o “bom é fazer complexo”. Tanto no mundo do Java quanto principalmente no .NET já encontramos “inspirações” positivas das idéias do Ruby on Rails por exemplo. Nodejs também traz boas idéias que já estão sendo copiadas no .NET por ex. As plataformas mais usadas atualmente tem conseguido sobreviver ao tempo. Particularmente nunca quis perder tempo com Ruby ou Python, só se vier uma real necessidade.

É problema pra linguagem não ter sucesso no mercado corporativo?

Exato, cada um com sua realidade. A do colega pode ser a de estar migrando para negócios que seriam melhor atendido com as linguagens citadas, e outra, repito que no final da jornada, dar uma olhada em outro paradigma de programação, ajuda a aperfeiçoar seus conceitos no paradigma em que já trabalha.

Realmente, acredito que você não precise parar pra estudar, mas não custa nada dar uma conferida.

Abs []

Ataxexe:

Complementando o adriano_si:

Eu acredito que estamos caminhando para um cenário onde a plataforma é mais relevante do que a linguagem. Um exemplo é você poder rodar Ruby e Python na JVM. Por isso vale a pena o aprendizado em linguagens de programação, vai te facilitar a resolver o problema com a ferramenta certa, e provavelmente rodando em cima da mesma plataforma do restante da sua solução.

Este cenário só é realista se você trabalha com produtos.

Se você trabalha com serviço muito provavelmente vai ser recrutado pro trabalho baseado na linguagem que o cliente, e não o profissional, decide é a melhor para o trabalho.

Como falei particularmente, é no meu caso, considerando mercado corporativo não existe um movimento para elas. Além disso, por ter facilidade em aprender algo novo quando surgir motivação real para uso, não vejo necessidade de gastar tempo aprendendo algo agora que não vejo grandes possibilidades de usar.

Exato, cada um com sua realidade. A do colega pode ser a de estar migrando para negócios que seriam melhor atendido com as linguagens citadas, e outra, repito que no final da jornada, dar uma olhada em outro paradigma de programação, ajuda a aperfeiçoar seus conceitos no paradigma em que já trabalha.

Realmente, acredito que você não precise parar pra estudar, mas não custa nada dar uma conferida.

Abs []
Acompanhar com certeza, tanto que observo as coisas boas que são copiadas delas.

Exato, cada um com sua realidade. A do colega pode ser a de estar migrando para negócios que seriam melhor atendido com as linguagens citadas, e outra, repito que no final da jornada, dar uma olhada em outro paradigma de programação, ajuda a aperfeiçoar seus conceitos no paradigma em que já trabalha.

Realmente, acredito que você não precise parar pra estudar, mas não custa nada dar uma conferida.

Abs []
Acompanhar com certeza, tanto que observo as coisas boas que são copiadas delas.

Como sabe se as coisas foram copiadas porque eram realmente boas e não… eh… porque existiam?

Exato, cada um com sua realidade. A do colega pode ser a de estar migrando para negócios que seriam melhor atendido com as linguagens citadas, e outra, repito que no final da jornada, dar uma olhada em outro paradigma de programação, ajuda a aperfeiçoar seus conceitos no paradigma em que já trabalha.

Realmente, acredito que você não precise parar pra estudar, mas não custa nada dar uma conferida.

Abs []
Acompanhar com certeza, tanto que observo as coisas boas que são copiadas delas.

Como sabe se as coisas foram copiadas porque eram realmente boas e não… eh… porque existiam?

Não sei, nem me importa, só sei que foram muito bem vindas na prática.

Na prática a maioria das empresas ainda usa Java 1.5 e .net 3.5.

Pergunta ao criador do tópico:

Se muitas startup trabalham com Ruby e Python já não seria o presente pra elas?

Boa

Ambas são muito parecidas em termo de tecnologia. Tratam de forma quase idêntica a questão do Threading entre outros apectos.

Ao meu ver, no mundo Ruby/Pyhton você não precisa se preocupar com certos detalhes de desenvolvimento que você precisa ter no Java. Por exemplo, o dinamismo da linguagem te favorece a implementar o conceito “convention over configuration”. Não que no Java não seja permitido, mas no Ruby a tendência é você ir pra esse caminho por causa do dinamismo. “Syntax sugares” a dar com rodo, pouca verbosidade entre outros aspectos que contribuem para tanto.

PORÉM (tudo tem um porém)

Vejo que cada vez mais a preocupação e os maiores desafios indo de encontro ao multithreading. Ou, a sistemas cada vez mais concorrentes e resilientes. No mundo Java, é meio que “normal e fácil” lidar com isso, uma vez que a JVM é poderosa no quesito threading. E Scala ta aí tbm, pra provar.

“Ruby/Python comes with GIL”
O lock global do interpretador do Ruby dificulta se você precisa desenvolver uma aplicação parruda que atenda uma pancada de requests simultaneos. Daí você precisa se especializar mais, conhecer o mundo Ruby/Python à sua volta e saber como tratar o problema (ex: JRuby,Jython, EventMachine, AsyncIO, etc).

Percebi com o tempo que pra desenvolver algo a sério com Ruby/Python (quando digo a sério, aplicação que guenta porrada e é resiliente), você precisa ter um grau ALTO de entendimento da stack, pois senão souber o que tá fazendo…hmm…dá merda! Fazer sistemas grandes em Ruby é possível, desde que você seja auto-didata e tenha um certo grau de experiência na área.

Já no mundo Java, muitos desses problemas para aplicações parrudas já foram resolvidos na JVM, cabendo ao programador o trabalho de entender sobre locks, cuidar do business model e das toneladas de XML’s ( ou annotations )

leandronsp:

Ambas são muito parecidas em termo de tecnologia. Tratam de forma quase idêntica a questão do Threading entre outros apectos.

Ao meu ver, no mundo Ruby/Pyhton você não precisa se preocupar com certos detalhes de desenvolvimento que você precisa ter no Java. Por exemplo, o dinamismo da linguagem te favorece a implementar o conceito “convention over configuration”. Não que no Java não seja permitido, mas no Ruby a tendência é você ir pra esse caminho por causa do dinamismo. “Syntax sugares” a dar com rodo, pouca verbosidade entre outros aspectos que contribuem para tanto.

PORÉM (tudo tem um porém)

Vejo que cada vez mais a preocupação e os maiores desafios indo de encontro ao multithreading. Ou, a sistemas cada vez mais concorrentes e resilientes. No mundo Java, é meio que “normal e fácil” lidar com isso, uma vez que a JVM é poderosa no quesito threading. E Scala ta aí tbm, pra provar.

“Ruby/Python comes with GIL”
O lock global do interpretador do Ruby dificulta se você precisa desenvolver uma aplicação parruda que atenda uma pancada de requests simultaneos. Daí você precisa se especializar mais, conhecer o mundo Ruby/Python à sua volta e saber como tratar o problema (ex: JRuby,Jython, EventMachine, AsyncIO, etc).

Percebi com o tempo que pra desenvolver algo a sério com Ruby/Python (quando digo a sério, aplicação que guenta porrada e é resiliente), você precisa ter um grau ALTO de entendimento da stack, pois senão souber o que tá fazendo…hmm…dá merda! Fazer sistemas grandes em Ruby é possível, desde que você seja auto-didata e tenha um certo grau de experiência na área.

Já no mundo Java, muitos desses problemas para aplicações parrudas já foram resolvidos na JVM, cabendo ao programador o trabalho de entender sobre locks, cuidar do business model e das toneladas de XML’s ( ou annotations )

Verdade. Não conheço muitos, mas por exemplo O VRaptor e o Play fazem bastante uso disto

Verdade. Não conheço muitos, mas por exemplo O VRaptor e o Play fazem bastante uso disto
GRails também

javaflex:

Graças ao sucesso do Ruby on Rails, Convention Over Configuration foi muito bem adotado em web frameworks Java e principalmente .NET.

Foi? Seria interessante ver os dados.

Eu sempre gosto de aprender linguagens novas. Ajuda a pensar de forma diferente, e de quebra ajuda a programar “melhor” em outras linguagens.
Nos últimos dois anos tenho focado em Python e (mais recentemente) Erlang.

É brutal como o paradigma funcional ajuda a pensar melhor na hora de resolver um problema dentro do universo imperativo.

Acabei me esquecendo de responder a pergunta do autor do tópico: “Essas linguagens são o futuro?”. Não.

O futuro é tecnologia, e não apenas uma linguagem. A linguagem IMO é apenas uma especificação, que pode ser implementada de diversas formas. Se você está emergido no Java, conheça o que existe no Java para resolver teu problema. Se for custoso, qual o custo então de resolver o problema com Python? E com Ruby? E com (arghh) Erlang? O que existe no mundo Ruby/Python/Erlang/C que possa resolver meu problema? Talvez essas são as perguntas deveríamos fazer.

Agora, se o objetivo é saber qual a hype do momento, sim, ambas linguagens têm tido muita aceitação em diversos setores de tecnologia. Sistemas de diversos tipos usam estas linguagens em produção, e não apenas os famosos blogs de 15 minutos, que têm uma config em produção que aponta pra localhost:3000
JS também tem ganhado uma atenção especial nos últimos tempos, de onde surgiram diversos frameworks (controversos ou não) no mercado.

Impossivel:

javaflex:

Graças ao sucesso do Ruby on Rails, Convention Over Configuration foi muito bem adotado em web frameworks Java e principalmente .NET.

Foi? Seria interessante ver os dados.

Entendo. No meu caso só atrapalha, prefiro me renovar mais com o tempo livre.