Sistemas O.O. não são apropriados para grandes demandas (milhares de transações/hora)

Isso é uma questão complicada.

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.

Se funciona, trocar pra que?

Quando valer a pena trocar, eles trocam.

Até onde eu sei, muitos sistemas do google são feitos em java… o wave mesmo foi feito em java(não sei se 100%) utilizando guice para DI.

[]'s

Se não me engano, Gmail e docs são Java. Orkut também. O buscador é parte python e parte C(ou c++). Eles trabalham com muitas linguagens.

O Yahoo, se não me engano, é PHP.

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

Pra quem não sabe, o gmail foi escrito em javascript.

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

Inté.

orra javascript…essa doeu!

pegou pesado…

douglaskd:

orra javascript…essa doeu!

pegou pesado…

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

que isso cara…

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”

douglaskd:

que isso cara…

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”

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.

matheuslmota:

douglaskd:

orra javascript…essa doeu!

pegou pesado…

Veja essa matéria no javaworld.

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/

Falou tudo. Criar e operar um objeto é mais caro (em termos computacionais) que manipular tipos primitivos.

Grandes bancos ainda tem o fator “legado”, com sistemas gigantescos em Cobol que são estáveis e funcionam muito bem.

Mas existem cases de aplicações de missão crítica em Java sim, basta dar uma googlada ou uma bingolada que você acha.

Olha, vou contar uma coisa.

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:

1. Falta de respeito total com o investimento anterior feito pelo seu cliente.
2. 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.

O Joel Spolsky tem um texto ótimo sobre esta questão: http://www.joelonsoftware.com/articles/fog0000000069.html

Aliás, sobre COBOL, eu fiz uma pesquisa a algum tempo atrás. Os resultados foram surpreendentes pra mim na época: http://www.itexto.net/devkico/?p=135

seu professor esta corretíssimo.

Qualquer operação da área da banca ou seguros é feita em AS/400 ou Mainframe.

A Allianz trabalha INTEIRAMENTE com COBOL, tem apenas a interface gráfica feita em .NET, o resto é TUDO cobol!

E quer saber? Funciona melhor do que se fizesse em .NET/Java (coloco os dois porque são duas linguagens iguais)

A Groupama Seguros (uma das maiores seguradoras da europa) trabalha da mesma forma que a Allianz.

O BBVA Madrid é igual.

Java/.NET é ridiculo para sistemas TPS.

Eu trabalho num sistema que lida com milhoes de transacoes diarias, escrito em java (totalmente OO) e rodando na amazon sem problema.

Seu professor comeu bola e quem ta concordando precisa dar uma estudada melhor antes de dar opiniao baseada em chute.

s4nchez:

Eu trabalho num sistema que lida com milhoes de transacoes diarias, escrito em java (totalmente OO) e rodando na amazon sem problema.

Seu professor comeu bola e quem ta concordando precisa dar uma estudada melhor antes de dar opiniao baseada em chute.

Foi bom te ouvir.

s4nchez:

Eu trabalho num sistema que lida com milhoes de transacoes diarias, escrito em java (totalmente OO) e rodando na amazon sem problema.

Seu professor comeu bola e quem ta concordando precisa dar uma estudada melhor antes de dar opiniao baseada em chute.

SIm, é possível, mas executaria muito mais rápido em COBOL, C ou alguma outra linguagem não OO.

Trabalho hoje com uma aplicação Java/Cobol.

Pelo fato de Cobol ser procedural, ele dá muito terro. Nunk vi igual. E estou falando de sistema que roda em banco.

Pode ser que tenha algum ganho em desempenho, mas na hora da manutenção é um sofrimento.

• Mas falo isso com base em apenas nos sistemas que vejo, não vi cobol fora de lá ainda. *

kicolobo:

s4nchez:

Eu trabalho num sistema que lida com milhoes de transacoes diarias, escrito em java (totalmente OO) e rodando na amazon sem problema.

Seu professor comeu bola e quem ta concordando precisa dar uma estudada melhor antes de dar opiniao baseada em chute.

SIm, é possível, mas executaria muito mais rápido em COBOL, C ou alguma outra linguagem não OO.

Mas isso eh bem diferente de dizer que nao sao apropriados.

Olha, vou contar uma coisa.

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:

1. Falta de respeito total com o investimento anterior feito pelo seu cliente.
2. 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.

O Joel Spolsky tem um texto ótimo sobre esta questão: http://www.joelonsoftware.com/articles/fog0000000069.html

Aliás, sobre COBOL, eu fiz uma pesquisa a algum tempo atrás. Os resultados foram surpreendentes pra mim na época: http://www.itexto.net/devkico/?p=135

Esse eh um tipo de afirmacao que tem que ser feita com cuidado. Acho que nao eh bem assim de dizer “Ah vamos manter o legado e pronto”. Eu ja li esse artigo e é realmente excelente, mas nao se pode levar tudo ao pe da letra. Eu ja vi empresas minguarem até que fosse tarde demais justamente por nao terem substituido o legado. Insistiram em aplicacoes DOS enquanto o mundo migrava pra Windows, seus produtos envelheceram e morreram.

A grande pergunta é “por que substituir o legado?” E a resposta é dificil de encontrar. Agora se for so por preciosismo, só porque o codigo é feio e fazer o do zero é mais bonito, aí sim eu concordo plenamente com voce.

Belo tópico.

Migração é um assunto complicado, tenho pouca experiência, a única que fiz foi de um internet banking em asp puro + sql server em um camada, para um ib em vb.net em 3 camadas, servidor de aplicação, servidor web, etc…

Mas gostaria de ter realizado outras, sem dúvidas agrega muito conhecimento. É o tipo de atividade ideal para um cara em começo de carreira, estagiário, etc., dar um grande salto, desde que orientado é claro rs;

YvGa:

kicolobo:

SIm, é possível, mas executaria muito mais rápido em COBOL, C ou alguma outra linguagem não OO.

Mas isso eh bem diferente de dizer que nao sao apropriados.

O problema é que aprender um novo paradigma é dificil e por isso programadores preferem atribuir o problema a performance ao invés de reconhecerem que OO não é apropriado para a maioria dos sistemas corporativos.

Levando em conta o título do tópico acho que temos que considerar o seguinte:

1. OO é um conceito, independente de linguagem e que não aborda questões relacionadas a perfomance; me corrijam se estiver errado.
2. A arquitetura dos microprocessadores parece não combinar muito com a implementação dos conceitos OO, porem combinam bem com as implementações das linguagems estruturadas. Acredito que os ponteiros se deslocam menos ao processar executáveis resultante a partir das linguagens estruturadas.
3. Progamas ruins sempre existiram e pelo jeito sempre irão existir, independente da linguagem.
4. Se uma equipe resolve desenvolver um bom sistema a linguagem talvez seja um dos menores problemas.
5. Cobol foi criada com a intenção de ser a linguagem de programação mais próxima possível de um idioma falado por um ser humano (no caso o inglês). Sem falar nas questões relacionadas aos cálculos, aprendizado, portabilidade, legibilidade e etc… Na época isso foi de um impacto gigante. Tão grande que podemos ver as ondas resultantes até hoje.
   …
   flws

fantomas:

5) Cobol foi criada com a intenção de ser a linguagem de programação mais próxima possível de um idioma falado por um ser humano (no caso o inglês). Sem falar nas questões relacionadas aos cálculos, aprendizado, portabilidade, legibilidade e etc… Na época isso foi de um impacto gigante. Tão grande que podemos ver as ondas resultantes até hoje.
…
flws

Isso explica melhor porque COBOL é usado até hoje. Além de funcionar, quem esta familiarizado com o negócio é capaz de entender o código.

A menos que vc esteja criando GUIs, objetos apenas introduzem complexidade desnecessária.

Bom vamos lá, vou dar aqui minha contribuição. O fato é que muitos aqui já explicaram que há sim, e eu concordo, uma pequena diferença de performance em trabalhar-mos com linguagens OO.
Creio que na prática podemos minimizar estas perdas, chegando a um resultado muito próximo do legado. Precisamos considerar alguns fatores que desenvolvedores de hoje em dia muitas vezes não se preocupam e acabam prejudicando a performance da aplicação como um todo. Vou elencar aqui alguns exemplos:
Frameworks de persistência: Muitas vezes encontramos algumas linhas de código comentadas -> “aqui buscamos os clientes para mostar no relatório” from Cliente -> dúvidas aqui: serão mostrados todos os atributos dos Clientes? e os relacionamentos, foram mapeados corretamente ? preciso listá-los como persistentes ou posso colocá-los em um map? quando a quantidade de clientes ultrapassar 5, 10, 50mil ? não existe milagre neste sentido…
Banco de dados:Estamos usando índices ? views ? stored procedures? em aplicações de grande porte, fica praticamente impossível não considerarmos a utilização destes PODEROSOS recursos dos SGDB´s
Aplicações Web JSF: é só ler este artigo http://www.jsfcentral.com/articles/speed_up_your_jsf_app_1.html

