"Simplicity does not precede complexity, but follows it."

Este é sem dúvida o meu epigrama favorito deste grande cientista da computação, o primeiro laureado com o Turing Award (a maior distinção que um cientista desta área de investigação pode aspirar a receber). A lista destas pequenas pérolas poéticas sobre programação (e muito mais) é extensa e reflete a grande sabedoria que advém de uma vida dedicada à causa. Pesquisem "Epigrams on Programming" no sítio do costume e deliciem-se com estas "asneiras livres" de altíssima qualidade.

É o meu favorito porque explica bem a força motriz por detrás do melhor que ciência nos tem dado. O caminho mais fácil é quase sempre o de acompanhar a complexificação dos sistemas, naturais ou artificiais, com a complexificação da teoria que os pretende explicar. Tantas vezes disfarçada de erudição, esta forma de ciência muitas vezes esconde mais do que explica, e acaba por levar a um ponto de saturação cognitiva que atrasa o progresso. Até que chega a ideia simples, unificadora, genial (de génios como Newton ou Turing), que de repente subjuga toda esta complexidade e a reduz à sua essência. O que era complexo de repente parece trivial e, libertos do nevoeiro que nos turvava a visão, podemos avançar para novos desafios.

É também o meu favorito porque explica muitas das minhas decisões, preferências e epifanias, quer pessoais, quer profissionais.

Membro orgulhoso do HASLab, investigo em Métodos Formais, área que há muitos anos procura dar algum sentido à palavra "Engenharia" na Engenharia de Software. Tal como nas outras engenharias, defendemos que se deve modelar e especificar antes de programar, ou como escreveu Leslie Lamport recentemente, simplesmente defendemos que se deve construir software como se constroem casas [1]. Para tal, recorremos a linguagens formais que nos permitam modelar e abstrair a complexidade do software, para mais facilmente podermos explicar e prever o seu comportamento. 

Porque nem todos podemos ser génios, muita da investigação nesta área padeceu do mal que descrevo acima: conforme a complexidade dos sistemas de software foi aumentando, também os métodos formais se tornaram cada vez mais complexos, criando barreiras de entrada muitas vezes inultrapassáveis para a maioria dos "engenheiros" de software, que assim preferiu continuar a ignorá-los. A minha própria crença na área foi ficando abalada e, quando ensinava métodos formais, sentia-me por vezes arauto de uma área moribunda e irrelevante.

Felizmente, há alguns anos descobri o Alloy, uma linguagem de modelação concebida por Daniel Jackson no MIT [2], caracterizada por uma simplicidade e elegância que facilita a abstração e a reflexão que se desejam numa fase de projeto de software. Permite-nos dizer muito com pouco, e rapidamente idealizar, explorar e validar diferentes soluções para o sistema pretendido. Encarnando o espírito do epigrama de Alan Perlis, o Alloy traduziu-se numa pequena epifania pessoal, pois fez-me acreditar que os métodos formais podem ser leves sem ser ocos, e assim aspirar a ter um impacto real na Engenharia de Software.

O HASLab encontra-se em processo de integração no INESC TEC. Variadas razões motivaram este "casamento". Pessoalmente, uma delas estava mais uma vez alinhada com este epigrama: a busca da simplicidade depois da complexidade. Neste caso, a simplicidade e eficiência dos processos organizacionais, que nos permitiria sacudir a complexidade burocrática que muitas vezes se interpôs no caminho da excelência científica. Agora esse caminho parece bem mais fácil!

Um abraço desde Braga.

[1] http://www.wired.com/opinion/2013/01/code-bugs-programming-why-we-need-specs/
[2] http://alloy.mit.edu/