Para quem gosta mesmo de programar, resolver problemas com recurso a meios muito limitados pode ter um gosto muito especial. Não que se seja masoquista a ponto de não gostar das possibilidades dos novos sistemas, mas acho que muitos de nós tiveram especial prazer em vencer certos desafios postos por sistemas pequeninos e com interfaces que não se parecem nada com aquilo que hoje temos disponível em qualquer computador pessoal.
Talvez por isso, compreende-se alguma nostalgia por sistemas antigos e pelos novos pequenos dispositivos como os Pilot e alguns menos novos como certas calculadoras programáveis (das quais o melhor exemplo deve ser a HP-48).
`Algo muito curioso que notei acerca da satisfação estética é que o nosso prazer é significativamente elevado quando conseguimos realizar algo com ferramentas limitadas. Por exemplo, o programa que pessoalmente me deu mais satisfação e orgulho é um compilador que em tempos escrevi para um minicomputador primitivo que tinha apenas 4096 palavras de memória, 16 bits por palavra. Completar algo sob restrições tão severas faz uma pessoa sentir-se como um verdadeiro virtuoso.
Um fenómeno semelhante acontece em muitos outros contextos. Por exemplo, as pessoas parecem frequentemente apaixonar-se pelos seus Volkswagens mas raramente pelos seus Lincoln Continentals (que supostamente funcionam muito melhor). Quando aprendi a programar, era um passatempo popular fazer tanto quanto fosse possível com programas que coubessem num único cartão perfurado. Suponho que é este mesmo fenómeno que faz os entusiastas de APL sentir prazer nos seus "one-liners". Quando ensinamos programação hoje em dia, é um facto curioso que raramente capturamos o coração de um estudante para a ciência da computação até ele ou ela ter tido um curso que permita experiência "hands-on" num minicomputador. O uso das nossas máquinas de grande escala com os seus luxuosos sistemas operativos e linguagens não parece gerar qualquer amor pela programação, pelo menos não no início.
Não é óbvio como aplicar este princípio para aumentar o gosto dos programadores no seu trabalho. Certamente os programadores iriam resmungar se o seu gestor anunciasse repentinamente que a nova máquina iria ter apenas metade da memória da anterior. E não penso que se possa esperar que ninguém, nem mesmo os mais dedicados "artistas da programação", acolhesse bem uma tal possibilidade, visto que ninguém gosta de perder meios necessariamente. Outro exemplo pode ajudar a clarificar a situação: os cineastas resistiram fortemente à introdução dos filmes sonoros na década de 1920 porque estavam justamente orgulhosos da forma como conseguiam transmitir palavras sem som. De forma semelhante, um verdadeiro artista em programação pode sentir algum ressentimento com a introdução de equipamento mais potente; os actuais mecanismos de armazenamento em massa tendem a estragar muita da beleza do nossos velhos métodos de ordenamento em fita. Mas os cineastas de hoje não querem voltar aos filmes mudos, não porque sejam preguiçosos mas porque sabem que é possível fazer filmes belos usando a tecnologia melhorada. A forma da sua arte mudou, mas ainda há muito espaço para a expressão artística.
Como é que desenvolveram a sua perícia? Os melhores cineastas ao longo dos anos parecem habitualmente ter aprendido a sua arte em circunstâncias comparativamente primitivas, frequentemente em outros países com uma indústria cinematográfica limitada. E em anos recentes as coisas mais importantes que temos aprendido sobre programação parecem ter tido origem com pessoas que não tinham acesso a computadores muito grandes. A moral desta história, parece-me, é que devíamos fazer uso da ideia de recursos limitados na nossa própria educação. Todos podemos beneficiar fazendo programas ocasionais "para brincar" ['"toy" programs' no original], onde são estabelecidas restrições artificiais, de forma a sermos forçados a levar as nossas habilidades até ao limite. Não devíamos viver todo o tempo ao colo do luxo, porque isso tende a deixar-nos letárgicos. A arte de atacar mini-problemas com toda a nossa energia irá aguçar os nossos talentos para os problemas reais, e a experiência ajudar-nos-á a ter mais prazer com os nossos sucessos posteriores em equipamento menos restrito.
Num espírito semelhante, não devíamos envergonhar-nos da "arte pela arte"; não devíamos sentir-nos culpados relativamente a programas que são apenas feitos por brincadeira. Uma vez entusiasmei-me imenso na escrita de um programa com uma única instrução, em ALGOL, que invocava uma rotina de cálculo de produtos internos de uma forma tão pouco usual que calculava o m-ésimo número primo, em vez de um produto interno. Há alguns anos os estudantes em Stanford andavam excitados sobre encontrar o programa em FORTRAN mais curto que se imprimisse a si próprio, no sentido de o output do programa ser idêntico ao texto do seu próprio código fonte. O mesmo problema foi considerado para muitas linguagens. Não creio que tenha sido um desperdício de tempo ter-se trabalhado nisto; nem Jeremy Bentham, que citei antes, negaria a "utilidade" de tais passatempos [3, Bk. 3, Ch. 1]. "Pelo contrário", escreveu ele, "não há nada cuja utilidade seja mais incontestável. A que há-de ser atribuído o carácter de utilidade, senão àquilo que é uma fonte de prazer?"'
-- Donald E. Knuth, "Computer Programming as an Art" (1974), in Literate Programming, CLSI Lecture Notes no. 27 (Stanford, 1992)
