Pessoal, eu estava num treinamento em Brasília esses dias e o instrutor disparou essa pérola:
Bem, nem precisa falar que na mesma hora ele foi contestado. Primeiro que paradigma de desenvolvimento não tem nenhuma correlação direta, em princípio, com performance, e depois grande parte dos sistemas dessa área ainda são legados (penso eu), e por isso ainda são sistemas do tempo da análise/projeto estruturado, orientados a dados, ou até mesmo são do tempo que nem existia qualquer tipo de paradigma
Mas mesmo assim fiquei com a pulga atrás da orelha. Será que esses bancos da vida, os maiores pelo menos (BB, Caixa, Bradesco, Itaú), ainda não têm mesmo seus sistemas de missão crítica desenvolvidos sob o paradigma da orientação a objetos por algum motivo relacionado a performance?
Tem alguém aqui no Fórum que trabalha, ou trabalhou, em algum desses bancos pra confirmar, ou refutar, essa tese estapafúrdia, IMHO, do distinto instrutor? É verdade mesmo que os sistemas dos bancos não são O.O. (possivelmente em Java) por questões de performance? Se alguém souber de exemplos de bancos aqui no Brasil ou no exterior para ajudar a desconstruir, ou confirmar, essa tese eu agradeceria.
Eles falam que Java não tem bom desempenho, que não aguenta o tranco, bla bla bla…Mas quem fala isso usa Cobol, conhece nada, ou quase nada de Java e acha que Java limita-se a interfaces.
Eu fico pensando no assunto e não me lembro de nenhum supercomputador criado hoje que use cobol. Alguém lembra ou pode confirmar/contestar essa informação?
Sei que Java também é usada em muitos bancos e empresas gigantes de telefonia.
Quer saber qual é a única razão que eu vejo que faz com que ainda exista tanto código “largado” no mercado?
PERFORMANCE;. Performance monetária. Pra quem investiu bilhões em sistemas, trocar tudo por Java sem ter um ganho real de MONEY, é um tremendo contrasenso.
Aqui onde trabalho temos um grande volume de informações e muitos calculos horarios.
E o negocio é demorado. Gostaria de procurar algo que nos ajude a fazer processamentos batch mais rapidos.
Tem processamento nosso que demora mais de 12 horas.
A maioria dos sistemas da Google são em Python, o GMail o povo acha que é Java por causa do GWT, mas ele é Python, o docs tbm. (Não posso garantir, pode ser que o front seja java e o back python, ou o contrario, quem sabe né auhuhauha)
Sabe, soa estranho mas há algum fundamento no que o seu instrutor está falando.
No caso de O.O envolvendo herança, por exemplo, você vai ter um overhead na chamada de funções sim. Ele é insignificante em casos normais, mas aquele milésimo de milisegundo em um ambiente de missão ultra mega hiper power chuck norris crítica faz a diferença.
Principalmente porque você paga pelo consumo de CPU né?
Além disto, há outro fato que tá sendo ignorado aqui: instanciação de objetos é um negócio caro. Parece que não, mas é.
Isto não quer dizer que não existam aplicações Java ultra rápidas. Só que não é tãããããão rápido assim como a gente gostaria de imaginar.
E sim: mainframes novos vêm com todo o suporte a COBOL que, pra processamento em lote, ainda é imbatível.
Em questoes criticas de altos processamentos ele tem razão.
Ja tentamos migrar aplicações em Cobol para Java e o processamento de um para outro em testes era grande causando time out em alguns momentos quando era utilizado java. estou dizendo milhoes de transaçoes por segundos arquivos de 1GB a 8GB
Incluindo todo o lado servidor dele? Então o armazenamento fica no browser via cookies? O gmail roda todo no seu browser via Javascript? Cacilds!
Se for isso, então estão justificados os requisitos para candidatos a uma vaga lá e acho que só o usuário luca se habilitaria a estar lá.
pegou pesado…[/quote]
Veja essa matéria no javaworld.
[/quote]
[quote]At the USENIX annual conference last month, Gmail engineer Adam de Boor surprised the audience by noting that the company’s Gmail service was written entirely in JavaScript, and that all of its code, around 443,000 lines worth, was written by hand.
pensei que construir um sistema tão grande com apenas javascript era impossível.
eu ja tinha minhas dúvidas que esse pessoal do google não era humano, 443.000 linhas de código javascript escritas a mão :shock:
“Total Ajaxsation”[/quote]
Pois é, os caras são malucos mesmo. Detalhe que na reportagem eles disseram que o Java e o C++ são por demais complexas para serem aplicadas nos grandes sistemas. Coisa sinistra e sem sentido.
pegou pesado…[/quote]
Veja essa matéria no javaworld.
[/quote]
Interessantíssimo isto. Eu já vi Javascript ser executado no servidor, mas nunca nesta escala.
Inclusive, existe um projeto chamado Jaxer, que é justamente isto. http://www.jaxer.org/
Eu já vi empresa QUEBRAR porque trocaram sistema legado “antiquado” em COBOL ou VB6 por algo feito em Java. Java é do caralho? Sem dúvida. É a minha plataforma favorita, mas não é ideal pra tudo.
Aliás, esta onde de “substituir o legado” de cara, na minha opinião, duas coisas:
Falta de respeito total com o investimento anterior feito pelo seu cliente.
Irresponsabilidade movida a arrogancia (e a arrogancia é alimentada pelo que? Ignorancia)
Eu já vi software de tempo real, que controla industria, feito em VB6.
Já vi gerenciamento de custos bilionários feito em Access 97 e Excel
Já vi softwares de empresas multi bilionárias feitos em FoxPro que funcionam, são mantidos e ampliados até hoje.
Muita coisa de engenharia feita em Fortran que é insubstituível
E muita coisa impressionante em COBOL
Vai trocar, vai. Da merda. Não porque a tecnologia é boa ou ruim, mas porque foi usado algo que, para o caso, caia como uma luva.
