Como é o seu fluxo de trabalho Lisp? [fechadas]

A maioria das pessoas no comp.lang.lisp e no Lisp Forum recomendam uma combinação de Emacs e SLIME, supondo que você não quer pagar por uma implementação comercial como Allegro ou LispWorks. O vídeo SLIME ilustra o processo de trabalho. Eu uso o Emacs e o SLIME para desenvolver programas pessoais em casa, e a combinação pode ser muito eficiente.

O SLIME oferece integração entre o Emacs e o REPL. O que eu normalmente faço é carregar todos os meus arquivos e depois abrir aquele em que estou trabalhando no Emacs. Depois de digitar ou alterar cada função, pressiono C-x C-e , que executa a definição da função no REPL. Então eu posso mudar para o buffer REPL e tentar a função. Todo o histórico do REPL está disponível e editável usando sequências de teclas padrão do Emacs, por isso é fácil refazer chamadas de função com diferentes parâmetros.

Eu trabalho principalmente com o Clojure e aqui está minha configuração:

1. Eclipse IDE (eu uso isso como também faço muito trabalho em Java, às vezes no mesmo projeto que o Clojure)
2. Plugin anti-horário para Clojure (isso inclui um REPL)
3. Maven para gerenciamento de dependência e construção
4. Egit para controle de código-fonte

Fluxo de trabalho durante a codificação é geralmente assim:

1. Abra um REPL, carregando todos os arquivos de origem atuais
2. Codifique e teste no REPL
3. Quando estou feliz com algum código, copie / cole de volta no arquivo de origem
4. Ocasionalmente, reinicialize o REPL (seja quando eu estraguei um namespace irrevogavelmente, ou apenas para verificar se tudo ainda está funcionando nos arquivos de origem)
5. Escreva também testes nos arquivos de origem, que são executados automaticamente por cada compilação do Maven. Às vezes, os testes informais que acabei de fazer no REPL se transformam em testes unitários.
6. Commit etc. neste momento - praticamente um fluxo de trabalho de desenvolvimento regular

No geral, não é muito diferente de um fluxo de trabalho Java / C # comum, além do uso mais interativo do REPL durante o desenvolvimento.

Para suplementar as outras respostas, eu faço uma combinação do tipo "Pense bem sobre o problema, depois anote a solução" e "Comece com uma replicação, e bata o programa no formato iterativamente". É geralmente no meio. O que eu faço é começar com uma idéia geral do que eu quero do meu programa, e então eu começo a escrevê-lo, tentando adquirir novos conhecimentos sobre o domínio do problema, a fim de revisar minha abordagem. Na prática, isso significa que eu faço muita experimentação e escrevo um monte de código para fora. Eu tento abordagens diferentes e posso mudar a direção muito rápido. Lisp é bom para esse tipo de desenvolvimento. É por isso que eu não gosto muito de TDD, tenho que saber o que quero fazer primeiro, para poder efetivamente fazer TDD.

Outra coisa importante que tento fazer é pensar mais sobre o protocolo entre as diferentes partes de um programa. Ao contrário de outras linguagens OO, o CLOS em Common Lisp é focado mais no conceito de uma função Genérica, os métodos IOW vivem fora das classes e são o foco do desenvolvimento. Às vezes eu apenas começo com um conjunto de GFs definindo o protocolo que eu quero, eu escrevo uma implementação simples e a utilizo para detalhar o protocolo, antes de escrever uma implementação real. Digamos que estou escrevendo uma camada que armazena um monte de posts, eu poderia ter um conjunto de GFs que definem como as postagens do blog são criadas, editadas e pesquisadas, e gostaria de escrever uma implementação simples que salva postagens do blog em uma lista na memória e, depois que estou satisfeito com meu protocolo, escrevo uma implementação que salva postagens de blog em um banco de dados ou as grava em arquivos.

Lisp torna tão fácil mudar de direção e fazer uma abordagem diferente quando você sabe que sua solução atual está abaixo do ideal e eu tento maximizar isso.

Ponto importante também: Use seu ambiente ao máximo, aprenda sobre como usar diferentes configurações de compilação para compilar seu código com mais informações de depuração, aproveite o fato de que o lisp pode ser compilado e interpretado. Use os recursos introspectivos dos lisps, como o MOP, use recursos de slimes para procurar documentação, use o inspetor para examinar objetos, consultar o hiperespaço regularmente, tratar seu sistema mais como um SO, do que um compilador estático para seu código, é muito mais poderoso do que isso.

Para um iniciante, o lisp não é uma grande vitória sobre o python e o ruby, mas à medida que você fica mais experiente com ele, você obtém enormes vitórias sobre ambientes menores.

Eu costumo trabalhar em um editor que tem uma conexão com um REPL (normalmente, editando no emacs e usando o SLIME como uma ponte para um ambiente Common Lisp). Eu tendem a começar tanto "na parte inferior" e "no topo", trabalhando para o meio, revisando o design como eu vou.

Quanto ao teste, é por isso que eu tenho um REPL. Eu acho que isso ajuda a testar o código enquanto eu vou. Às vezes, escrevo testes ou benchmarks mais formais à medida que vou (normalmente, quando estou no estágio de otimização). Tenha uma implementação de funcionalidade mais lenta, em bom estado, experimente (em uma janela de editor) com código para uma versão otimizada, envie para o código lisp subjacente e verifique se ele é mais rápido e retorna os mesmos resultados que o mais lento código.

No que diz respeito ao empacotamento, tenho alguns códigos de utilitários para me ajudar a empacotar projetos instaláveis no ASDF, colocá-los em um repositório de downloads e lidar com o controle de versão.