E porque o tal do Ruby on Rails não decolou?

Veja sobre o Grails, framework de groovy que roda em cima da JVM

Sparcx86:

tava lendo este topico que por sinal foi travado sei lá por que:

O sujeito que abriu tem sim muita razão em alguns argumentos, pensei que ele iria falar do Ruby e outras linguagens desse estilo pois esse negocio de type casting do Java, ter de criar get and sets e outros recursos só servem pra uma coisa: perder tempo e muito. Não sei precisar quanto tempo perdemos com bobagens como isso de verifica se um tipo é determinado, de verificar se um objeto é igual ao outro e outras coisas que poderiam ser simplesmente dinamicas com o uso do tal do Ruby que infelizmente jamais decolou (se virem citar meia duzia de projeto sinto muito mas nao serve).

Na epoca que ouvi falar do ruby achei uma otima ideia, alias até pensei que a Sun (epoca era a Sun hoje Oracle que detém o Java) iria incorpora-lo no compilador, assim poderiamos desenvolver codigo em Ruby nativamente em vez de java. Mas infelizmente nada disso se provou eficaz. Até hoje sinto uma raiva danada de perder tanto tempo definindo objetos, Value Object, get and seters, casting e outras coisas ultrapassadissimas que poderiam ser limadas ou simplesmente opcionais.

Na minha opinião algo como o ruby ou parecido devia ter sido incorporado há muito tempo dentro do JDK! Digo isso pois usar biblioteca separada nao dá, teria de ser nativo algo interno do compilador.

Dynamic typing não é bom em nenhuma linguagem. O java é fortemente tipado por uma grande razão, os sistemas legados em pascal/fortran/cobol quebravam muito por conta de variáveis fracamente tipadas.
Orientação a objetos não é suposta a ser fracamente tipada, o tipo dynamic no C# é um fiasco, veja as comunidades e o que elas reclamam sobre ele.

Como assim não decolou?
Segundo o Indeed, que é um agregador de vagas de emprego, há atualmente mais de 11 mil vagas de Rails pelo mundo e quase 200 só aqui no Brasil.
http://www.indeed.com/jobs?q=rails&l=
http://www.indeed.com.br/empregos?q=rails&l=
Acho que isso vai muito além de “meia duzia de projetos”, não acha?

E não sou “rubista”.

Eu já acho que não é questão de “decolar” ou “não decolar”, é questão de atingir seu público alvo. Ruby (bom, Rails. Ruby é uma linguagem de propósito geral) atingiu seu objetivo de mostrar pras pessoas um ambiente de desenvolvimento rápido voltado pra web sites. Lógico que não dá pra fazer projetos muito grandes com ela, porque a manutenção se torna um pesadelo, mas o objetivo foi atingido.

[]'s

Alexandre Saudate:

Eu já acho que não é questão de “decolar” ou “não decolar”, é questão de atingir seu público alvo. Ruby (bom, Rails. Ruby é uma linguagem de propósito geral) atingiu seu objetivo de mostrar pras pessoas um ambiente de desenvolvimento rápido voltado pra web sites. Lógico que não dá pra fazer projetos muito grandes com ela, porque a manutenção se torna um pesadelo, mas o objetivo foi atingido.

[]'s

Exato, fora que ainda é algo realmente novo, mas só cresce… Embora não seja nativo na JVM já há o JRuby que outro dia assistindo a uma apresentação, achei a proposta interessante.

Creio que a linha do raciocínio do RoR se diferencie da do Java. RoR não não veio pra tomar o lugar do Java, veio pra atacar fortemente onde o Java não era o melhor dos mundos, que era justamente o desenvolvimento Web rápido.

Mantenho Java como linguagem de desenvolvimento principal e é aonde sou mais produtivo, mas não dá pra fechar os olhos que Ruby On Rails tem conquistado.

Ainda não consigo enxergar tal coisa em Java: http://startupdev.com.br/

Abs []

Postei recentemente o link para um artigo que explica um pouco essa euforia sobre novas linguagens e porque isso não dá certo.

Recomendo também a leitura do artigo: No Silver Bullet: Essence and Accident in Software Engineering
“there is no single development, in either technology or management technique, which by itself promises even one order of magnitude improvement within a decade in productivity, in reliability, in simplicity”

Além disso, como os outros colegas disseram e só estou reforçando aqui, RoR é mais indicado para substituir PHP do que Java.

Sparcx86:

tava lendo este topico que por sinal foi travado sei lá por que:

O sujeito que abriu tem sim muita razão em alguns argumentos, pensei que ele iria falar do Ruby e outras linguagens desse estilo pois esse negocio de type casting do Java, ter de criar get and sets e outros recursos só servem pra uma coisa: perder tempo e muito. Não sei precisar quanto tempo perdemos com bobagens como isso de verifica se um tipo é determinado, de verificar se um objeto é igual ao outro e outras coisas que poderiam ser simplesmente dinamicas com o uso do tal do Ruby que infelizmente jamais decolou (se virem citar meia duzia de projeto sinto muito mas nao serve).

Na epoca que ouvi falar do ruby achei uma otima ideia, alias até pensei que a Sun (epoca era a Sun hoje Oracle que detém o Java) iria incorpora-lo no compilador, assim poderiamos desenvolver codigo em Ruby nativamente em vez de java. Mas infelizmente nada disso se provou eficaz. Até hoje sinto uma raiva danada de perder tanto tempo definindo objetos, Value Object, get and seters, casting e outras coisas ultrapassadissimas que poderiam ser limadas ou simplesmente opcionais.

Na minha opinião algo como o ruby ou parecido devia ter sido incorporado há muito tempo dentro do JDK! Digo isso pois usar biblioteca separada nao dá, teria de ser nativo algo interno do compilador.

