“Fiz um curso de COBOL e gostei”

Jeremy Morgan é um desenvolvedor com mais de 20 anos de experiência na construção de aplicações e websites. É especialista em tecnologias como C#, .NET Framework, ASP.NET, .NET Core, MVC, PHP 5, HTML, CSS, Javascript e outras.

Em 2020, com a recupercusão causada pela falta de programadores COBOL nos EUA, resolveu “por pura curiosidade” fazer um curso para conhecer a linguagem e, na sequência, escreveu um artigo em seu blog falando sobre a experiência.

Neste artigo, ele dá uma visão geral sobre o que aprendeu e faz comparações interessantes entre o COBOL e as linguagens que conhece.

Legível

Como tudo é escrito em maiúsculas (o curso que ele fez era baseado em mainframe) parece que o programa está sempre gritando. Mas é perfeitamente legível. Ele também cometa que o ponto no COBOL é o ponto-e-vírgula das outras linguagens, e como pontos são pequenos, às vezes é difícil descobrir onde eles estão faltando.

Sintaxe rígida

Ele já tinha ouvido falar sobre a rigidez sintática do COBOL e comenta que “é preciso ter olhos de águia” para codificar programas nessa linguagem.

Restrições selvagens

O COBOL impõe restrições que lhe parecem anacrônicas em 2020, mas reconhece que isso é causado justamente para garantir a compatibilidade com versões anteriores. Ele comenta, por exemplo, as linhas de código com 80 caracteres e as linhas de relatório com no máximo 132 colunas, resquícios dos tempos dos cartões perfurados e das impressoras de linha de impacto.

Escassez de recursos

Chamou sua atenção o fato do COBOL ter sido projetado com foco na conservação de recursos. Memória, espaço em disco e ciclos de CPU são tratados pela linguagem como se fossem escassos, e por isso precisam ser consumidos “com sabedoria”. Em sua opinião, os desenvolvedores hoje em dia se esquecem o quanto esses recursos eram caros no passado, mas deveriam se preocupar mais com seu consumo.

Você deve ser muito claro

Ele diz que não há muita programação “solta” em COBOL. Tudo o que você codifica precisa ter uma finalidade bem específica, e ele vê isso como uma coisa boa.

O foco é o job

Ficou muito claro para ele que o COBOL foi projetado para executar um trabalho específico, com começo, meio e fim, de cima para baixo. Não é uma linguagem que foi pensada para interações em tempo real, como a maioria que existe hoje. O negócio é ler dados, fazer coisas com esses dados, e gravar outros dados.

Desenvolvedores de hoje em dia podem aprender muito com o COBOL

Jeremy comenta que depois de fazer o curso desenvolveu respeito pela linguagem, que em suas palavras foi projetada para ser uma “pedra sólida” desde o seu nascimento.

Ele cita quatro ensinamentos proporcionados por essa experiência e que todo programador de hoje em dia deveria levar em consideração:

1. Preserve seus recursos: memória, disco e CPU não são de graça. Economize o quanto for possível quando estiver construindo alguma coisa.
2. Seja claro em tudo o que fizer: dedique um tempo para descobrir o que você realmente precisa e só então codifique. Pense em arrays e estruturas ao invés de listas e variáveis espalhadas. O desempenho vem de você saber exatamente o que precisa e quando.
3. Escreva códigos como se eles fossem sobreviver por décadas: para quem programa em COBOL isso é uma verdade. Ele sugere que os desenvolvedores “pensem adiante” e codifiquem como se seu código fosse sobreviver por anos. Como você deve escrever um programa de maneira que ele possa ser mantido por mais tempo?
4. Evite grandes mudanças: desenvolvedores modernos adoram reinventar a roda e introduzir grandes mudanças em tudo o que fazem. O COBOL induz o programador a só fazer grandes mudanças quando elas forem indispensáveis, e segundo Jeremy, “precisamos um pouco mais disso em 2020”.

Conclusão

É interessante observar o ponto de vista de alguém que desenvolveu toda a sua carreira em um ambiente tão diferente, e eu concordo com todas as suas conclusões.

Desde que comecei a trabalhar com open source tenho visto muitos programas em C que mostram que o desenvolvedor não teve (e provavelmente não tem) nenhuma preocupação em fazê-los durar por muito tempo. Muito código solto (às vezes com comentários engraçadinhos dizendo que estão soltos mesmo), muita tag “:to-do” mostrando que o programa foi liberado antes de estar totalmente concluído, nomes de variáveis e funções que não dizem nada, quase nenhuma linha de comentário esclarecedora…

Em COBOL, nos acostumamos a construir sistemas “para a eternidade”. Realmente nós não lançamos uma versão hoje pensando que ela será substituída por algo totalmente diferente daqui a dois anos.

Talvez por isso estamos por aí há mais de sessenta anos.

---