Meu workflow em Clojure

Há algum tempo postei sobre LightTable e Clojure, e embora minha opinião sobre essa nova forma de programar não tenha mudado, algumas coisas infelizmente mudaram bastante.

A primeira foi o esquema de plug-ins do LightTable. Ele tem poucos plug-ins úteis, e alguns dos que existem não funcionam com as versões mais novas. A documentação da API do LightTable é inexistente, e eu passei mais tempo lendo o código fonte do editor do que eu gostaria. Então, resolvi experimentar novamente o Atom, com seu novo plug-in proto-repl.

Uma das vantagens (grandes vantagens) do Atom é que ele facilita muito a criação de plug-ins. Embora ele não seja livre de problemas (eu mesmo postei no fórum deles sobre como as APIs mudam sem aviso prévio), ele ainda é melhor que todos os outros editores que eu usei para esse fim. Além do mais, recentemente o Atom ganhou duas bibliotecas interessantes – Ink, que permite fazer o que o LightTable faz (exibir resultados próximo de onde o código que o gerou está) e também ganhou, nativamente, decorações em bloco – uma ou mais linhas inteiras aonde se pode exibir qualquer informação, e o usuário não pode digitar nessas linhas. Isso é muito bom, e abre o caminho para coisas bem interessantes.

Infelizmente, eu ainda não achei uma maneira simples de lidar com ClojureScript, então vamos pensar apenas em Clojure agora. A primeira coisa a fazer é instalar o Parinfer, Ink, proto-repl e o LISP Paredit. Sim, esse último é necessário pelo motivo mais bobo – o Atom não indenta direito códigos Clojure… Além disso, recentemente comecei a trabalhar profissionalmente com Clojure, e por esse motivo, muitas vezes eu pego códigos legados aonde a indentação está completamente errada, e eu não posso alterar um arquivo inteiro se meu intuito é acrescentar uma linha.

A segunda coisa a se fazer é inserir o proto-repl no arquivo de profiles do lein. Isso é importante para não ter que inseri-lo em todos os projetos a serem desenvolvidos.

; dentro do arquivo ~/.lein/profiles.clj
{:user {:plugins [[refactor-nrepl "2.0.0-SNAPSHOT"]] ; Para alguns códigos que vamos usar
        :dependencies [[org.clojure/tools.nrepl "0.2.12"]
                       [proto-repl "0.1.2"]]}}

Como funciona?

O proto repl adiciona a habilidade de rodar códigos clojure no editor. Ele pode abrir um repl para você, ou você pode abrir um e se conectar a ele. Essa segundo opção é bem mais saudável, então normalmente é a que eu uso. Uma vez conectado ao repl, o proto vai tentar fazer o que se chama de refresh do namespace – isso significa que ele vai pré carregar todos os arquivos do seu projeto, identificar dependências, e uma vez que você mude um arquivo ele tentará recarregar esse arquivo, e tudo o que depende dele. Isso significa que, se há algum código que pede que o usuário digite algo, ou algo código que interage com o sistema fora de um defn ou alguma outra estrutura que não rode imediatamente, o código vai rodar nesse processo de refresh.

Extensões ao workflow

Claro que não é só essa a vantagem. Eu, por exemplo, uso o vim plus no atom. Por isso, eu criei dois atalhos – um no modo de comando que expande a seleção da sexp. Outro no modo visual, que também expande a seleção. Isso significa que, ao apertar s s em modo de comando, ele selecionará uma string. Apertando s de novo, selecionará a string e também as aspas. Apertando mais uma vez, selecionará os parêntese aonde essa string está, e assim por diante.

Nesse ponto, tudo está praticamente pronto. Mas, infelizmente, a vida não pode ser correta e bela ao mesmo tempo, já diria Douglas Adams…

Correções…

Bom, o Atom, para variar, tem alguns bugs bem irritantes que não são corrigidos. Primeiramente, quando as coisas acontecem no fim da tela (tipo, perto da parte de baixo do editor), há um flickering ridículo, reportado nesse bug. Enquanto isso, eu uso um hack no meu editor, adicionando nas stylesheets as linhas abaixo. Além disso, o Lisp Paredit, quando não faz “match” dos parenteses, deixa uma cor vermelho-berrante, então eu também estilizo de forma diferente:

// O flicker ainda existe, mas é mais suave.
.autocomplete-plus {
  transition: top ease 0.4s, left ease 0.4s;
}

atom-text-editor::shadow .lisp-syntax-error .region {
  background-color: rgba(204, 0, 0, 0) !important;
  border: 1px solid rgba(204, 0, 0, 0.8) !important;
}