cara você cria gets e sets na mão? não usa a IDE pra isso não? como que você perde tanto tempo com isso?
quanto a casts, qual versão do java você está usando, 1.4 - ? se for de 1.5 para cima (os generics “E” os boxing e unboxing) resolvem um monte de problema de cast, se você está usando uma versão antiga, o problema é estar usando uma versão antiga, se está usando uma nova e continua com estes problemas, provavelmente você está programando como se estivesse na versão antiga, eu te indicaria estudar e usar estes recursos…

java tem seus defeitos, é verdade, mas não vejo nada que seja assim problemático, particularmente acho que o alguns reclamam demais, muitas vezes por motivos bestas…

numa boa eu tinha que falar…

recentemente recebo ofertas de trabalho na Inglaterra pra trabalhar com Rails, lá pelo menos tá bombando muito… o salário é menor que o de Java, mas há muitas, muitas vagas mesmo!

acho que é difícil nós, que temos esse background de Java, ver se ele realmente “decolou”, pois vivemos lidando com sistemas legados, corporativos e integrações aleatórias. Eu vejo Rails (e Django) bombando muito em startups e empresas de internet. Agora, acho muito difícil ver Rails em empresas aqui no BR, citando por baixo alguns clientes: Net, Sky, Claro, Oi, Vivo, Tim, Itaú, Bradesco, CVC etc -> empresas onde há bastante gente que trabalha com Java (e pessoas daqui do fórum também)

doravan:

Dynamic typing não é bom em nenhuma linguagem. O java é fortemente tipado por uma grande razão, os sistemas legados em pascal/fortran/cobol quebravam muito por conta de variáveis fracamente tipadas.
Orientação a objetos não é suposta a ser fracamente tipada, o tipo dynamic no C# é um fiasco, veja as comunidades e o que elas reclamam sobre ele.

O motivo que eles quebram devia ser outro então porque nenhuma dessas linguagens é fraca, ou dinamicamente tipada.

Eu se fosse chutar diria que quebrava porque os programadores não sabia o que estavam fazendo mesmo.

Por quê dynamic do C# é um fiasco? Tudo existe para ser usado em momentos que aquilo seja adequado, cada equipe deve ter a consciência de trabalhar unido para isso, do que preferir trabalhar sem novas possibilidades flexíveis, como se fossemos crianças em não saber direito o que estamos lidando.

O que não fez decolar não sei, cheguei a comprar um livro e fazer algo, larguei pois a linguagem Ruby é muito chata. Mas a ideia do Rails é legal, só que preferi seguir com ASP.NET MVC que traz o melhor de todos os mundos.

maior_abandonado:

java tem seus defeitos, é verdade, mas não vejo nada que seja assim problemático, particularmente acho que o alguns reclamam demais, muitas vezes por motivos bestas…

numa boa eu tinha que falar…

Quanto ao assunto…

Tirem das vossas visões sistemas legados e grandes corporações financeiras. Esqueçam repartições públicas, pensem por apenas em algum momento em negócios do século XXI, com todo esse boom de empresas com novos modelos de negócios, onde entregas rápidas para feedbacks rápidos são fundamentais, Java não é nem TOP 3 na hora de escolher uma linguagem pra esse modelo, isso sendo bonzinho com a linguagem, embora eu acho que seja adequado a perto de 100% das situações como plataforma.

Abs []

Pessoalmente, eu também achei. Sem “porques” simplesmente meu espírito não bateu com a sintaxe…

Enfim :roll:

eu poderia passar batido nessa thread com assunto tosco como muitas aqui, mas essa não podia deixar de dizer que a maioria dos argumentos aqui foi totalmente mediano e sem sentido algum.

• primeiro, dá sim pra fazer o site startupdev em java em pouco tempo. É tão difícil isso?
• getters e setters tomam tempo. Não usa IDE?
• dizer que Rails veio pra substituir PHP. Só sabe fazer scaffold em Rails?
• empresas grandes não usam Rails. É piada né?

ruby é uma linguagem como outra qualquer, assim como java. ser religioso e não gostar dela não quer dizer que não presta.
e rails é um framework, não linguagem de programação. dá pra fazer desde um blog de 15 minutos (que muitos não saem disso) até sistemas complexos e distribuídos.

Não precisa disso. Olha só:

A JVM é uma maquina virtual.
O compilador do java gera o bytecode, e a jvm por sua vez interpreta esse bytecode pra instrucoes de maquina.

O JRuby faz a mesma coisa, tem o processo de analise lexica, ou tokenizer, faz o parsing e gera bytecode. Igualzinho no Java. Depois a Jvm pega o bytecode gerado e pumba!, interpreta pra instrução de maquina da mesma forma.

Pra que incorporar? Não tem sentido isso. Nem o próprio java, digamos assim, é “incorporado” no processo. Cada ferramenta com seu trabalho…

Por quê dynamic do C# é um fiasco? Tudo existe para ser usado em momentos que aquilo seja adequado, cada equipe deve ter a consciência de trabalhar unido para isso, do que preferir trabalhar sem novas possibilidades flexíveis, como se fossemos crianças em não saber direito o que estamos lidando.

Também não entendi. A documentação é bem clara ao dizer que esse tipo de dado é usado para representar objetos COM, páginas HTML e coisas que, a princípio, você entupiria o código de casts cheios de pré-supostos.
Não para transformar o C# em uma linguagem não tipada.

Opa, como esse argumento foi meu, me sinto na responsabilidade de responder…

Em pouco tempo, dá, consegui fazer um protótipo em Java para um negócio que tenho hoje em 1 dias… Depois foram mais 2 semanas refinando e colocando frameworks facilitadores em alguns aspectos sem mexer em nada no negócio. Ou seja, não foram apenas 24 horas foram 2 semanas e 1 dia.

Tá, pode ser o meu tempo e minha produtividade, mas meu argumento é baseado no tanto de esforço que eu tenho pra fazer um Sistema WEB com a linguagem Java e em GRails…

Se você consegue fazer ambos no mesmo tempo, legal, talvez eu esteja precisando praticar mais Java, mas pelo menos percebo o ganho de 60% ou mais de tempo com a segunda opção.

