Introdução da UC e motivação

Além das minudências sobre o funcionamento da disciplina — e algumas considerações mais impactantes ("A universidade é para ter tudo público!") — tiveram-se algumas considerações sobre a motivação da UC.

Partimos da noção que, em geral, não há base científica para a prática da programação. Existe muita literatura e conhecimento sobre o processo de programar, mas não sobre o produto. E quando existe essa necessidade de segurança sobre um resultado, naturalmente opta-se pela programação funcional (imagino que uma das vantagens seja a ausência de um estado, e a possibilidade de compor funções para tirar conclusões rápidas).

(aparentemente, faz-se muito pouco Cálculo de Programas em Portugal; é uma UC única em Portugal; há uma universidade em Eindhoven que usa este manual; recomendou o livro The Essence of Software: Why Concepts Matter for Great Design, de Daniel Jackson do MIT, que aparentemente tem ligações com o trabalho desenvolvido cá).

Houve ainda um breve contexto histórico sobre as linguagens de programação (e a influência de Von Neumann).

Primeiro caso prático — o Nokia 3310

Foi mostrado um enunciado simples de um problema técnico necessitado de uma solução. Enuncio-o de memória, com a melhor das minhas capacidades:

a) a chamada mais recente fica no topo da lista;

b) o registo de chamadas não contém duplicados;

c) só se guardam dez chamadas.

Este exercício foi dado a alunos, há muitos anos. Entre as várias respostas (maioritariamente Java, C#, C++), apenas uma funcional — incidentemente, a única correcta.

Há uma solução em Haskell muito elegante (possivelmente, errei a copiá-la).

store :: Call -> [Call] -> [Call]
store c L = take 10 (nub (c:l))

Seguiu-se um breve estudo de como se pode considerar cada uma destas funções separadamente, levando a uma aproximação do conceito mais matemático de função. Naturalmente, advém a ideia de composição de funções. Aflorou-se o conceito de combinadores.