No meu caso, eu tenho muitos projetos que usam o midje. Isso significa que cada refresh do código vai rodar testes, e o refresh deveria ser algo bem rápido. Eu tentei resolver isso com “injections” no meu profiles.clj – o proto-repl prefere chamar uma função user/reset, e se isso falhar, chama o clojure.tools.namespace.repl/refresh, mas isso não funcionou muito bem… por isso, desabilitei o refresh do proto-repl, e adicionei uma função de refresh no meu plug-in (ainda não publicado) Clojure Plus.

Outras extensões

Eu tive que mexer também na forma como se trabalha com ambientes docker. No proto-repl, os caminhos dos arquivos são absolutos. Acabei fazendo um monkey patch para poder remover a parte absoluta e deixar tudo relativo, e logo depois migrei para meu pacote (abaixo). O que eu fiz foi, após conectar ou desconectar do proto-repl, ele abre uma API para subscription. Minhas alterações estão no meu GitHub.

Além disso tudo, estou trabalhando num plug-in para adicionar certas funcionalidades do Cursive no Atom, no meu repositório Clojure Plus. Poucas delas são uma busca de códigos que dependem de determinado símbolo, adicionar require de namespaces automaticamente, e basicamente fazer o que o refactor nrepl faz com o emacs no Atom. Outra funcionalidade que estou estudando adicionar são as watch expressions do LightTable no Atom, e também numa forma de gerar autocomplete em ClojureScript, ou pelo menos adicionar a possibilidade de subir dois repls diferentes – um para Clojure é um para ClojureScript (ou mesmo dois para Clojure, fazendo algo semelhante às connections do LightTable). Essa parte provavelmente é fácil – basta fazer um cache de todas as conexões que já foram feitas, e remover as que não existem mais. Como isso será feito ainda segue um exercício.

O ideal é fazer o que se faz há anos com Smalltalk – um ambiente rodando o aplicativo que se reflete no editor. Uma coisa possível, e que hoje o Atom não faz, é sintax highlight de forma semântica. Por exemplo, todas as vars são de uma determinada cor, todos os defs de outra, etc. Porém, isso para mim não é suficiente – o ideal seria ter isso de forma customizada. Com o esquema de subscription do Atom, seria fácil fazer uma ferramenta que, uma vez que o Atom começa o highlight de um arquivo Clojure, ele repassa para um plug-in externo o símbolo e o que ele significa naquele contexto. Digamos que um plug-in quer fazer sintaxe semântica – todos os símbolos de um mesmo let tem a mesma cor. Ele iria fazer um subscribe, e receberia a AST com um repl conectado, e a posição que está sendo feito o highlight, e a partir dali é decidir o que fazer. Outras possibilidades são mostrar automaticamente quando um método vem de um schema (tipo o Prismatic Schema) e o schema não vai bater, ou quando um método não aceita aquele tipo de parâmetro (no caso de um defmulti, por exemplo, ou de um protocol), ou mesmo – e é aqui que as coisas podem realmente ficar interessantes – uma forma de eval inteligente – ele define que aquele bloco que se quer rodar está dentro de um bloco específico, vê os símbolos que deveriam existir naquele escopo, e então pede, num pop-up, os parâmetros que faltam.

Conectando num ambiente, as possibilidades são infinitas. Provavelmente vou escrever bastante sobre isso nos próximos posts. Por hora, um pequeno vídeo sobre essas novidades (em inglês, com legendas):

Bom divertimento.

Publicado em Clojure | Marcado com , , , , , | Deixe um comentário

Clojure, gentilmente

Nos últimos posts eu percebi que me empolguei um pouco no assunto Clojure. Então, esse é um post para tentar começar com a linguagem, ao invés de tentar entender detalhes. Vou atualizar os outros posts para indicar que esse é o primeiro da série, apesar de estar por último…

Clojure é uma linguagem baseada em LISP. Isso, pra muita gente, significa parênteses intermináveis e sintaxe horripilante. Mas não é bem assim.

Os parênteses são um desafio, um degrau. Então ignore-os por enquanto. Use um editor com suporte ao parinfer – Atom ou LightTable. Acho que o vim também. Isso vai tratar de manter os parênteses em sincronia, baseado na indentação, e também de forçar você a entender a indentação de Clojure. A partir daí, é entender por que esses parênteses existem. Então vamos lá:

Em LISPs, ou seja, em Clojure, parênteses nunca são opcionais. Nunca. Então nem tente resolver seu código com “vou tentar colocar um parênteses aqui” porque não vai funcionar. Você sempre abre um parênteses quando você vai chamar uma função ou special form, ou macro. A soma, multiplicação, divisão e subtração (+ * / e -, respectivamente) são funções. Concatenação de strings (str) também, bem como map, reduce, split e join. Já o if não é uma função – é uma special form, bem como fn* (retorna uma nova função) e def (define novas variáveis, que os LISPs gostam se chamar de símbolos). E o or, o and, e o defn são macros. Para poder usar todos eles, sem exceção, você tem que abrir um parêntese.