Agora me ficou uma dúvida, só eu acho que o ganho é assim? Pois posso estar com algum problema na hora de desenvolver em Java e preciso detectar…

Abs []

Não gostar não significa religião, apenas opção da pessoa ou equipe, e acho que não falamos que não presta. Sei do valor, mas pessoalmente hoje não me sentiria motivado escrevendo em Ruby, pra mim o fator de produtividade que mais pesa é a motivação da pessoa. Já o Rails realmente achei legal, tanto que o framework web que mais gosto (ASP.NET MVC) copiou muita ideia positiva dele. Eu quando fui tentar aprender Ruby on Rails agarrei o livro muito empolgado, mas a sintaxe da linguagem me desanimou, e se pode usar outra linguagem isso é obscuro para mim no mercado. Claro que se não tivesse um bom mercado para o que gosto (C# e Java), valeria o sacrifício de aprender essas linguagens diferentes de meu costume. Para as pessoas mais jovens que estão começando com certeza é muito tranquilo entrar nessa onda.

Então, realmente pelo fato de usar menos configurações, menos preocupação com ambiente e tal, você acabou fazendo em Ruby em menos tempo.
Acho que da forma que citei ficou um pouco rude, pois minha intenção não era entrar no mérito da produtividade de cada um, mas acabar com essa falácia que tem surgido nos últimos tempos aqui de que Ruby é apenas pra coisas simples.
E esse tipo de falácia não tem sentido nenhum, pois não vejo muito interesse por parte da galera em estudar ou aprender realmente como funciona. Mas nada contra ti, só usei teu argumento pois já vi parecido muitas vezes por aqui
Abs!

Sim, o Rails acabou sendo um amontado de “padrões” onde muitos outros players acabaram incorporando. Mas todos são padrões que já existiam, como exemplo, o ActiveRecord, que é um padrão catalogado no eaa. O Rails pegou esse padrões e aplicou alguns princípios, como DRY, CoC, etc.

eu particularmente não aprendo qualquer linguagem que seja pensando no mercado, aprendi ruby só pra adquirir mais conhecimento mesmo, e naturalmente as coisas foram aparecendo. Hoje uso tanto Ruby quanto Java profissionalmente, e te digo que o mercado de Ruby não está só crescendo, como cresceu. Muitas grandes empresas já o incorporaram, e existem até legados em Ruby.

No entanto se for olhar para as vagas em sua maioria consultorias, que já têm um legado em Java, claro que as vagas serão em sua maioria Java.
Por isso volto a dizer, que o papo de que Ruby é pra startup e Java para grandes projetos, ou a grosso modo, Ruby é pra crianças e Java é coisa de gente grande, não tem sentido

Sim, o Rails acabou sendo um amontado de “padrões” onde muitos outros players acabaram incorporando. Mas todos são padrões que já existiam, como exemplo, o ActiveRecord, que é um padrão catalogado no eaa. O Rails pegou esse padrões e aplicou alguns princípios, como DRY, CoC, etc.

eu particularmente não aprendo qualquer linguagem que seja pensando no mercado, aprendi ruby só pra adquirir mais conhecimento mesmo, e naturalmente as coisas foram aparecendo. Hoje uso tanto Ruby quanto Java profissionalmente, e te digo que o mercado de Ruby não está só crescendo, como cresceu. Muitas grandes empresas já o incorporaram, e existem até legados em Ruby.

No entanto se for olhar para as vagas em sua maioria consultorias, que já têm um legado em Java, claro que as vagas serão em sua maioria Java.
Por isso volto a dizer, que o papo de que Ruby é pra startup e Java para grandes projetos, ou a grosso modo, Ruby é pra crianças e Java é coisa de gente grande, não tem sentido ;)
Entendi, hoje eu só aprendo à fundo algo se tiver um objetivo, claro que quando era mais novo na faculdade eu queria aprender de tudo pois não sabia onde poderia parar, por incrível que pareça o VB quem me abriu a primeira porta, hoje não sei escrever um if, acho VB tão confuso quanto a sintaxe do Ruby. Eu fujo de consultorias, pois em fábrica de software temos que estar preparados para tudo mesmo. É muito positivo o Ruby on Rails no mercado, para quem goste ou para quem ver suas vantagens sendo aplicadas em outra tecnologia mais madura.

leandronsp:

Então, realmente pelo fato de usar menos configurações, menos preocupação com ambiente e tal, você acabou fazendo em Ruby em menos tempo.
Acho que da forma que citei ficou um pouco rude, pois minha intenção não era entrar no mérito da produtividade de cada um, mas acabar com essa falácia que tem surgido nos últimos tempos aqui de que Ruby é apenas pra coisas simples.
E esse tipo de falácia não tem sentido nenhum, pois não vejo muito interesse por parte da galera em estudar ou aprender realmente como funciona. Mas nada contra ti, só usei teu argumento pois já vi parecido muitas vezes por aqui
Abs!

Não cara, de forma alguma, não foi rude não, realmente a linha que separa rudeza de uma simples opinião bem colocada as vezes é muito tênue.

Eu concordo com você quando falas que Rails não é só pra coisas simples, até porque estou presnciando alguns colegas desenvolvendo algo fenomenal com RoR. O ponto principal da minha ideia, é o tempo de resposta no desenvolvimento de apps Web 2.0.

Possível, quase tudo é em quase todas as linguagens, mas quando levamos em consideração o item velocidade de desenvolvimento, RoR está bem na frente da linguagem Java e seus calhamaços de frameworks…

Só pra ficar claro, eu usei GRails e não Rails… rsrsrs

E desculpe também se pareceu rude minha resposta, mas coloquei a ideia de forma firme também, sem de fato estar com raiva quanto ao que você escreveu.

Não é que Rails não decolou.

É que o mercado não liga mais pra websites, o quente agora é desenvolver apps.

Infelizmente o Ruby não decolou tão alto como alguns entusiastas previram na época.

