na documentacao do Lucy, diz ser escrito em C, e é um reimplementacao do Lucene.
qt a precisar de outros profissionais, a jvm hoje é tão obrigatória quanto linux, IMHO, devido a adocao do mercado, ou seja, nao há perca de tempo, é skill pre-req. Qt a implementacao em perl de um FTT, Lucy eh em Perl? Vou ver, mas acho que demorou pra fazer esse produto. A galera enterprise do Java sentiu as dores a mais tempo e fez o Lucene/Solr. Acho mqis produtivo ler um livro e estudar uma tecnologia bem difundida que escrever reescrever codigo, reinventar a roda. Bem, prefiro me orientar a solucoes de mercado que já provaram seu proposito a tecnologia que apesar de serem maravilhosas nao me promovem algum determinado aspecto. estou no cel, no metro lotado, foi mal os.erros :P On Jul 18, 2012 6:01 PM, "Eden Cardim" <[email protected]> wrote: > >>>>> "Marcio" == Marcio Ferreira <[email protected]> > writes: > > Marcio> Continuo sem entender, trabalho com Perl usando o > Marcio> Lucene/Solr com WebService::Solr, ou seja, sem custo de > Marcio> troca de linguagem. Mas a diferença é a tecnologia então? > > A diferença é que, do meu ponto de vista de engenheiro, é mais fácil de > entender e mecher no source se for implementado na linguagem do restante > do sistema, caso seja necessário. E tem o by-product que ter uma > implementação de indexação em perl é bom pro ecossistema da linguagem. > > Marcio> Amanhã troca de Perl pra whatever e seu argumento foi pro > Marcio> limbo? Lucy for Perl systems? > > Err, não entendi, dentro de uma comunidade de perl, acho razoável > promover uma implentação de tecnologia escrita em perl, se fosse a lista > do GUJ, eu recomendaria Lucene, invés de um binding pro Lucy em perl. > > Marcio> Acho que vale a pena sim ~mudar~ seu "eco-sistema só pra > Marcio> poder usar uma implementação de indexador...", > > OK, se você prefere gastar seu tempo re-descobrindo quem são os > profissionais qualificados em quais áreas, se atualizar/familiarizar com > os problemas da linguagem, re-descobrir quais são os canais de > comunicação e modus operandi usados pela comunidade e re-abrir esses > canais com todo mundo, ótimo. Eu acho mais produtivo implementar código. > > Marcio> porque 90% dos sistemas que participei, a busca da > Marcio> informação foi faz parte do business. > > Se já estiver no business quando você chegou, ótimo, não tem porque > mecher, vide outra thread onde ainda usam TN3270, porque está lá a > séculos. Mas se você tiver controle da tecnologia antes de ser > implantada, faz sentido usar algo na sua linguagem primária. > > Marcio> Lucy via REST? Caching? Replicação ~trivial~(nada é trivial > Marcio> até se saber fazer)? ~telinha~ de admin? ferramenta de > Marcio> análise dos índices? permissão de update, query? > > O Lucy não tem isso, e se você precisa de tudo isso, faz sentido usar > uma implementação, em qualquer linguagem, que já forneça isso > pronto. Taí uma coisa boa de se implementar, invés de mais frameworks > web, o triste é que seguindo a tendência de toolkits novinhos > brilhosinhos, provavelmente não vai demorar muito pra outra pessoa > implementar outro indexador, usando os mesmíssimos algoritmos e algumas > vírgulas a mais ou a menos, invés de colocar uma implementação REST > default no Lucy. > > Marcio> Estou perguntando de curioso, não quero tomar seu tempo de > Marcio> consultor, só estou colocando minha visão de consumidor de > Marcio> FTT. =) > > Hoje estou em modo comunidade, subindo patches de módulos, escrevendo > artigos, cutucando pessoas na lista, etc. :) > > -- > Eden Cardim > +55 11 9644 8225 > =begin disclaimer > Sao Paulo Perl Mongers: http://sao-paulo.pm.org/ > SaoPaulo-pm mailing list: [email protected] > L<http://mail.pm.org/mailman/listinfo/saopaulo-pm> > =end disclaimer >
=begin disclaimer Sao Paulo Perl Mongers: http://sao-paulo.pm.org/ SaoPaulo-pm mailing list: [email protected] L<http://mail.pm.org/mailman/listinfo/saopaulo-pm> =end disclaimer
