Ceylon: nova linguagem de Gavin King para a JVM

Assuntos Gerais Notícias
#41

[quote=peczenyj]Hibernate não é um amontoado de xmls, basta ver o Hibernate Annotations

http://docs.jboss.org/hibernate/stable/annotations/reference/en/html_single/

Agora, querer comparar uma solução de ORM com diversas features como second level cache, lazy fetching, controle de transações com algo que simplesmente gera beans - que pode ser bem util - é forçar a barra. Afinal poderiamos simplesmente serializar os objetos em disco se fosse o caso.[/quote]

Sabe aquela grana pesada que gastaram nas licenças do Oracle ou do DB2? Que tal começar a utilizá-los? Cache, transações, etc são problemas do DB e não da aplicação. Para que se dar ao trabalho de fazer isso em software se o servidor de DB foi feito exclusivamente para isso? É uma incoerência trazer funções de um DB para o software.

Simples SQL com uma API que utilize DBUtils já dá conta do recado para a maior parte das aplicações Java. E assim seria possível utilizar os próprios componentes da sua lógica de negócio, sem DAOs ou coisa que o valha.

O argumento “mas e os Annotations…” é sinal de desespero. Em primeiro lugar que eles não desfazem anos de XML hell, e segundo que ainda há a necessidade de configuração, apenas mudaram-na de lugar.

#42

Eu acredito que a maioria dos frameworks são assim, não só Hibernate. As pessoas acabam utilizando-os por causa da moda e para colocar no currículo.

#43

Eu acredito que a maioria dos frameworks são assim, não só Hibernate. As pessoas acabam utilizando-os por causa da moda e para colocar no currículo.[/quote]

Sim, utilizam-no por causa da moda ou do curriculo, sem duvidas.

Mas isto nao quer dizer que automaticamente estas ferramentas sao inuteis. Como eu disse, se voce tem um modelo de negocios implementado seguindo as praticas OO, o Hibernate, ou outra ferramenta ORM, será indispensavel.

#44

Eu acredito que a maioria dos frameworks são assim, não só Hibernate. As pessoas acabam utilizando-os por causa da moda e para colocar no currículo.[/quote]

Sim, utilizam-no por causa da moda ou do curriculo, sem duvidas.

Mas isto nao quer dizer que automaticamente estas ferramentas sao inuteis. Como eu disse, se voce tem um modelo de negocios implementado seguindo as praticas OO, o Hibernate, ou outra ferramenta ORM, será indispensavel.[/quote]

Se uma moda depender de outra moda elas se anulam? Acho que não.

Sem explicar porque modelo de negócio deve ser OO (e não funcional, estruturado ou relacional) estamos falando de outra moda, senão a maior delas!

#45

Eu acredito que a maioria dos frameworks são assim, não só Hibernate. As pessoas acabam utilizando-os por causa da moda e para colocar no currículo.[/quote]

Sim, utilizam-no por causa da moda ou do curriculo, sem duvidas.

Mas isto nao quer dizer que automaticamente estas ferramentas sao inuteis. Como eu disse, se voce tem um modelo de negocios implementado seguindo as praticas OO, o Hibernate, ou outra ferramenta ORM, será indispensavel.[/quote]

Se uma moda depender de outra moda elas se anulam? Acho que não.

Sem explicar porque modelo de negócio deve ser OO (e não funcional, estruturado ou relacional) estamos falando de outra moda, senão a maior delas![/quote]

O problema nao eh ser ou nao moda, o problema eh usar sem saber porque, só porque eh moda.

#46

Annotations é sinal de desespero? cache deveria ser apenas pelo Database? :shock:

#47

Eu acredito que a maioria dos frameworks são assim, não só Hibernate. As pessoas acabam utilizando-os por causa da moda e para colocar no currículo.[/quote]

Sim, utilizam-no por causa da moda ou do curriculo, sem duvidas.

Mas isto nao quer dizer que automaticamente estas ferramentas sao inuteis. Como eu disse, se voce tem um modelo de negocios implementado seguindo as praticas OO, o Hibernate, ou outra ferramenta ORM, será indispensavel.[/quote]

Se uma moda depender de outra moda elas se anulam? Acho que não.

Sem explicar porque modelo de negócio deve ser OO (e não funcional, estruturado ou relacional) estamos falando de outra moda, senão a maior delas![/quote]

O problema nao eh ser ou nao moda, o problema eh usar sem saber porque, só porque eh moda.[/quote]

Mas a questão é que hibernate é inútil porque é desnecessário transformar em modelo de objetos na maioria das vezes. Mas em java seria uma heresia já que tudo é objeto, então cria-se frameworks para vários problemas que antes não existiam.

