CajuScript 0.3.5

http://code.google.com/p/cajuscript/

Changelog:

* Compilador.
* For each.
* Suporte à Java Enums.
* E bugs resolvidos...

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

JavaTeenager Membro desde: 08/01/2008 10:55:41 Mensagens: 172 Offline

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.

This message was edited 2 times. Last update was at 26/02/2009 13:24:08

LuksS wrote: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.

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...

GUJ Master Membro desde: 04/06/2007 17:47:24 Mensagens: 1030 Offline

LuksS wrote: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.

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.

JavaTeenager Membro desde: 08/01/2008 10:55:41 Mensagens: 172 Offline

djemacao wrote:
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.

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?

neófito wrote: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?

mas a comparação é performance e não quantidade de features!

This message was edited 4 times. Last update was at 27/02/2009 06:24:51

peerless wrote:

neófito wrote: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?

mas a comparação é performance e não quantidade de features!

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:

Normal, mais lento, uso de regular expression para interpretar o script com a feature de sintaxe dinâmica o que torna pesado.

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.

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.

peerless wrote:

neófito wrote: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?

mas a comparação é performance e não quantidade de features!

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.

This message was edited 3 times. Last update was at 27/02/2009 09:35:42

neófito wrote:

peerless wrote:

neófito wrote: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?

mas a comparação é performance e não quantidade de features!

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.

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.

eduveks wrote:O que o CajuScript propõe pra já é ser um complemento ao Java, tentando ter o menor impacto possível na performance.

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.

eduveks wrote: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?

Não entendi. O que pode ser lento é a iteração com closures, do tipo:

Mas o loop do groovy não. O código abaixo roda com uma performance próxima a do java:

eduveks wrote:
Neste momento CajuScript tem 3 opções para executar um script:

Normal, mais lento, uso de regular expression para interpretar o script com a feature de sintaxe dinâmica o que torna pesado.
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.
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?

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.

eduveks wrote: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.

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é?

This message was edited 6 times. Last update was at 27/02/2009 11:26:44

neófito wrote: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 }

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.

This message was edited 1 time. Last update was at 27/02/2009 13:42:17

eduveks wrote: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.

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.

eduveks wrote:
Output:

Groovy: 7203ms - 3000
Caju: 671ms - 3000

É preciso mais? Quanto mais vc aumentar o número 500 maior será a diferença.

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?

eduveks wrote:Quanto ao resto das coisas que você diz dispenso comentar, acho que não vale a pena.

Sinto muito, mas isso só mostra que você não sabe manter uma discussão civilizada.

Notícias, artigos e o maior fórum brasileiro sobre Java