Descubra o que foi/é a Crise do Software.

Do que estou falando? Do caos atrás dos teclados, devido a instabilidade dos primeiros anos da computação com softwares imprecisos e os gastos milionários em CPDS. Esse termo foi cunhado na década de 70 do século passado e até hoje motiva muita discussão entre acadêmicos e profissionais.
Leia na InTEGRA

Bellacosa Mainframe conversa sobre a confusao semantica entre Logica e Paradigma

A Confusão Semântica que Atravessa Gerações de Programadores

Jovem padawan, muitos programadores antes de você ouviram que “lógica de programação” é um tipo de linguagem ou paradigma. Não é. Lógica é a forma de pensar; paradigma é a forma de construir.

A confusão nasceu nas salas de aula, onde simplificar ajuda a começar, mas deixa cicatrizes conceituais. Assim, gerações repetem termos imprecisos sem perceber.

Quando você distingue pensamento algorítmico de modelo estrutural, o código deixa de ser magia e vira engenharia. Entenda isso cedo e evitará debates inúteis, documentação confusa e decisões ruins de arquitetura. 

Clareza conceitual é uma arma poderosa na Força — e também na manutenção de sistemas que precisam sobreviver décadas.

🧠 1) “Lógica de programação” NÃO é um paradigma

“Lógica de programação” é um termo didático.

Ele se refere à capacidade de:

• decompor um problema

• definir passos ordenados

• usar condições e repetições

• estruturar algoritmos

Ou seja: é uma habilidade mental, não um modelo formal de linguagem.

Você pode usar lógica de programação em:

• C

• COBOL

• Python

• Java

• Assembly

• até planilhas 😄

👉 Portanto, lógica ≠ paradigma

---

🏛️ 2) Paradigma procedural é o termo técnico correto

Na teoria da computação, linguagens são classificadas por paradigmas.

O procedural é um deles.

✔️ Paradigma Procedural

Baseia-se em:

• sequência de instruções

• procedimentos / funções

• alteração de estado

• fluxo de controle explícito

Exemplos clássicos:

• C

• Pascal

• COBOL

• Fortran

• PL/I

• ALGOL

👉 Em COBOL, por exemplo, a PROCEDURE DIVISION é a essência procedural.

---

📚 3) Por que o ensino usa “lógica procedural”?

Principalmente por motivos pedagógicos:

🎓 A) Iniciantes não precisam de teoria de paradigmas

É mais simples dizer:

“Vamos aprender lógica de programação”

do que:

“Vamos estudar um paradigma imperativo/procedural”

---

🎓 B) Nem sempre usam uma linguagem “pura”

Cursos iniciais misturam:

• pseudocódigo

• fluxogramas

• Portugol

• Scratch

• Python básico

Fica difícil falar de paradigma formal.

---

🎓 C) O objetivo é aprender a pensar, não a linguagem

Antes de aprender:

• OOP

• Funcional

• Concorrente

• Declarativo

o aluno precisa aprender a resolver problemas passo a passo.

---

⚙️ 4) Relação com o paradigma imperativo

Tecnicamente, procedural é um subtipo de outro paradigma:

👉 Imperativo

Imperativo
   ├── Procedural
   └── Orientado a Objetos

Ambos usam:

• comandos

• estado mutável

• execução sequencial

---

🏆 5) No mundo mainframe isso é muito claro

COBOL clássico é procedural puro:

• fluxo top-down

• parágrafos e seções

• controle explícito

• pouca abstração estrutural

Embora o COBOL moderno suporte OO, a cultura mainframe ainda é fortemente procedural.

---

✅ Conclusão

Dizemos “lógica de programação procedural” por tradição educacional — mas o termo técnico correto é:

👉 Paradigma procedural

Resumo rápido:

• 🧠 Lógica de programação = habilidade de pensar algoritmicamente

• 🏛️ Paradigma procedural = modelo formal de construção de programas

• 🎓 O ensino simplifica a terminologia para iniciantes

COBOL Imperativo, Procedural e Procedural Estruturado

Três fases da mesma linguagem (e três estados de espírito no CPD)

Ao estilo Bellacosa Mainframe, servido quente no El Jefe Midnight Lunch

---

☕ Introdução: o mesmo COBOL, três mentalidades

Quem olha de fora acha que COBOL é tudo igual desde 1959. Quem viveu mainframe sabe: o COBOL mudou — não tanto na sintaxe, mas na forma de pensar.

Imperativo, Procedural e Procedural Estruturado não são dialetos oficiais escritos em pedra. São estágios evolutivos, reflexo direto de:

• Limitações de hardware

• Pressões de negócio

• Maturidade da engenharia de software

Entender essas diferenças é entender por que tanto código legado funciona… e por que outro tanto assombra equipes até hoje.

---