Coloquei aqui alguns exemplos que considero importantes (encontro diariamente estes tipos de erros), e é lógico que existem muitos outros.
Também acho importante compartilhar com todos que trabalho atualmente e já trabalhei com aplicações onde a concorrência era fator crítico e quase sempre problemas de performance são oriundos de mau uso da(s) tecnologia(s) envolvida(s).

Na minha opinião os resultados estão relacionados com a infra-estrutura.

Se fizer um comparativo entre as linguagens mesmo considerando as devidas proporções a conversa provavelmente ficar bem longa; com riscos de flames ainda por cima rsrsrs.

flws

fantomas:

Na minha opinião os resultados estão relacionados com a infra-estrutura.

Se fizer um comparativo entre as linguagens mesmo considerando as devidas proporções a conversa provavelmente ficar bem longa; com riscos de flames ainda por cima rsrsrs.

flws

Não apenas com a infra-estrutura mas com uma série de fatores (facilidade de desenvolvimento com a linguagem, infra-estrutura, se a linguagem é compilada ou interpretada., etc.).

IMHO, o que determina o resultado final é o expertise da equipe que desenvolve o sistema. E, em geral, o expertise das equipes que trabalham em bancos é mais o cobol e outras linguagens. Por isso, é válido o sanchez dizer que trabalha num sistema de milhões de transações feitos em Java, assim como qualquer outro dizer que trabalha num sistema com milhares de transações feito em C, ou Assembler, ou Cobol, ou Fortran, ou (x). Porque isso depende da especialidade de cada um.

[]´s

Na realidade Java pode sim ser usado em aplicações que possuam grandes demandas. Eu mesmo já vi aplicações.

Mas o interessante mesmo neste tópico (muito bom por sinal), é que ele ajuda a desfazer alguns mitos interessantes sobre o COBOL, como por exemplo uma linguagem morta, acabada, terrível e fedorenta.

No caso do Java nestes ambientes, o que observo é o seguinte. Muitas vezes o problema está na escolha da JVM, ou vocês acham que a JVM padrão da conta de aplicações em tempo real (até na licença dela diz isto)?

Concordo co o asaudate, o que manda mesmo, no final, é a expertise da equipe.

Acho que o sujeito usou um exemplo, muito, muito, muito infeliz:

1. Sistemas bancários tem seu gargalo em I/O: Especialmente, em consultas ao BD, não na linguagem;
2. Sistemas bancários tem poucas transações de tempo real. Boa parte é pós-processada.
3. Muitos computadores “mainframe” com cobol são mais lentos que alguns i-Pods de hoje em dia.

Sistemas OO dão diferença em sistemas de tempo crítico, quando o intervalo de resposta cai na casa de poucos milisegundos. Onde uma indireção devido à um método polimórfico pode fazer diferença. Geralmente são sistemas para controle de hardware, microcontroladores e coisas coisas nefastas.

Nesse caso, usa-se C e C++. No caso do segundo, muito código baseado em templates, pouco em objetos.

É impressão minha, ou já existe OO em cobol?

To viajando?

foxpv:

É impressão minha, ou já existe OO em cobol?

To viajando?

Não sei, mas já existe cobol visual e cobol que desenvolve pra ambiente Web.

Só sei que legado é uma tristeza em tudo que é empresa maior. No Hospital que trabalho hoje, os programas web usavam uma biblioteca javascript gigantesca desenvolvida por eles que tem compatibilidade desde o Internet Explorer 3 e Netscape. E as páginas que eram carregadas também tinham muito código javascript dentro delas pra manter compatibilidade com esses navegadores.

Só o ano passado, com muita briga, consegui remover o suporte pra navegadores anteriores ao IE 4 e as páginas carregadas diminuíram em 30% o tamanho.

Que inveja de quem só se preocupa em matar o IE 6 :oops:

Normalmente o gargalo está em quem executa a leitura e escrita dos arquivos. No caso o driver do próprio banco mesmo. Em nível de aplicação, o desempenho de um software java e de um c++ que vão acessar o mesmo bd seriam quase a mesma coisa, pois quem sofre com o processamento das consultas é o driver do banco.
Que existe uma pequena diferença existe, mas é muito pequena mesmo e não sei se influenciaria astronomicamente de uma aplicação para outra.

Sobre o paradigma acho que não influencia não. Depende do compilador.

marcosalex:

foxpv:

É impressão minha, ou já existe OO em cobol?

To viajando?

Não sei, mas já existe cobol visual e cobol que desenvolve pra ambiente Web.

Só sei que legado é uma tristeza em tudo que é empresa maior. No Hospital que trabalho hoje, os programas web usavam uma biblioteca javascript gigantesca desenvolvida por eles que tem compatibilidade desde o Internet Explorer 3 e Netscape. E as páginas que eram carregadas também tinham muito código javascript dentro delas pra manter compatibilidade com esses navegadores.

Só o ano passado, com muita briga, consegui remover o suporte pra navegadores anteriores ao IE 4 e as páginas carregadas diminuíram em 30% o tamanho.

Que inveja de quem só se preocupa em matar o IE 6 :oops:

Eu sempre falo, fragmentação é uma merda… :roll:

quer 100% de performace?

faça tudo em Assembly… agora os custos, tempo, etc…
dai já é outra historia…

quer 100% de performace?

faça tudo em Assembly… agora os custos, tempo, etc…
dai já é outra historia…

Escrever asm na unha? E abandonar todo o know-how dos compiladores? Nem louco.

É a diferença do teoricamente possível, do realmente possível.
Teoricamente é possível fazer em assembly um programa mais rápido que em C.

Mas, na prática, isso não é possível:

1. Compiladores NUNCA perdem uma chance de otimização;
2. Organização do código contribui para boa performance;
3. O número de bugs é incrivelmente reduzido (e bota incrivelmente nisso);
4. Um compilador específico conhece centenas de instruções específicas, além de técnicas de otimização. Mesmo que você seja bom em assembly, tente entender um código gerado em C com compilação o3 num compilador específico da Intel, e você vai ver o que estou falando.

Na Siemens, constatamos que programar em C com muito cuidado era mais fácil e gerava código mais rápido do que em assembly. Mesmo com desenvolvedores experientes nas duas plataformas e altos investimentos em otimização. O que não significa que pequenas rotinas muito específicas fossem escritas em ASM, mas aí, em trechos bastante restritos e críticos.

Pra enriquecer um pouco a discussão, encontrei um post interessante: “Java for HPC” que tem links muito interessantes

É a diferença do teoricamente possível, do realmente possível.
Teoricamente é possível fazer em assembly um programa mais rápido que em C.

Mas, na prática, isso não é possível:

1. Compiladores NUNCA perdem uma chance de otimização;
2. Organização do código contribui para boa performance;
3. O número de bugs é incrivelmente reduzido (e bota incrivelmente nisso);
4. Um compilador específico conhece centenas de instruções específicas, além de técnicas de otimização. Mesmo que você seja bom em assembly, tente entender um código gerado em C com compilação o3 num compilador específico da Intel, e você vai ver o que estou falando.

Na Siemens, constatamos que programar em C com muito cuidado era mais fácil e gerava código mais rápido do que em assembly. Mesmo com desenvolvedores experientes nas duas plataformas e altos investimentos em otimização. O que não significa que pequenas rotinas muito específicas fossem escritas em ASM, mas aí, em trechos bastante restritos e críticos.

Sem falar que a linguagem c foi criada justamente para se poder ter os mesmos recursos do assembly em uma linguagem de nível mais alto. Hoje é praticamente inviável escrever um aplicação em assembly. Digo aplicação, mas em hardware ou partes críticas de programas(como funções de copia e transferência de dados na memória Ex: memcpy, copymem, ZeroFill) ainda é amplamente utilizado assim como c.

Tem gente criando aplicação web com C++ http://www.webtoolkit.eu/wt

Recentemente eu li um estudo sobre custo operacional destas aplicações. Em larga escala (casos como Facebook), vale muito à pena. Assim que encontrar o link repasso aqui.

Yeap, existe programação orientada a objetos em COBOL: http://www.netcobol.com/info/whitepaper/oocoby2k.pdf

