Scala: Bringing Future Languages to the JVM

Assuntos Gerais
#101

[quote=Mathemathic][quote=fredferrao]
Our website is currently offline for scheduled maintenance, but will be back around 13:45 UTC. Thank you for your patience!
:shock: :shock: :shock: :shock: Scala tambem precisa de manutenção. Fato :twisted: [/quote]
Scala vai alcançar uma maturidade muito mais rápido, isso é fato só no olhar de closure não atindo pelo Java 7, isso é FATO !!!

[/quote]

Scala com tanta maturidade e o Site é feito em PHP usando Dupral :wink:

Scala maturidade mais rápido? Com que base? Aonde está o fato nisso? qual a evolução do scala no ultimo ano? Ou é so é mais maduro por causa das closures?

Java não foi criado para ter closures, isso é fato. Não existe um jeito simples de alterar uma linguagem que nunca teve o proposito de possuir essa funcionalidade, consequentemente a alteração tem que ser bem avaliada.

Consigo fazer a maioria das coisas sem closures. Closures não é bala de prata, não vai salvar sua vida. Se vc não consegue desenvolver sem Closures tbm Não consegue com ela.

Até agora o unico FATO visto, foi vc alegando que Scala é Scala por isso é melhor (e tem closures tbm).

#102

[quote=Mathemathic][quote=fredferrao]
Our website is currently offline for scheduled maintenance, but will be back around 13:45 UTC. Thank you for your patience!
:shock: :shock: :shock: :shock: Scala tambem precisa de manutenção. Fato :twisted: [/quote]
Scala vai alcançar uma maturidade muito mais rápido, isso é fato só no olhar de closure não atindo pelo Java 7, isso é FATO !!!

[/quote]

Se o java não adicionou closure foi por escolha da SUN Microsystems. Não por deficiência de linguagem. Além de que closure não é uma coisa essencial.

#103

[quote=juliocbq]
O Duran, numa boa, se você quer usar Scala em seus projetos, não hà problema nenhum, é apenas mais uma
linguagem. Só não tenta impor suas idéias nas outras pessoas.[/quote]
Eu disse outra coisa, estou aqui levantando um questionamento sobre Scala não estou fazendo imposição mas vou sim trazer aqui todas as informações possiveis e imagináveis sobre essa tendencia, e disso vocês não me vetar.

#104

[quote=juliocbq]
Se o java não adicionou closure foi por escolha da SUN Microsystems. Não por deficiência de linguagem. Além de que closure não é uma coisa essencial.[/quote]
opaaa!!!

  • Vai ter que provar seus arguementos sobre Closure.
#105

[quote=Mathemathic][quote=juliocbq]
Se o java não adicionou closure foi por escolha da SUN Microsystems. Não por deficiência de linguagem. Além de que closure não é uma coisa essencial.[/quote]
opaaa!!!

  • Vai ter que provar seus arguementos sobre Closure.[/quote]

Então porque não prova os seus? Até agora te passei fontes de tudo aquilo que disse, na esperança que ao menos você lesse os artigos.

Se você segue tendências, nem deve ser considerado. Um profissional deve saber distinguir e selecionar o que é mais adequado para ele mesmo.

Prova para gente ae a superioridade da Scala, como você está pregando.

#106

Sim , vou colocar minhas fontes e informações e o que já estou ajuntando pra continuar esse Post.

#107

Dizer que Scala é um Java com closures ou que é um Ruby sem o Rails que deu certo na JVM é uma visão pessimista. Mas eu concordo com ela.

Essa questão de ter closures é pura besteira, ninguém faz nada com closures apenas. A linguagem precisa ser funcional para se adequar a nova geração de computadores multicore. O problema com Scala e outras linguagens funcionais (ou com closures) é que não tem como uma linguagem ser OO e ao mesmo tempo funcional o suficiente. A própria definição de objeto é imperativa, de agrupamento de função e dados mutáveis, enquanto programação funcional consiste na sua separação e maior predominancia de estado imutável. Portanto são conceitos totalmente diferentes e misturar os dois assim, na definição da linguagem, exige mecanismos que ainda precisam ser inventados para conciliar os dois paradigmas.

#108

