[quote=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.[/quote]
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.
[quote=kicolobo][quote=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.[/quote]
SIm, é possível, mas executaria muito mais rápido em COBOL, C ou alguma outra linguagem não OO.[/quote]
Mas isso eh bem diferente de dizer que nao sao apropriados.
[quote]
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:
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[/quote]
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;
[quote=YvGa][quote=kicolobo]
SIm, é possível, mas executaria muito mais rápido em COBOL, C ou alguma outra linguagem não OO.[/quote]
Mas isso eh bem diferente de dizer que nao sao apropriados.[/quote]
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:
[quote=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[/quote]
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
[quote=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
[/quote]
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:
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?
[quote=foxpv]É impressão minha, ou já existe OO em cobol?
To viajando?[/quote]
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.
[quote=marcosalex][quote=foxpv]É impressão minha, ou já existe OO em cobol?
To viajando?[/quote]
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: [/quote]
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…
[quote]quer 100% de performace?
faça tudo em Assembly… agora os custos, tempo, etc…
dai já é outra historia… [/quote]
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:
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