Teoricamente qualquer linguagem pode ser orientada a objetos, já que isso é uma metodologia. Basta aplicar os conceitos em qualquer uma delas. O problema das linguagens que não suportam esse conceito é a dificuldade em se empregar a metodologia. Existe um exemplo de interfaces com c++.

Em c também é perfeitamente possível, tanto é que temos o seu set objective c, que nada mais é que a linguagem c.

kicolobo:

Pra enriquecer um pouco a discussão, encontrei um post interessante: “Java for HPC” que tem links muito interessantes

http://ateji.blogspot.com/2010/09/java-for-high-performance-computing.html

Esse artigo é muito esclarecedor mesmo kiko. Por uma questão de magnitude c++ tem melhor desempenho que java, mas escrever um bom software em java é mais fácil que um bom software em c++. Então este é o motivo do software java se equiparar ou até mesmo ser uns 50% mais rápido. Tudo questão de otimização de código de máquina no final das contas(Quanto menos código melhor para o processador).

É a diferença do teoricamente possível, do realmente possível.
Teoricamente é possível fazer em assembly um programa mais rápido que em C.

Mas, na prática, isso não é possível:

1. Compiladores NUNCA perdem uma chance de otimização;
2. Organização do código contribui para boa performance;
3. O número de bugs é incrivelmente reduzido (e bota incrivelmente nisso);
4. Um compilador específico conhece centenas de instruções específicas, além de técnicas de otimização. Mesmo que você seja bom em assembly, tente entender um código gerado em C com compilação o3 num compilador específico da Intel, e você vai ver o que estou falando.

Na Siemens, constatamos que programar em C com muito cuidado era mais fácil e gerava código mais rápido do que em assembly. Mesmo com desenvolvedores experientes nas duas plataformas e altos investimentos em otimização. O que não significa que pequenas rotinas muito específicas fossem escritas em ASM, mas aí, em trechos bastante restritos e críticos.

Ué e só o cara ter um compilador no cerebro… Chuck Norris não usa compilador… compila tudo com o cerebro e injeta com um randhousekick as instruções direto no processador… alias chuck norris não precisa de processador… :lol:

Chuck Norris não tem celebro, tem cérebro =)

Um case de ambiente critico que foi migrado do mainframe para “baixa” plataforma(.Net) é a Bolsa de Valores de São Paulo. Diversos sistemas de billing das maiores operadoras de telefonia do pais são feitos em java e rodam em servidores e bancos de dados que não estão em mainframe. Então é balela que não da pra migrar sistemas em mainframe(COBOL) pra plataformas como JEE ou .Net. Outra coisa, não é o fato da aplicação ser escrita em COBOL que faz dela mais rápida, no caso de uma ambiente mainframe e sim o CICS, que é um monitor de transações. E digo mais, da pra escrever aplicações CICS em java se quiser.

+1 aqui que desenvolve uma aplicação em Java para uma grande quantidade de requisições(média de 1600/minuto) que inclui transações da grande maioria das bolsas do mundo(Bovespa, Chicago, NY, etc).
E como dito, o paradigma não tem quase influência, nosso maior gargalo é sempre I/O

Rafael Nunes:

+1 aqui que desenvolve uma aplicação em Java para uma grande quantidade de requisições(média de 1600/minuto) que inclui transações da grande maioria das bolsas do mundo(Bovespa, Chicago, NY, etc).
E como dito, o paradigma não tem quase influência, nosso maior gargalo é sempre I/O

É porque normalmente o io usa jni em bibliotecas nativas. Nesse ponto você perde desempenho por causa dele. O chamado Overhead(O tempo que leva um método para executar um outro, e assim por diante).

YvGa:

kicolobo:

s4nchez:

Eu trabalho num sistema que lida com milhoes de transacoes diarias, escrito em java (totalmente OO) e rodando na amazon sem problema.

Seu professor comeu bola e quem ta concordando precisa dar uma estudada melhor antes de dar opiniao baseada em chute.

SIm, é possível, mas executaria muito mais rápido em COBOL, C ou alguma outra linguagem não OO.

Mas isso eh bem diferente de dizer que nao sao apropriados.

Cara acho que faltou é a definição de apropriado.
depende dos requisitos não funcionais da app

juliocbq:

É porque normalmente o io usa jni em bibliotecas nativas. Nesse ponto você perde desempenho por causa dele. O chamado Overhead(O tempo que leva um método para executar um outro, e assim por diante).

Me referia a I/O de forma geral. Conexões com banco, serialização/deserialização de objetos, rede, chamadas ao MongoDB, requisições HTTP, etc.

Rafael Nunes:

+1 aqui que desenvolve uma aplicação em Java para uma grande quantidade de requisições(média de 1600/minuto) que inclui transações da grande maioria das bolsas do mundo(Bovespa, Chicago, NY, etc).
E como dito, o paradigma não tem quase influência, nosso maior gargalo é sempre I/O

Eu não duvido nada que “sistemas O.O.” do titulo do tópico na verdade é uma referência a sistemas que acessam SGBDs, mais do que propriamente sistemas orientado a objetos.

Rafael Nunes:

juliocbq:

É porque normalmente o io usa jni em bibliotecas nativas. Nesse ponto você perde desempenho por causa dele. O chamado Overhead(O tempo que leva um método para executar um outro, e assim por diante).

Me referia a I/O de forma geral. Conexões com banco, serialização/deserialização de objetos, rede, chamadas ao MongoDB, requisições HTTP, etc.

Me referi de forma geral também. A maioria delas ae são mapeamentos.

Exemplo: Driver de algum Banco(Mysql ) // A sua conexão com o banco de dados usa uma biblioteca que é um mapeamento de uma nativa.

Jni tem perda de desempenho justamente por causa desse mapeamento(Que é um método dentro de outro, que faz gerar mais código de máquina, e por sua vez leva mais tempo para ser processado).

juliocbq:

Rafael Nunes:

juliocbq:

É porque normalmente o io usa jni em bibliotecas nativas. Nesse ponto você perde desempenho por causa dele. O chamado Overhead(O tempo que leva um método para executar um outro, e assim por diante).

Me referia a I/O de forma geral. Conexões com banco, serialização/deserialização de objetos, rede, chamadas ao MongoDB, requisições HTTP, etc.

Me referi de forma geral também. A maioria delas ae são mapeamentos.

Exemplo: Driver de algum Banco(Mysql ) // A sua conexão com o banco de dados usa uma biblioteca que é um mapeamento de uma nativa.

Jni tem perda de desempenho justamente por causa desse mapeamento(Que é um método dentro de outro, que faz gerar mais código de máquina, e por sua vez leva mais tempo para ser processado).

Na maioria dos casos este tempo é insignificante… mais dependendo da app pode ser sim muito significativo…

A experiência que tenho com JNI neste projeto é o contrário.
Para implementarmos um servidor Comet e manter uma requisição Http persistente, acabamos substituindo alguns conectores do JBoss, principalmente o que trata requisições HTTP por um componente nativo do SO, e tanto a quantidade de usuários simultâneos quando o tempo de resposta, são consideravelmente melhores utilizando bibliotecas nativas + JNI.

E pelo que me lembro tanto driver do MySQL quanto do Postgre que usamos aqui, são do tipo IV(pure-Java)

juliocbq:

Rafael Nunes:

juliocbq:

É porque normalmente o io usa jni em bibliotecas nativas. Nesse ponto você perde desempenho por causa dele. O chamado Overhead(O tempo que leva um método para executar um outro, e assim por diante).

Me referia a I/O de forma geral. Conexões com banco, serialização/deserialização de objetos, rede, chamadas ao MongoDB, requisições HTTP, etc.

Me referi de forma geral também. A maioria delas ae são mapeamentos.

Exemplo: Driver de algum Banco(Mysql ) // A sua conexão com o banco de dados usa uma biblioteca que é um mapeamento de uma nativa.

Jni tem perda de desempenho justamente por causa desse mapeamento(Que é um método dentro de outro, que faz gerar mais código de máquina, e por sua vez leva mais tempo para ser processado).

Você ainda está preso a manipulação, io está mais relacionado ao trabalho do recurso. O Rafael está falando de IO Bloqueante. Da forma convencional não se pode fazer muita coisa além de diminuir o tempo de espera pelo recurso. E a alternativa seria trocar para uma abordagem como node.js, que usa callbacks.

Rafael Nunes:

juliocbq:

Jni tem perda de desempenho justamente por causa desse mapeamento(Que é um método dentro de outro, que faz gerar mais código de máquina, e por sua vez leva mais tempo para ser processado).