Primeiros passos

Para somar 4 números, abrimos um parêntese e o primeiro elemento é a função da soma. Ou seja:

(+ 5 3 9 7)

Isso vai somar os quatro números. Normalmente deixamos grudado ao parêntese a função que vamos rodar.
Continuar lendo

Publicado em Clojure | Marcado com , | 1 Comentário

Clojure e simplicidade

AVISO – me empolguei um pouco nessa postagem, para uma introdução mais gentil, verifique o post após esse.

Qualquer linguagem baseada em LISP, como Clojure, tem o mesmo problema: as pessoas falam de como a linguagem é fantástica, como ela revoluciona como você programa, até o momento em que você resolve entender por que. Aí você estuda a linguagem, aprende uma ou outra coisa, e não entende porque as pessoas falam tão bem dela.

Esse ciclo se repete várias vezes, e várias vezes, e você nunca entende o motivo das pessoas falarem tão bem. Até um dia em que você finalmente entende – e é aí que você vira uma dessas pessoas que falam bem, mas ninguém mais entende por que.

Clojure é, basicamente, um LISP que roda sobre a JVM. Porém, diferente de common LISP, Clojure possui duck typing – LISP não. É essa foi a primeira realização – tipagem dinâmica não implica em duck typing.

Ruby, JS, e Clojure possuem métodos (ou keywords, ou funções) que rodam sobre qualquer tipo que atenda aquele protocolo. for element in array, por exemplo, roda em Ruby e JS da mesma maneira para Arrays, ou para Objects (em JS) ou Hash, Set, para Ruby. Em Ruby, é porque todos implementam o método .to_a. Já em Clojure, o nth serve para pegar um elemento de uma coleção qualquer, seja ela uma List ou Vector, usando (nth ["some" "elements"] 1). E como é isso em Common LISP? Bom, se for uma List, usa-se: (nth 1 '("some" "elements")). Se for um Vector, com (aref (vector "some" "elements") 1). E assim por diante (o que quer que isso signifique nessa situação, já que nem posicionamento dos parâmetros nem nome das funções é consistente).

A segunda coisa interessante de Clojure é a sua “sintaxe”, ou na verdade, ausência de sintaxe. Na prática, a sintaxe não existe – você programa definido diretamente as S-Expressions, como se fosse uma lista de comandos. Por exemplo:

; uma definição de uma função
(defn sum-ages [people]
  (reduce + (map :age people)))

; uma definição de uma lista
`(defn sum-ages [people]
   (reduce + (map :age people)))

A segunda expressão, apenas pela presença de um “quote”, torna-se uma lista. O primeiro e segundo elementos são Symbol, o terceiro elemento é um Vector que contém outro Symbol, e o quarto elemento é outra List: (reduce + (map :age people)), e assim as coisas continuam. Symbols, em Clojure, serão convertidos em sintaxe mais cedo ou mais tarde, então defn será clojure.core/defn, e chamará a função, símbolo, ou special-form desse nome mais cedo ou mais tarde. E isso é uma coisa fantástica pelos motivos que veremos a seguir. Mas o primeiro deles é bem óbvio: você não tem códigos – apenas dados. E como a linguagem é composta de dados, podemos manipulá-la, moldá-la, e alterá-la com macros. Além disso, Clojure é uma linguagem muito simples – ao contrário por exemplo, de Ruby, aonde a linguagem é complexa, mas programar nela é simples, em Clojure a linguagem é simples, mas programar nela é um pouco mais complicado.

E o motivo, por mais absurdo que pareça, é que nós, programadores, aprendemos a programar de forma errada
Continuar lendo

Publicado em Clojure | Marcado com , , , , | 1 Comentário

Programação funcional, imutabilidade, e previsibilidade

O post de hoje é uma introdução à programação funcional, para podermos entrar finalmente em Clojure. Mas antes disso, vamos falar sobre como aprendemos a programar na faculdade, em cursos, e em todos os lugares. Vamos falar de “orientação a objetos”, principalmente, e vamos falar sobre “abstração”. A programação, como sabemos, é um exercício total de abstração – ao fazer um software, temos apenas um objetivo – fazer com que um trabalho, que provavelmente seria realizado de forma ineficaz ou manual, torne-se automático. Parece uma super-simplificação, mas é verdade. Processadores de texto substituem máquinas de escrever, editores de imagem automatizam vários trabalhos de restauradores, pintores, e desenhistas, e sistemas de folha de pagamento substituem o trabalho de vários matemáticos, contadores, etc. A profissão de todos continua válida – apenas simplificamos um pouco (ou MUITO!) o trabalho deles. E o nosso trabalho, de programadores, é simplificado com linguagens mais modernas, nas quais se escreve menos e se sub-entende mais. E para isso, precisamos aprender a escrever nessas linguagens. E aí entram os cursos, ou a faculdade.

Basicamente, aprendemos a programar nesses cursos, ou na faculdade, pensando em orientação a objetos. Para muita gente, essa é a única maneira sadia de se programar – afinal, orientação a objetos é o paradigma que representa melhor o mundo real, uma frase que muito se ouve. E essa frase é verdadeira, mas com uma pegadinha muito difícil de encontrar: o mundo real é um lugar complicado.

Esse será um post grande, portanto, está dividido em partes. Falaremos sobre a imprevisibilidade, depois mutabilidade e imutabilidade, e na última parte teremos exemplos em Ruby e Clojure sobre trabalhar com dados mutáveis e imutáveis.
Continuar lendo

Publicado em Clojure, Ruby | Marcado com , , , , , | 1 Comentário

Clojure, LightTable, e uma nova forma de programar

Esses últimos meses tenho estudado Clojure, ClojureScript, e me entendendo com o ecosistema de tudo isso. Mas sobre a linguagem fica para outro post. Por hora, vamos a uma frase famosa: A language that doesn’t affect the way you think about programming, is not worth knowing, ou Uma linguagem que não afeta a forma que você pensa sobre programar, não vale a pena aprender. Essa frase, de Alan Perlis, mostra muita coisa do que eu penso antes de aprender uma nova linguagem, e vai explicar muito ao aprender sobre Clojure.

Antes de mais nada, vejamos como as linguagens evoluíram – C++ e Java são linguagens orientadas a objeto. Ruby, Python, e Scala também. Mas vejamos como usar uma lista em Java: abrimos o Java, numa IDE lenta como o Eclipse (que precisa de instalação, etc), importamos a lib…. qual lib mesmo? Bom, entramos num Javadoc, procurarmos a lib…. isso em C++ é pior ainda, já que em Java, pelo menos a IDE completa automaticamente os métodos (e algumas vezes, até os imports) pra nós.

Em Scala e Ruby? Abrimos o console, criamos uma lista, atribuímos a uma variável e digitamos: variable., seguido de alguns tabs e o console completa para a gente. Esse é o poder de um REPL (Read-Eval-Print-Loop, ou console, IRB, etc), e o REPL muda completamente a forma de escrever, explorar, entender e até mesmo de pensar em programação. Precisamos um dado no banco de dados? Entramos no REPL, digitamos User.create!(login: “foobar”), e voilá – temos um objeto criado. Não precisamos criar uma tela de cadastro para criar esse dado, não precisamos abrir o gerenciador do banco, etc.

Isso, com Clojure, é elevado ao limite.

Continuar lendo

Publicado em Clojure | Marcado com , , , , , | 1 Comentário

Alguns meses com CoffeeScript

Recentemente, resolvi testar o editor Atom… Mas isso eu já falei em outro post.

O que eu vim falar agora é sobre CoffeeScript, e a forma como eu tenho programado recentemente envolvendo Javascript.

Estando no mundo Rails, é bem comum a gente acabar usando as ferramentas que o Rails nos disponibiliza. Embora seja uma boa idéia no começo, há uma tendência a ficarmos meio “engessados” numa única tecnologia. Então, resolvi começar um projeto meio ousado de fazer uma UI inteira em HTML + CoffeeScript, sem a intervenção do Rails, e por hora, nem sequer com backend. Talvez eu fale sobre isso num post futuro, mas especificamente agora quero falar de Coffee.

Eu nunca gostei de CoffeeScript, na verdade, por causa da idéia de “indentation-based”. Outra coisa do Coffee é que ele basicamente não faz milagres – tudo no fim das contas é Javascript, e é essa a parte difícil e chata de entender.

Continuar lendo

Publicado em CoffeeScript | Marcado com , , | 2 Comentários

Interface Gráfica com Ruby

Quando se pensa em Ruby, logo se imagina usando Rails. Na verdade, Ruby é uma linguagem completa com suporte a praticamente qualquer coisa. Todo programador Ruby sabe disso, mas esquecemos isso em nosso dia-a-dia.

Muitas pessoas usam várias GEMs para tentar automatizar qualquer coisa – e isso é bem errado. Por exemplo, há várias gems que tentam trazer o ActiveRecord para Sinatra, enquanto que na verdade, tudo o que temos que fazer é o código abaixo:

ActiveRecord::Base.establish_connection(
  adapter: 'sqlite3',
  database: 'some_database.sqlite3'
)

E é a mesma coisa com GUI (Graphical User Interface). Há uma série de gems que tentam trazer uma interface gráfica “fácil” para nós, que na verdade só acabam complicando tudo. Por isso, temos às vezes que simplificar o processo – que no caso de interfaces gráficas, para mim significa usar a gem qtbindings
Continuar lendo

Publicado em Ruby | Marcado com , , | Deixe um comentário