Programação moderna para as massas

O FISL deste ano me deu uma idéia interessante. Observando todos aqueles programadores de Perl, PHP, Java fazendo palestras, e os programadores de Python, orgulhosos por o serem, citando a beleza do código da linguagem como uma das principais vantagens, pensei submeter um artigo para palestrar no próximo fórum: programação funcional e/ou lógico-funcional, e as ferramentas SL disponíveis para utilizar esta técnica.

A principal motivação talvez seja, num espaço onde muitos não são da computação e conhecem apenas algumas ferramentas empurradas^W^H propostas pelo mercado e/ou criadas por ícones da comunidade, mostrar que há alternativas muito melhores e atuais para solucionar os problemas, de maneira simples, prática, e com uma composibilidade muito melhor. Isso, claro, sem contar a fortíssima base matemática por trás destas linguagens, o que facilita a formalização da mesma.

Eu choveria no molhado se repetisse todo o que está escrito aqui, especialmente a parte de verificação, paradigmas de programação e recursos das linguagens de programação modernas (que é a parte pertinente para este post). Então, aproveito para recomendar a leitura.

Por enquanto, só tive umas idéias de algumas coisas importantes para comentar, e de como estruturar uma apresentação desse tipo, que deve falar em linhas gerais sem tornar o conteúdo massivamente técnico ou fazer com que pareça uma aula de programação funcional/lógica. Se o projeto evoluir bem, em um próximo post trago mais informações, e possivelmente um "sumário" dos itens a tratar. Aberto a sugestões, claro!

E é isso.

Truths that might hurt.

"APL is a mistake, carried through to perfection. It is the language of the future for the programming techniques of the past: it creates a new generation of coding bums."

"It is practically impossible to teach good programming to students that have had a prior exposure to BASIC: as potential programmers they are mentally mutilated beyond hope of regeneration."

"FORTRAN, 'the infantile disorder', by now nearly 20 years old, is hopelessly inadequate for whatever computer application you have in mind today: it is now too clumsy, too risky, and too expensive to use." [todas de Edsger Dijkstra]

Eu diria que, considerando os tempos atuais, a tripla (APL, BASIC, FORTRAN) poderia muito bem ser substituída pela tripla (Java, Clipper, FORTRAN) sem perda de significado.

E é isso.

11 dicas para programar em O'Caml

Depois de algum tempo programando em Objective Caml, adquirí uma certa experiência na linguagem para fazer programas facilmente reusáveis e razoavelmente bem abstraídos, utilizando os recursos mais poderosos desta. Listei alguns dos itens que considero mais importantes para se observar ao programar em O'Caml, que podem fazer grande diferença na qualidade final do código gerado e da sua expressividade. Seguem estes, abaixo:

• [1] Não utilize orientação a objetos, a menos que tenha uns bons anos de experiência com a linguagem, e que saiba o que está fazendo. A maior parte dos programadores tende a abusar deste recurso, erroneamente;


• [2] Não programe imperativamente, a menos que tenha feito pelo menos uma dezena de programas puramente funcionais, e que saiba o que está fazendo. Neste caso, também há muitos abusos, e é importante notar que eles atrapalham a abstração do programa removendo as vantagens da programação funcional;


• [3] Use o sistema de tipos para abstrair o dado que está tentando modelar. Ele é, até prova em contrário, poderoso o bastante para isso. Caso não for, você sempre pode isolá-lo como um tipo abstrato dentro de um módulo, e controlar a criação/manipulação do dado para forçar determinadas restrições extras que necessita;


• [4] Use o sistema de módulos para isolar os tipos do resto do programa, delimitando a interface entre a sua(s) biblioteca(s) e o programa principal;


• [5] Tipos, exceções, funções e métodos usados internamente pelo seu código devem permanecer internamente, e não serem declarados nas assinaturas (sig ... end, arquivos mli). Utilize a diretiva private, se necessário, para isolar construtores que são usados internamente;


• [6] Evite as variantes polimórficas. Aliás, procure não usá-las nunca. Construtores de tipos encapsulados dentro de módulos evitam conflitos de nomes, e são tão poderosos quanto as variantes; além de permitirem uma checagem de tipos mais apurada;


• [7] Casos excepcionais, especialmente os erros, devem permanecer casos excepcionais, e não devem ser inseridos nas abstrações, a menos que você realmente tenha um bom motivo. Um exemplo de como não se deve implementar uma abstração é o caso da biblioteca Netclient: no módulo Http_client, o tipo protocol pode assumir valor `Other, além do tipo da conexão (HTTP ou HTTPS) e das versões disponíveis neste, o que complica o código de tratamento deste tipo;


• [8] Diminua o número de funções do seu módulo/classe usando parâmetros nomeados opcionais. Por exemplo, se você tiver:
  
  
  let add_with_callback callback msg = ...
  let add msg = ...
  
  Reduza a uma função só, da seguinte maneira:
  
  
  let add ~callback msg =
  match callback
  with
  None -> ...
  | Some c -> ...
  ;;


• [9] Utilize funtores onde achar necessário. Por exemplo: um módulo principal que implementa certa funcionalidade, mas que pode ter vários comportamentos diferentes associados a ele, pode ser abstraído em um funtor. Faz-se isto isolando-se cada aspecto comportamental como um tipo de módulo e parametrizando o módulo principal a partir desses das assinaturas dos módulos de comportamento. Desta forma, o módulo principal parametrizado pelos módulos comportamentais resultará em um módulo final, implementando a funcionalidade o com o comportamento desejado. O resultado é uma abstração do código em comum e uma boa extensibilidade no programa;


• [10] Evite o uso de if-then-else: utilize guards quando fizer um pattern-matching. De preferência, use um pattern-matching no lugar de um if-then-else quando possível: isto facilita a legibilidade e flexibilidade do código;


• [11] Aprenda a usar o ocamldoc e gere documentação para seu código, mesmo que sem comentários adicionais.

Obviamente seguir só estes passos não vai resultar em um código melhor. Mas, com certeza, eles são muito úteis para se fazer programas e bibliotecas com interfaces mais sãs e implementações mais alto-nível.

E, por enquanto, é isso.