Visão Geral dos Algoritmos

Os primeiros computadores eletrônicos (anos 40) eram programados diretamente em binário — sequências de 0 e 1 que o processador entende como instruções.

Linguagem de máquina

Cada CPU tem um conjunto de instruções próprio. Uma instrução pra somar dois números pode ser algo como 10110000 01100001. Programar assim é tedioso e propenso a erro — qualquer bit trocado quebra o programa.

Assembly

Veio em seguida como uma camada fina por cima do binário. Em vez de 10110000, você escreve MOV AL, 61h. Cada instrução Assembly corresponde a uma instrução de máquina (relação 1:1), mas com nomes legíveis (mnemônicos).

; soma dois números em Assembly x86
MOV AX, 5      ; coloca 5 no registrador AX
ADD AX, 3      ; soma 3 ao AX
; AX agora vale 8

Ainda é colado no hardware: você precisa saber quais registradores existem, como a CPU lê memória, etc. Não tem if, não tem for, não tem função — só JUMP (pular pra outro lugar do código).

Anos 50 e 60. O custo de programar em Assembly era altíssimo — cada projeto reinventava a roda. Surgem as linguagens de alto nível: você escreve algo próximo da matemática e um compilador traduz pra Assembly.

A revolução do ALGOL

Quando alguém pergunta "onde foram criados os for, while, if, e funções?" — a resposta é ALGOL 58/60. Antes dele, o controle de fluxo era feito com GOTO (pular pra um número de linha). ALGOL inventou:

• Blocos de código com BEGIN/END (depois viraria { } no C)
• Estruturas de controle: if-then-else, for, while
• Funções e procedimentos com parâmetros e recursão
• Escopo léxico de variáveis

Programação estruturada (1968)

Edsger Dijkstra publica "Go To Considered Harmful" — um manifesto contra o uso de GOTO. Defende que todo algoritmo pode (e deve) ser escrito apenas com sequência, seleção (if) e repetição (loops). Esse paradigma ficou conhecido como programação estruturada e dominou os anos 70/80.

A parada no C

O C (Dennis Ritchie, 1972) consolidou tudo isso numa linguagem prática e portátil. Sintaxe enxuta, performance perto do Assembly, e a possibilidade de escrever sistemas operacionais inteiros (Unix). Java, JavaScript, Python, C# — todas herdam sintaxe do C.

// um algoritmo estruturado em C — soma de 1 a N
int somatorio(int n) {
    int total = 0;
    for (int i = 1; i <= n; i++) {
        total += i;
    }
    return total;
}

Em 1968, Donald Knuth começa a publicar The Art of Computer Programming — uma série de livros que formaliza algoritmos como disciplina científica. A pergunta deixa de ser "esse código funciona?" e passa a ser "esse código é eficiente?".

Estruturas de dados clássicas

Diferentes formas de organizar dados na memória, cada uma boa pra um tipo de operação:

Big O — medindo "rápido" e "lento"

Notação que descreve como o tempo cresce conforme o input cresce, ignorando constantes. É o vocabulário universal pra dizer se um algoritmo escala.

Ordenar 1 milhão de itens com BubbleSort (O(n²)) leva minutos; com QuickSort (O(n log n)) leva milissegundos. Mesmo input, mesma máquina — só muda o algoritmo.

A história costuma ser contada como uma linha reta: máquina → estruturada → orientada a objetos. Mas a evolução foi vários paradigmas em paralelo, cada um resolvendo o problema do seu jeito.

O retorno do funcional

Por décadas, OO dominou. Mas a partir de 2010 o estilo funcional voltou forte — Java 8 ganhou lambdas e Stream, JavaScript adotou map/filter/reduce, Kotlin e Scala misturam OO com funcional.

// estilo procedural
int total = 0;
for (Pedido p : pedidos) {
    if (p.isPago()) {
        total += p.getValor();
    }
}

// estilo funcional (Java 8+)
int total = pedidos.stream()
    .filter(Pedido::isPago)
    .mapToInt(Pedido::getValor)
    .sum();

Os dois fazem a mesma coisa, mas o segundo expressa a intenção, não o passo a passo. É a mesma onda do SQL — você diz "me dá os pagos", não "percorra a lista um por um".

Conforme os sistemas cresceram (anos 80/90), ficou claro que escrever um algoritmo que funciona não basta — ele precisa ser legível, testável e modificável. Surgem livros e movimentos focados em qualidade de código.

O que mudou na cabeça do programador

Antes: "se compila e roda, tá bom". Depois: código é lido 10x mais vezes do que escrito — e o leitor é você daqui a 6 meses, ou um colega novo. O algoritmo continua sendo o mesmo, mas como ele é expresso ganha tanta importância quanto se ele funciona.

// "funciona" mas é difícil de ler
public boolean v(User u) {
    return u != null && u.s == 1 && u.t > 0;
}

// Clean Code — o nome conta a história
public boolean isUserActive(User user) {
    return user != null
        && user.getStatus() == STATUS_ACTIVE
        && user.getRemainingTokens() > 0;
}

Cada era resolveu um problema da anterior: máquina nua era impraticável → estruturadas. Estruturadas viraram caóticas em sistemas grandes → OO. OO virou bagunçada → Clean Code. A próxima era já está em curso (IA gerando código), e provavelmente vai cobrar a próxima conta.