Mas ele tem um impacto importante que não podemos esquecer: O mundo dos frameworks Web (em diversas linguagens) se dividiu em “antes do Rails” e “depois do Rails”.
As idéias desse framework influenciaram tudo que veio depois em termos de velocidade de desenvolvimento, uso de convenções, código enxuto, etc.

gomesrod:

Infelizmente o Ruby não decolou tão alto como alguns entusiastas previram na época.

Mas ele tem um impacto importante que não podemos esquecer: O mundo dos frameworks Web (em diversas linguagens) se dividiu em “antes do Rails” e “depois do Rails”.
As idéias desse framework influenciaram tudo que veio depois em termos de velocidade de desenvolvimento, uso de convenções, código enxuto, etc.

doravan:

Sparcx86:

tava lendo este topico que por sinal foi travado sei lá por que:

O sujeito que abriu tem sim muita razão em alguns argumentos, pensei que ele iria falar do Ruby e outras linguagens desse estilo pois esse negocio de type casting do Java, ter de criar get and sets e outros recursos só servem pra uma coisa: perder tempo e muito. Não sei precisar quanto tempo perdemos com bobagens como isso de verifica se um tipo é determinado, de verificar se um objeto é igual ao outro e outras coisas que poderiam ser simplesmente dinamicas com o uso do tal do Ruby que infelizmente jamais decolou (se virem citar meia duzia de projeto sinto muito mas nao serve).

Na epoca que ouvi falar do ruby achei uma otima ideia, alias até pensei que a Sun (epoca era a Sun hoje Oracle que detém o Java) iria incorpora-lo no compilador, assim poderiamos desenvolver codigo em Ruby nativamente em vez de java. Mas infelizmente nada disso se provou eficaz. Até hoje sinto uma raiva danada de perder tanto tempo definindo objetos, Value Object, get and seters, casting e outras coisas ultrapassadissimas que poderiam ser limadas ou simplesmente opcionais.

Na minha opinião algo como o ruby ou parecido devia ter sido incorporado há muito tempo dentro do JDK! Digo isso pois usar biblioteca separada nao dá, teria de ser nativo algo interno do compilador.

Dynamic typing não é bom em nenhuma linguagem. O java é fortemente tipado por uma grande razão, os sistemas legados em pascal/fortran/cobol quebravam muito por conta de variáveis fracamente tipadas.
Orientação a objetos não é suposta a ser fracamente tipada, o tipo dynamic no C# é um fiasco, veja as comunidades e o que elas reclamam sobre ele.

Concordo, e mais…

Pra mim não tem diferença nenhuma em pegar uma linguagem fortemente tipada e ficar penando na criação de objetos, ou pegar uma linguagem sem tipagem e ter que ficar enchendo métodos de validações pra não quebrar o programa…

O tempo gasto é o mesmo…

Ruttmann:

Pra mim não tem diferença nenhuma em pegar uma linguagem fortemente tipada e ficar penando na criação de objetos, ou pegar uma linguagem sem tipagem e ter que ficar enchendo métodos de validações pra não quebrar o programa…

O tempo gasto é o mesmo…

Eu ainda acho que se gasta mais tempo para escrever um teste do que definir o tipo da variável. Fora que definindo o tipo, você ganha code-completion o que vale muito mais do que o tempo perdido na declaração.

Além disso, em Java, é garantido que esteja tudo ok. Já numa linguagem sem tipos fotes, vai saber se o teste é abrangente o suficiente…

Eu tenho uma filosofia básica, sempre é mais vantagem pegar o erro num estagio anterior do desenvolvimento. Se mais erros são acusados em tempo de compilação, melhor.

E ainda… economizar três linhas de desenvolvimento para uma sintaxe mais enxuta mais cheia de simbolos e que muitas vezes nem tem checagem em tempo de compilação só serve para chegar aquela máxima: 5 minutos desenvolvendo, 5 horas debugando.

Fui um tanto radical na minha opinião … mas é por aí…

Ruttmann:

doravan:

Sparcx86:

tava lendo este topico que por sinal foi travado sei lá por que:

O sujeito que abriu tem sim muita razão em alguns argumentos, pensei que ele iria falar do Ruby e outras linguagens desse estilo pois esse negocio de type casting do Java, ter de criar get and sets e outros recursos só servem pra uma coisa: perder tempo e muito. Não sei precisar quanto tempo perdemos com bobagens como isso de verifica se um tipo é determinado, de verificar se um objeto é igual ao outro e outras coisas que poderiam ser simplesmente dinamicas com o uso do tal do Ruby que infelizmente jamais decolou (se virem citar meia duzia de projeto sinto muito mas nao serve).

Na epoca que ouvi falar do ruby achei uma otima ideia, alias até pensei que a Sun (epoca era a Sun hoje Oracle que detém o Java) iria incorpora-lo no compilador, assim poderiamos desenvolver codigo em Ruby nativamente em vez de java. Mas infelizmente nada disso se provou eficaz. Até hoje sinto uma raiva danada de perder tanto tempo definindo objetos, Value Object, get and seters, casting e outras coisas ultrapassadissimas que poderiam ser limadas ou simplesmente opcionais.

Na minha opinião algo como o ruby ou parecido devia ter sido incorporado há muito tempo dentro do JDK! Digo isso pois usar biblioteca separada nao dá, teria de ser nativo algo interno do compilador.

Dynamic typing não é bom em nenhuma linguagem. O java é fortemente tipado por uma grande razão, os sistemas legados em pascal/fortran/cobol quebravam muito por conta de variáveis fracamente tipadas.
Orientação a objetos não é suposta a ser fracamente tipada, o tipo dynamic no C# é um fiasco, veja as comunidades e o que elas reclamam sobre ele.

Concordo, e mais…

Pra mim não tem diferença nenhuma em pegar uma linguagem fortemente tipada e ficar penando na criação de objetos, ou pegar uma linguagem sem tipagem e ter que ficar enchendo métodos de validações pra não quebrar o programa…

O tempo gasto é o mesmo…