O Facebook é bem mais complexo que o twitter e tem um número bem maior de usuários e é desenvolvido em PHP, e isso que é dita por aí como uma linguagem de má qualidade para ‘gambiarrizadores’, apesar de não concordar que a linguagem seja ruim. Bem, não quero discutir PHP e nem nada. Só quero usar como o argumento que o sucesso do projeto depende mais do conhecimento e experiência sobre a tecnologia do que a quantidade de ‘features’ dela. Na época que começaram o Facebook, era com PHP4 se não me engano. E nessa versão, a orientação a objetos era deprimente. Ela só foi melhorada na versão 5.x(e closures só entrou recentemente na 5.3, mas nem fazia falta). Ou seja, a maior rede social do mundo em número de acessos e número de usuários usa uma linguagem que qualquer cientista da computação trataria como ultrapassada se comparadas com as mais novas. Mas para eles serve. E muito bem. E ninguém tá reclamando. Não conheço Scala, mas me parece ser uma boa linguagem sim, assim como Ruby, Java, Python e muitas outras. Cada uma tem seus méritos e deficiências. Nenhuma delas é perfeita.

#109

Se vc pensa que todo o Facebook é feito em PHP aposto que se vc tivesse feito em Java estaria tudo dentro de um jar. :wink:

#110

Eu não seria capaz de me julgar melhor que uma pessoa que usa fortran, basic ou cobol só porque utilizo uma linguagem recente. Todos sabemos que o poder do programador está na sua capacidade lógica e no seu raciocínio, e não em uma mera linguagem, que apenas serve para expressar isso.

#111

Você quis dizer que Scala é superior a qualquer linguagem de programação ?

Poderia nos mostrar um exemplo de programa em Scala que você tenha feito, demonstrando toda a superioridade da linguagem ?

#112

Verdade. E como outros exemplos dá para citar o Wordpress e o Joomla.

#113

Aliás, complementando o tópico anterior. Esse papo de “linguagem é só ferramenta e podemos troca-la a cada projeto” é conversa pra boi dormir. Aliás, é outro argumento de vendedor de linguagens alternativas, que muitos tem comprado.

Não estou falando que devemos fechar os olhos para outras linguagens. De forma alguma. Mas não se pode trocar de linguagem o tempo todo, pois trocar de linguagem implica em:
a) Uma nova curva de aprendizado na nova linguagem, e em suas bibliotecas (esse é um custo que impactará em todos os membros da equipe);
b) Descobrir novos fornecedores de bibliotecas que sejam tão confiáveis quanto os da antiga (que solução vc usaria para persistência em scala? É tão garantido quanto o hibernate?)
c) Abrir mão do investimento já feito nas suas próprias libs internas, que resolvem diversos problemas diretamente relacionados com seu business.

Portanto, uma linguagem deve apresentar uma vantagem considerável para que seja trocada. Por exemplo, supondo que minha equipe seja proficiente em Java. Eu trocaria java por C++ se, e somente se, a aplicação exigisse tempo real, um baixo footprint ou integração pesada com hardware. Acho que seria muito difícil me convencer a sair do Java e ir para o C#, a menos talvez que exija mais interoperabilidade com a API do Windows.

Não estou falando de uma vantagem técnica, mas administrativa. E que deve ser levada em conta, pois representa um custo monstruoso, e não pode ser negligenciada. Como o colega demonstrou, mesmo uma linguagem mais simples, como o PHP, pode gerar resultados surpreendentes numa equipe com alto conhecimento técnico. E uma equipe assim fica muito difícil de se obter se você trocar de linguagem ou plataforma o tempo todo.

#114

[quote=ViniGodoy]
a) Uma nova curva de aprendizado na nova linguagem, e em suas bibliotecas (esse é um custo que impactará em todos os membros da equipe);[/quote]

Avanços representados pelas linguagens modernas farão com que elas sejam adotadas cada vez mais pelo mercado. A indústria ta se lixando pra sua curva de aprendizado. A demanda fará com que novos programadores atuem nesse novo paradigma enquanto “especialistas” Java passam a ser considerados os novos dinossauros.

[quote=ViniGodoy]
b) Descobrir novos fornecedores de bibliotecas que sejam tão confiáveis quanto os da antiga (que solução vc usaria para persistência em scala? É tão garantido quanto o hibernate?)
c) Abrir mão do investimento já feito nas suas próprias libs internas, que resolvem diversos problemas diretamente relacionados com seu business.[/quote]

b e c não precisam nem ser respondidas. Pelo visto vc nunca usou uma linguagem diferente de Java na JVM, senão saberia que o que já existe em Java não precisa ser necessariamente substituido.

E porque vc acha que Scala precisa de Hibernate?

#115

Como eu falei, não é necessário fechar os olhos para outras linguagens. O que sou contra é você assumir que a troca de uma linguagem para outra é uma operação sem custo. Obviamente, quando se troca de empresa, você terá que se adaptar ao mercado mas, como gerente de projetos dentro de uma mesma empresa, acho imprudente negligenciar os custos de treinamento/aprendizado.