🧠 COBOL no modo Imperativo — o nascimento selvagem

📅 Quando surgiu

Final dos anos 50 e início dos 60, junto com o próprio COBOL.

🎯 Ideia central

“Faça exatamente isso. Agora isso. Agora pule para lá.”

O foco é comando direto. O programa é uma lista de ordens explícitas para a máquina.

🧩 Características

• Uso intenso de GO TO

• Fluxo não linear

• Dependência forte da ordem física do código

• Parágrafos longos e multifuncionais

🧨 Comentário Bellacosa

Era compreensível. Memória era cara, CPU era lenta e ninguém pensava em manutenção a longo prazo.

Funcionou ontem? Então não mexe.

🥚 Easter Egg

Muito código imperativo ainda roda em produção porque ninguém tem coragem de tocar.

---

🧠 COBOL Procedural — organização por rotinas

📅 Quando ganhou força

Anos 60 e 70, com sistemas maiores e equipes crescendo.

🎯 Ideia central

“Organize o programa em procedimentos reutilizáveis.”

Aqui surge a noção clara de rotinas, chamadas e retorno.

🧩 Características

• Uso intenso de PERFORM

• Divisão do programa em parágrafos

• Fluxo mais previsível

• Ainda aceita GO TO (e muita gente abusou)

⚠️ O perigo oculto

Procedural não é automaticamente estruturado.

Você pode ter um código procedural organizado e ainda assim caótico.

🥚 Easter Egg

Parágrafos chamados 9999-FIM ou EXIT-PROG são herança direta dessa fase.

---

🧠 COBOL Procedural Estruturado — quando o COBOL vira engenharia

📅 Quando surgiu

Final dos anos 70 e anos 80, influenciado pela programação estruturada (Dijkstra, Böhm & Jacopini).

🎯 Ideia central

“Fluxo previsível é mais importante que truque de performance.”

Aqui o COBOL ganha disciplina formal.

🧩 Características

• Eliminação prática do GO TO

• Uso sistemático de:

  • IF / END-IF

  • EVALUATE / END-EVALUATE

  • PERFORM UNTIL / END-PERFORM

• Parágrafos pequenos e coesos

• Código que se lê como um roteiro lógico

🏦 Razão de negócio

• Auditoria

• Confiabilidade

• Manutenção por décadas

Bancos e seguradoras exigiram esse padrão.

---

📊 Comparativo rápido

Estilo	Controle de fluxo	Manutenção	Risco
Imperativo	Caótico	Difícil	Alto
Procedural	Médio	Melhor	Médio
Procedural Estruturado	Previsível	Excelente	Baixo

---

🛠️ Passo a passo: migrando o pensamento

1️⃣ Pare de pensar em linhas, pense em fluxo

Pergunte:

• Onde começa?

• Onde decide?

• Onde termina?

2️⃣ Um parágrafo, uma responsabilidade

Se o nome precisa de “E”, “OU” e “TAMBÉM”… está grande demais.

3️⃣ Substitua IFs aninhados por EVALUATE

Mais legível, mais auditável.

4️⃣ Use PERFORM como se fosse chamada de função

Mesmo sem parâmetros formais, o conceito é o mesmo.

---

🔐 Segredos de veterano

🔹 Código estruturado reduz incidentes noturnos.

🔹 Auditor confia mais em código previsível do que em código “esperto”.

🔹 Performance se resolve depois; clareza primeiro.

🔹 Todo sistema legado parece ruim… até você entender o contexto em que nasceu.

---

🧾 Curiosidades de bastidor

• Muitos padrões internos de bancos proíbem GO TO há mais de 30 anos.

• Há programas imperativos mais antigos que seus mantenedores.

• COBOL estruturado influenciou diretamente padrões de codificação em PL/I e até Java.

---

🥚 Easter Eggs do CPD

🕰️ Parágrafos numerados (1000-INICIO) são fósseis vivos.

🐘 Compiladores modernos reclamam de GO TO, mas ainda aceitam — respeito aos ancestrais.

☕ Quanto mais estruturado o código, menos café o time consome em fechamento.

---

✅ Boas práticas Bellacosa Mainframe

✔ Evite GO TO como se fosse vazamento em produção
✔ Prefira clareza a micro-otimização
✔ Nomeie parágrafos com linguagem de negócio
✔ Estruture pensando no próximo mantenedor
✔ Código bom é código explicável

---

🌙 Conclusão: não é sobre sintaxe, é sobre mentalidade

Imperativo, Procedural e Procedural Estruturado contam a história da maturidade do software corporativo.

O COBOL não ficou velho.
Ele ficou responsável.

E no mundo mainframe, responsabilidade é o que mantém sistemas rodando…

sem glamour, sem barulho e sem falhar.

— Bellacosa Mainframe, direto do CPD para o El Jefe Midnight Lunch 🌙