A experiência que tenho com JNI neste projeto é o contrário.
Para implementarmos um servidor Comet e manter uma requisição Http persistente, acabamos substituindo alguns conectores do JBoss, principalmente o que trata requisições HTTP por um componente nativo do SO, e tanto a quantidade de usuários simultâneos quando o tempo de resposta, são consideravelmente melhores utilizando bibliotecas nativas + JNI.

E pelo que me lembro tanto driver do MySQL quanto do Postgre que usamos aqui, são do tipo IV(pure-Java)

Se você usar o driver da Oracle está usando jni.

Se a conexão se mantém firme você não vê diferença porque tudo isso foi carregado na memória ram. A partir do momento que o mapeamento é carregado, é onde acontece o overhead(onde se tem a perda de desempenho). Se já foi carregado ae não é nem mais java, é assembly.

Ouvi dizer que o peido da formiga-leão pode afetar as moléculas transientes que compõem o éter multidimensional onde trafegam as meta-informações extra-sensoriais usadas pelos frameworks abstratos auto-replicantes…

Esse fórum tá muito “legalize” hoje.

bobmoe:

juliocbq:

Rafael Nunes:

juliocbq:

É porque normalmente o io usa jni em bibliotecas nativas. Nesse ponto você perde desempenho por causa dele. O chamado Overhead(O tempo que leva um método para executar um outro, e assim por diante).

Me referia a I/O de forma geral. Conexões com banco, serialização/deserialização de objetos, rede, chamadas ao MongoDB, requisições HTTP, etc.

Me referi de forma geral também. A maioria delas ae são mapeamentos.

Exemplo: Driver de algum Banco(Mysql ) // A sua conexão com o banco de dados usa uma biblioteca que é um mapeamento de uma nativa.

Jni tem perda de desempenho justamente por causa desse mapeamento(Que é um método dentro de outro, que faz gerar mais código de máquina, e por sua vez leva mais tempo para ser processado).

Você ainda está preso a manipulação, io está mais relacionado ao trabalho do recurso. O Rafael está falando de IO Bloqueante. Da forma convencional não se pode fazer muita coisa além de diminuir o tempo de espera pelo recurso. E a alternativa seria trocar para uma abordagem como node.js, que usa callbacks.

IO é a troca de dados entre recursos, e pode ser software ou hardware. O fato é que se você mapear um recurso nativo, no momento que você carrega ele na memória você tem uma perda consistente no desempenho.

Este artigo é bem interessante
http://www.javamex.com/tutorials/jni/

http://www.javamex.com/tutorials/jni/overhead.shtml

Aqui uma comparação do mapeamento da opencv da Intel, com a execução da biblioteca nativa

http://code.google.com/p/javacv/wiki/SpeedComparisons

É claro que se você usa um recurso nativo, dependendo da biblioteca sua aplicação terá um ganho de desenpenho maior, mas isso não está somente relacionado ao fato do recurso ser nativo.

Alguém pode me explicar o porque java foi mais rápido nestes testes no clean mode?

Motion Compensation time
Frame Capture time
Image Preprocessing
Output Display time
Video Stabilization time

juliocbq:

Rafael Nunes:

juliocbq:

Jni tem perda de desempenho justamente por causa desse mapeamento(Que é um método dentro de outro, que faz gerar mais código de máquina, e por sua vez leva mais tempo para ser processado).

A experiência que tenho com JNI neste projeto é o contrário.
Para implementarmos um servidor Comet e manter uma requisição Http persistente, acabamos substituindo alguns conectores do JBoss, principalmente o que trata requisições HTTP por um componente nativo do SO, e tanto a quantidade de usuários simultâneos quando o tempo de resposta, são consideravelmente melhores utilizando bibliotecas nativas + JNI.

E pelo que me lembro tanto driver do MySQL quanto do Postgre que usamos aqui, são do tipo IV(pure-Java)

Se você usar o driver da Oracle está usando jni.

Se a conexão se mantém firme você não vê diferença porque tudo isso foi carregado na memória ram. A partir do momento que o mapeamento é carregado, é onde acontece o overhead(onde se tem a perda de desempenho). Se já foi carregado ae não é nem mais java, é assembly.

o thin driver da oracle é java puro.

bobmoe:

juliocbq:

Rafael Nunes:

juliocbq:

Jni tem perda de desempenho justamente por causa desse mapeamento(Que é um método dentro de outro, que faz gerar mais código de máquina, e por sua vez leva mais tempo para ser processado).

A experiência que tenho com JNI neste projeto é o contrário.
Para implementarmos um servidor Comet e manter uma requisição Http persistente, acabamos substituindo alguns conectores do JBoss, principalmente o que trata requisições HTTP por um componente nativo do SO, e tanto a quantidade de usuários simultâneos quando o tempo de resposta, são consideravelmente melhores utilizando bibliotecas nativas + JNI.

E pelo que me lembro tanto driver do MySQL quanto do Postgre que usamos aqui, são do tipo IV(pure-Java)

Se você usar o driver da Oracle está usando jni.

Se a conexão se mantém firme você não vê diferença porque tudo isso foi carregado na memória ram. A partir do momento que o mapeamento é carregado, é onde acontece o overhead(onde se tem a perda de desempenho). Se já foi carregado ae não é nem mais java, é assembly.

o thin driver da oracle é java puro.

Melhor ainda;

Mas quando eu disse “da Oracle” estava me referindo ao “MySql”. Mas não sei também se ele possui um driver java, o que eu conheço é nativo.

O hotspot já otimiza o bytecode e o compila para código de máquina, então na maioria dos casos jni é insignificante para ganhos de desempenho. É mais útil para a integração com bibliotecas nativas já existentes. O Artigo no post anterior explica isso.

juliocbq:

bobmoe:

juliocbq:

Rafael Nunes:

juliocbq:

Jni tem perda de desempenho justamente por causa desse mapeamento(Que é um método dentro de outro, que faz gerar mais código de máquina, e por sua vez leva mais tempo para ser processado).

A experiência que tenho com JNI neste projeto é o contrário.
Para implementarmos um servidor Comet e manter uma requisição Http persistente, acabamos substituindo alguns conectores do JBoss, principalmente o que trata requisições HTTP por um componente nativo do SO, e tanto a quantidade de usuários simultâneos quando o tempo de resposta, são consideravelmente melhores utilizando bibliotecas nativas + JNI.

E pelo que me lembro tanto driver do MySQL quanto do Postgre que usamos aqui, são do tipo IV(pure-Java)

Se você usar o driver da Oracle está usando jni.

Se a conexão se mantém firme você não vê diferença porque tudo isso foi carregado na memória ram. A partir do momento que o mapeamento é carregado, é onde acontece o overhead(onde se tem a perda de desempenho). Se já foi carregado ae não é nem mais java, é assembly.

o thin driver da oracle é java puro.

Melhor ainda;

Mas quando eu disse “da Oracle” estava me referindo ao “MySql”. Mas não sei também se ele possui um driver java, o que eu conheço é nativo.

O hotspot já otimiza o bytecode e o compila para código de máquina, então na maioria dos casos jni é insignificante para ganhos de desempenho. É mais útil para a integração com bibliotecas nativas já existentes. O Artigo no post anterior explica isso.

acho difícil drivers jdbc atuais terem código nativo, já que os deste tipo não são thread safe (tipo II).

bobmoe:

juliocbq:

bobmoe:

juliocbq:

Rafael Nunes:

juliocbq:

Jni tem perda de desempenho justamente por causa desse mapeamento(Que é um método dentro de outro, que faz gerar mais código de máquina, e por sua vez leva mais tempo para ser processado).

A experiência que tenho com JNI neste projeto é o contrário.
Para implementarmos um servidor Comet e manter uma requisição Http persistente, acabamos substituindo alguns conectores do JBoss, principalmente o que trata requisições HTTP por um componente nativo do SO, e tanto a quantidade de usuários simultâneos quando o tempo de resposta, são consideravelmente melhores utilizando bibliotecas nativas + JNI.

E pelo que me lembro tanto driver do MySQL quanto do Postgre que usamos aqui, são do tipo IV(pure-Java)

Se você usar o driver da Oracle está usando jni.

Se a conexão se mantém firme você não vê diferença porque tudo isso foi carregado na memória ram. A partir do momento que o mapeamento é carregado, é onde acontece o overhead(onde se tem a perda de desempenho). Se já foi carregado ae não é nem mais java, é assembly.

o thin driver da oracle é java puro.

Melhor ainda;

