Natural: a linguagem que você pensou que tinha desaparecido
Outro dia, um seguidor deixou um comentário em um dos meus vídeos mencionando que tinha trabalhado muito com Natural e perguntando o que teria acontecido com essa linguagem. Isso me lembrou que, em boa parte dos clientes nos quais atuei, Natural e COBOL eram as principais linguagens de programação dos sistemas corporativos.
No mainframe, diferentes linguagens convivem há muito tempo, cada uma procurando resolver determinados problemas de maneira mais eficiente. Assembler, PL/I, Easytrieve, REXX e Natural são alguns exemplos. Algumas dessas linguagens foram desenvolvidas pela própria IBM. Outras surgiram de empresas independentes e conquistaram espaço nos grandes centros de processamento de dados.
Quando programar em COBOL dava muito trabalho
Na década de 1970, computadores de grande porte já estavam consolidados nas grandes organizações. Bancos, seguradoras, indústrias, empresas de telefonia, órgãos governamentais e grandes varejistas dependiam cada vez mais de sistemas informatizados para sustentar suas operações de missão crítica.
O COBOL era uma das principais linguagens desse universo. Mas havia uma percepção generalizada de que desenvolver aplicações comerciais em COBOL significava escrever uma quantidade considerável de código, mesmo para realizar operações relativamente simples. Essa visão persiste até hoje, mas confesso que nunca concordei inteiramente com ela.
Em COBOL, era necessário definir estruturas de dados, controlar a leitura e a gravação de registros, tratar condições de erro e construir a lógica dos algoritmos com um nível de detalhe que, na opinião de muitos, consumia tempo e aumentava riscos.
Em aplicações transacionais, que dependiam de interação com terminais, o trabalho podia ser ainda mais complexo. Para que o CICS apresentasse uma tela ao usuário, era necessário respeitar convenções e regras de programação nem sempre intuitivas, destinadas a garantir o funcionamento e a estabilidade das aplicações.
Foi nesse contexto que começaram a ganhar espaço ferramentas destinadas a aumentar a produtividade dos programadores. Em vez de exigir que o desenvolvedor descrevesse detalhadamente como o computador deveria executar cada operação, essas ferramentas procuravam permitir que ele expressasse diretamente o que desejava fazer deixando para o compilador, o interpretador ou o ambiente de execução a responsabilidade de resolver os detalhes por baixo dos panos.
Essa ideia ajudou a popularizar o conceito de linguagens de quarta geração, ou 4GL. E foi justamente nesse movimento que surgiu o Natural.
Natural e Adabas: uma promessa irresistível
O Natural foi desenvolvido pela Software AG, empresa alemã fundada em 1969. Sua história está intimamente ligada ao Adabas, um sistema gerenciador de banco de dados lançado na década de 1970 que oferecia uma alternativa aos métodos tradicionais de armazenamento de dados.
Enquanto muitas aplicações COBOL trabalhavam diretamente com arquivos sequenciais, indexados ou com sistemas de gerenciamento de banco de dados relacionais ou hierárquicos, o Adabas fornecia mecanismos próprios para armazenar, localizar e recuperar informações.
E o Natural surgiu para facilitar o desenvolvimento de aplicações oferecendo um nível maior de abstração na codificação de comandos para processar esses dados. A proposta era bastante atraente: permitir que os programadores se concentrassem nas regras de negócio, deixando para a linguagem e seu ambiente de execução boa parte dos detalhes relacionados ao acesso aos dados e à interação com os usuários.
Em um documento institucional de 1980, preservado pelo Computer History Museum, a Software AG afirmava que o Natural poderia reduzir o tempo de desenvolvimento entre 50% e 90% em determinadas aplicações. Era uma afirmação comercial, naturalmente, mas revelava a dimensão da promessa que a empresa fazia a um mercado que precisava acelerar seu “time to market”.
Menos código para fazer a mesma coisa?
Para entender o apelo do Natural, imagine um programa muito simples que precisa localizar todos os clientes de determinada agência e apresentar seus nomes e números de conta.
No COBOL tradicional, usando VSAM, essa lógica poderia ficar assim:
PERFORM UNTIL WS-FIM = 'S'
READ ARQ-CLIENTES NEXT RECORD
AT END
MOVE 'S' TO WS-FIM
NOT AT END
IF CLI-AGENCIA = 1234
DISPLAY CLI-CONTA ' ' CLI-NOME
END-IF
END-READ
END-PERFORM
Em Natural, considerando que os dados estão no Adabas, a mesma operação poderia ser executada com três comandos:
FIND CLIENTES WITH AGENCIA = 1234 DISPLAY CONTA NOME END-FIND
Essa era uma das grandes promessas das linguagens de quarta geração: permitir que o programador se concentrasse mais naquilo que precisava fazer e menos nos detalhes de como executar cada operação.
Mas essa integração tinha um preço.
A produtividade também criava dependências
Uma organização que desenvolvia aplicações em Natural frequentemente utilizava outros produtos e ferramentas da Software AG como Adabas, Complete e Predict.
Com o passar dos anos, esses componentes passavam a definir a própria arquitetura dos sistemas, criando uma dependência tecnológica que tinha consequências financeiras: o clássico “vendor lock-in”.
Uma das críticas ao modelo comercial da Software AG estava relacionada ao licenciamento baseado na capacidade de processamento do mainframe, frequentemente medida em MIPS. Nesse modelo, os custos não dependiam necessariamente da quantidade de transações executadas ou da utilização efetiva dos produtos.
Paradoxalmente, o mesmo Natural que acelerava a construção e manutenção de programas algumas vezes consumia mais mipagem do que uma mesma aplicação escrita em COBOL tradicional. Eu mesmo trabalhei em alguns projetos de migração de Natural Batch para COBOL Batch para diminuir o consumo de MIPS do cliente.
A produtividade no desenvolvimento, portanto, nem sempre se traduzia em menor custo operacional.
Mas uma linguagem não substituiu a outra
O Natural era particularmente atraente para aplicações que exigiam consultas, manutenção de cadastros, geração de relatórios e interação com usuários. O COBOL, por sua vez, já possuía uma enorme base instalada e continuava atendendo a diferentes necessidades de processamento comercial, incluindo aplicações batch e transacionais com vantagens de desempenho em muitos tipos de processamento.
Além disso, COBOL não estava vinculado a um único fornecedor de ferramentas ou sistema gerenciador de banco de dados. E essa diferença é importante. Curiosamente, naquele momento em que vivia o mercado, encontrar um desenvolvedor COBOL era relativamente mais fácil do que encontrar um desenvolvedor Natural de mesmo nível.
Uma linguagem pode oferecer vantagens significativas em determinado tipo de aplicação sem necessariamente se tornar a melhor escolha para todos os sistemas de uma organização.
Mas, afinal, que fim levou o Natural?
O Natural não desapareceu. A linguagem continuou evoluindo e permanece disponível para ambientes IBM z/OS, Linux e outras plataformas.
Mais do que isso, em outubro de 2026, a Software AG anunciou a versão 9.2.5 do Natural para z/OS, acompanhada de novas funcionalidades e ferramentas de integração. Entre as novidades estão o Natural Messaging, que permite a comunicação com IBM MQ, e o Natural API Server, destinado a disponibilizar funcionalidades existentes como APIs REST. A linguagem também recebeu melhorias em seus recursos de programação e operação.
E é interessante observar o que isso representa.
Uma linguagem criada em uma época em que terminais de texto dominavam o acesso aos sistemas corporativos continua sendo utilizada em um mundo de APIs, serviços distribuídos e computação em nuvem. E assim como acontece com o COBOL, nem sempre a estratégia de substituir os programas existentes é a melhor alternativa para as empresas.
Em muitos casos, a melhor opção é permitir que os programas construídos e testados ao longo de décadas continuem executando suas funções, mas possam ser acessados por aplicações desenvolvidas com tecnologias mais recentes.
Por que algumas linguagens sobrevivem?
A permanência de uma tecnologia depende de diversos fatores: o investimento realizado pelas organizações, a estabilidade dos sistemas existentes, a disponibilidade de ferramentas, o custo de substituição e a capacidade de continuar atendendo às necessidades do negócio.
Em muitos casos, um sistema continua funcionando porque foi desenvolvido para resolver um problema que permanece essencial. E, enquanto esse problema existir, substituir sua tecnologia pode não representar uma vantagem econômica ou operacional.
O Natural é um bom exemplo disso. A linguagem nasceu oferecendo uma maneira mais produtiva de desenvolver aplicações corporativas. Conquistou espaço, construiu seu próprio ecossistema e passou a fazer parte de sistemas que continuam importantes para seus usuários.
Hoje, como muitas outras linguagens, já não ocupa o mesmo espaço nas discussões sobre programação que ocupava décadas atrás.
O Natural é mais um exemplo de como frequentemente confundimos uma tecnologia que deixou de ser popular com uma tecnologia que deixou de ser útil.
