Hoje publicamos a segunda parte da tradução de material sobre matemática, sobre COBOL e por que esse idioma ainda está vivo.
→
A primeira parteTaxa de recorrência de Müller e COBOL
Vamos dar uma olhada em como o COBOL lida com a relação de recorrência de Müller. Aqui está um programa COBOL que implementa a relação de recorrência que estamos estudando.
IDENTIFICATION DIVISION. PROGRAM-ID. muller. AUTHOR. Marianne Bellotti. DATA DIVISION. WORKING-STORAGE SECTION. 01 X1 PIC 9(3)V9(15) VALUE 4.25. 01 X2 PIC 9(3)V9(15) VALUE 4. 01 N PIC 9(2) VALUE 20. 01 Y PIC 9(3)V9(15) VALUE ZEROS. 01 I PIC 9(2) VALUES ZEROS. PROCEDURE DIVISION. PERFORM N TIMES ADD 1 TO I DIVIDE X2 INTO 1500 GIVING Y SUBTRACT Y FROM 815 GIVING Y DIVIDE X1 INTO Y MOVE X1 TO X2 SUBTRACT Y FROM 108 GIVING X1 DISPLAY I'|'X1 END-PERFORM. STOP RUN.
Se esta é a primeira vez que você vê um programa escrito em COBOL, vamos esclarecer algumas coisas imediatamente. Em primeiro lugar, é o chamado "formulário livre" COBOL, que foi introduzido em 2002 para aproximar o COBOL de como as linguagens modernas são estruturadas. Tradicionalmente, o código COBOL tem uma largura fixa quando determinadas entidades são colocadas em determinadas colunas. A idéia de considerar o código na forma de uma estrutura na qual as linhas e colunas são destacadas pode parecer estranha, mas essa estrutura de código foi projetada para simular a formatação do cartão perfurado. Nos dias de COBOL, os programas foram criados dessa maneira. Um cartão perfurado possui 80 colunas - determinadas colunas são para determinados dados. A mesma abordagem é tradicional para o COBOL.
A coisa mais importante neste código, algo que talvez atraia mais atenção, é como as variáveis são declaradas aqui:
01 X2 PIC 9(3)V9(15) VALUE 4.
O código
01 no início da linha é chamado de número do nível. Ele diz ao COBOL que estamos declarando uma nova variável. O COBOL permite vincular ou agrupar variáveis (um exemplo clássico é um endereço que pode incluir os nomes das ruas, cidades e países como variáveis separadas); como resultado, nesse caso, o número do nível se torna importante.
X2 é o nome da variável - tudo é bem simples. No final, há uma construção que define o valor inicial da variável, que se parece com "
VALUE 4. " O ponto no final não é um erro de digitação. Essa é uma maneira de terminar as linhas no COBOL.
Agora, precisamos apenas considerar o que está no meio da linha - a construção do
PIC 9(3)V9(15) .
PIC é um pouco um operador para descrever um tipo de dados de caractere. Pode armazenar valores alfanuméricos. Pode até armazenar números decimais. COBOL é um idioma com tipagem estática estrita e com um recurso incomum, que é que a maioria dos tipos de COBOL é muito mais flexível que os tipos em outros idiomas. Além disso, ao declarar variáveis, você deve especificar quantos caracteres eles podem consistir. No nosso caso, esse é o número entre parênteses. A construção do
PIC 9(3) significa que uma variável pode armazenar três caracteres, que são números (indicados pelo número
9 ).
Como resultado, a construção
9(3)V9(15) deve ser lida da seguinte forma: "3 dígitos, seguidos por um ponto decimal (v), seguidos por outros 15 dígitos".
Aqui estão os resultados deste programa:
01|004.470588235294118 02|004.644736842105272 03|004.770538243626253 04|004.855700712593068 05|004.910847499165008 06|004.945537405797454 07|004.966962615594416 08|004.980046382396752 09|004.987993122733704 10|004.993044417666328 11|005.001145954388894 12|005.107165361144283 13|007.147823677868234 14|035.069409660592417 15|090.744337001124836 16|099.490073035205414 17|099.974374743980031 18|099.998718461941870 19|099.999935923870551 20|099.999996796239314
Isso aconteceu usando números com 15 casas decimais. Se
PIC9(3)V9(25) as propriedades das variáveis
X1 ,
X2 e
Y para
PIC9(3)V9(25) , podemos seguir em frente:
01|004.4705882352941176470588236 02|004.6447368421052631578947385 03|004.7705382436260623229462114 04|004.8557007125890736342050246 05|004.9108474990827932004556769 06|004.9455374041239167250872200 07|004.9669625817627006050563544 08|004.9800457013556312889833307 09|004.9879794484783948244551363 10|004.9927702880621195047924520 11|004.9956558915076636302013455 12|004.9973912684019537143684268 13|004.9984339443572195941803341 14|004.9990600802214771851068183 15|004.9994361021888778909361376 16|004.9996648253090127504521620 17|004.9998629291504492286728625 18|005.0011987392925953357360627 19|005.0263326115282889612747162 20|005.5253038494467588243232985
Mainframes diferentes oferecem limites superiores diferentes para tipos de dados COBOL. Na IBM (pelo menos - no meu caso), são 18 dígitos. O MicroFocus possui 38 dígitos.
Quanto custa a precisão?
Tudo o que acabamos de falar visa mostrar que o COBOL realiza cálculos não melhores do que outras linguagens de programação mais comuns. Devido a restrições no tamanho dos números de ponto fixo, o COBOL pode ser inferior aos idiomas que dão ao desenvolvedor mais controle sobre o que está acontecendo.
Mas há um recurso. O fato é que o Python (e Java) não tem suporte interno para números de ponto fixo. E no COBOL esse suporte é.
Para executar cálculos de ponto fixo em Python, tive que importar o módulo
Decimal . Se você já trabalhou com um projeto que possui vários comandos de importação, saiba que cada um desses comandos tem um determinado "preço". Em linguagens como Java (ou seja, essa linguagem é geralmente considerada por quem se livra do COBOL), o "preço" de uma biblioteca adequada pode ser significativamente
maior . De fato, é uma questão de saber se o "custo" de importar bibliotecas desempenha algum papel em seu projeto. Para muitos programadores, pensar no impacto no desempenho que os comandos de importação têm é o auge da otimização prematura.
Mas os programadores da COBOL geralmente trabalham em sistemas que precisam processar milhões e, possivelmente, bilhões de operações por segundo, fazendo-o com precisão e confiabilidade. E, infelizmente, é muito difícil apresentar um argumento convincente para a COBOL ou contra esse cenário, uma vez que essa é, de fato, uma área de inúmeras variações. O suporte a ponto fixo incorporado ao COBOL é um fator determinante na escolha de um idioma para resolver esses problemas? Ou talvez os problemas correspondentes possam ser resolvidos escolhendo a combinação certa de processador, memória e sistema operacional? Ou, talvez, para resolver problemas de cálculos rápidos, precisos e confiáveis, você precisa recorrer à "dança com um pandeiro"? Talvez - limitaremos o raciocínio? Vamos reduzi-los a encontrar uma resposta para uma pergunta como "Qual é melhor - COBOL ou Java se você usar o mesmo hardware?". Mas, mesmo assim, será difícil para nós avaliar como as deficiências de cada um dos idiomas afetarão o desempenho no momento em que o sistema começar a executar os bilhões de operações acima mencionados por segundo. Como resultado, podemos apenas dizer que o mesmo COBOL e Java são apenas linguagens muito diferentes.
Aqui está o que eles escrevem sobre isso
aqui , explorando o desempenho do código Java traduzido do código COBOL.
COBOL é uma linguagem compilada que usa uma pilha que suporta ponteiros e junções. A conversão de tipo não cria uma carga no sistema durante a execução do programa. Não há agendamento ou conversões de tipo durante a execução do programa. O código Java, por outro lado, é executado em uma máquina virtual. Ele usa um monte e não suporta junções. A conversão de tipo coloca uma pressão no sistema durante a execução do programa. Java usa despacho dinâmico e inferência de tipo em tempo de execução. Embora seja possível minimizar a quantidade de uso desses recursos, isso geralmente leva ao fato de o código ser mais ou menos "diferente" do código Java comum. Ao estudar os resultados da tradução do código Java do COBOL, eles geralmente reclamam que o código é ilegível e não é suportado. Isso nega a maioria dos objetivos de mudar de COBOL para Java.
Antes de decidir deixar de lado essas considerações com a frase "Sim, mas é Java, e Java também não é um presente" - lembre-se: a maioria das linguagens de programação modernas não tem suporte interno para cálculos de ponto fixo. (Eu acho que seria mais correto dizer que nenhuma das línguas modernas suporta isso, mas não posso verificar isso de forma confiável.) Obviamente, você pode escolher outro idioma que tenha seu próprio conjunto de vantagens e desvantagens, mas se a precisão for necessária nos cálculos com um ponto fixo e se você acha que uma pequena perda de desempenho ao importar uma biblioteca que implementa esses cálculos pode prejudicá-lo, isso significa que você tem a única opção - COBOL.
É por isso que a chamada “modernização” é tão complexa: depende de muitos fatores. Algumas organizações receberão resultados tangíveis de investimentos na mudança da plataforma de software, enquanto outras descobrirão que perderam algo importante em troca de "melhorias" que, de fato, não melhoram muito. Se uma organização é uma grande instituição financeira que processa milhões de transações a cada segundo e precisa de precisão decimal dos cálculos, então, na verdade, será mais barato treinar especialistas no trabalho com COBOL do que pagar recursos e produtividade para migrar para um idioma mais popular. Afinal, a popularidade é temporária.
Sumário
Como resultado, falando sobre por que tantas organizações ainda usam o COBOL, é necessário entender que a tarefa de processar os programas é diferente da tarefa de criar programas. Os programadores que criaram a solução tiveram a vantagem de sua implementação em fases. Os aplicativos geralmente se esforçam para chegar o mais próximo possível dos limites dos recursos que suas tecnologias suportam. O dilema referente à migração do COBOL não é uma questão de mudar de um idioma para outro. Essa é a tarefa de passar de um paradigma para outro. Os limites do Java ou Python no Linux não são iguais aos limites do COBOL no mainframe. Em alguns casos, os aplicativos COBOL são capazes do que as linguagens modernas não podem. Nesses casos, o uso do COBOL em um mainframe moderno será, de fato, uma solução mais barata, produtiva e precisa.
Caros leitores! Você acha que o COBOL é realmente uma linguagem que, em algumas situações, se mostra realmente melhor do que as linguagens mais modernas?