Mas quando eu disse “da Oracle” estava me referindo ao “MySql”. Mas não sei também se ele possui um driver java, o que eu conheço é nativo.

O hotspot já otimiza o bytecode e o compila para código de máquina, então na maioria dos casos jni é insignificante para ganhos de desempenho. É mais útil para a integração com bibliotecas nativas já existentes. O Artigo no post anterior explica isso.

acho difícil drivers jdbc atuais terem código nativo, já que os deste tipo não são thread safe (tipo II).

Existem muitas coisas que não são thread safe, uma delas é o próprio swing, e ele é completamente escrito em java. Isso não tem nada a ver com a conversa de desempenho de aplicações.

Eu fiquei com uma dúvida…
Esse driver atual do mysql padrão na sua release é nativo ou não?

bobmoe:

acho difícil drivers jdbc atuais terem código nativo, já que os deste tipo não são thread safe (tipo II).

O mysql também é java. Tem razão.

quebrado:

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.

:arrow: base de dados
carrega e processa os dados e envia para a memoria
:arrow: linguagem de programacao
recebe os muitos dados e calcula o que for necessario e depois volta a enviar para a base de dados onde é guardado e ou recebido os outros dados a anlisar.

solução:::::
para os calculos mais complexos e demorados usa sempre procedures do lado do servidor de base de dados (oracle pl/sql).
assim os dados sao carregados e analisados todos dentro do banco de dados, e acho que fica 50% mais rapido

kicolobo:

Olha, vou contar uma coisa.

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:

1. Falta de respeito total com o investimento anterior feito pelo seu cliente.
2. 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.

O Joel Spolsky tem um texto ótimo sobre esta questão: http://www.joelonsoftware.com/articles/fog0000000069.html

Aliás, sobre COBOL, eu fiz uma pesquisa a algum tempo atrás. Os resultados foram surpreendentes pra mim na época: http://www.itexto.net/devkico/?p=135

“”"" o segredo não esta na arma, mas sim no ninja ( shinobi ) “”""
traduzindo “”"" o segredo não esta na linguagem , mas sim no programador “”"

o problema do java é o tempo de estrada, para os mais velhos e programadores mais experientes ( a partir dos 50 anos acima ), dificilmente usam java, e se usarem não conhecem a linguagem a fundo, porque java é uma tecnologia recente, tem poucos anos de estrada, e normalmente os mais velhos e experientes programadores, é que lideram os grandes projectos, e sempre preferem apostar nas linguagens da idade da pedra, até que alguem les prove o contrario eles vao achar que java nao é melhor que as linguagens antigas cobol e etc, mas sem esquecer dois pontos essenciais, para cada projecto podera ter uma linguagem que mais se adequa ao caso.

kicolobo:

s4nchez:

Eu trabalho num sistema que lida com milhoes de transacoes diarias, escrito em java (totalmente OO) e rodando na amazon sem problema.

Seu professor comeu bola e quem ta concordando precisa dar uma estudada melhor antes de dar opiniao baseada em chute.

SIm, é possível, mas executaria muito mais rápido em COBOL, C ou alguma outra linguagem não OO.

depende da plataforma, o java rodando em mainframe com vm otimizada suporta o volume do que voce imaginar. mas depende mais da otimização em hardware, cobol é feito pra rodar em mainframe é por isso, java sempre foi utilizado em baixa plataforma. sao conceitos diferentes.

dmitsuo:

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.

–

pra fechar o topico o ultimo post, :? :?
se isso fosse verdade “”“Sistemas O.O. não são apropriados para grandes demandas (milhares de transações/hora)” “”
então o cobol nao incluiria a versão orientada a objectos.

Acabei de ver um artigo no Javalobby (Java PHP Python - Which is “Faster In General”?) relacionado ao tema aqui do tópico. Não trata especificamente de COBOL vs. Java, mas de Java vs. PHP vs. Python.

Logo de cara esse artigo faz uma afirmação que serve de resposta ao meu ilustre instrutor (excelente profissional por sinal, mas acho que comeu mosca sobre o que falou de Java e OO):

Abraços.
Davi.

dmitsuo:

Acabei de ver um artigo no Javalobby (Java PHP Python - Which is “Faster In General”?) relacionado ao tema aqui do tópico. Não trata especificamente de COBOL vs. Java, mas de Java vs. PHP vs. Python.

Logo de cara esse artigo faz uma afirmação que serve de resposta ao meu ilustre instrutor (excelente profissional por sinal, mas acho que comeu mosca sobre o que falou de Java e OO):

Abraços.
Davi.

Mas a discussão não era sobre linguagem, era sobre o paradigma da linguagem.
E quando eu aprendi OO na faculdade ouvi muitos boatos que em grandes sistemas, OO não era nada recomendado, mas não tenho nenhum artigo para comprovar isso, então não sei se é verdade.

Eu também acho que os OO não são apropriados, pois usa muito a memória, por isso prefiro as procedurais, além de serem mais rápidas.

Aqui no serviço só trabalhando usando o bom e velho paradigma procedural.

Forreta:

seu professor esta corretíssimo.

Qualquer operação da área da banca ou seguros é feita em AS/400 ou Mainframe.

A Allianz trabalha INTEIRAMENTE com COBOL, tem apenas a interface gráfica feita em .NET, o resto é TUDO cobol!

E quer saber? Funciona melhor do que se fizesse em .NET/Java (coloco os dois porque são duas linguagens iguais)

A Groupama Seguros (uma das maiores seguradoras da europa) trabalha da mesma forma que a Allianz.

O BBVA Madrid é igual.

Java/.NET é ridiculo para sistemas TPS.

So um detalhe, .NET nao eh linguagem.
Acho que vc queria comparar C# com Java, ambas tem similaridades, mas o C# tem um monte de coisas que o Java nao tem e vice-versa.

Voltando ao topico, eu nao entendo a raiva que o pessoal aqui desse forum tem com o Cobol e programadores Cobol, eu dou muito mais credito pro tiozao de 50 anos que desenvolveu e implementou um monte de sistemas nos maiores bancos do Brasil e continuam rodando ate hoje do que neguinho de 20 e poucos anos que so faz sisteminha de cadastro usando netbeans “porque eh mais facil pra fazer as telinhas” hehehe
O Cobol eh uma linguagem extremamente robusta e serve muito bem o seu proposito.

Eu trabalhava com bioinformatica uns anos atras, eu tinha que processar muitos arquivos de texto (strings gigantes de DNA) fazia tudo em Perl, um belo dia alguem disse que nos deveriamos fazer em Java, fiz uns testes e adivinha qual atentou melhor o que a gente queria e rodou infinitamente mais rapido? Perl!!! Isso mesmo Perl, linguagem de script.

Mesmo sendo linguagens completamente diferentes, qual eh melhor??? Perl eh bom pra umas coisas e impossivel pra outras, mesma coisa Java.

Talvez o seu instrutor tenha se expressado um pouco mal o que ofendeu os javeiros de plantao, mas ele tem um pouco de razao sim.

Como ja falaram tem muitas razoes que o Cobol ainda ta por ai e vai ficar por muito tempo, eh o famoso “em time que ta ganhando nao se mexe”, como ja disseram acima.

//Daniel

bozo25:

Eu também acho que os OO não são apropriados, pois usa muito a memória, por isso prefiro as procedurais, além de serem mais rápidas.

Aqui no serviço só trabalhando usando o bom e velho paradigma procedural.

Em que linguagem ??? :shock:

sim, GWT.

sim. era .Net, mas migrou pra java. aqui no guj tem um tópico sobre.

pode ser que eu me engane, mas acho que é só C++

sim, só tem ‘ninja’ lá, com um tesão enorme por Python e AJAX… alguém me disse que eles tem uma espécia de ‘white papers’ online, onde é possível saber o que eles usam, em cada sistema etc, mas esqueci a url… :roll:

aí eu já não sei…

eu fico pensando se a limitação é mesmo o java.

penso em sistemas horizontalmente escalaveis, cache, rest, map reduce e seria possivel rodar em uma cloud um sistema eficiente que capaz de processar qq coisa - principalmente elastico para aguentar o pico. provavelmente falamos de processamento onde precisamos cruzar tantas informações que precisamos de tecnicas elaboradas e o cobol esta ai, faz de uma forma menos complexa, etc…

Pessoal, à propósito do assunto, olha o que o Mike Cohn escreveu no site dele. Ele tá falando de outro assunto nesse post, dos dez anos do manifesto ágil, mas fez uma analogia mencionando justamente o tema discutido aqui na thread.

