http://code.google.com/p/cajuscript/
Para saber os lançamentos das novas versões e tirar dúvidas registre-se no mailing list do projeto:
http://groups.google.com/group/cajuscript
Sugestões e criticas são bem vindas. E para quem quiser ajudar a dar continuidade ao projeto esta convidado.
a principio os parabens… é um excelente exemplo de brasilero fazendo coisa bem feita, mesmo com certo preconceito q as vezes vejo até mesmo aqui dentro do brasil…
parabens mesmo… rs e quando eu crescer quero ajudar nisso…hehe
Antes de tudo, não estou criticando.
Mas existem tantas linguagens de scripting hj, o que levaria um desenvolvedor largar Groovy (como eu) e utilizar CajuScript ?
É uma ótima iniciativa, mais questiono a criatividade, novos paradigmas, conceitos, estruturas e ferramentas a serem inseridas em linguagens.
Um exemplo são as Closures: é uma coisa antiga, e alguns pensam que é novidade e só algumas linguagens (de scripting ou não) à incorporam com sucesso.
[quote=LuksS]Antes de tudo, não estou criticando.
Mas existem tantas linguagens de scripting hj, o que levaria um desenvolvedor largar Groovy (como eu) e utilizar CajuScript ?
É uma ótima iniciativa, mais questiono a criatividade, novos paradigmas, conceitos, estruturas e ferramentas a serem inseridas em linguagens.
Um exemplo são as Closures: é uma coisa antiga, e alguns pensam que é novidade e só algumas linguagens (de scripting ou não) à incorporam com sucesso.[/quote]
Em desenvolvimento web tive grande dificuldade em encontrar uma linguagem de script de alta performance para o que eu precisava.
E ai que entra o CajuScript, que é usado em paralelo com uma framework web que estou desenvolvendo a alguns anos e em breve estará disponível.
Conseguimos grandes performances e soluções bastante dinâmicas graças ao CajuScript. O consumo de memória, cpu, startup, do CajuScript é muito superior ao do Groovy por exemplo. Faça os testes.
Veja aqui o caso do Gustavo que usava Groovy:
http://www.guj.com.br/posts/list/15/86146.java#579929
Acabou entrando para o projeto do CajuScript.
Mas ai no teste dele ele mostra bem algumas das grandes diferenças em performance entre CajuScript vs Groovy.
A questão é, se vc liga para performance então isto vai ter provavelmente muito mais peso na escolha da linguagem do que outros fatores.
O objetivo do CajuScript não é fazer tudo que o Groovy faz, mas sim o que fizer fazer o mais rápido possível.
E outra o CajuScript tem algo diferencial entre as outras linguagens de script… sintaxe dinâmica! Isto pode não ter muito interesse a primeira vista, mas para quem quer ter uma linguagem rápida e customizada a sua medida como melhor lhe agrada, CajuScript tem este ponto forte também.
Mas além da performance, sintaxe, também tem a questão gosto! E isto vai de cada um…
[quote=LuksS]Antes de tudo, não estou criticando.
Mas existem tantas linguagens de scripting hj, o que levaria um desenvolvedor largar Groovy (como eu) e utilizar CajuScript ?
É uma ótima iniciativa, mais questiono a criatividade, novos paradigmas, conceitos, estruturas e ferramentas a serem inseridas em linguagens.
Um exemplo são as Closures: é uma coisa antiga, e alguns pensam que é novidade e só algumas linguagens (de scripting ou não) à incorporam com sucesso.[/quote]
Estes são os mesmos questionamentos que fizeram ao Linux ou ao MySQL qdo surgiram. Entretanto, se os desenvolvedores focarem em performance e simplicidade podem sim, vir a se tornar uma grande referencia.
O maior problema das pessoas está no achar ou ver que mais um não significa nada ou que até mesmo, não vai dar em nada. Pode até ser que no momento, realmente não valha de nada, mas adiante, nunca saberemos. Tudo depende mais do empenho de quem mantem o projeto. E aos desenvolvedores, meus sinceros parabéns. Descartem os maus críticos e aceitem os bons, que ajudam muito, de certa forma, apontando os problemas.
Vc está desvirtuando a discussão. Em nenhum momento minha questão está baseada em achismos, muito menos em críticas que não levam à nada. Eu simplesmente perguntei qual é a proposta de CajuScript e eduveks explicou suas razões. Eu acho que o maior problema das pessoas é a falta de atenção ao interpretar uma pergunta ou declaração. Como disse, é uma ótima iniciativa, uma resposta aos desenvolvedores estrangeiros de que o Brasil também exporta tecnologia. VRaptor, Genesis, MentaWay, Swingbean, JSenna e agora CajuScript são exemplos
Bom, a princípio, parabéns.
Mas você não acha covardia comparar a performance do cajuScript com groovy sendo que o último tem muito mais features do que o primeiro? 
[quote=neófito]Bom, a princípio, parabéns.
Mas você não acha covardia comparar a performance do cajuScript com groovy sendo que o último tem muito mais features do que o primeiro?
[/quote]
mas a comparação é performance e não quantidade de features!
[quote=peerless][quote=neófito]Bom, a princípio, parabéns.
Mas você não acha covardia comparar a performance do cajuScript com groovy sendo que o último tem muito mais features do que o primeiro?
[/quote]
mas a comparação é performance e não quantidade de features! [/quote]
Exatamente!
Num ambiente onde a performance conta, principalmente em produção, você vai preferir ter uma solução rápida ou uma com features?
O que o CajuScript propõe pra já é ser um complemento ao Java, tentando ter o menor impacto possível na performance.
O que devem levar em conta também é que o CajuScript é um projeto do zero, tem pouco tempo de vida comparado as outras linguagens de script, e não quer dizer que não venhamos a ter muitas das features que as outras linguagens tem. Em cada versão acrescentamos mais algum recurso.
Para a versão 4, o principal objetivo é um melhor tratamento de arrays, collections e maps.
Agora se querem dizer que o CajuScript tem menos recursos que o Groovy e por isso é mais rápido. Isto não é verdade. O que o Groovy faz num loop por exemplo? Por que ele demora tanto a inicializar? Isto são problemas básicos que o CajuScript já tem ultrapassado, mas normalmente é por que a maioria das linguagens de script usam parsers e interpretadores de terceiros, no CajuScript foi feito tudo do zero, a medida, isto nos da muito mais liberdade para fazermos o que quisermos, e por isso também conseguimos fazer a sintaxe dinâmica.
Por exemplo o Marcos fez este recurso:
http://code.google.com/p/cajuscript/wiki/tutorialOperable
Para ajuda-lo a realizar calculos em 2D e 3D, ele viu o projeto, foi ver o código para ver se dava para fazer isto, e em poucas horas me mandou esta idéia!
Você consegue ter esta facilidade em outros motores?
O que quero dizer é que o CajuScript não é nenhum bicho de sete cabeças, é simples, e fácil de fazer certas features. Só é preciso ter criatividade.
Neste momento CajuScript tem 3 opções para executar um script:
:arrow: Normal, mais lento, uso de regular expression para interpretar o script com a feature de sintaxe dinâmica o que torna pesado.
:arrow: Cache, um pouco mais lento na primeira vez, mas depois mantem o parser em memória tornando as próximas execuções muito mais rápidas, em scripts mais longos faz muita diferença comparado com execuções em modo normal, a desvantagem é que consome memória.
:arrow: Compile, compila o script em uma class Java, bytecode, primeira vez demora mais, pois tem que interpretar e compilar, mas as próximas vezes extremamente rápido. O objetivo para as próximas versões também é melhor ainda mais.
O Groovy por exemplo tem estes recursos de exeução? Então até que ponto performance é importante para você ou para o teu projeto? Que opções você tem no Groovy de otimizações?
Mas como já disse o gosto conta muito, e o hábito também, quem esta hábituado a trabalhar com uma linguagem que é “mão na roda” dificilmente vai largar mão para ter mais performance, ai se ficar lento vai precisar de mais hardware, mas quanto mais hardware você colocar, talvez se você tivesse uma solução mais performática seria sempre mais rápido, com mais hardware mais rápido ainda. E não quer dizer que o CajuScript não venha a ter muitos das facilidades do Groovy e companhia, estamos tentando caminhar para isto.
Java tem uma má fama, é pesado, pois consome muita memória, e o CajuScript é uma maneira de minimizar este impacto. Como eu já disse em outra altura, eu usava LuaJava por ser muito mais rápida que as outras linguagens, só que como o projeto esta abandonado e tem alguns bugs cruciais pra mim, fui forçado a procurar alternativa melhor, e cada vez que ia testando uma nova linguagem ficava decepcionado, me vi forçado a fazer algo a medida para o que eu precisava.
Como já disse estamos abertos a idéias, qualquer sugestão que acham que o CajuScript deveria focar para as próximas versões, que vejam que seria muito útil e que faz falta, só dizerem e vamos colocar na nossa lista de prioridades.
[quote=peerless][quote=neófito]Bom, a princípio, parabéns.
Mas você não acha covardia comparar a performance do cajuScript com groovy sendo que o último tem muito mais features do que o primeiro?
[/quote]
mas a comparação é performance e não quantidade de features! [/quote]
Sim, mas com algumas features que o groovy tem e o cajuScript não, fica difícil comparar a performance dos dois. Dois exemplos simples são closures e metaprogramming. O groovy suporta os dois e faz uso massivo deles, e todos sabemos que a performance usando isso sempre será menor do que uma linguagem que não os usa, como o cajuScript. Sendo assim, a comparação de performance entre os dois não é justa.
[quote=neófito][quote=peerless][quote=neófito]Bom, a princípio, parabéns.
Mas você não acha covardia comparar a performance do cajuScript com groovy sendo que o último tem muito mais features do que o primeiro?
[/quote]
mas a comparação é performance e não quantidade de features! [/quote]
Sim, mas com algumas features que o groovy tem e o cajuScript não, fica difícil comparar a performance dos dois. Dois exemplos simples são closures e metaprogramming. O groovy suporta os dois e faz uso massivo deles, e todos sabemos que a performance usando isso sempre será menor do que uma linguagem que não os usa, como o cajuScript. Sendo assim, a comparação de performance entre os dois não é justa.[/quote]
Isto se aplica no teste de loops simples? Como o que usamos nos testers de performance?
Um script bem básico só um loop… e isto não é uma comparação justa?!
O que tem a ver isto com o consumo de memória excessivo?
Faça testes, básicos e verá logo a diferença. E creio que você ainda não viu isto:
http://www.guj.com.br/posts/list/15/86146.java#579929
Pela tua agurmentação justifica a perda de performance então quando o cliente esta reclamando que tem 1000 conexões simultâneas e o servidor ta empacado, e vc vai dizer: O Groovy usa closures e metaprogramming por isso é meio pesado e não da para melhorar! Tem que ter pelo menos uns 32GB no mínimo de memória.???
Se tiver alguma dica de como tornar os testes mais justos, por favor nos ajude.
Bom, se você não quiser ir até onde o groovy e o jruby foram, o máximo que você vai conseguir é adicionar syntax sugar ao java, o que não é uma coisa ruim. Mas recursos sofisticados como closures e metaprogramming sempre terão um impacto na performance.
Não entendi. O que pode ser lento é a iteração com closures, do tipo:
[1, 2, 3].each{ println it }Mas o loop do groovy não. O código abaixo roda com uma performance próxima a do java:
def nums = [1, 2, 3]
for(num in nums){ println it }O groovy possui dois modos de execução: pré-compilado ou compilado em run-time. A desvantagem do compilado em run-time é que há um tempo de startup maior, mas após a compilação do primeiro script os outros são compilados muito rapidamente. Um interpretador ao estilo ruby realmente faz falta, pelo menor tempo de startup.
Ainda acho que o cajuScript faz muito menos que o groovy e jruby, e se um dia fizer, a performance certamente vai diminuir. Isso não quer dizer que eu ache o projeto ruim, só não acho correto a comparação de performance com linguagens como groovy e jruby. E como disse, um bom caminho a seguir é adicionar syntax sugar ao java, o que pode ser interessante para execução de scripts.
[quote=eduveks]Pela tua agurmentação justifica a perda de performance então quando o cliente esta reclamando que tem 1000 conexões simultâneas e o servidor ta empacado, e vc vai dizer: O Groovy usa closures e metaprogramming por isso é meio pesado e não da para melhorar! Tem que ter pelo menos uns 32GB no mínimo de memória.???
Se tiver alguma dica de como tornar os testes mais justos, por favor nos ajude.
[/quote]
O groovy usa mais memória por um simples fato: usa metaprogramming. E para adaptar esse modelo ao java é necessário muito mais memória do que o normal.
Como já disse, não acho que o cajuScript não tenha seus méritos. Mas comparar caju com melancia não dá né?
[quote=neófito]Não entendi. O que pode ser lento é a iteração com closures, do tipo:
[1, 2, 3].each{ println it }Mas o loop do groovy não. [size=18]O código abaixo roda com uma performance próxima a do java:[/size]
def nums = [1, 2, 3]
for(num in nums){ println it }[/quote]
neófilo, o teu azar é que eu tenho aqui tudo pronto para realizar testes, então vou resumir tudo a isto:
long time = 0;
time = System.currentTimeMillis();
groovy.lang.GroovyShell groovyShell = new groovy.lang.GroovyShell();
int xGroovy = 0;
for (int i = 0; i < 500; i++) {
groovyShell.setVariable("x", new Integer(0));
groovyShell.setVariable("nums", new int[] {1,2,3});
groovyShell.evaluate("for(num in nums){ x = x + num; }");
xGroovy += ((Integer)groovyShell.getVariable("x")).intValue();
}
System.out.println("Groovy: "+ (System.currentTimeMillis() - time) + "ms - " + xGroovy);
time = System.currentTimeMillis();
org.cajuscript.CajuScript caju = new org.cajuscript.CajuScript();
int xCaju = 0;
for (int i = 0; i < 500; i++) {
caju = new org.cajuscript.CajuScript();
caju.set("x", new Integer(0));
caju.set("nums", new int[] {1,2,3});
caju.eval("caju.cache: test; caju.each('num', nums) @ x = x + num; @;");
xCaju += ((Integer)caju.get("x")).intValue();
}
System.out.println("Caju: "+ (System.currentTimeMillis() - time) + "ms - "+ xCaju);Output:
Groovy: 7203ms - 3000
Caju: 671ms - 3000
É preciso mais? Quanto mais vc aumentar o número 500 maior será a diferença.
Detalhe, para cada iteração do loop for esta sendo criado uma nova instancia do CajuScript, e no caso do Groovy esta usando sempre a mesma instancia, por isso o CajuScript esta em desvantagem, devido a um problema que detectei agora, o for each do CajuScript não pode ser usado mais que uma vez usando a mesma váriavel e na mesma instância, para próxima versão vou fazer uma solução para isto e ai até vai ficar mais rapidinho.
Os arrays foram criados pelo Java para não dar vantagem a ninguem de como é criado os arrays, pois provavelmente o groovy deve criar tipo genérico de array e não array primitivo.
E neste ponto você disse que o Groovy era tão rápido quanto o Java, então o Caju foi mais rápido que o Java? Lol, já disse, realize testes antes de falar.
Quanto ao resto das coisas que você diz dispenso comentar, acho que não vale a pena.
Realmente me expressei mal quando disse que o código rodava próximo a performance do java. Na verdade, o que quis dizer, é que o groovy não faz muitas coisas além do que o java na execução de um loop, por isso não há porque dizer que o loop do groovy é muito mais lento do que o java. Vou dar uma olhada no bytecode gerado pelo groovy para o código do loop e compará-lo a um gerado pelo java.
O seu código em groovy está errado. Da forma que você implementou, ele está compilando o script a cada vez que passa pelo array, enquanto que pelo cajuScript você está interpretando, o que é muito menos custoso do que compilar e carregar dinamicamente uma classe. O correto seria algo como:
import groovy.lang.Binding;
import groovy.lang.GroovyShell;
import groovy.lang.Script;
import org.cajuscript.CajuScript;
public class TestesJ {
public static void main(String[] args) throws Exception {
long time = 0;
time = System.currentTimeMillis();
GroovyShell groovyShell = new GroovyShell();
Script script = groovyShell.parse("for(num in nums){ x = x + num }");
int xGroovy = 0;
for (int i = 0; i < 500; i++) {
Binding vars = new Binding();
vars.setVariable("x", new Integer(0));
vars.setVariable("nums", new int[] { 1, 2, 3 });
script.setBinding(vars);
script.run();
xGroovy += ((Integer) vars.getVariable("x")).intValue();
}
System.out.println("Groovy: " + (System.currentTimeMillis() - time)
+ "ms - " + xGroovy);
time = System.currentTimeMillis();
CajuScript caju = new CajuScript();
int xCaju = 0;
for (int i = 0; i < 500; i++) {
caju = new CajuScript();
caju.set("x", new Integer(0));
caju.set("nums", new int[] { 1, 2, 3 });
caju.eval("caju.cache: test; caju.each('num', nums) @ x = x + num; @;");
xCaju += ((Integer) caju.get("x")).intValue();
}
System.out.println("Caju: " + (System.currentTimeMillis() - time)
+ "ms - " + xCaju);
}
}Na minha máquina, o resultado foi:
Groovy: 516ms - 3000
Caju: 375ms - 3000
O que não é uma diferença tão grande assim, não acha?
Sinto muito, mas isso só mostra que você não sabe manter uma discussão civilizada.
[quote=neófito]
Na minha máquina, o resultado foi:
Groovy: 516ms - 3000
Caju: 375ms - 3000
O que não é uma diferença tão grande assim, não acha?
Sinto muito, mas isso só mostra que você não sabe manter uma discussão civilizada. [/quote]
Não é uma diferença muito grande? 28% mais rápido não é muito grande? Mais que 1/4 mais rápido. Pra mim continua sendo mais vantagioso.
Mas como ja disse vai de cada um, CajuScript tem os recursos que tem, e estamos fazendo o melhor para melhora-lo, o Groovy tem o poder que tem, para certos cenários um é mais indicado que outro!
E olha ainda bem que o Groovy ficou mais rápido neste testes, por que me assustava aquele resultado grotesco.
Este foi um teste isolado, mas há inumeras situações, dependendo do contexto o CajuScript pode se tornar muito vantagioso.
E na boa, faz este teste em Java e veja bem o resultado, se chegar a 5ms é muito! Groovy performance próxima da do Java é um argumento completamente sem base, queria ver testes que comprovem isto, que só vc falando e pelos resultado que vi do Groovy até agora não me parecem nada próximo do Java.
Acho que não devemos mais discutir performance, pois se para ti 28% não quer dizer nada, e que o Groovy tem quase a mesma performance do Java, então podemos ficar por aqui.
Uma coisa sei, CajuScript tem me aberto portas excelentes de negócio, tenho clientes que ganho de 5% já faz muita diferença. Tudo depende das exigências dos projetos/clientes. Se um dos meus projetos ficasse 28% mais lento seria uma desgraça.
Parabens eduveks, pelo projeto e tambem por se preocupar com a performance.
Quanto aos recursos, tenho certeza que primando pela velocidade, quando voce implementar
o que tem seus concorrentes, seu soft sera’ a melhor opcao disparado.
Continue Assim !!!
Quando eu tiver um tempo aqui , verei com mais calma seu produto.
[quote=j-menezes]Parabens eduveks, pelo projeto e tambem por se preocupar com a performance.
Quanto aos recursos, tenho certeza que primando pela velocidade, quando voce implementar
o que tem seus concorrentes, seu soft sera’ a melhor opcao disparado.
Continue Assim !!!
Quando eu tiver um tempo aqui , verei com mais calma seu produto.
[/quote]
Muito obrigado pelo apoio e compreensão.
A nossa preocupação e o nosso plano é exatamente isso. Penso que a barreira da performance é a mais crítica e temos vencido, o resto virá com o tempo.
Não é uma diferença tão grande quanto à que você havia dito antes. Lá o groovy estava demorando 7 segundos, o que é absurdo. Agora a diferença foi de 141ms, bem menos do que antes. E 28% mais lento mas com recursos como metaprogramming, que torna as coisas mais lentas. Só quero ver como estará a performance do cajuscript quando ele chegar perto dos recursos do groovy.
O resultado grotesco foi devido à sua falta de conhecimento sobre a linguagem.
Você não sabe ler? Ou simplesmente ignorou o que eu escrevi em um post anterior? Bom, vou escrever novamente para que fique claro:
[quote=neófito]
Você não sabe ler? Ou simplesmente ignorou o que eu escrevi em um post anterior? Bom, vou escrever novamente para que fique claro:
“por isso não há porque dizer que o loop do groovy é muito mais lento do que o java” !? Ou seja volta a afirmar sutilmente! Não há por que dizer realmente, é só um fato! Vc apenas quiz indiretamente dizer que loop em Groovy é tão rápido quanto em Java. O que não é verdade nem de longe. E realmente se expressou mau e continua…
Quanto ao resto, me resumo a perguntar… nos testes foi usado em algum momento metaprogramming? Se são loops simples onde entra os outros recursos que debilitam a performance?
Meu caro, como eu já disse, é tudo uma questão de gosto, em alguns cenários o CajuScript tem performance superior, tendo ou não mais ou menos recursos, se isto é útil para vc maravilha! Se não não há por que usar o CajuScript.
Em nenhum momento disse que o CajuScript é melhor que o Groovy, apenas CajuScript é sim mais rápido que o Groovy em alguns cenários, como os usados nos testes, por isso fazemos questão de mostrar o código usado nos testes, para que também possam nos chamar atenção se estamos fazendo alguma coisa errada para realizar os testes mais justos possíveis.
Por isso se vc não entendeu ainda, e já faz tempo que não vejo razão para tanta discussão, quando outras pessoas já compreenderam o propósito, menos tu até agora, é que o CajuScript propõe ser rápido, logo se um dia implementarmos closures ou metapramming e isto prejudicar a performance, dificilmente vamos fazer, vamos sim tentar fazer outras coisas para compensar isto.
O principal objetivo do CajuScript é manter a performance, para cenários que exigem isto! Como é o caso da área em que trabalho, que com certeza não é a mesma que a tua, por isso Groovy é excelente para ti e CajuScript é o único que me serve. Se o teu projeto se encaixa melhor com um ou com outro cabe a ti melhor decidir. Se conta performance ou recursos.
Agora que vamos tentar implementar a maioria dos recursos vamos, se vai prejudicar a performance vamos ver, e no futuro poderemos falar melhor sobre isto. Mas para mim especialmente se o CajuScript tiver ou não suporte a tantos recursos pouco importa, o que importa é ser dinâmico e rápido.
De uma vez por todas os testes de comparação do CajuScript só serve demonstrar que é mais rápido em alguns cenários, claro que basta 5 minutos vendo a documentação para ver que CajuScript não tem tudo que o Groovy e Ruby e etc oferecem, por isso o CajuScript ser mais rápido? Talvez! É apenas claro que se tens problema de performance e precisa de algo dinâmico CajuScript pode ser opção.
Pensava que tudo isto era bem óbvio, mas acho que expliquei da maneira mais detalhada que pude para ver se fica bem compreensivel.
E outra eu poderia dizer N cenários onde justificaria o testes em que o Groovy levou 7 segundos como real e justo, pois em um ambiente multithread por exemplo onde por alguma razão eu não posso reaproveitar a mesma instancia do Groovy por algum motivo, ai como contornaria para baixar os 7 segundos? Compilar o script? Mas se também eu não puder compilar o script por ser um script gerado dinâmico por exemplo? Nestas condições pode haver vários fatores em que favorece o uso do CajuScript.
Então para complicar a vida do Groovy, mas usando a mesma instancia para não complicar tanto. E se eu tivesse dois ou N scripts, diferentes claro, para serem executados em loop dependendo de algumas condiçoes, ai em vez de 7 segundos levaria quanto? 14 segundos? Ou mais? Pois o teste foi com apenas um script.
Só pensar um pouco e podera ver onde o CajuScript pode ser aplicado com sucesso, cada um no seu quadrado, cada um com o seu ponto forte. E somos todos felizes.