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 🌙

 

COBOL Estruturado: disciplina, elegância e sobrevivência no mundo mainframe

Ao melhor estilo Bellacosa Mainframe, direto dos porões do CPD para o El Jefe Midnight Lunch

---

☕ Introdução: quando o COBOL aprendeu a pensar

Durante décadas, o COBOL foi injustamente carimbado como uma linguagem verborrágica, rígida e cheia de GOTOs selvagens pulando de parágrafo em parágrafo como gremlins em madrugada de fechamento mensal. O COBOL estruturado surge justamente como a vacina contra esse caos.

Mais do que uma evolução sintática, COBOL estruturado é postura, disciplina mental e, acima de tudo, respeito ao próximo programador — normalmente você mesmo daqui a 6 meses.

---

🧠 O que é COBOL Estruturado, afinal?

COBOL estruturado é a aplicação dos princípios da programação estruturada ao COBOL clássico:

• Nada de saltos caóticos com GO TO

• Fluxo lógico previsível

• Blocos com início, meio e fim bem definidos

Ele se apoia em três pilares universais:

1. Sequência – código executado em ordem natural

2. Seleção – decisões claras (IF, EVALUATE)

3. Iteração – repetição controlada (PERFORM UNTIL, PERFORM VARYING)

Se você domina isso, domina qualquer código mainframe.

---

📜 Por que o COBOL estruturado é mais legível?

Porque ele conta uma história.

Compare:

• Parágrafos pequenos e objetivos

• END-IF, END-PERFORM explícitos

• Nomes semânticos (CALCULA-TOTAL, VALIDA-CPF)

O código deixa de ser um labirinto e vira um manual técnico executável.

💡 Dica Bellacosa: se o código parece um romance russo, algo está errado.

---

🛠️ Passo a passo para escrever COBOL estruturado

1️⃣ Planeje antes de codar

Desenhe o fluxo:

• O que entra?

• Quais decisões existem?

• Onde o processamento termina?

2️⃣ Quebre tudo em parágrafos pequenos

Um parágrafo = uma responsabilidade.

Errado:

• PROCESSA-TUDO

Certo:

• LE-ARQUIVO

• VALIDA-DADOS

• CALCULA-VALORES

• GRAVA-SAIDA

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

PERFORM VALIDA-DADOS
PERFORM CALCULA-TOTAL

Isso é COBOL estruturado em sua forma mais pura.

4️⃣ Elimine GO TO (sem dó)

Se você precisa de GO TO, provavelmente:

• O parágrafo está grande demais

• O fluxo está mal pensado

---

🧪 Segredos que veteranos não contam

🔹 Menos é mais: COBOL estruturado prefere muitos parágrafos pequenos a poucos gigantes.

🔹 IF aninhado demais é cheiro de problema: use EVALUATE.

🔹 Comentários explicam o porquê, não o como:

* Validação exigida pelo Bacen após incidente de 2009

🔹 Código bem estruturado envelhece melhor que documentação externa.

---

🧾 Curiosidades de bastidor (fofoca técnica)

• O impulso pela programação estruturada veio forte nos anos 70, após sistemas críticos se tornarem impossíveis de manter.

• Grandes bancos só aceitaram novas rotinas COBOL sem GO TO.

• Há sistemas em produção hoje que seguem padrões estruturados criados nos anos 80 — e funcionam melhor que muito microserviço moderno.

---

🥚 Easter Eggs do mundo mainframe

🕵️‍♂️ Já reparou que muitos sistemas usam parágrafos chamados MAIN-PARA ou 0000-INICIO? Isso é herança direta da transição do COBOL não estruturado.

🐘 Alguns compiladores modernos avisam quando você usa GO TO. É o mainframe te julgando silenciosamente.

☕ Programadores COBOL estruturado costumam dormir melhor em fechamento contábil.

---

✅ Boas práticas Bellacosa Mainframe (anote!)

✔ Um parágrafo não deve passar de uma tela
✔ Nomeie tudo com significado de negócio
✔ Prefira EVALUATE a IF encadeado
✔ Evite variáveis globais desnecessárias
✔ Código deve ser lido como um roteiro lógico

---

🌙 Conclusão: COBOL estruturado não é velho — é sábio

COBOL estruturado é como um bom uísque: não precisa de modinha, precisa de respeito. Ele entrega previsibilidade, estabilidade e clareza — exatamente o que sistemas críticos exigem.

No fim das contas, não é sobre COBOL.
É sobre engenharia, disciplina e responsabilidade.

E como todo bom código mainframe…

Ele não faz barulho. Ele simplesmente funciona.

— Bellacosa Mainframe, servido à meia-noite no El Jefe Midnight Lunch 🌙