Entao parte para Scala e seja feliz, fortemente tipada e com um type inference fodastico.

fredferrao:

Ruttmann:

doravan:

Sparcx86:

tava lendo este topico que por sinal foi travado sei lá por que:

O sujeito que abriu tem sim muita razão em alguns argumentos, pensei que ele iria falar do Ruby e outras linguagens desse estilo pois esse negocio de type casting do Java, ter de criar get and sets e outros recursos só servem pra uma coisa: perder tempo e muito. Não sei precisar quanto tempo perdemos com bobagens como isso de verifica se um tipo é determinado, de verificar se um objeto é igual ao outro e outras coisas que poderiam ser simplesmente dinamicas com o uso do tal do Ruby que infelizmente jamais decolou (se virem citar meia duzia de projeto sinto muito mas nao serve).

Na epoca que ouvi falar do ruby achei uma otima ideia, alias até pensei que a Sun (epoca era a Sun hoje Oracle que detém o Java) iria incorpora-lo no compilador, assim poderiamos desenvolver codigo em Ruby nativamente em vez de java. Mas infelizmente nada disso se provou eficaz. Até hoje sinto uma raiva danada de perder tanto tempo definindo objetos, Value Object, get and seters, casting e outras coisas ultrapassadissimas que poderiam ser limadas ou simplesmente opcionais.

Na minha opinião algo como o ruby ou parecido devia ter sido incorporado há muito tempo dentro do JDK! Digo isso pois usar biblioteca separada nao dá, teria de ser nativo algo interno do compilador.

Dynamic typing não é bom em nenhuma linguagem. O java é fortemente tipado por uma grande razão, os sistemas legados em pascal/fortran/cobol quebravam muito por conta de variáveis fracamente tipadas.
Orientação a objetos não é suposta a ser fracamente tipada, o tipo dynamic no C# é um fiasco, veja as comunidades e o que elas reclamam sobre ele.

Concordo, e mais…

Pra mim não tem diferença nenhuma em pegar uma linguagem fortemente tipada e ficar penando na criação de objetos, ou pegar uma linguagem sem tipagem e ter que ficar enchendo métodos de validações pra não quebrar o programa…

O tempo gasto é o mesmo…

Entao parte para Scala e seja feliz, fortemente tipada e com um type inference fodastico.

javaflex:

fredferrao:

Ruttmann:

doravan:

Sparcx86:

tava lendo este topico que por sinal foi travado sei lá por que:

O sujeito que abriu tem sim muita razão em alguns argumentos, pensei que ele iria falar do Ruby e outras linguagens desse estilo pois esse negocio de type casting do Java, ter de criar get and sets e outros recursos só servem pra uma coisa: perder tempo e muito. Não sei precisar quanto tempo perdemos com bobagens como isso de verifica se um tipo é determinado, de verificar se um objeto é igual ao outro e outras coisas que poderiam ser simplesmente dinamicas com o uso do tal do Ruby que infelizmente jamais decolou (se virem citar meia duzia de projeto sinto muito mas nao serve).

Na epoca que ouvi falar do ruby achei uma otima ideia, alias até pensei que a Sun (epoca era a Sun hoje Oracle que detém o Java) iria incorpora-lo no compilador, assim poderiamos desenvolver codigo em Ruby nativamente em vez de java. Mas infelizmente nada disso se provou eficaz. Até hoje sinto uma raiva danada de perder tanto tempo definindo objetos, Value Object, get and seters, casting e outras coisas ultrapassadissimas que poderiam ser limadas ou simplesmente opcionais.

Na minha opinião algo como o ruby ou parecido devia ter sido incorporado há muito tempo dentro do JDK! Digo isso pois usar biblioteca separada nao dá, teria de ser nativo algo interno do compilador.

Dynamic typing não é bom em nenhuma linguagem. O java é fortemente tipado por uma grande razão, os sistemas legados em pascal/fortran/cobol quebravam muito por conta de variáveis fracamente tipadas.
Orientação a objetos não é suposta a ser fracamente tipada, o tipo dynamic no C# é um fiasco, veja as comunidades e o que elas reclamam sobre ele.

Concordo, e mais…

Pra mim não tem diferença nenhuma em pegar uma linguagem fortemente tipada e ficar penando na criação de objetos, ou pegar uma linguagem sem tipagem e ter que ficar enchendo métodos de validações pra não quebrar o programa…

O tempo gasto é o mesmo…

Entao parte para Scala e seja feliz, fortemente tipada e com um type inference fodastico.

Tem algum link prático sobre Scala pra eu conhecer legal?

docs, tutoriais e artigos:
http://docs.scala-lang.org/

Livro Scala for the impatient 10 capitulos gratis:

mas o que eu quis dizer é, tu tem todo o poder da tipagem e ainda os beneficios e economia de código das dinamicas:

tipo:

val a = "fred" //ja vai ser "inferido" que a é String

//até mesmo os métodos tu nao precisa declarar o tipo de retorno

def soma(a: Int, b:Int) = a + b

Mas Scala não é só isto, tem muito mais, vale a pena dar uma olhada!

Scala não tem todo o poder da tipagem pq esse poder ainda não foi explorado

Só vai ter ele quando disponibilizarem uma IDE que seja tão boa quando o Eclipse é pra Java

Eu jamais vou trocar de linguagem na JVM enquanto não oferecem alguma outra que ou tenha o mesmo suporte via IDE ou seja mais rápida. Scala não tem nenhuma dessas 2 coisas

E pra quem não entender meu post anterior, vantagem de linguagem tipada pra mim = performance + IDE (autocomplete, code navigation, refactoring, etc)

A de Scala era horrível antigamente e ainda vejo muita gente reclamando, a que tá melhor agora parece ser a da IntelliJ IDEA pelo que vejo

victorcosta:

Scala não tem todo o poder da tipagem pq esse poder ainda não foi explorado

Só vai ter ele quando disponibilizarem uma IDE que seja tão boa quando o Eclipse é pra Java

