Teixeira
(usa Linux Mint)
Enviado em 12/03/2009 - 21:52h
Apenas para definir um pouco mais, eu não diria que Assembly é "difícil", porém "incômodo".
Coisas que já estão prontas em outras linguagens, tem-se de implementar passo a passo no Assembly, ou seja, temos de ensinar o computador a ser um computador...
Nas linguagens de nivel "mais baixo", a produtividade é muito próxima do zero. Principalmente se alguma coisa der errada, pois é bastante difícil entender as formas de raciocínio de cada programador.
Quanto ao Cobol, hoje em dia pode-se aumentar a produtividade através de ferramentas específicas como RADs e GUIs, por exemplo, além de editores melhores que os de antigamente - e nessse quesito até mesmo o Notepad do Windows (tido como muito simples) é infinitamente melhor que os editores da época áurea daquela linguagem.
A oportunidade de ouro para se ganhar dinheiro com a manutenção de sistemas em Cobol foi no final dos anos 90, até o final do ano de 2000.
Muita gente ganhou um bom dinheiro com a falta de previsão de nossos antepassados que não previram que as datas após 2000 voltariam para 1900.
E olha que não era assim tão difícil fazer tal correção. Apenas que o grau de responsabilidade envolvida era extremamente alto.
Aquela chatice de "sections" e "divisions" dá para tirarmos de letra e nos concentrarmos no código em si.
Outra coisa chata eram os níveis de identação, pois os compiladores eram muito "caxias" e não admitiam nenhuma discrepância.
Mesmo porque, a mídia dos programas em Cobol era quase sempre os tais cartões perfurados...
Para termos um programa em Cobol, tínhamos um Analista de Sistemas (com sua secretária), um ou mais programadores, uma perfuradora, uma conferente, e um operador.
Se desse algum problema, essa turma toda entrava na dança. Outra vez.
O Cobol "moderno" (com o uso de ferramentas modernas) pode ser uma linguagem MUITO mais fácil de se aprender do que o C e suas derivadas, ou Python, ou Java, por exemplo.
E os programas serão sensivelmente menores e mais rápidos, além do que não precisamos de um time ou de uma tribo inteira para o desenvolvimento.
Resta saber se realmente vale a pena fazê-lo.
Para alguns vale, e muito, mas para outros não.
Hoje em dia não tenho nenhum cliente que use Cobol ou Assembly, embora alguns ainda tenham sistemas de gerenciamento completos em Clipper ou mesmo em MUMPS (agora chamado de "Tecnologia M") ou Paradox (da Borland).
Acho que o banco de dados que menos ocupa espaço é o do Mumps, com campos de tamanho variável e tendo um ponto-e-vírgula (;) como delimitador.
Os arquivos do Cobol têm tamanhos previamente fixados para os campos e por isso são altamente perdulários. Dá o maior trabalho ajustar esse valor posteriormente.
E são de acesso sequencial, afinal de contas. Mas claro que podem ser indexados (mais ou menos isso).
Hoje em dia os bancos de dados lidam muito bem com seus índices, mas na época do Cobol isso era feito ou pelo próprio programador (se fosse realmente competente e criativo), ou através de uma técnica pronta chamada "ISAM" que dava ensejo a mais um - caríssimo - curso de aprendizado.
Para que se tenha uma idéia do que era a "computação" naquela época, uma "linguagem" que sustentou altos salários de muitos foi a RPG2 (Report Program Generator 2) que, afinal de contas, era assim um tipo do que é o "Chrystal Reports" - apenas um gestor de relatórios impressos.
Acho que o ponto fraco do Cobol não é a verborragia, mas o formato engessado de seus arquivos.