#48

[quote=marcosvinicius.rj]
Mas a questão é que hibernate é inútil porque é desnecessário transformar em modelo de objetos na maioria das vezes. Mas em java seria uma heresia já que tudo é objeto, então cria-se frameworks para vários problemas que antes não existiam.[/quote]

É isso mesmo. Não poderia ter explicado melhor.

#49

[quote=Paulo Silveira]Gavin King, da Red Hat, divulgou a linguagem Ceylon no QCon Beijing.

Uma linguagem estaticamente tipada para rodar em cima da JVM, e facilitar o desenvolvimento enterprise. Possuindo higher order functions, properties, nullable types, type inference e muitos outros recursos que sempre foram aguardados para o Java 7, e talvez só teremos no Java 8. Ha uma similaridade com Scala.

Será que Gavin King vai também acertar esse projeto, depois dos hits Hibernate e Seam?

mais informacoes:


http://in.relation.to/Bloggers/Ceylon[/quote]

Desculpe a pergunta, más o que é uma linguagem estaticamente tipada?

#50

esse cara parece k concorre p um grammie ou coisa parecida

#51

[quote=Henrique.tenorio][quote=Paulo Silveira]Gavin King, da Red Hat, divulgou a linguagem Ceylon no QCon Beijing.

Uma linguagem estaticamente tipada para rodar em cima da JVM, e facilitar o desenvolvimento enterprise. Possuindo higher order functions, properties, nullable types, type inference e muitos outros recursos que sempre foram aguardados para o Java 7, e talvez só teremos no Java 8. Ha uma similaridade com Scala.

Será que Gavin King vai também acertar esse projeto, depois dos hits Hibernate e Seam?

mais informacoes:


http://in.relation.to/Bloggers/Ceylon[/quote]

Desculpe a pergunta, más o que é uma linguagem estaticamente tipada?[/quote]

Herique, estaticamente tipada é como o java onde vc deve informar o tipo, obrigatoriamente por exemplo

//Tipo  Nome     Valor
   int    codigo = 0;
   codigo = "asdasd"; //erro

Em ruby, por exemplo, vc não precisa definir o tipo.

codigo = 0
codigo = "adasdasd"

O tipo e definido em tempo de execução.

#52

[quote=Felagund][quote=Henrique.tenorio][quote=Paulo Silveira]Gavin King, da Red Hat, divulgou a linguagem Ceylon no QCon Beijing.

Uma linguagem estaticamente tipada para rodar em cima da JVM, e facilitar o desenvolvimento enterprise. Possuindo higher order functions, properties, nullable types, type inference e muitos outros recursos que sempre foram aguardados para o Java 7, e talvez só teremos no Java 8. Ha uma similaridade com Scala.

Será que Gavin King vai também acertar esse projeto, depois dos hits Hibernate e Seam?

mais informacoes:


http://in.relation.to/Bloggers/Ceylon[/quote]

Desculpe a pergunta, más o que é uma linguagem estaticamente tipada?[/quote]

Herique, estaticamente tipada é como o java onde vc deve informar o tipo, obrigatoriamente por exemplo

//Tipo  Nome     Valor
   int    codigo = 0;
   codigo = "asdasd"; //erro

Em ruby, por exemplo, vc não precisa definir o tipo.

codigo = 0
codigo = "adasdasd"

O tipo e definido em tempo de execução.[/quote]

Muita calma nesta hora, o que voce acabou de explicar foi Inferencia de Tipos;

Scala é estaticamente tipada, e isto funciona perfeitamente, devido ao type inference:

Estaticamente tipada, o tipo é definido em compile-time, e nao pode ser mais alterado
Dinamicamente, é definido em runtime, e o tipo pode mudar.

Basicamente é isto.

#53

[quote=fredferrao]
Muita calma nesta hora, o que voce acabou de explicar foi Inferencia de Tipos;

Scala é estaticamente tipada, e isto funciona perfeitamente, devido ao type inference:

Estaticamente tipada, o tipo é definido em compile-time, e nao pode ser mais alterado
Dinamicamente, é definido em runtime, e o tipo pode mudar.

Basicamente é isto.[/quote]

Digamos que só quis ilustrar pra ficar mais facil o entendimento do cara.

Nunca mechi com Scala, e esse val é o mesmo do C#? uma keyword pra inferencia de tipos?

#54

[quote=Felagund][quote=fredferrao]
Muita calma nesta hora, o que voce acabou de explicar foi Inferencia de Tipos;