Eu jamais vou trocar de linguagem na JVM enquanto não oferecem alguma outra que ou tenha o mesmo suporte via IDE ou seja mais rápida. Scala não tem nenhuma dessas 2 coisas

Existe um IDE para scala tão bom quanto o de java , se chama Eclipse. Mas cuidado que tem que ter o plugin mais recente.
Dá para fazer muitas coisas e é igual ao java (porque é igual ao eclipse). O scala é fortemente tipado, mais que qualquer outra linguagem com um sistema de generics que é absurdo (e complexo) que pode fazer quase tudo. Alguém brincou que o sistema de generics do scala é quase um máquina de Turing completa ( so o sistema de tipo). Ainda por cima em scala vc pode definir operadores. Definir mesmo, nao apenas override como em C# ou groovy. E com os simbolos que quiser. Eu fiz uma classe de Vector e defini o prudto interno como | e o externo como >< . É muito legal. Junte a isso funções e mixins e algumas outras cosas e o IDE é o que menos interessa…

victorcosta:

Scala não tem todo o poder da tipagem pq esse poder ainda não foi explorado

Só vai ter ele quando disponibilizarem uma IDE que seja tão boa quando o Eclipse é pra Java

Eu jamais vou trocar de linguagem na JVM enquanto não oferecem alguma outra que ou tenha o mesmo suporte via IDE ou seja mais rápida. Scala não tem nenhuma dessas 2 coisas

Scala roda igual java na JVM, alguns pontos uma outros a outra, mas são equivalentes. Se tu partir para um código o mais funcional possivel ele tende a ficar mais lento, mas nada que afete aplicações normais, se for um código que realmente precise ser muito performático, ainda assim tu pode escrever tal código em Scala, basicamente escrevento java com scala.

IDE, o suporte ja esta legal, tanto Eclipse quanto IDEA que é a que uso, e tem um excelente plugin Scala.

Não vou começar a velha batalha de X vs Z aqui, mas como em java temos que escrever na proporção de no minimo umas 6x ou mais código que scala ou ruby e outras, ha que precisar muito da IDE mesmo

fredferrao:

victorcosta:

Scala não tem todo o poder da tipagem pq esse poder ainda não foi explorado

Só vai ter ele quando disponibilizarem uma IDE que seja tão boa quando o Eclipse é pra Java

Eu jamais vou trocar de linguagem na JVM enquanto não oferecem alguma outra que ou tenha o mesmo suporte via IDE ou seja mais rápida. Scala não tem nenhuma dessas 2 coisas

Scala roda igual java na JVM, alguns pontos uma outros a outra, mas são equivalentes. Se tu partir para um código o mais funcional possivel ele tende a ficar mais lento, mas nada que afete aplicações normais, se for um código que realmente precise ser muito performático, ainda assim tu pode escrever tal código em Scala, basicamente escrevento java com scala.

IDE, o suporte ja esta legal, tanto Eclipse quanto IDEA que é a que uso, e tem um excelente plugin Scala.

Não vou começar a velha batalha de X vs Z aqui, mas como em java temos que escrever na proporção de no minimo umas 6x ou mais código que scala ou ruby e outras, ha que precisar muito da IDE mesmo

Scala tem uma performance boa, mas oq quis dizer é que não é melhor que Java. Eu só trocaria pra outra linguagem na JVM (sem suporte bom na IDE) caso ela tivesse alguma vantagem como performance melhor

Eu caí nesse papo de suporte a IDE tão bom quanto Java no Eclipse antes e não era verdade. Mas foi a muito tempo isso, tenho que testar denovo

fredferrao:

docs, tutoriais e artigos:
http://docs.scala-lang.org/

Livro Scala for the impatient 10 capitulos gratis:

mas o que eu quis dizer é, tu tem todo o poder da tipagem e ainda os beneficios e economia de código das dinamicas:

tipo:

val a = "fred" //ja vai ser "inferido" que a é String

//até mesmo os métodos tu nao precisa declarar o tipo de retorno

def soma(a: Int, b:Int) = a + b

Mas Scala não é só isto, tem muito mais, vale a pena dar uma olhada!

javaflex:

fredferrao:

docs, tutoriais e artigos:
http://docs.scala-lang.org/

Livro Scala for the impatient 10 capitulos gratis:

mas o que eu quis dizer é, tu tem todo o poder da tipagem e ainda os beneficios e economia de código das dinamicas:

tipo:

val a = "fred" //ja vai ser "inferido" que a é String

//até mesmo os métodos tu nao precisa declarar o tipo de retorno

def soma(a: Int, b:Int) = a + b

Mas Scala não é só isto, tem muito mais, vale a pena dar uma olhada!

Valeu, bom conhecer. Só não gostei que parece não ter ponto e virgula no final da instrução. Qual framework web mais usado, Play?

Não gostou? ; is boring

mas nada te impede de colocar, mas não é obrigado.
mas acredite, depois q acostumar nao vai mais querer saber de ponto e virgula. ponto e virgula existe pro compilador saber quando uma centença acabou, o compilador do scala tem a inteligencia necessária pra saber disto sozinho.

Frameworks web temos os dois full-stack que são Play e o Lift, e mais uma meia duzia de outros lightweight, tipo Unfiltrered, Scalatra e etc.

Scala esta bacana pra aprender, o ecosistema em volta dela esta muito grande, ja tem framework pra tudo que tu precisar, sem falar q em não havendo, tu pode usar um em java. Até um Spring Scala estão fazendo :twisted:

fredferrao:

javaflex:

fredferrao:

docs, tutoriais e artigos:
http://docs.scala-lang.org/

Livro Scala for the impatient 10 capitulos gratis:

mas o que eu quis dizer é, tu tem todo o poder da tipagem e ainda os beneficios e economia de código das dinamicas:

tipo:

val a = "fred" //ja vai ser "inferido" que a é String

//até mesmo os métodos tu nao precisa declarar o tipo de retorno