Bem, vindo de um cara renomado como ele, acho que tem um peso enorme nessa discussão:

O texto completo (excelente, por sinal) vocês podem conferir aqui: Reflections on the 10 Years Since the Agile Manifesto (http://blog.mountaingoatsoftware.com/reflections-on-the-10-years-since-the-agile-manifesto)

Aos que se manifestaram aqui na thread, meus agradecimentos por me deixar por dentro das mais diferentes visões e circunstâncias sobre esse assunto. Valeu!

Bem, cheguei atrasado, mas vou dar o meu pitaco:

A maior parte dos programas encontrados em bancos e instituições financeiras realmente não são feitos com metodologia OO. Tampouco metodologia estruturada, nem funcional, nem qualquer outra assim. Eles usam a exata metodologia que é a mais usada de todas: A POG.

Dos sistemas bancários que já vi e já ouvi falar, o que vejo em comum entre eles é a grande quantidade de remendos, erosão e subversão de suas arquiteturas e estruturas e grande desorganização. Não muito diferente do que a maioria dos sistemas feitos em java, em C ou mesmo na melhor linguagem que você puder imaginar, mesmo que a linguagem seja muito boa, não há remédio para programadores ruins. É óbvio que há programas bons rodando e eles melhoram com o tempo, mas grande parte é gambi.

Estes sistemas tem o seu sucesso por motivos bem diferentes do que a linguagem de programação usada:

[list]O hardware é rápido.[/list]
[list]Os programas passaram por vários remendos para corrigir bugs (e são muitos bugs). Há um medo muito grande de qualquer mudança para evitar que novos bugs sejam inseridos (refactoring torna-se algo proibido). Quando as mudanças são necessárias elas sempre ocorrem da forma que menos altere/afete código já existente, por pior que este seja. Com o passar dos anos o sistema fica estabilizado, mesmo se for mal-projetado e mesmo que pemaneçam alguns bugs menores não corrigidos.[/list]
[list]Os sistemas em geral rodam isolados uns dos outros (frequentemente fisicamente), e se comunicam entre si por uma série de meios distintos, entre eles escrita e leitura arquivos em formato texto ou binário, sockets, banco de dados relacionais, webservices SOAP, POX+HTTP+REST e mais um monte de outras coisas. O motivo de isso ter ocorrido é que cada um deles foi concebido em separado para fazer uma determinada coisa (como é de se esperar em qualquer lugar), de forma que no final “o sistema” seja na verdade algumas dezenas ou centenas de sistemas independente se comunicando entre si. Isto tem a vantagem de que cada ponto pode evoluir (e até ser completamente substituído) de forma independente sem afetar muito os demais. Também é uma vantagem que, embora nem sempre tenha sido inicialmente planejado, isto acaba trazendo escalabilidade. As grandes desvantagens são a grande desorganização e a heterogenidade.[/list]
[list]Existe bastante intervenção humana.[/list]

Enfim, um dos maiores mitos que existem na área de sistemas de bancos e outras instituições financeiras é que eles são muito bem arquitetados, confiáveis e rápidos. Isso daí é simplesmente uma grande mentira. Dizer que eles são bem arquitetados, confiáveis e rápidos porque não são OO é mentir duas vezes.

OO é sim apropriada (e muito bem apropriada, diga-se de passagem) para grandes demandas de milhares de transações por hora. Não é a linguagem que determina se é ou se não é, é a infraestrutura de rede, a organização interna dos servidores e o hardware que determina isso.

victorwss:

Bem, cheguei atrasado, mas vou dar o meu pitaco:

A maior parte dos programas encontrados em bancos e instituições financeiras realmente não são feitos com metodologia OO. Tampouco metodologia estruturada, nem funcional, nem qualquer outra assim. Eles usam a exata metodologia que é a mais usada de todas: A POG.

Dos sistemas bancários que já vi e já ouvi falar, o que vejo em comum entre eles é a grande quantidade de remendos, erosão e subversão de suas arquiteturas e estruturas e grande desorganização. Não muito diferente do que a maioria dos sistemas feitos em java, em C ou mesmo na melhor linguagem que você puder imaginar, mesmo que a linguagem seja muito boa, não há remédio para programadores ruins. É óbvio que há programas bons rodando e eles melhoram com o tempo, mas grande parte é gambi.

Estes sistemas tem o seu sucesso por motivos bem diferentes do que a linguagem de programação usada:

[list]O hardware é rápido.[/list]
[list]Os programas passaram por vários remendos para corrigir bugs (e são muitos bugs). Há um medo muito grande de qualquer mudança para evitar que novos bugs sejam inseridos (refactoring torna-se algo proibido). Quando as mudanças são necessárias elas sempre ocorrem da forma que menos altere/afete código já existente, por pior que este seja. Com o passar dos anos o sistema fica estabilizado, mesmo se for mal-projetado e mesmo que pemaneçam alguns bugs menores não corrigidos.[/list]
[list]Os sistemas em geral rodam isolados uns dos outros (frequentemente fisicamente), e se comunicam entre si por uma série de meios distintos, entre eles escrita e leitura arquivos em formato texto ou binário, sockets, banco de dados relacionais, webservices SOAP, POX+HTTP+REST e mais um monte de outras coisas. O motivo de isso ter ocorrido é que cada um deles foi concebido em separado para fazer uma determinada coisa (como é de se esperar em qualquer lugar), de forma que no final “o sistema” seja na verdade algumas dezenas ou centenas de sistemas independente se comunicando entre si. Isto tem a vantagem de que cada ponto pode evoluir (e até ser completamente substituído) de forma independente sem afetar muito os demais. Também é uma vantagem que, embora nem sempre tenha sido inicialmente planejado, isto acaba trazendo escalabilidade. As grandes desvantagens são a grande desorganização e a heterogenidade.[/list]
[list]Existe bastante intervenção humana.[/list]

Enfim, um dos maiores mitos que existem na área de sistemas de bancos e outras instituições financeiras é que eles são muito bem arquitetados, confiáveis e rápidos. Isso daí é simplesmente uma grande mentira. Dizer que eles são bem arquitetados, confiáveis e rápidos porque não são OO é mentir duas vezes.

OO é sim apropriada (e muito bem apropriada, diga-se de passagem) para grandes demandas de milhares de transações por hora. Não é a linguagem que determina se é ou se não é, é a infraestrutura de rede, a organização interna dos servidores e o hardware que determina isso.

sulito:

victorwss:

Bem, cheguei atrasado, mas vou dar o meu pitaco:

A maior parte dos programas encontrados em bancos e instituições financeiras realmente não são feitos com metodologia OO. Tampouco metodologia estruturada, nem funcional, nem qualquer outra assim. Eles usam a exata metodologia que é a mais usada de todas: A POG.

Dos sistemas bancários que já vi e já ouvi falar, o que vejo em comum entre eles é a grande quantidade de remendos, erosão e subversão de suas arquiteturas e estruturas e grande desorganização. Não muito diferente do que a maioria dos sistemas feitos em java, em C ou mesmo na melhor linguagem que você puder imaginar, mesmo que a linguagem seja muito boa, não há remédio para programadores ruins. É óbvio que há programas bons rodando e eles melhoram com o tempo, mas grande parte é gambi.

Estes sistemas tem o seu sucesso por motivos bem diferentes do que a linguagem de programação usada:

[list]O hardware é rápido.[/list]
[list]Os programas passaram por vários remendos para corrigir bugs (e são muitos bugs). Há um medo muito grande de qualquer mudança para evitar que novos bugs sejam inseridos (refactoring torna-se algo proibido). Quando as mudanças são necessárias elas sempre ocorrem da forma que menos altere/afete código já existente, por pior que este seja. Com o passar dos anos o sistema fica estabilizado, mesmo se for mal-projetado e mesmo que pemaneçam alguns bugs menores não corrigidos.[/list]
[list]Os sistemas em geral rodam isolados uns dos outros (frequentemente fisicamente), e se comunicam entre si por uma série de meios distintos, entre eles escrita e leitura arquivos em formato texto ou binário, sockets, banco de dados relacionais, webservices SOAP, POX+HTTP+REST e mais um monte de outras coisas. O motivo de isso ter ocorrido é que cada um deles foi concebido em separado para fazer uma determinada coisa (como é de se esperar em qualquer lugar), de forma que no final “o sistema” seja na verdade algumas dezenas ou centenas de sistemas independente se comunicando entre si. Isto tem a vantagem de que cada ponto pode evoluir (e até ser completamente substituído) de forma independente sem afetar muito os demais. Também é uma vantagem que, embora nem sempre tenha sido inicialmente planejado, isto acaba trazendo escalabilidade. As grandes desvantagens são a grande desorganização e a heterogenidade.[/list]
[list]Existe bastante intervenção humana.[/list]

Enfim, um dos maiores mitos que existem na área de sistemas de bancos e outras instituições financeiras é que eles são muito bem arquitetados, confiáveis e rápidos. Isso daí é simplesmente uma grande mentira. Dizer que eles são bem arquitetados, confiáveis e rápidos porque não são OO é mentir duas vezes.

OO é sim apropriada (e muito bem apropriada, diga-se de passagem) para grandes demandas de milhares de transações por hora. Não é a linguagem que determina se é ou se não é, é a infraestrutura de rede, a organização interna dos servidores e o hardware que determina isso.

concordo plenamente com cada letra e virgula do que escreveste… exacto acho que tens toda a razao

++

victorwss:

Bem, cheguei atrasado, mas vou dar o meu pitaco:

A maior parte dos programas encontrados em bancos e instituições financeiras realmente não são feitos com metodologia OO. Tampouco metodologia estruturada, nem funcional, nem qualquer outra assim. Eles usam a exata metodologia que é a mais usada de todas: A POG.

Dos sistemas bancários que já vi e já ouvi falar, o que vejo em comum entre eles é a grande quantidade de remendos, erosão e subversão de suas arquiteturas e estruturas e grande desorganização. Não muito diferente do que a maioria dos sistemas feitos em java, em C ou mesmo na melhor linguagem que você puder imaginar, mesmo que a linguagem seja muito boa, não há remédio para programadores ruins. É óbvio que há programas bons rodando e eles melhoram com o tempo, mas grande parte é gambi.

Estes sistemas tem o seu sucesso por motivos bem diferentes do que a linguagem de programação usada:

[list]O hardware é rápido.[/list]
[list]Os programas passaram por vários remendos para corrigir bugs (e são muitos bugs). Há um medo muito grande de qualquer mudança para evitar que novos bugs sejam inseridos (refactoring torna-se algo proibido). Quando as mudanças são necessárias elas sempre ocorrem da forma que menos altere/afete código já existente, por pior que este seja. Com o passar dos anos o sistema fica estabilizado, mesmo se for mal-projetado e mesmo que pemaneçam alguns bugs menores não corrigidos.[/list]
[list]Os sistemas em geral rodam isolados uns dos outros (frequentemente fisicamente), e se comunicam entre si por uma série de meios distintos, entre eles escrita e leitura arquivos em formato texto ou binário, sockets, banco de dados relacionais, webservices SOAP, POX+HTTP+REST e mais um monte de outras coisas. O motivo de isso ter ocorrido é que cada um deles foi concebido em separado para fazer uma determinada coisa (como é de se esperar em qualquer lugar), de forma que no final “o sistema” seja na verdade algumas dezenas ou centenas de sistemas independente se comunicando entre si. Isto tem a vantagem de que cada ponto pode evoluir (e até ser completamente substituído) de forma independente sem afetar muito os demais. Também é uma vantagem que, embora nem sempre tenha sido inicialmente planejado, isto acaba trazendo escalabilidade. As grandes desvantagens são a grande desorganização e a heterogenidade.[/list]
[list]Existe bastante intervenção humana.[/list]

Enfim, um dos maiores mitos que existem na área de sistemas de bancos e outras instituições financeiras é que eles são muito bem arquitetados, confiáveis e rápidos. Isso daí é simplesmente uma grande mentira. Dizer que eles são bem arquitetados, confiáveis e rápidos porque não são OO é mentir duas vezes.

OO é sim apropriada (e muito bem apropriada, diga-se de passagem) para grandes demandas de milhares de transações por hora. Não é a linguagem que determina se é ou se não é, é a infraestrutura de rede, a organização interna dos servidores e o hardware que determina isso.

Victor, falou tudo!

concordo com cada palavra!

sem falar que vc não precisa fazer 100% OO.

Vc pode ter a parte de regra de negócios, por exemplo, e o resto ser “procedural”, “funcional” ou até mesmo implementado diretamente em hardware.

victorwss:

Bem, cheguei atrasado, mas vou dar o meu pitaco:

A maior parte dos programas encontrados em bancos e instituições financeiras realmente não são feitos com metodologia OO. Tampouco metodologia estruturada, nem funcional, nem qualquer outra assim. Eles usam a exata metodologia que é a mais usada de todas: A POG.

Dos sistemas bancários que já vi e já ouvi falar, o que vejo em comum entre eles é a grande quantidade de remendos, erosão e subversão de suas arquiteturas e estruturas e grande desorganização. Não muito diferente do que a maioria dos sistemas feitos em java, em C ou mesmo na melhor linguagem que você puder imaginar, mesmo que a linguagem seja muito boa, não há remédio para programadores ruins. É óbvio que há programas bons rodando e eles melhoram com o tempo, mas grande parte é gambi.

Estes sistemas tem o seu sucesso por motivos bem diferentes do que a linguagem de programação usada:

[list]O hardware é rápido.[/list]
[list]Os programas passaram por vários remendos para corrigir bugs (e são muitos bugs). Há um medo muito grande de qualquer mudança para evitar que novos bugs sejam inseridos (refactoring torna-se algo proibido). Quando as mudanças são necessárias elas sempre ocorrem da forma que menos altere/afete código já existente, por pior que este seja. Com o passar dos anos o sistema fica estabilizado, mesmo se for mal-projetado e mesmo que pemaneçam alguns bugs menores não corrigidos.[/list]
[list]Os sistemas em geral rodam isolados uns dos outros (frequentemente fisicamente), e se comunicam entre si por uma série de meios distintos, entre eles escrita e leitura arquivos em formato texto ou binário, sockets, banco de dados relacionais, webservices SOAP, POX+HTTP+REST e mais um monte de outras coisas. O motivo de isso ter ocorrido é que cada um deles foi concebido em separado para fazer uma determinada coisa (como é de se esperar em qualquer lugar), de forma que no final “o sistema” seja na verdade algumas dezenas ou centenas de sistemas independente se comunicando entre si. Isto tem a vantagem de que cada ponto pode evoluir (e até ser completamente substituído) de forma independente sem afetar muito os demais. Também é uma vantagem que, embora nem sempre tenha sido inicialmente planejado, isto acaba trazendo escalabilidade. As grandes desvantagens são a grande desorganização e a heterogenidade.[/list]
[list]Existe bastante intervenção humana.[/list]

Enfim, um dos maiores mitos que existem na área de sistemas de bancos e outras instituições financeiras é que eles são muito bem arquitetados, confiáveis e rápidos. Isso daí é simplesmente uma grande mentira. Dizer que eles são bem arquitetados, confiáveis e rápidos porque não são OO é mentir duas vezes.

OO é sim apropriada (e muito bem apropriada, diga-se de passagem) para grandes demandas de milhares de transações por hora. Não é a linguagem que determina se é ou se não é, é a infraestrutura de rede, a organização interna dos servidores e o hardware que determina isso.

Eu não só concordo como ratifico, tendo em vista que esse cenário é o meu dia-a-dia… Não tiro nem uma vírgula do que disseste…

Abs []

É vero, metodologia POG, com projeto Ágil a la XGH é a tendencia!!

Eu não digo nem tendência, mas é como o Víctor colocou lá em cima… o medo de mecher no que já está funcionando é tão grande…

É quase como se fizéssemos um castelo de cartas, onde em um determinado momento, a construção do mesmo se estabilizou… O medo de que ele caia é tão grande que (e isso é sério) NINGUÉM quer que você mecha no que “está funcionando”…

Não adianta trazer argumentos, não haverá ninguém que vai se responsabilizar pela cagada…

Se você conversar com quem nasceu o filho, eles defenderão com unhas e dentes… Se conversar com alguém que entrou no meio do Processo, ele diz que até queria que fosse diferente, mas que não adianta tentar… Ou seja, a maioria quer mudança, mas ninguém quer assinar a mudança…

É desse cenário que eu não vejo a hora de sair, afinal, acabamos dançando conforme a música…

Isso é complicado viu, eu mesmo estava(estou) dando manutenção em um programa que tem algumas bizarrices e partes obscuras… O cara que começou o projeto já está longe, na verdade já estou na “terceira geração” de desenvolvedores mechendo no sistema e não se tem tempo de ficar refatorando o código, pois a cada dia os clientes pedem uma funcionalidade diferente, e do jeito que a coisa tá, se começar a modificar vai demorar um bom tempo até corrigir tudo e fazer ficar funcionando de novo :oops:

Esta é uma visão muito simplista.
A verdade é que na maioria dos casos seria uma IRRESPONSABILIDADE mexer no que está funcionando.
Quem nunca trabalhou na TI de um Banco (só pra ficar no caso clássico de legado) não tem a mínima idéia da quantidade de sistemas, do tamanho, da complexidade, e do tempo que se levou para que tudo esteja simplesmente funcionando.
Não tem a menor (e isso não é exagero) idéia de tudo o que ocorre quando aperta um botão no caixa eletrônico ou clica em algum botão no internet banking.
Estes sistemas estão sob constante ameaça de erros que causam a insatifação e até a perda de clientes, processos judiciais, multas de orgãos regulatórios, etc.
Imaginem então o risco que representa para estas empresas reconstruir tudo do zero!
Isto NUNCA vai acontecer.
Sem contar que o mainframe é uma máquina espetacular, não pode ser comparada com nenhuma outra opção comercial.
O mainframe é eterno, o cobol é eterno, pelo menos enquanto o mundo for o mundo que conhecemos.
Tudo o que o vitorwss falou é verdade, e vai continuar assim indefinidamente.
Afinal, o objetivo destas empresas não é fazer sistemas bonitos, mas simplesmente funcionarem.

Verdade… É o castelo de carta delicado que seria difícil e demorado reconstruir de novo…

Meus 5 centavos de contribuição: Big Ball of Mud.

Inté.

Não é só banco, a maioria das grandes empresas que a tecnologia não é atividade fim são conservadoras na hora de atualizar-se e refatorar código. Estabilidade é mais importante que atualização tecnológica e sai mais barato atualizar o hardware que o software.

Só pra citar um caso interessante, onde trabalho hoje eles usam Java pra web, com uma biblioteca javascript própria, que tem compatiblidade até com o IE 3 e Netscape 4. Foi a maior luta convencê-los a retirar o código de compatibilidade antigo, queriam me matar, mesmo que há anos não usássemos mais e mesmo os sites externos, quantos ainda acessam web por um Windows 95?

No final, consegui deixar até o IE 5, já podemos utilizar CSS. hehehe
E os programas java quero atualizar os 100% servlets, pelo menos deixar os apps JSP pra cima.

bem, eu tenho uma certa experiência com instituições financeiras…

no meu antigo emprego, que a maioria dos clientes eram bancos, a linguagem predominante era sem dúvida c/c++ + cobol…

primeiramente eu acho que vai demorar séculos para um banco trocar seu cobol / mainframe / db2…

o que eu vi acontecendo é que a parte transacional tem sido repensada, porém a validação, regras de negócios, etc, ainda ficam no mainframe…

o maior problema é ver alguns frameworks próprios horríveis que os bancos estão usando…

eu trabalhei cerca de 1 ano e meio em projetos para apenas um banco, um dos maiores do brasil… e posso afirmar que o ambiente que eles possuem utilizando ansi c é maravilhoso… muito bom, estável e fácil de desenvolver novas aplicações… aliás c é maravilhoso. porém eles vieram com uma plataforma nova em java, e sinceramente, não há nada mais escroto e instável que aquilo, e definitivamente foi um dos motivos de eu ter largado este emprego, pois era extremamente broxante trabalhar com algo tão mal feito…

a questão não é saber se OO é melhor que estruturado, a questão é saber quais são as melhores opções que você tem e fazer direito.

Rafael Marques:

bem, eu tenho uma certa experiência com instituições financeiras…

no meu antigo emprego, que a maioria dos clientes eram bancos, a linguagem predominante era sem dúvida c/c++ + cobol…

primeiramente eu acho que vai demorar séculos para um banco trocar seu cobol / mainframe / db2…

o que eu vi acontecendo é que a parte transacional tem sido repensada, porém a validação, regras de negócios, etc, ainda ficam no mainframe…

o maior problema é ver alguns frameworks próprios horríveis que os bancos estão usando…

eu trabalhei cerca de 1 ano e meio em projetos para apenas um banco, um dos maiores do brasil… e posso afirmar que o ambiente que eles possuem utilizando ansi c é maravilhoso… muito bom, estável e fácil de desenvolver novas aplicações… aliás c é maravilhoso. porém eles vieram com uma plataforma nova em java, e sinceramente, não há nada mais escroto e instável que aquilo, e definitivamente foi um dos motivos de eu ter largado este emprego, pois era extremamente broxante trabalhar com algo tão mal feito…

a questão não é saber se OO é melhor que estruturado, a questão é saber quais são as melhores opções que você tem e fazer direito.

Java roda em um Segmento OMVS do Mainframe ou no zLinux. A IBM ja ofereceu onde eu trabalho desconto pros MIPS do java. Assim eles podem rodar WebSphere com tudo que se tem direito no z10 ou no zEnterprise. Qual o custo/benefício? Não sei, mas me chamou a atenção.

Porém ainda tem o mal do trabalhador que não se capacita e não se atualiza. Ai mantem-se o que está.

Isso vale na plataforma baixa também que permite gestores preferirem contratar 10 programadores dotNet mediocres bem baratinho (tem também ainda os que vieram do VB6/ASP) que contratar 2 bons e caros programadores java. E da espaço pros mesmos fazerem afirmações sobre o dotNet com VB ser melhor que o mesmo java oferecido pela IBM em seus produtos.

Galera pelo amor do Pai…

Os bancos não vão migrar os legados em MainFrame por questões financeiras, isto é determinação executiva e não vem de nehnum comitê de IT, eles não estão nem ai para linguagem procedural ou O.O, o banco se importa é com custos e os custos de migração são altos de mais e ainda não justificáveis.

Foram gastos no mínimo 30 anos em desenvolvimento e manutenção desses legados, sem contar as enormes perdas da epóca da Reengenharia onde tentou-se fazer isso e não deu certo. O problema não é técnico é financeiro.

Já citaram lá atrás que as Telecom operam plataformas baseadas Java e na sua maioria aqui no Brasil utilizando um SOA através de uma solução de mercado com Oracle SOA Suite e antiga BEA e as coisas vão bem, dão conta milhões de transações.

Existe uma pressão para a troca de tecnologia nos bancos que vai aumentando ano a ano, essa pressão tem como causa a falta de profissionais Mainframe, por isso muitos bancos investem na formação desses profissionais ou vão atrás do pessoal de mainframe aposentado. Pode não estou afirmando que vai acontecer de que em um determinado momento a falta de profissionais possa justificar essa migração.

DaviPiala:

Galera pelo amor do Pai…

Os bancos não vão migrar os legados em MainFrame por questões financeiras, isto é determinação executiva e não vem de nehnum comitê de IT, eles não estão nem ai para linguagem procedural ou O.O, o banco se importa é com custos e os custos de migração são altos de mais e ainda não justificáveis.

Foram gastos no mínimo 30 anos em desenvolvimento e manutenção desses legados, sem contar as enormes perdas da epóca da Reengenharia onde tentou-se fazer isso e não deu certo. O problema não é técnico é financeiro.

Já citaram lá atrás que as Telecom operam plataformas baseadas Java e na sua maioria aqui no Brasil utilizando um SOA através de uma solução de mercado com Oracle SOA Suite e antiga BEA e as coisas vão bem, dão conta milhões de transações.

Existe uma pressão para a troca de tecnologia nos bancos que vai aumentando ano a ano, essa pressão tem como causa a falta de profissionais Mainframe, por isso muitos bancos investem na formação desses profissionais ou vão atrás do pessoal de mainframe aposentado. Pode não estou afirmando que vai acontecer de que em um determinado momento a falta de profissionais possa justificar essa migração.

Bom, eu não sei quanto aos outros, mas eu não falei em migrar legado. Mas continuar desenvolvendo na tecnologia do legado vale a pena?

Outra coisa: Visual Age é legado forte em alta plataforma também e a IBM já deu uma rasteira nos compradores desse legado. O EGL não é 100% compatível e as customizações não estão previstas no conversor do fornecedor. Portanto, ao meu ver, continuar no legado sem suporte é tiro no pé.

Deixo apenas uma questão,
o Cobol é mais performático ou a infra-estrutura sobre a qual ele roda é que é muito boa?

Poucos servidores se comparam em termos de processamento que os sistemas mainframe.
Na minha visão, cobol só é realmente eficaz por atuar em mainframe, se atuasse em servidores “usuais” não teria muitos elogios e seria substituido com menos medo

Legado é algo que se troca quando o valor da manutenção supera o valor da migração com melhorias.