O registro do avô de que COBOL estava “morto” havia muito tempo
(wumpus-cave.net)- Um artigo publicado em junho de 1992 na revista Technical Support já declarava a morte do COBOL, mas o ponto central é que, mesmo 30 anos depois, a linguagem ainda não desapareceu por completo
- A maioria dos termos da moda da época, como 4GL, não durou muito, mas o COBOL permaneceu por mais tempo do que muitas alternativas posteriores
- O fator decisivo que manteve o COBOL em funcionamento foi o problema do Y2K, e a resposta real exigiu treinar uma nova geração de programadores COBOL
- Uma linguagem que já teve uma grande base instalada pode ser mantida com uma cauda longa, em que o número de novos aprendizes diminui, em vez de desaparecer de repente
- O avô do autor morreu em 1º de setembro de 2024, aos 91 anos, e o texto sobrepõe uma lembrança pessoal a antigas previsões tecnológicas
A declaração de “COBOL morto” já feita em 1992
- O avô do autor publicou, em junho de 1992 na revista Technical Support, um artigo declarando a morte do COBOL
- O texto da época menciona termos próprios daquele período, como 4GL, e o autor acrescenta que o COBOL sobreviveu por mais tempo do que muitos dos exemplos de 4GL listados na Wikipedia
- O texto original está preservado no arquivo da NaSPA: http://www.naspa.net/magazine/1992/t9206003.txt
- O artigo de 1992 separa os sentidos da palavra “dead” e trata o COBOL como uma espécie de zumbi: morto, mas não desaparecido
- Autocoder também é apresentado como antecessor do COBOL e comparado como um caso de linguagem considerada morta, mas da qual alguns vestígios ainda podem restar
A longa vida do COBOL criada pelo Y2K
- Um grande fator que manteve o zumbi COBOL em movimento foi o problema do Y2K
- Na época, ele teve grande cobertura no noticiário e depois pareceu que nada havia acontecido, mas, na prática, foi um problema gigantesco
- O processo de resposta exigiu treinar uma nova geração de programadores COBOL
- Esse processo pode ter contribuído para manter o COBOL por mais tempo
- O autor hoje quase não usa a expressão dead para linguagens de programação
- Uma linguagem que já teve uma grande base instalada dificilmente morre por completo
- Em vez disso, deixa uma cauda longa que vai se tornando mais tênue à medida que novos programadores deixam de aprendê-la
Um episódio da história da tecnologia que leva a uma lembrança pessoal
- O avô do autor morreu em 1º de setembro de 2024, aos 91 anos
- A causa oficial da morte foi pneumonia
- A avó havia morrido em abril daquele ano, e o avô pediu para não receber tratamento
1 comentários
Opiniões do Hacker News
O texto menciona 4GL, um termo que eu não ouvia há muito tempo
O COBOL também prometia que, por “parecer uma frase legível por humanos, não seria mais preciso ter programadores”, o que lembra as plataformas low-code atuais ou código gerado por LLMs
O problema é que uma pessoa comum normalmente não consegue explicar e decompor o problema com detalhes suficientes para se chegar a uma solução que funcione. Se ela consegue fazer esse processo, no fim das contas acaba se tornando programadora, e a principal lição do COBOL é que a razão pela qual programadores são necessários não está apenas na interface do computador ou na linguagem
A ideia era mais permitir que alguém que conhecesse bem os processos de negócio pudesse transcrevê-los para COBOL sem precisar aprender muito sobre o funcionamento do computador, algo parecido com analistas ou profissionais de dados conversando com bancos de dados por meio de SQL
COBOL e 4GL tinham como principal objetivo construir aplicações de negócio como folha de pagamento, bancos, RH e estoque, com foco especial em processamento em lote para reduzir trabalhos repetitivos em massa, como liquidações
Como era um produto de uma época sem DBMS dedicados, a organização de arquivos e os verbos relacionados a arquivos eram muito desenvolvidos, e há partes que lembram o SQL de hoje
Mesmo que o LLM gere magicamente uma solução, a responsabilidade de expressar o problema de forma concisa e precisa apenas sobe um nível
No fim, você “programa” por prompts e revisa o código, que é o resultado formalizado sugerido pelo LLM. A natureza da programação pode mudar para engenharia de prompt, mas a necessidade de entender código como linguagem formal continua existindo
O texto diz que 4GL estava na moda no começo dos anos 1990, mas duvido que isso fosse verdade também fora dos mainframes. O movimento 4GL foi fortemente orientado a mainframes desde o início, e até a Wikipédia menciona como objetivo inicial reduzir o número de cartões perfurados necessários para um programa
Em 1992, o Linux já havia surgido, o trabalho em Python estava em andamento, Perl estava ganhando popularidade e Haskell já tinha suas primeiras versões. A fronteira tecnológica estava se deslocando de workstations caras para PCs de consumo, e acredito que os projetistas de linguagens não estavam muito conscientes do conceito de 4GL mesmo quando criavam coisas que, no fim, podem ser vistas como 4GL, como dBase, HyperTalk e AppleScript
Concordo que texto parecido com linguagem natural é uma má ideia para a maioria dos usos de programação, mas não acho que tenha sido só por isso que o movimento 4GL fracassou. A maioria das 4GLs nem era mais parecida com linguagem natural do que o COBOL, que era uma 3GL
O problema maior foi que o movimento 4GL não conseguiu definir direito o que era a nova geração nem o que seria útil. A 2GL trouxe a tradução de assembly para linguagem de máquina, a 3GL trouxe a mudança revolucionária da compilação, mas a mudança ao menos definível na 4GL era algo como “vamos colocar dentro da linguagem mais funcionalidades que antes ficavam em rotinas externas ou bibliotecas”
Essa abordagem funcionou bem em linguagens específicas de domínio, e por isso surgiram 4GLs bem-sucedidas como SQL, R e MATLAB. Por outro lado, acho que o conceito de uma 4GL de uso geral estava fadado a resultar em uma linguagem excessivamente inchada
Hoje, quase ninguém consegue ou precisa fazer esse tipo de coisa
Neste contexto, Scala vem à mente. Pela forma como o texto descreve COBOL, acho que Scala também está, na prática, perto de estar morto
Ainda há muitas empresas e serviços com componentes centrais escritos em Scala, mas o interesse em novos projetos caiu bastante
Entre 2012 e 2014, parecia que eu via o tempo todo no HN artigos do tipo “fazendo X com Scala”, mas agora quase não aparecem. Talvez seja um fenômeno natural e inevitável, mas é uma pena, porque Scala tinha pontos fortes que outras linguagens mainstream ainda não conseguiram cobrir
Há projetos bastante importantes para o ecossistema da empresa, como sistemas de teste, e os engenheiros que criaram esses sistemas no passado hoje, em sua maioria, viraram executivos de alto escalão
Alguns ainda defendem a escolha tecnológica daquela época, mas outros mostram uma postura mais aberta quando têm a chance de olhar para trás. Em geral, a sensação é que, se Kotlin existisse na época ou se Swift fosse utilizável para serviços de backend, eles não teriam escolhido Scala
https://redmonk.com/sogrady/2024/09/12/language-rankings-6-2...
A euforia inicial esfriou, mas tudo bem. Toda linguagem tem ciclos de hype, e as previsões geralmente erram. Hoje, é difícil uma linguagem de programação mainstream morrer como COBOL
Dizem que Java vai morrer desde 2001, mas ela sobreviveu à bolha das pontocom, ao .NET, ao P do LAMP, ao Ruby, ao JS e ao Go. Também disseram que Python morreria na transição para a versão 3, quando as pessoas estavam migrando para Ruby
Scala é a linguagem de programação funcional mais popular do mundo, tem boas ferramentas e bibliotecas, e vejo Scala 3 como uma excelente atualização
Em certo momento foi enorme e parecia estar em todos os lugares, mas agora está sendo empurrado cada vez mais para nichos. Assim como COBOL, ainda há muito código Perl em uso no mundo real
Jack Henry, SiriusXM, Starbucks, os serviços de streaming da Disney e a Capitol One também vêm criando novos projetos em Scala na área de serviços, não de ciência de dados, de cinco anos para cá até hoje
Claro que há muitas outras equipes, mas só citando os nomes conhecidos que vêm à mente de imediato já dá para ver que é difícil dizer que morreu
Dito isso, parece que as vagas ligadas a frameworks centrados em Play e Akka, e trabalhos em Spark puro que não sejam Airflow, estão diminuindo. Acho que esses eram apenas empregos de frameworks surgidos no ecossistema Scala, e muitas vezes Scala em si era algo secundário
Gosto de Scala, mas ela sempre foi uma linguagem periférica, enquanto COBOL realmente estava em todos os lugares
Algum dia, acho que preciso sentar e mexer diretamente em linguagens legadas como Fortran, COBOL, Ada e APL
Elas claramente perderam popularidade, mas ainda são usadas em lugares importantes
Ao mesmo tempo, também me vem à cabeça a quantidade gigantesca de código Java. Para o bem ou para o mal, Java praticamente engoliu o espaço corporativo; fico me perguntando se, daqui a 30 ou 40 anos, haverá algum motivo para só aposentados usarem Java para manter sistemas bancários antigos
Também deve ter a ver com o fato de serem bases de código ou plataformas enormes e monolíticas. A linguagem não é obscura nem difícil; só há código demais cuja estrutura não é muito visível
Acho que ela vai manter algo como 0,05% do mercado pelos próximos 100 anos
No entanto, nos últimos anos, a maior parte do código novo tem sido escrita em Kotlin
Pessoalmente também tenho apego a ela: nos anos 90, usei de fato em PCs na empresa. O trabalho era descobrir como inserir os dados e, no fim, escrevi uma rotina que tratava números de ponto flutuante como vetores de 1s e 0s, alterando bits para converter do formato da Microsoft para o formato IEEE
Claro, isso foi na época em que eu usava uma cebola presa ao cinto
Se eu fosse fazer simulações numéricas puras, acho que preferiria Fortran a C++ ou Python. Exceto pelo NumPy, claro, mas o próprio NumPy no fim depende de Fortran e C++
Na Carolina Code Conference 2025, ainda estamos procurando palestrantes sobre COBOL
Especialmente agora que o GnuCOBOL foi atualizado recentemente, há algum tempo eu queria incluir uma palestra sobre COBOL
https://gnucobol.sourceforge.io/
https://carolina.codes
“Não sei como será a linguagem do ano 2000, mas seu nome será Fortran.” —Tony Hoare
Pode-se dizer que COBOL está vivo porque continuou mudando ao longo das eras. O COBOL moderno é bem diferente do COBOL dos anos 1950 que as pessoas instintivamente imaginam quando ouvem esse nome
É parecido com se Java fosse chamado de algo como Algol-94 e, por isso, disséssemos que ainda programamos em Algol
MULTIPLY A BY B GIVING C ON SIZE ERROR STOP RUN.<https://dtss.dartmouth.edu/sciencearticle/index.html>
O COBOL não morreu, mas é difícil de acessar, porque há pouquíssimas ferramentas open source que possam ser usadas no Linux
Na OCamlPro, foi iniciado um projeto chamado SuperBOL para criar um ambiente open source em torno do compilador open source GnuCOBOL. O GnuCOBOL já é maduro e também é usado por empresas
Já foi publicada uma extensão para VSCode com LSP para COBOL, oferecendo uma experiência moderna de IDE, e outras ferramentas estão em desenvolvimento conforme as demandas dos clientes
Dá para aprender COBOL em um ou dois dias, e eu gostaria de fazer trabalho “entediante” em COBOL, mas não tenho experiência com mainframe
https://gnucobol.sourceforge.io/
https://cobolworx.com/pages/cobforgcc.html
Como sempre, esse tipo de discussão depende de como se define “morto” e “vivo”
Se uma tecnologia pode ser chamada de morta quando novos negócios já não são mais construídos sobre ela, então não há problema em considerar o COBOL morto. O mesmo vale para o IBM 390x, isto é, a plataforma Z/OS, que costuma ser usada quase como uma representação do COBOL
Por outro lado, se algo é considerado vivo quando ainda é usado em ambientes operacionais, então o COBOL obviamente está vivo, e está muito mais vivo do que muitas tecnologias mais jovens que ele
Mas não é necessário encarar isso como uma vantagem do COBOL ou do ecossistema de mainframes. Organizações tendem a continuar presas ao que funcionou bem pela primeira vez, e em lugares que foram protagonistas da digitalização inicial, como governos, bancos e companhias aéreas, essa primeira escolha geralmente foi um mainframe IBM e o software rodando sobre ele
Nosso mainframe processa tranquilamente 100 milhões de transações por hora. Além disso, a maioria é síncrona, e cada transação leva a várias transações SQL
Consistência eventual também é uma abordagem, mas combina muito mal com o setor financeiro, e é bem provável que também seja o caso em áreas militar, de seguros, médica e de saúde. Também é possível dividir o trabalho em partições, mas surgem problemas de consistência quando se cruza o limite entre shards
O COBOL ainda não morreu, mas está caminhando lentamente nessa direção. Não conheço nenhum banco que não esteja trabalhando ativamente para sair dos mainframes. Ainda assim, as previsões que vi dizem que mainframes e COBOL permanecerão pelo menos até 2050
Ou seja, isso significa usar código COBOL pelos próximos 26 anos. Programadores COBOL são bastante demandados e costumam ser bem remunerados, então mesmo começar uma carreira como programador COBOL agora poderia preencher quase uma vida inteira de trabalho
A barreira de entrada sempre foi extremamente alta, e os principais clientes da época também eram seguradoras antigas, bancos, governos e afins. Foi mais a partir dos minicomputadores que passou a ser possível uma empresa nova usar computação
Nesse sentido, não mudou muita coisa, e, considerando o mercado-alvo do produto, não acho adequado usar “novos negócios usam?” como critério para julgar se uma plataforma está viva ou morta
Uma nova unidade de negócios ou uma equipe interna de startup, por exemplo uma nova categoria de produto de seguros, pode acabar escrevendo parte em COBOL se precisar se integrar ao restante dos sistemas do banco
No mínimo, mesmo que não escreva diretamente em COBOL, ela pode ser colocada na infraestrutura existente de execução COBOL, isto é, sobre Z/OS, por não haver orçamento para comprar um novo rack x86 e contratar pessoas para administrá-lo
A nuvem é o novo mainframe, mas em uma versão pior. Tem todas as desvantagens e não tem a maior vantagem
Antigamente, com CICS, era possível criar serviços muito estáveis e de alto desempenho, e chamar outros serviços dentro da mesma transação. A plataforma cuidava de tarefas complexas, como manter a integridade dos dados
Tente escrever AWS Lambda chamando umas às outras dentro da mesma transação e a diferença fica evidente
E não entendo por que o termo de comparação é “AWS Lambda chamando umas às outras dentro da mesma transação”. Deploy em mainframe também era tão simples quanto jogar um
.zipcom código em uma API à qual o desenvolvedor recebeu acesso?Alguns interpretaram como se eu estivesse escolhendo ou preferindo COBOL em vez de linguagens modernas e me criticaram, mas não foi isso que eu quis dizer. Foi apenas uma observação no estilo advogado do diabo, olhando de fora da caixa.
Ironicamente, já existia em COBOL uma linguagem segura em relação à memória e estável, mais fácil de ler e entender do que Rust. Mas, como ninguém quer usá-la, virou uma linguagem “morta”, enquanto os sistemas que tornaram o mundo moderno possível rodam em cima dela.
Por exemplo, se compararmos um código em Rust e um em COBOL que recebem um número e imprimem se ele é par ou ímpar, o COBOL é lido de forma mais direta.
Não sei se entrega o mesmo nível de desempenho, se se integra da mesma forma com código nativo de outras linguagens, se tem um gerenciador de pacotes usável sobre um sistema de módulos que ajude na composição e na compatibilidade retroativa, ou se permite expressar convenientemente formatos de dados e erros como os tipos algébricos de dados do Rust.
Assim como há motivos para COBOL ainda ser usado, também há bons motivos para novas linguagens terem sido criadas.
Se você acrescentar o boilerplate realmente necessário e criar um programa COBOL executável, ele imprime “even” para a entrada
abce “odd” para a entrada12.Também é curioso implicar especificamente com a sintaxe do Rust. Como a maioria das linguagens atuais, Rust tem em geral uma sintaxe da família C, com alguns elementos de OCaml misturados. Independentemente da sintaxe, Rust e COBOL têm objetivos muito diferentes, então “vamos simplesmente usar COBOL” não elimina a razão de existir do Rust.
https://www.ibm.com/docs/en/cobol-zos/6.2?topic=statement-ex...
Aparecem códigos como
ALLOCATE, definição de endereço de ponteiro eFREE.Esse tweet é estranhamente bom.
https://x.com/grauhut/status/1000017084435312642
Traduzindo, o conteúdo é: “Encontrei COBOL em um cliente. Tudo bem. É um mainframe. Nada de especial. O último comentário era de 1985. A autora era minha mãe.”