Pular para o conteúdo principal

Ensinando Programação Não-Estruturada

Conversando com várias pessoas novatas ao longo dos anos, percebi que é muito difícil obter uma compreensão clara do que é a programação estruturada por falta de contexto.

O material didático e os cursos afirmam a maravilha da programação estruturada ao organizar programas, enumerando problemas que ninguém mais tem, porque todas as linguagens de programação atuais são estruturadas. Como é possível comunicar a dificuldade de programar de uma forma que é, atualmente, impossível programar?

Uma solução seria ensinar BASIC e então mostrar como é problemático escrever programas longos em BASIC, em comparação com Pascal. Porém, BASIC e Pascal são escrotas por sí só, sem qualquer relação com a presença ou ausência de estruturas.

Ensinar programação não-estruturada com o intuito de redescobrir a programação estruturada não pode implicar mais dores que esta: manifestar o fluxo de controle apenas com goto.

Me ocorreu, então, que esta é exatamente a solução: tomar uma linguagem de programação moderna, como C ou Javascript, e arrancar dela todos os elementos de programação estruturada ou mais avançada. O usuário não poderá dividir o código em funções isoladas; o usuário não poderá usar if, while, do. A única estrutura de controle será goto e if-goto. Todo o resto se mantém mais ou menos intacto; criação de objetos, atribuição de valores, sintaxe de literais etc.. O único acréscimo será algum tipo de sintaxe para entrada e saída padrão. (Ou talvez uma maneira secreta de invocar chamadas de procedimento escrita por terceiros.)

Como exemplo, eis uma pesquisa binária em uma formulação inicial da minha linguagem não-estruturada:

data_size : integer ; // parameter
data : array(integer, data_size) ; // parameter
value : integer ; // parameter

@ continue
pivot : integer = ( left + right ) / 2 ;
goto (data[pivot] == value) found ;
goto (left == pivot || pivot == right) not_found ;
goto (data[pivot] < value) adjust_left ;
right = pivot ;
goto (true) continue ;
@ adjust_left
left = pivot ;
goto (true) continue ;
@ not_found
write("value not found") ;
exit ;
@ found
write("value found in position %i", pivot) ;
exit ;

Cara, imagina este programa se o alvo do goto não fosse um nome mas um número de linha...
Marcadores:

Comentários

Postar um comentário

Postagens mais visitadas deste blog

return void();

É uma pequeneza mas eu gostaria muito que as linguagens da família do C permitissem retornar void quando a função retorna void . Escrever da forma a seguir me aborrece. public class Foo  {    public void log (String msg) { }    public void bar (String x, String y) { }    public void bar (String x)    {      if (x == null)      {        log("x was null");        return;      }      bar(x, "default");    } } Eu ficaria mais feliz escrevendo assim: public class Foo  {    public void log (String msg) { }    public void bar (String x, String y) { }    public void bar (String x)    {      if (x == null) return log("x was null");      bar(x, "default");     } }
Postar um comentário
Leia mais

.NET COM Interop, IStream e Visual Studio

Investigando oportunidades para otimizar um componente, experimentei definir métodos que não solicitam dados (em arrays etc.) como argumentos mas sim instâncias de IStream , e me deparei com um problema interessante: interoperabilidade com .NET. Usar componentes COM em programas .NET não é particularmente difícil; no Visual Studio, é possível adicionar componentes COM como referências no projeto. Se o componente for capaz de Automation, é possível usar a ferramenta tlbimp.exe para gerar manualmente um callable wrapper para o componente, que, se eu entendi as coisas corretamente, não precisa ser distribuído com a aplicação. Porém, todos os métodos que eu aprendi tem essa peculiaridade: eles parecem assumir que um componente não usa interfaces definidas por outros componentes -- como, por exemplo, declarando parâmetros com tipo IStream , uma interface definida pelo sistema. Pelo método do callable wrapper , a ferramenta assume que as interfaces mencionadas integram o componente...
Postar um comentário
Leia mais

Eclipse PDE com Gradle

Na virada de 2016 para 2017, adotamos oficialmente o Gradle como ferramenta de construção de software na Prodist. A fila da migração está fluindo confortavelmente desde então. Já temos as provas de conceito necessárias para todos os projetos, inclusive os projetos nativos para compilador C++. Para fontes Java usamos Eclipse. Integramos projetos Gradle ao Eclipse usando Buildship . Acho que o Buildship ainda tem um longo caminho pela frente, mas realiza tudo o que necessitamos. Já estamos entregando com base nesse esquema. O problema mais importante que encontramos foi na integração de projetos OSGi. No Eclipse, trabalhamos projetos OSGi com o PDE. Nosso ciclo de desenvolvimento inclui rodar configurações "OSGi Framework" no Eclipse para teste. Infelizmente, o PDE assume uma estrutura de projeto própria e não funciona corretamente caso contrário. Estes problemas estão registrados em bugs como, por exemplo, o  bug 153023 . Nossos projetos OSGi com Gradle usam o layout ...
Postar um comentário
Leia mais