Algoritmos x Algoritmos Computacionais

Olá, devs!

Este é o artigo inicial de uma série de artigos que estou iniciando na DIO sobre Algoritmos.

O objetivo da série é apresentar aos devs iniciantes a base da lógica de programação, pois hoje é comum um programador receber uma demanda e já sentar na cadeira para codificar sua ideia de solução diretamente no editor de código.

O meu artigo anterior, que apresenta essa série que começa aqui, é esse (link abaixo):

Iniciantes 4 – Algoritmos e Estruturas de Dados

1 – Introdução

Eu sou das antigas (”old fashioned”) e aprendi a programar elaborando primeiro um plano básico para a solução do problema, ou seja, o algoritmo.

Este algoritmo inicial listava os passos da solução, que seriam depois implementados em código-fonte.

Naquele tempo, em 1980, programando para mainframes na Universidade e perfurando cartões, o tempo entre a codificação e o recebimento da listagem era em torno de 2 horas. Só aí, a gente poderia corrigir os erros de digitação, lógica e reescrever o programa novamente e submeter à execução, para mais 2 horas de espera.

Depois do algoritmo pronto, a gente fazia um fluxograma, que dava uma visão do relacionamento, sequenciamento e dependências entre os diversos passos do algoritmo.

O próximo passo ainda não era a codificação, pois a gente simulava a execução do algoritmo, no papel, passo a passo, no que era chamado teste de mesa.

Esse teste permitia visualizar claramente o comportamento do programa que seria escrito, ajustar os limites dos loops (malhas de repetição), os fluxos das decisões, os dados de entrada, saída e os cálculos que seriam realizados.

Só depois disso, a gente ia para a perfuradora digitar as instruções do programa.

Por isso tudo, não dava para digitar tudo de qualquer jeito, senão o programa correto, que resolveria o problema, levaria dias para ser concluído. A primeira versão do programa já deveria ter uma incerteza menor de que daria certo.

Se você achou isso anacrônico, bizarro, engraçado ou interessante, veja meus primeiros artigos aqui na DIO, em que detalho essa saga de aprender a programar no início dos anos 80 (links abaiixo).

Dinossauros 1 – Como virei um programador (com FORTRAN!!) em 1980;

Dinossauros 2 – E como era essa tal de linguagem FORTRAN.

Algoritmos x Algoritmos Computacionais

Você pode perguntar: “mas eu estou iniciando a minha carreira de dev hoje, sem nunca ter visto nada de programação, como já vou escrever de cara um algoritmo?”

Na verdade, o algoritmo não é um conceito de programação, da Computação. Ele é usado em muitas outras áreas, inclusive no seu cotidiano.

Um algoritmo é apenas uma sequência organizada de passos para se fazer qualquer coisa na vida, seja escovar os dentes, calçar um sapato, trocar uma lâmpada, trocar um pneu do carro, etc.

Fazer uma compra online, fazer um bolo, atravessar a rua, dirigir até o shopping e lavar os pratos são outros exemplos de atividades que precisam de um algoritmo. Muitas delas a gente já faz no automático e não precisa ficar decidindo os passos nem escrevê-los no papel para poder fazer.

Já no caso do algoritmo computacional, os passos do algoritmo devem ser codificados em alguma linguagem de programação e submetidos ao computador para executá-lo.

E o computador é muito obediente, só faz aquilo que você ordenou no seu programa. E só! Ele também é burro, pois não faz nada além do que você mandou fazer no seu programa!

Se aparecer alguma situação na execução do seu programa que o computador não saiba (ou não tenha sido instruído a) fazer, ou ele vai ficar parado sem fazer nada ou vai fazer alguma coisa que foi programada para ele agir automaticamente pelo seu sistema de controle (por exemplo, abortar a tarefa ou entrar em "halt" após alguns minutos)

Exemplo de algoritmo para o cotidiano

Para ficar mais claro, imagine que a lâmpada da sua sala queimou, pifou! Agora você precisa trocar a lâmpada.

O algoritmo básico para fazer essa troca é mais ou menos assim:

1.   Pegar uma nova lâmpada;

2.   Pegar a escada;

3.   Subir na escada;

4.   Afrouxar a lâmpada até ela sair do bocal;

5.   Colocar a nova lâmpada no bocal e apertar até ele encaixar totalmente;

6.   Descer da escada;

7.   Apertar o interruptor para testar a lâmpada nova.

Veja que os passos são ordenados, pois não adiantaria nada você primeiro descer da escada se não tivesse subido antes (dãããããããã!!). Ou colocar a lâmpada nova sem ter tirado a lâmpada queimada!

Parece óbvio, não é? Mesmo assim, vai ter gente que não vai saber como trocar a lâmpada!!

Um fluxograma para este algoritmo seria assim:

Agora imagine que você vai viajar e passar uns dias fora de casa, sem nenhum contato externo. É como aqueles bilionários donos de empresas globais que viajam para um retiro espiritual numa montanha do Tibet, sem levar nada tecnológico (celular, tablet, computador, gps, etc.). Nada!