Scala é estaticamente tipada, e isto funciona perfeitamente, devido ao type inference:

Estaticamente tipada, o tipo é definido em compile-time, e nao pode ser mais alterado
Dinamicamente, é definido em runtime, e o tipo pode mudar.

Basicamente é isto.[/quote]

Digamos que só quis ilustrar pra ficar mais facil o entendimento do cara.

Nunca mechi com Scala, e esse val é o mesmo do C#? uma keyword pra inferencia de tipos?[/quote]

Não, o val não tem haver com inferencia em scala.

a keyword “val” serve para definir variaveis imutaveis, ou read-only.
ja o “var” para mutaveis.

Agora algo muito legal de scala, que deixa o código limpo se comparado com ruby, que é dinamicamente tipado, é o forte type inference que ela possui, inclusive para métodos, não somos obrigados a definir o tipo de retorno.

val a = 1
var b = "asdf"

//um metodo
def umMetodo = {
   println("teste")
}

def outroMetodo = {
  "retorno"
}
//aqui ele sabe que o retorno do metodo é uma string, e tambem nao precisamos do "return", em scala, a ultima instrução do metódo é o seu retorno.
#55

Mas em ruby vc não precisa do return ele é opcional

def outro_metodo
  "retorno"
end

Muito interessante essa abordagem de read-only :), preciso tirar um tempo pra dar uma olhada em scala :stuck_out_tongue:

#56

Achei uma pena ele ter tomado a decisão de não suportar sobrecarga em sua linguagem. :cry:

#57

[quote=Felagund] Mas em ruby vc não precisa do return ele é opcional

def outro_metodo
  "retorno"
end

[/quote]

Legal, eu só estava mostrando o type inference de scala. Em ruby, eu não sabia!

Sim, e o “val” é extremamente indicado nas “best practices”, devido a imutabilidade, e como Scala é OO e Funcional, eles pregam uso maximo de imutabilidade, para se evitar os side-effects, sendo mutabilidade um dos BIG problems de multithreading.

#58

:shock: ++

#59

Eu acredito que a maioria dos frameworks são assim, não só Hibernate. As pessoas acabam utilizando-os por causa da moda e para colocar no currículo.[/quote]

Sim, utilizam-no por causa da moda ou do curriculo, sem duvidas.

Mas isto nao quer dizer que automaticamente estas ferramentas sao inuteis. Como eu disse, se voce tem um modelo de negocios implementado seguindo as praticas OO, o Hibernate, ou outra ferramenta ORM, será indispensavel.[/quote]

Se uma moda depender de outra moda elas se anulam? Acho que não.

Sem explicar porque modelo de negócio deve ser OO (e não funcional, estruturado ou relacional) estamos falando de outra moda, senão a maior delas![/quote]

O problema nao eh ser ou nao moda, o problema eh usar sem saber porque, só porque eh moda.[/quote]

Mas a questão é que hibernate é inútil porque é desnecessário transformar em modelo de objetos na maioria das vezes. Mas em java seria uma heresia já que tudo é objeto, então cria-se frameworks para vários problemas que antes não existiam.[/quote]

Esta é a sua opinião, meu amigo, e que está longe de ser opinião da maioria. Os problemas que o Hibernate tenta resolver (tenta, porque nao resolve de todo) são problemas tão antigos quanto a proposta de objetos.

Acho curioso voce apontar como inutil algo que nos auxilia, sem apresentar nada em troca para aqueles, que como eu, e diferentemente de voce, acreditam e usam os objetos.

#60

Gavin King sem dúvida é uma pessoa com bastante mérito. O Hibernate pode não ser o ideal, mas é um dos frameworks que mais trouxe avanços no desenvolvimento de aplicações com ORM.

Vendo uma entrevista de Gavin na InfoQ, ele disse que Scala influenciou demais o design da Ceylon, mas que a própria Ceylon vai para um caminho diferenciado. E que a Ceylon será uma linguagem também para desenvolvedores de UI (fazedo menção ao falecido JavaFX).

Vasculhei algumas coisas sobre a linguagem e vejamos um pouco de sua definição:

Concatenação

Em várias linguagens, temos… "meu nome é " + nome + “!”

Em Ceylon será assim:

String nome;
writeLine("Meu nome é " nome "!");

Construtor

Difere de linguagens como Java e C# onde você define o escopo da classe e dentro desse escopo, define o construtor. Em Ceylon temos algo do tipo:

class MinhaClasse (String cNome, Int cIdade) {
	variable String nome := cNome;
	...

assign

Essa keyword represeta “get” e “set”, funciona para ambos os papéis.

Depois posto mais…