def soma(a: Int, b:Int) = a + b

Mas Scala não é só isto, tem muito mais, vale a pena dar uma olhada!

Valeu, bom conhecer. Só não gostei que parece não ter ponto e virgula no final da instrução. Qual framework web mais usado, Play?

Não gostou? ; is boring

mas nada te impede de colocar, mas não é obrigado.
mas acredite, depois q acostumar nao vai mais querer saber de ponto e virgula. ponto e virgula existe pro compilador saber quando uma centença acabou, o compilador do scala tem a inteligencia necessária pra saber disto sozinho.

Frameworks web temos os dois full-stack que são Play e o Lift, e mais uma meia duzia de outros lightweight, tipo Unfiltrered, Scalatra e etc.

Scala esta bacana pra aprender, o ecosistema em volta dela esta muito grande, ja tem framework pra tudo que tu precisar, sem falar q em não havendo, tu pode usar um em java. Até um Spring Scala estão fazendo :twisted:

Voltando ao assunto do tópíco (Rails)

Não sei se vcs tem acompanhado mas desde dezembro do ano passado saíram 2 falhas graves no framework, permitindo SQL injections em algumas aplicações (a falha q eu vi era um pouco difícil de explorar pq eram poucas aplicações q ficavam vulneráveis)

Mas agora a coisa explodiu de vez, se você tiver qualquer aplicação rails de qualquer versão seu servidor inteiro tá vulnerável pq a falha q descobriram agora permite acesso ao shell, sua rede inteira pode estar comprometida

Depois dessa vai ser difícil recuperar a reputação…

Ainda bem que Rails não é usado pra nada muito sério, ao contrário do Java…

[quote=JoseIgnacio]Ainda bem que Rails não é usado pra nada muito sério, ao contrário do Java…

Você mandaria bem como jornalista, você tem já tem a falta de conhecimento técnico e uma grande tendencia a distorcer os fatos.

diegosammet:

Você mandaria bem como jornalista, você tem já tem a falta de conhecimento técnico e uma grande tendencia a distorcer os fatos.

Só estou passando a notícia emitida pelo governo americano, mas fique a vontade para nos dizer aonde esta o equivoco…

JoseIgnacio:

diegosammet:

Você mandaria bem como jornalista, você tem já tem a falta de conhecimento técnico e uma grande tendencia a distorcer os fatos.

Só estou passando a notícia emitida pelo governo americano, mas fique a vontade para nos dizer aonde esta o equivoco…

O Equivoco é no seu entendimento sobre a plataforma e a sua aplicação. Na realidade a culpa não é sua, é de quem escreveu a matéria que deveria ter pesquisado mais a fundo antes de escrever qualquer merda que pode ser interpretada de N formas por pessoas leigas, como você.

O problema de vulnerabilidade é na utilização do java rodando cliente, por exemplo, como applet. Só que ao contrario do que você disse, ninguém usa java para nada “sério” do lado cliente, java para desktop é uma porcaria, e applet está em um nicho morto. 99% das utilizações “Sérias” em java, são feitas em aplicações server side… E nesse ponto o usuário não precisa se preocupar, porque nenhuma vulnerabilidade vai prejudicar ele. Logo, a noticia foi escrita por um leigo e na maioria dos casos a unica coisa que ela vai fazer é trazer desinformação e dar motivos pra pessoas como você virem encher o saco no fórum.

diegosammet:

O Equivoco é no seu entendimento sobre a plataforma e a sua aplicação. Na realidade a culpa não é sua, é de quem escreveu a matéria que deveria ter pesquisado mais a fundo antes de escrever qualquer merda que pode ser interpretada de N formas por pessoas leigas, como você.

O problema de vulnerabilidade é na utilização do java rodando cliente, por exemplo, como applet. Só que ao contrario do que você disse, ninguém usa java para nada “sério” do lado cliente, java para desktop é uma porcaria, e applet está em um nicho morto. 99% das utilizações “Sérias” em java, são feitas em aplicações server side… E nesse ponto o usuário não precisa se preocupar, porque nenhuma vulnerabilidade vai prejudicar ele. Logo, a noticia foi escrita por um leigo e na maioria dos casos a unica coisa que ela vai fazer é trazer desinformação e dar motivos pra pessoas como você virem encher o saco no fórum. :)

Você deve ter lido outra matéria então, ou não leu com atenção, porque em nenhum lugar diz que o usuário precisa se preocupar com software que está no servidor. A matéria diz que o usuário tem que desativar o Java que está no seu sistema.

A menos que você tenha uma solução para este problema que não precise desativar o Java, não há equívoco nenhum com a matéria.

OMG! Frameworks java também podem ter bugs que permitem execução remota de código. Exemplos:

Todo software tem problemas de segurança. Esse tipo de problema “queima” qualquer framework, mas nem por isso deixamos de usar. Windows, Linux, Java, Ruby, ou qualquer plataforma já tiveram falhas de segurança reveladas. Não importa qual linguagem ou framework vc use, vc sempre tem que ficar de olho e aplicar correções de segurança.

maior_abandonado:

Sparcx86:

tava lendo este topico que por sinal foi travado sei lá por que:

O sujeito que abriu tem sim muita razão em alguns argumentos, pensei que ele iria falar do Ruby e outras linguagens desse estilo pois esse negocio de type casting do Java, ter de criar get and sets e outros recursos só servem pra uma coisa: perder tempo e muito. Não sei precisar quanto tempo perdemos com bobagens como isso de verifica se um tipo é determinado, de verificar se um objeto é igual ao outro e outras coisas que poderiam ser simplesmente dinamicas com o uso do tal do Ruby que infelizmente jamais decolou (se virem citar meia duzia de projeto sinto muito mas nao serve).