Aliás, muitas tecnologias novas sequer irão se fixar no mercado. Por isso, ser um pouco conservador também pode poupar custos.

[quote=mochuara]
b e c não precisam nem ser respondidas. Pelo visto vc nunca usou uma linguagem diferente de Java na JVM, senão saberia que o que já existe em Java não precisa ser necessariamente substituido.[/quote]

Obviamente que já usei outras tecnologias na JVM, aliás, sou um dos que posta sobre Groovy no fórum, pois já o usei muito a fundo. Inclusive, já abri até bug reports para o groovy, e apresentei correções para alguns erros da linguagem:
http://jira.codehaus.org/browse/GROOVY-2392

Mas nesse caso, você está mantendo a plataforma, que é a VM. Estou falando num contexto mais amplo e, pode ver no meu post anterior, eu falei em linguagem/plataforma, não só em linguagem.

Aliás, não entendo pq no GUJ agora o padrão está se tornando responder como o thiagosc responde. Você mesmo se inflamou no tópico dele onde ele pressupos que você nunca tinha usado uma linguagem de funcional. Então, por favor, vamos prossupor aqui que nós sabemos do que estamos falando.

Talvez o Scala não precise, até porque o Hibernate faz mapeamento objeto relacional, e scala nem sequer é OO, e sim funcional.

Mas eu estava falando do serviço de persistência, e isso uma aplicação scala irá exigir. O que eu quis dizer, simplesmente, é que haverá necessidade de APIs para resolver muitas vezes os mesmos problemas, e você não terá que descobrir que APIs são essas. Existe o custo de se atrelar a um fornecedor, e esse fornecedor precisa ser confiável, ou você ficará na mão em longo prazo. Novamente, é um problema não só técnico, mas também administrativo. Numa troca de paradigma, você ainda pode ser surpeendido pelo contrário: problemas que você não tinha no paradigma anterior, e que terá no novo, e aí você descobre que aquela linguagem não era realmente a panacéia.

Não precisa ir muito longe. Recentemente troquei do Java para o C#, duas tecnologias praticamente iguais. Entretanto, no C#, tive que descobrir que APIs usar para persistência, ou para inversão de controle. Sabia que existia o Spring e o Hibernate para C#, mas eles teriam a mesma confiabilidade? Usariam os recursos do C# com eficiência? Muitas versões para outras linguagens não são tão boas fora de seu ambiente original. E o que usar para gerar relatórios? Não adianta, trocou a tecnologia, novas curvas de aprendizado, novas descobertas de fornecedores, etc. E tudo isso é custo.

#116

Só para ressaltar. Não estou dizendo que você deve fechar os olhos para outras linguagens/plataformas. Aliás, qualquer equipe de informática que queira se manter atualizada deve estar bem atento ao mercado, e experimentar tecnologias.

Mas acho que você deve mensurar bem se o ganho de produtividade é real, ou não. Se a tecnologia é realmente superior, ou se muito do que se fala dela é marketing.

Comece com um projeto piloto, pague a curva de aprendizado para um ou dois funcionários. Avalie se o desempenho dele foi realmente superior, obtenha feedback dele sobre os problemas encontrados na nova tecnologia. Veja se ela é realmente muito mais adequada para o tipo de problemas que você resolve. Só então faça a troca. Mas faça com base em dados concretos, não em achismos, modismos ou pq a revista “InfoQ” do mês disse que tem que ser assim.

#117

Scala não é OO?

Existe até conceito de propriedade em scala

private var value: T = init

/** The getter function, defaults to identity. */
private var setter: T => T = identity[T]

/** The setter function, defaults to identity. */
private var getter: T => T = identity[T]

Não sou especialista em scala, mas pelo pouco que eu estudei tive a impressão da linguagem ser OO sim.

#118

Tem razão. Pensei que ela fosse mais funcional do que OO, mas acho que me enganei. Mas isso não invalida todo resto da argumentação.

#119

Com certeza não, concordo em tudo o que vc escreveu.

Parabéns

Acho que li todos os arquigos de C++ do seu site ponto V. Todo o conteudo é acima da média.

#120

Já que eu entrei aqui vou dar a minha opinião, que é minha opinião IHMO opinão pessoal

Eu acho scala uma linguagem qualquer, se nada d+, sem nenhum atrativo. Mas uma entre muitas.

Me interesso muito mais por erlang, orientada a concorrencia, com hot swapping, propria para aplicações de tempo real.

Posso estar errado como eu já falei não sou especialista em scala, mas o pouco que vi achei scala carne de vaca.