Prq vc reinicia o programa em vez de aumentar a quantidade de números:
Mas assim:
srand(time(NULL)+i);
ou
srand(Time.msec());
Ae vai do seu framework. Eu uso qt aqui.[/quote]
Essas funções são ansi, então são independentes… só espero que você não esteja usando a semente(tempo) para para algo que precise ser realmente aleatório… tal como criptografia/sorteios/etc.
[/quote]
Acho que voces estao confundindo aleatorio com unico.
Aleatorio nao quer dizer que nao repete, aleatorio é aleatorio mesmo.
Tipo um numero aleatorio entre 1 e 10 = 6;
Outro numero aleatorio entre 1 e 10 = 6;
Isto é aleatorio. Voce nao sabe qual vai ser e pode ser qualquer um entre 1 e 10.
Acho que a discussao de voces seria “Aleatorio que nao se repete”. ou aleatorio unico.
Gosto muito de Ruby que é MUITO mais produtiva do que Java para escrever código novo. Gosto também bastante de Scala que permite fazer as mesmas coisas (ou um pouco mais) que o Java faz porém escrevendo muito menos linhas. Não é só a redução de linhas que me seduz. É que o código fica mais condensado nas questões relativas ao problema a resolver.
Ruby é bem mais fácil de aprender do que Scala (e tem muito mais fontes de estudo). Em compensação Scala, com sua tipagem estática não exige tantas linhas de testes quanto Ruby (que exige testar tudo e mais um pouco).
Ambas as linguagens permitem escrever código que roda na JVM. Nenhuma das duas atende 100% ao JIT que é otimizado para a semântica do Java. Mas Scala é mais próxima do Java e parece ser mais fácil de ser domesticada pela JVM. Dificilmente JRuby redundará em bytecodes tão bons quanto os oriundos de código Java.
Pelo parágrafo anterior alguém poderia concluir que recomendo Scala ao invés de JRuby. A conclusão não estaria de todo errada se não fosse pelo fato de que o uso de Ruby é muito mais difundido e muito mais gente sabe trabalhar com ele e com os gems disponíveis para ele.
Pode ser que esta situação mude daqui a alguns meses e eu acho mesmo que vai mudar com mais gente estudando Scala. Mas não acredito que Scala um dia chegue a ter a mesma popularidade do que o Ruby.
O melhor dos mundos já existe. Muito dos experts em integração de sistemas já concluiram que usar RPC atualmente é uma idiotice e que sistemas diferentes podem se integrar e escalar sem repetir erros dos tempos do CORBA. Hoje é fácil e possível usar a ferramenta adequada a cada problema e integrar de maneira simples sem manter estado e sem precisar de consultor SOA ou de WSDL, SOAP, UDDI, repositório, etc. O exemplo que me fez escrever este parágrafo é o SOLR que disponibiliza o LUCENE para código escrito em qualquer linguagem.
Prq vc reinicia o programa em vez de aumentar a quantidade de números:
Mas assim:
srand(time(NULL)+i);
ou
srand(Time.msec());
Ae vai do seu framework. Eu uso qt aqui.[/quote]
Essas funções são ansi, então são independentes… só espero que você não esteja usando a semente(tempo) para para algo que precise ser realmente aleatório… tal como criptografia/sorteios/etc.
[quote=fredferrao]Acho que voces estao confundindo aleatorio com unico.
Aleatorio nao quer dizer que nao repete, aleatorio é aleatorio mesmo.
Tipo um numero aleatorio entre 1 e 10 = 6;
Outro numero aleatorio entre 1 e 10 = 6;
Isto é aleatorio. Voce nao sabe qual vai ser e pode ser qualquer um entre 1 e 10.
Acho que a discussao de voces seria “Aleatorio que nao se repete”. ou aleatorio unico.[/quote]
Eu sei. Ele não tem noção do que está dizendo. A diferença entre pseudo e um número realmente aleatório. O nº realmente aleatório não se consegue por representação matemática, apenas por hardware.
Criptografia não usa números aleatórios. Somente pseudo aleatórios.
Ruby é a linguagem de programação, Ruby MRI é a implementação oficial, e também há o JRuby, Rubinius, IronRuby, YARV é muitas outras implementações.
Da mesma forma que o JRuby é feito em bytecodes Java, o MRI é feito em outra linguagem também, C.
Com C se consegue ter o controle da matéria bruta dos recursos, enquanto na JVM eles são abstraídos, protegidos, e qualquer controle maior depende do quanto a JVM libera pra vc. É fato que a JVM foi feita para rodar somente Java, então ela se adapta 100% às necessidades dela. Agora que há mais linguagens usando os mesmos bytecode, mais instruções próprias à linguagens dinâmicas tem que ser adicionadas à JVM para que essas linguagens rodem melhor. Faça uma procura pelo invokeDynamic para saber mais.
Plataforma J2EE /JEE virou legado para o que hoje já se tem em termos de web 2.0 essa devem simplesmente fazer interoperabilidade mas trabalhando com um conceito novo de se produzir aplicações.
As linguagem que tem um efeito indepentente de plataforma também possuem engine que se comunicam com a JVM e de outrs JVMs fornecedores que precisam manter o seu negocio funcional também, projetos que estão indo para Frameworks Grails, Rails, entre outros vão sofrer redesenhos não tem como manter especificações que não atendem a propria arquitetura, nesse caso não existe a migração do negócio entretanto a curva de aprendizagem e implementação é consideralmente muito melhor e rápido de se fazer, pois não se perde-se tempo com uma infinidade de configuração em arvores de arquivos e deployments de tudo que é tipo, que são essas entranhas de frameworks que estão dentro da plataforma J2EE.
Me corrijam se estiver errado, mas a subtituicão do core do Twitter esta sendo feito para Scala né? tanto que um dos “donos” lá esta até vendendo um livro sobre Scala rs… o front-end vai continuar com Rails, por enquanto pelo menos.
Acho que se sair em alguns meses um Rails-like forte e eficiente como o próprio Rails é para Rubu, só que apra Scala, é bem possível que a linguagem ganhe muitos adeptos, muita gente preferiria algo mais java-like(Scala) do que script-like (Ruby) na hora de ter alternativa ao Java.
É aquela coisa Java é uma linguagem que realmente é bem sincronizadas com ferramentas UML pois tem o codigo especificado nesses instrumentos geradores de Codigo , fato que você pode usufluir do AndroMDA para até produzir metodologia baseado em Orientação a Aspecto.
Ator em ação é mais para requisito em cenário use case, isso não quer dizer que você precise tambem de qualquer software para fazer isso, tambem pode rascunhar a mão.
Márcio, o “Actor” ao qual o Mochuara está-se referindo não é o ator de um caso de uso do UML, mas um objeto usado para escrever programas concorrentes.
Em vez de você ter de tratar com threads ou pools de threads, que são coisas pesadas e demasiadamente concretas, o uso de Actors abstrai esse processamento concorrente.
Embora Actors sejam normalmente implementados com pools de threads, isso não é obrigatoriamente necessário; você nem precisaria de threads se você tivesse um suporte equivalente ao runtime do Erlang.
[quote=thingol]Márcio, o “Actor” ao qual o Mochuara está-se referindo não é o ator de um caso de uso do UML, mas um objeto usado para escrever programas concorrentes.
Em vez de você ter de tratar com threads ou pools de threads, que são coisas pesadas e demasiadamente concretas, o uso de Actors abstrai esse processamento concorrente.
Embora Actors sejam normalmente implementados com pools de threads, isso não é obrigatoriamente necessário; você nem precisaria de threads se você tivesse um suporte equivalente ao runtime do Erlang. [/quote]
[quote=mochuara]
Marcio, estava me referindo a um recurso da linguagem Scala chamado Atores. Não estava me referindo a atores que existe nos diagramas de UML.[/quote]
Bom, melhor explicado como iria também saber, foi mau !!!
[quote=Luiz Aguiar]Me corrijam se estiver errado, mas a subtituicão do core do Twitter esta sendo feito para Scala né? tanto que um dos “donos” lá esta até vendendo um livro sobre Scala rs… o front-end vai continuar com Rails, por enquanto pelo menos.
Acho que se sair em alguns meses um Rails-like forte e eficiente como o próprio Rails é para Rubu, só que apra Scala, é bem possível que a linguagem ganhe muitos adeptos, muita gente preferiria algo mais java-like(Scala) do que script-like (Ruby) na hora de ter alternativa ao Java.
@Luca que bom vc por aqui de novo amigo :)[/quote]
Se não me engano, não foi todo o código Ruby no backend que foi substituído pelo código equivalente em Scala. Foi “só” o Starling, que é o message queue escrito em Ruby por eles, que foi substituído pelo Kestrel, um message queue escrito em Scala e também desenvolvido pela equipe do Twitter.
Muitos desenvolvedores da comunidade Ruby/Rails reclamaran dessa mudança, acusando os desenvolvedores do Twitter de serem ruins, principalmente por emularem um sistema de tipagem estática no Ruby através do uso compulsivo do método kind_of?, ou por não considerarem outras hipóteses, como utilizar o RabbitMQ, que é um message queue escrito em Ruby, e, aparentemente, bem melhor que o Starling, que foi o desenvolvido por eles.
P.S.: O Alex Payne, autor do livro sobre Scala, não chega a ser um dos donos do Twitter, é “só” um dos principais desenvolvedores.
[]s
Luca[/quote]
Ops, acabei me confudindo nesse post. O RabbitMQ é de fato escrito em Erlang, no entanto, aperentemente, ele é a opção mais popular entre os desenvolvedores Ruby.