Na epoca que ouvi falar do ruby achei uma otima ideia, alias até pensei que a Sun (epoca era a Sun hoje Oracle que detém o Java) iria incorpora-lo no compilador, assim poderiamos desenvolver codigo em Ruby nativamente em vez de java. Mas infelizmente nada disso se provou eficaz. Até hoje sinto uma raiva danada de perder tanto tempo definindo objetos, Value Object, get and seters, casting e outras coisas ultrapassadissimas que poderiam ser limadas ou simplesmente opcionais.

Na minha opinião algo como o ruby ou parecido devia ter sido incorporado há muito tempo dentro do JDK! Digo isso pois usar biblioteca separada nao dá, teria de ser nativo algo interno do compilador.

cara você cria gets e sets na mão? não usa a IDE pra isso não? como que você perde tanto tempo com isso?
quanto a casts, qual versão do java você está usando, 1.4 - ? se for de 1.5 para cima (os generics “E” os boxing e unboxing) resolvem um monte de problema de cast, se você está usando uma versão antiga, o problema é estar usando uma versão antiga, se está usando uma nova e continua com estes problemas, provavelmente você está programando como se estivesse na versão antiga, eu te indicaria estudar e usar estes recursos…

java tem seus defeitos, é verdade, mas não vejo nada que seja assim problemático, particularmente acho que o alguns reclamam demais, muitas vezes por motivos bestas…

numa boa eu tinha que falar…

Veja nao sou dono da verdade, tem gente aqui que tem mais experiencia que eu, entendo que a linguagem tem la seus motivos mas o que perdemos de tempo com essas coisas estranhas que nada tem a ver com o core mesmo do projeto não é brinquedo.

Entendo teu ponto de vista, foi apenas uma observação. :lol:

Acho que já ta na hora de ‘modernizarem’ a linguagem, tirar os excessos ou torna-los opcionais. TEm projetos que eu pego e só pra criar uma simples tela voce edita uns 4 ou 5 XML´s e cria duas ou tres classes ai voce pergunta e dizem que são design patterns, voce vai ver os patterns tem uns 10 anos atras pra resolver problemas que não existem mais. :lol:

Sparcx86:

Veja nao sou dono da verdade, tem gente aqui que tem mais experiencia que eu, entendo que a linguagem tem la seus motivos mas o que perdemos de tempo com essas coisas estranhas que nada tem a ver com o core mesmo do projeto não é brinquedo.

Entendo teu ponto de vista, foi apenas uma observação. :lol:

Acho que já ta na hora de ‘modernizarem’ a linguagem, tirar os excessos ou torna-los opcionais. TEm projetos que eu pego e só pra criar uma simples tela voce edita uns 4 ou 5 XML´s e cria duas ou tres classes ai voce pergunta e dizem que são design patterns, voce vai ver os patterns tem uns 10 anos atras pra resolver problemas que não existem mais. :lol:

Concordo plenamente, mas alguns veem soluções complexas como se aquilo tivesse mais valor, sendo que o mais importante é focar nas necessidades do cliente.

Sparcx86:

maior_abandonado:

Sparcx86:

tava lendo este topico que por sinal foi travado sei lá por que:

O sujeito que abriu tem sim muita razão em alguns argumentos, pensei que ele iria falar do Ruby e outras linguagens desse estilo pois esse negocio de type casting do Java, ter de criar get and sets e outros recursos só servem pra uma coisa: perder tempo e muito. Não sei precisar quanto tempo perdemos com bobagens como isso de verifica se um tipo é determinado, de verificar se um objeto é igual ao outro e outras coisas que poderiam ser simplesmente dinamicas com o uso do tal do Ruby que infelizmente jamais decolou (se virem citar meia duzia de projeto sinto muito mas nao serve).

Na epoca que ouvi falar do ruby achei uma otima ideia, alias até pensei que a Sun (epoca era a Sun hoje Oracle que detém o Java) iria incorpora-lo no compilador, assim poderiamos desenvolver codigo em Ruby nativamente em vez de java. Mas infelizmente nada disso se provou eficaz. Até hoje sinto uma raiva danada de perder tanto tempo definindo objetos, Value Object, get and seters, casting e outras coisas ultrapassadissimas que poderiam ser limadas ou simplesmente opcionais.

Na minha opinião algo como o ruby ou parecido devia ter sido incorporado há muito tempo dentro do JDK! Digo isso pois usar biblioteca separada nao dá, teria de ser nativo algo interno do compilador.

cara você cria gets e sets na mão? não usa a IDE pra isso não? como que você perde tanto tempo com isso?
quanto a casts, qual versão do java você está usando, 1.4 - ? se for de 1.5 para cima (os generics “E” os boxing e unboxing) resolvem um monte de problema de cast, se você está usando uma versão antiga, o problema é estar usando uma versão antiga, se está usando uma nova e continua com estes problemas, provavelmente você está programando como se estivesse na versão antiga, eu te indicaria estudar e usar estes recursos…

java tem seus defeitos, é verdade, mas não vejo nada que seja assim problemático, particularmente acho que o alguns reclamam demais, muitas vezes por motivos bestas…

numa boa eu tinha que falar…

Sim amigo, é obvio que uso Eclipse e ele gera tudo automaticamente, porém voce nao entendeu meu ponto de vista. Isto tudo é muito codigo redundante, na minha visão, nao agrega nada no negocio do produto.

Veja nao sou dono da verdade, tem gente aqui que tem mais experiencia que eu, entendo que a linguagem tem la seus motivos mas o que perdemos de tempo com essas coisas estranhas que nada tem a ver com o core mesmo do projeto não é brinquedo.

Entendo teu ponto de vista, foi apenas uma observação. :lol:

Acho que já ta na hora de ‘modernizarem’ a linguagem, tirar os excessos ou torna-los opcionais. TEm projetos que eu pego e só pra criar uma simples tela voce edita uns 4 ou 5 XML´s e cria duas ou tres classes ai voce pergunta e dizem que são design patterns, voce vai ver os patterns tem uns 10 anos atras pra resolver problemas que não existem mais. :lol:

Se você acha que os gets e sets não agregam nada ao seu produto…Deixa os atributos como public … dai não precisa de gets e sets =)