Você mora sozinho e vai deixar seu robô doméstico humanoide (com pernas e braços, daqueles da Boston Dynamics) de última geração programado para resolver qualquer coisa que aconteça na sua casa. 

Aí, com você repousando ali no Tibet, a lâmpada da sala queima (a mesma que você havia trocado rapidamente aí em cima!).

Mas o robô foi programado com o mesmo algoritmo que você usou para trocar a lâmpada antese vai trocá-la em segundos.

Aí ele começa:

1.   Pegar uma nova lâmpada;

Na última faxina, a faxineira trocou as coisas da despensa de lugar e as lâmpadas foram parar dentro da gaveta de ferramentas. Por um milagre, o robô achou as lâmpadas e pegou uma.

2.   Pegar a escada;

O zelador precisou consertar o telhado e depois esqueceu de guardar a escada no lugar dela. Por outro milagre, o robô achou a escada e levou para a sala.

3.   Subir na escada;

O robô não sabe que ainda será preciso colocar a escada embaixo da lâmpada, destravar as pernas, apertar um botão verde para abrir as pernas dela, e só então levantá-la. Se, por mais um milagre, o robô consiga fazer tudo isso, continuamos...

4.    Afrouxar a lâmpada até ela sair do bocal;

O bocal foi importado de outro país e lá tudo é feito ao contrário, de modo que a rotação para tirar a lâmpada deve ser no sentido horário, ao invés de anti-horário. Por não saber disso, o robô forçou para girar a lâmpada no sentido anti-horário e quebrou o vidro da lâmpada!

E agora??? O que o robô irá fazer?

Um ser humano saberia o que fazer com muito mais agilidade do que o robô, que não tinha sido programado para sair dessa situação.

Como eu disse, o robô teria que ser programado para seguir em cada um adas situações que foram resolvidas aqui por milagres. E se ele não conseguisse sair de alguma delas, agiria como foi programado pelo fabricante para não entrar em loop infinito ou no modo pânico!!

Eu fico até rindo sozinho imaginando as coisas mais absurdas que o robô iria fazer para sair de cada situação sem as instruções dadas claramente:

Subir na escada: ele poderia subir na escada deitada no chão da sala, pois não foi dito para levantá-la antes de subir.

Pegar uma nova lâmpada: ele teria que saber aonde estavam as lâmpadas e como era a lâmpada da sala, pois poderia haver vários tipos de lâmpada nos cômodos da casa.

Apertar o interruptor para testar a lâmpada nova: Se faltasse energia após ele trocar a lâmpada, ele passaria o dia todo testando a lâmpada, achando que a nova também estava queimada e trocaria ela de novo. E de novo, e de novo e de novo...

Ao final, o robô ainda teria que guardar a escada no lugar e jogar a lâmpada queimada no lixo.

E por aí vai...

Dever de casa: elabore um algoritmo para trocar o pneu de um carro e depois mostre para alguém com experiência em trocar pneu de carro. A maioria das pessoas sem essa experiência costume esquecer de 2 ou 3 passos essenciais!!

A diferença entre um algoritmo comum (do cotidiano) e um algoritmo computacional é que no computacional, que será implementado em um computador (ou num robô computadorizado) é que TODOS os passos para resolver o problema devem estar escritos explicitamente, pois ele só vai fazer o que for mandado. E só isso!

Exemplo de Algoritmo Computacional

Como exemplo, vamos ver um algoritmo para um problema simples.

Faça um algoritmo para um programa que vai ler 2 números inteiros, dividir o primeiro pelo segundo e imprimir o resultado.

1.   Leia o primeiro número

2.   Leia o segundo número

3.   Divida o primeiro número pelo segundo

4.   Imprima o resultado

Parece simples, não é? Mais simples só se for imprimir o “Hello, world!”.

Pense um pouco e diga quais são as informações não dadas no algoritmo precisariam ser passadas para o computador para garantir que o programa funcionaria, ou seja, que não quebraria?

De cara, eu penso logo em algumas:

• E se o usuário digitasse os dados de entrada que não fossem números?
• E se o segundo número digitado fosse zero?
• Se você rodar o programa assim, como o usuário saberia que precisaria digitar um número, e em seguida, outro número?
• Como ele saberia que o objetivo do programa era imprimir o resultado da divisão de um número por outro?

Eu pensei em outras possibilidades, mas fique livre para listar outras que você pensou.

Todos estes detalhes devem ser codificados para que o programa funcione bem e que a resposta seja adequada ao que ele se propõe a resolver.

O algoritmo lista o que deve ser feito, mas ele não detalha como fazer. E esses detalhes são específicos de cada linguagem de programação.

Detalhando melhor, só a entrada dos números pode ser feita de diversas formas diferentes em cada linguagem, de acordo com a sua sintaxe própria e funções de entrada disponíveis nas suas bibliotecas.

Mas o algoritmo dá todos os passos para que seja implementado em qualquer linguagem do gosto do programador.

É claro que seu algoritmo inicial (e o fluxograma também!) poderia ser atualizado com mais passos, de acordo com os detalhes que você desejasse acrescentar.

Bem, por hoje é só! Obrigado por ter lido até aqui.

Aguarde o próximo artigo desta série.