“How much does a choice of language really matter? Are there good reasons to choose one language over another or does it all come down to taste?”

E sua resposta foi:

“I think it matters quite a bit. A good language is opinionated, and strives to make a particular style of programming easy and idiomatic. It only seems a matter of taste when you are comparing languages that are more similar than they are different, like Java/C# or Python/Ruby. Try something really different like Clojure, Haskell, or Erlang and the fact that it matters becomes readily apparent.”

Eu acho que concordo bastante com sua opinião. Discutir se Java é melhor do que C#, por exemplo, é inútil, porque as duas linguagens são muito semelhantes. Nesse caso, o que acaba pesando mais na hora da escolha é o ecosistema no qual cada linguagem está inserida, que pode agradar mais a um ou a outro programador. É puro gosto.

O mesmo vale para Ruby e Python, como ele mesmo cita.

Mundos diferentes

Mas e se a comparação for entre Java e Ruby, por exemplo, como é que fica? Na minha humilde opinião, fica no sense. Porque Java e Ruby não são liguagens de mesma proposta; e mesmo sendo ambas de propósito geral, ambas tem objetivos claramente diferentes.

Comparação entre mundos diferentes

Agora vou, propositalmente, contradizer um pouco o que eu disse à cima: faz sentido, sim, você comparar Ruby com Java; Erlang com Python; F# com PHP. Sim, faz sentido.

Faz sentido quando você está escolhendo a linguagem que oferece a melhor solução para um dado domínio de problema.

Super CRUD com Erlang? Não, acho que não.

Precisar de concorrência massiva, tolerância a falhas, processos distribuídos, downtime mínimo? Humm, não sei não, mas será que não é de Erlang que você precisa?

Entende? É nessa hora que a escolha de uma linguagem começa a pesar de verdade. Isso realmente importa.

Mundos diferentes se complementam

Tempos atrás, escrevendo programas Erlang/OTP, senti falta de uma ferramenta que me ajudasse a criar rapidamente a estrutura inicial do projeto e umas coisas mais. O que fiz? Criei uma ferramenta que faz isso: otp_kickoff. Em Erlang? Não, em Ruby. Fiz isso em poucas horas, usando Thor.

Pouco tempo depois, senti falta de uma ferramenta de build amigável. Novamente, o que fiz? Criei o ebuilder, usando Ruby/Thor.

Um outro exemplo de mundos diferentes que se complementam é o JSparrow, um cliente de JMS bem fluente, que fiz usando JRuby.

Essa é a ideia de tirar o melhor de cada linguagem!

Mesmo porque, dificilmente, você constroi um sistema de verdade – que não seja um super CRUD – com apenas uma única linguagem de programação. Na minha equipe mesmo, há sistemas desenvolvidos em C# .NET, que são buildados, testados e deployados com Ruby/Rake/Cucumber e usam Java/Ivy como repositório de assemblies. Isso sem falar em JavaScript, que também tem de monte.

Esse é o mundo real dos sistemas de verdade.

Moral da história

Isso me faz pensar que brigas de fanboys de linguagens – em frenéticas buscas por prosélitos – são uma verdadeira piada.

A deixa final

Como já disse algumas vezes aqui no blog, em meus times, além de alguns legados, lidamos basicamente com Ruby on Rails, C#/ASP.NET MVC e Git como DVCS. Então, além de um bom editor de textos e um terminal, precisamos também de um Visual Studio – com ReSharper, porque sem isso, ele não é nada – que, infelizmente, para usuários de Mac e Linux, só roda em Windows. Tentei resolver isso usando Mono, mas acabei desistindo – por enquanto, porque vai ter revanche!

Bem, resolvi então usar o Parallels Desktop 5 para rodar o Visual Studio 2010 no conforto do meu Mac e, de tabela, adicionar mais um monitor à minha área de trabalho.

Meu space de programação

Pra mim ficou fantástico! Porque no meu space de programação deixei o Visual Studio maximizado na tela grande (à esquerda), rodando no Windows, que por sua vez está rodando no Parallels Desktop, em tela cheia e com look & feel de Mac OS X; e na tela do Mac (à direita) – que eu adoro! –, deixei o terminal, onde posso interagir com o Git e tudo mais. Yay!

Visual Studio 2010 no Windows (à esquerda); Terminal no Mac OS X (à direita)

E tem mais: quando não precisar usar o Visual Studio por um longo tempo, tenho duas alternativas:

- desligar o Windows;
- ou simplesmente pausá-lo no Parallels Desktop.

E se for o caso, arrastar o TextMate pra tela grande.

Ficou muito bom isso, o Parallels Desktop é demais!

Meus outros spaces

Uma área de trabalho dessas não serve só pra programação. Hoje mesmo precisava editar um wiki enquanto olhava dados em uma planilha. Sem problemas! Planilha na tela grande e wiki sendo editado na tela do Mac. Fantástico!

Só faz um dia que estou com essa área de trabalho expandida e sinto que não posso mais trabalhar sem ela. hehehe

Há alguns meses, quando comecei a mexer mais com Erlang/OTP, senti a necessidade de ter uma ferramenta que gerasse a estrutura dos projetos, bem como stubs dos módulos necessários. Não encontrei nenhuma que fosse realmente simples. O que fiz? Cocei minha própria coceira, crie o projeto otp_kickoff.

Agora, de saco cheio desconfortável de usar Make para automatizar tarefas de build, resolvi coçar minha própria coceira novamente, crie o projeto ebuilder.

Se você também está mexendo com Erlang/OTP, sugiro que dê uma olhada nestes projetos, quem sabe eles também não facilitam sua vida, ahmmm?

Erlang nasceu no laboratório de ciência da computação da Ericsson na década de 1980, influenciada por linguagens como ML, Ada, Module, Prolog e Smalltalk, quando um time de três cientistas – entre eles, o grande Joe Armstrong – receberam a missão de descobrir qual seria a melhor linguagem de programação para escrever a próxima geração de sistemas de telecom. Após dois anos de investigação e prototipação, estes cientistas descobriram que nenhuma linguagem era completa o bastante para tal objetivo e, conclusivamente, decidiram criar uma nova linguagem. Nasceu então Erlang, the Ericsson Language.

De lá pra cá, Erlang tem sido evoluida e usada para escrever grandes sistemas críticos, porque é exatamente nesse cenário que Erlang faz mais sentido. Se seu projeto é construir um sistema crítico, altamente tolerante a falhas, com disponibilidade 24×7 e veloz como o papa-léguas, sim, Erlang é para você. Mas se não é bem esta sua necessidade, se você quer apenas construir um pequeno sistema, com baixa concorrência, poucos usuários, pouca necessidade de performance e possibilidade de passar horas down em manutenção, não, você não precisa de Erlang. Que tal Basic?

Diferente de algumas linguagens que nascem para encontrar um nicho, Erlang nasceu com um problema a ser resolvido, com requisitos a serem atendidos. Tolerância a falhas, concorrência realmente pesada, computação distribuída, atualização da aplicação sem derrubá-la, sistemas de tempo real, este é o nicho de Erlang; foi para isto que Erlang nasceu.

Quem usa Erlang atualmente?

Além da Ericsson, é lógico, há algumas outras grandes empresas e projetos usando Erlang, como por exemplo:

- Facebook, no backend de seu sistema de chat, lidando com 100 milhõs de usuários ativos;
- Delicious, que tem mais de 5 milhões de usuários e mais de 150 milhões de bookmarks;
- Amazon SimpleDB, o serviço de dados do seu poderoso EC2;
- Motorola, CouchDB, RabbitMQ, Ejabbed, etc.

Ok, mas Erlang é propriedade da Ericsson?

Não, felizmente, não. Em 1998 a Ericsson tornou Erlang open source sob a licença EPL.

Quer mais uma boa notícia? Você não precisa de um servidor de aplicações para rodar sua aplicação Erlang, nem mesmo uma pesada IDE para escrevê-las. Tudo o que você precisa é de uma distribuição de Erlang para sua plataforma, seja Mac OS X, Linux, Windows, Solaris, ou qualquer outro sistema Unix-like, que traz consigo máquina virtual, compilador e vasta bibliotéca de módulos muito úteis – além do banco de dados Mnesia; e um editor de textos de sua preferência – TextMate, por exemplo, tem um ótimo bundle para Erlang.

Algumas características de Erlang

1- Expressividade e beleza

Há quem diga que não, mas Erlang é uma linguagem muito bonita — ao menos pra mim. Dado as já citadas influências de Erlang, ela é uma linguagem bem expressiva e declarativa, que encoraja a escrita de código simples e objetivo, o que certamente torna seu código fácil de ler, de escrever e de organizar [em módulos reutilizáveis]. O snippet abaixo é um exemplo de implementação do famoso fatorial:

-module(sample1).
-export([fac/1]).

fac(0) -> 1;
fac(N) -> N * fac(N-1).

2- Forte uso de recursividade

Isto certamente é uma herança da veia funcional de Erlang que torna o código muito menos imperativo e mais declarativo. Mas além da beleza declarativa óbvia, é importante saber que Erlang foi projetada para lidar com iterações recursivas gigantescas sem qualquer degradação – e sem estourar o “heap” de memória.

3- Livre de efeito colateral

Uma das grandes capacidades dadas por Erlang é a construção de sistemas altamente concorrentes rodando em processadores com multiplos núcleos. Isto não combina nada com efeito colateral, por isso, em Erlang, uma vez que um dado valor tenha sido atribuído a uma variável, esta não poderá mais ser modificada – ou seja, estão mais para o que conhecemos por constantes do que para o que conhecemos por variaveis.

Se você já escreveu código concorrênte sabe o quanto tê-lo livre de efeitos colaterais te faz livre de dores de cabeça. Poucas coisas são tão deprimentes quanto debugar código concorrênte repleto de efeitos colaterais.

4- Pattern matching

Pattern matching em Erlang é usado para associar valores a variáveis, controlar fluxo de execução de programs, extrair valores de estruturas de dados compostas e lidar com argumentos de funções. Mais um ponto para código declarativo e expressividade. Vejamos o código abaixo:

-module(sample2).
-export([convert_length/1]).

convert_length(Length) ->
    case Length of
        {centimeter, X} ->
            {inch, X / 2.54};
        {inch, Y} ->
            {centimeter, Y * 2.54}
    end.

Fala por si, não?

5- Concorrência baseada em passagem de mensagens (a.k.a. Actors)

Acho que concorrência baseada em passagem de mensagem entre atores é uma das features mais populares de Erlang. Vejamos o porque com o famoso exemplo do Ping-Pong:

-module(sample3).

-export([start/0, ping/2, pong/0]).

ping(0, Pong_PID) ->
    Pong_PID ! finished,
    io:format("Ping finished~n", []);

ping(N, Pong_PID) ->
    Pong_PID ! {ping, self()},
    receive
        pong ->
            io:format("Ping received pong~n", [])
    end,
    ping(N - 1, Pong_PID).

pong() ->
    receive
        finished ->
            io:format("Pong finished~n", []);
        {ping, Ping_PID} ->
            io:format("Pong received ping~n", []),
            Ping_PID ! pong,
            pong()
    end.

start() ->
    Pong_PID = spawn(sample3, pong, []),
    spawn(sample3, ping, [3, Pong_PID]).

Neste pequeno snippet podemos observar algumas características de Erlang já citadas neste post, tal como pattern matching na captura das mensagens e recursividade no controle das iterações.

Agora, falando do aspecto concorrente em sim, algumas coisas são particularmente interessantes aqui:

a. Em Erlang, a concorrência acontece entre processos leves, diferente de linguagens como C++ e Java, que baseiam sua concorrência em threads nativas de sistema operacional [caríssimas];
b. Em Erlang, há um tipo de dado chamado PID, o qual é o identificador do processo paralelo (mais conhecido como Actor) e para o qual as mensagens podem ser enviadas.

Releia o código acima com estas informações em mente e veja como concorrência em Erlang é algo completamente descomplicado e natural. Depois, pense no mesmo código implementado em C#, Java ou C++.

Gostei de Erlang, há algum livro para eu começar a estudar?

Sim, há dois livros excepcionais. Um, do próprio criador da linguagem, Joe Armstrong:

E outro de Francesco Cesarini e Simon Thompson:

Além disso, há o próprio material on line que é muito bom e barato.

Conclusão

Erlang possui muitas outras características e informações bem interessantes, mas que me falta espaço neste post para citar e apresentar, senão ele ficará absurdamente gigantesco para o meu gosto. Mas acredito que pelo que já apresentei até aqui, você já tenha motivos suficientes para pensar em Erlang com carinho e conciderá-la para seu próximo grande projeto.

Em breve devo escrever algo sobre OTP, já que neste post apresentei características mais inerentes à linguagem em si e nem tanto sobre a plataforma.

Até mais!

O primeiro canal é o do famoso getting started, como estamos acontumados a encontrar em outras linguagens, só que em três versões diferentes, uma para cada saco gosto para leitura. Tem a versão rápida, a lenta, e a muito, muito, muito lenta. Já o segundo canal é uma coleção de diversas publicações interessantes, que vale a pena ao menos saber que existe.

Bom, com todo esse material disponível, seria chover no molhado eu querer dizer “o que é Erlang”, “qual o seu propósito”, e “blá blá blá”. Os materiais supra citado já fazem isso muito bem.

Em lugar disso, vou deixar aqui um passo a passo sucinto para instalar no Ubuntu a versão mais atual a partir dos fontes (já que não queremos a versão desatualizada disponível por apt-get) e mais alguns links para estudo rápido e mastigado. Ou seja, vou te dar um empurrãozinho te ajudar a dar o seu próprio pontapé inicial no aprendizado de Erlang.

Lembrando que, mesmo que você seja usuário de Windows, não há problema algum, este post também é pra você. Basta você fazer o download do .exe de instalação mais atual aqui e pular o próximo tópico.  E, caso você seja usuário de outra distro de Linux, I’m so sorry! Você vai ter que procurar sua própria receita de instalação no Google.

Instalação no Ubuntu

Antes de começar a instalação, você precisará fazer duas coisas:

1) Criar o diretório onde você fará a instalação

No meu caso, o path que é:

/home/leandro/Desenvolvimento/erlang/tools/otp_r12b-5

Vou usá-lo em toda a receita, então, fique atento e não se esqueça substituir pelo seu próprio path.

2) Baixar a última versão dos fontes aqui e depois descompactá-la no diretório criado no passo anterior

Feito isso, ótimo! É hora de começar a instalação de verdade. Vamu qui vamu!

1) Instale o conjunto básico de ferrametas para fazer o build

sudo apt-get install build-essential libncurses5-dev m4

2) Instale um conjunto de ferrametas de SSL, caso você ainda não tenha

sudo apt-get install openssl libssl-dev

3) Execute a configuração do build

./configure

4) Faça o build!

make && sudo make install

Aguarde, aguarde, aguarde…

5) Configure o diretório bin no PATH do sistema

Com seu editor de texto preferido, edite o arquivo /etc/bash.bashrc e insira o bloco abaixo:

# Setting the ERLANG_HOME and PATH to Erlang otp_r12b-5
ERLANG_HOME=/home/leandro/Desenvolvimento/erlang/tools/otp_r12b-5
PATH=$ERLANG_HOME/bin:$PATH
export ERLANG_HOME PATH

Ou faça como você preferir, esse passo é bem a la vonté mesmo.

6) Teste!

No console, digite erl. Se carregar o Erlang (BEAM) emulator é porque está tudo OK!

Se não carregar o Erlang (BEAM) emulator, revise os passos anteriores com calma, para ver se você fez tudo certinho, se não errou ou se esqueceu de algum detalhe. Caso ainda tenha problemas, o Google é seu amigo!

Mais dicas de referências

Como disse, além dos links que citei no início que estão realmente repletos de material interessante, queria indicar também uma série de posts do Caio Ariede, que também está aprendendo a fantástica Erlang.

Outra dica é um projeto que criei no meu GitHub [que vergonhosamente não tinha nada desde outubro] para colocar os códigos dos meus estudos, mas até agora só subi uns poucos programinhas bem didáticos do Getting Started Lento. Vamos ver se logo arranjo um tempo para organizar a coisas por aqui e subir mais coisas legais. Fique de olho nele.

Mais uma, ainda no GitHub, é o projeto que o Nando Vieira criou para publicar suas anotações da leitura do livro Programming Erlang, Software for a concurrent world, de ninguém menos que Joe Armstrong.

E para finalizar, não deixe de ler meu post sobre programação funcional, se você quiser ter uma rápida introdução a esse assunto.

É isso ai, até mais!!!

No entanto, hoje, li uma notícia sobre Clojure que me fez pensar um pouco além da própria programação…

“Por que as pessoas normalmente não tentam fazer as coisas de outra maneira?”

Achei muito interessante o fato de terem usado Clojure, que é uma linguagem jovem, para implementar concorrência em um grande e importante sistema de informação, mesmo não havendo ainda relatos de que já o tenham feito antes.

Inovação, pioneirismo, pragmatismo… Pensamento fora da caixa!!!

Isso também é sobre ser inteligente. Se já inventaram a solução do problema de concorrência, de maneira elegante, por que ainda ficar batendo cabeça com linguagens “consolidadas”, mas que não o resolvem tão eficientemente? Aham? Por que a linguagem ainda é muito nova?

Esse é só um exemplo, mas há muitos outros em nosso dia a dia. Dê uma olhada ao seu redor. Dê uma olhada em seus próprios desafios. Aliás, aproveite, e dê uma olhada em suas próprias soluções!

O quanto você tem sido tradicionalista e conservador?

O medo das novas soluções, das novas maneiras de fazer as coisas, normalmente, são um atraso para os novos bons resultados. Afinal de contas, normalmente, quem sai na frente lucra primeiro…

Leitura obrigatória!

Aliás, falando em JBoss Seam, a Caelum lançou um super curso, rápido e objetivo, que você pode conferir o conteúdo programático aqui. Como sempre, qualidade indiscutível.

O que ocorre é que ontem um cara que tem um blog legal, o Diego, fez um comentário num de meus posts que me fez pensar a respeito… Até agora…

Na hora, sinceramente, não tive nada de muito substancial para responder, porque ainda não havia pensado a respeito. Mas tenho que confessar que isso ficou martelando a minha cabeça o tempo todo… Existe alguma vantagem de se usar Groovy invés de JRuby?

Bem, lendo e pensando a respeito, cheguei a algumas simples conclusões:

Se você tem familiaridade com Java e quer permanecer 100% no ambiente Java, sem a perspectiva de migrar, Groovy é a melhor opção pra você.

Porque a sintaxe de Groovy é muito parecida com a de Java; Groovy traz consigo uma porção de vantagens de uma linguagem OO moderna e dinâmica, como meta-programação, duck type, e closures; e você ainda pode programar usando objetos Java e Groovy numa mesma classe, de forma totalmente transparente (já que .groovy ao ser compilado se transforma em um .class qualquer).

Só que, mais uma vez: Não há qualquer possibilidade de se rodar código Groovy fora de ambiente Java, porque Groovy foi especificamente criada para ser uma “alternativa” à linguagem Java.

Se você quer que seu código seja portável para outras plataformas de runtime, tal como .Net, por exemplo, JRuby é o melhor pra você.

Acho que este é um dos fatores primordiais na escolha de JRuby invés de Groovy. Porque o fato da sintaxe de Groovy ser próxima à de Java, sinceramente, pra mim não quer dizer nada – aprender uma nova sintaxe não é coisa de outro mundo; e é até legal. Agora, portabilidade, isto sim faz a diferença – quando necessário, claro.

Você pode escrever, por exemplo, uma aplicação Ruby on Rails comum e coloca-la para rodar em um web container Java, sem muito esforço. Aliás, se você estiver usando o NetBeans, ele faz isso pra você em um ou dois cliques. E se num dado momento decidir rodar, sei lá, num Mongrel, tudo bem, você pode fazer isso sem problema algum. Isto é fantástico!

Se você quiser se manter 100% compatível com a MRI, isto é totalmente possível, porque JRuby é uma implementação completa de Ruby para a plataforma Java. E se você quiser aproveitar algum código escrito em Java, você também pode fazer isto – mas neste caso, claro, sacrificando a portabilidade.

Outro fator primordial que vejo é “comunidade”.

A comunidade JRuby tem crescido a cada dia – claro que por conta do próprio Ruby/Rails. E a indústria de software tem investido nisto, aja vista o ótimo suporte do NetBeans a Ruby/Rails; e a própria contratação de membros chaves do JRuby pela Sun há algum tempo.

E a comunidade Groovy? Bem, acho que Grails tem ajudado a levanta-la. Mas o seu barulho ainda não é dos maiores não. (Espero que isto mude.)

E o fim deste pensamento, qual é?

Use JRuby. Use Groovy. Use o que melhor atender aos seus próprios requisitos e aos de seu cliente. Porque não há apenas uma linguagem de programação, nem uma única solução pra tudo!

Atualmente estou propenso a usar tanto JRuby [on Rails] quanto Groovy [on Rails]. O que vai me fazer decidir entre um e outro serão os requisitos do momento – e a expectativa futura.

Então, seja JRuby ou Groovy, o que importa é desenvolver o software certo, no tempo certo, com a qualidade certa.

(Valeu Diego, por me fazer pensar um pouco sobre isto.)

Até a próxima!

O que Grails, afinal?

Grails é a resposta da Plataforma Java ao desenvolvimento web ágil, dinâmico, sem toda aquela parafernália de 7.203 arquivos XML para configurar, 3.412 classes dos frameworks jAbc, J-XPTO e JSeila Oq+ para estender, e mais uns 1.300 arquivos JAR para “bibliotecar”.

Esta maravilha do mundo Java segue a filosofia de frameworks web full stack, tais como Ruby on Rails e Django. E segue fundamentalmente o conceito de Convention over Configuration, que pode ser resumido em uma simples frase: “É ótimo poder configurar, mas é péssimo ser obrigado a fazer isto”. Sendo assim, tudo tem um padrão de nome a seguir e um local bem definido para estar.

O que está por trás?

Grails não foi construido a partir do nada. Muito pelo contrário. Ele está fundamentado sobre frameworks de mercado mais que consagrados:

- Hibernate, sobre o qual esta o GORM (Grails ORM);
- Log4J, controle de log;
- Spring, injeção de dependência e MVC;
- Jetty, web container embutido;
- SiteMesh, templates de página web.

E tudo isto sendo “colado” e “manipudalo” pela linguagem Groovy, que para quem viveu os últimos anos em Marte, é uma linguagem orientada a objetos, fortemente tipada e dinâmica, desenvolvida para a Plataforma Java, como alternativa à própria linguagem Java.

Vale a pena usar Grails?

Para o seus projetos, só você mesmo pode responder. Mas o fato é que já existe muita coisa por ai rodando em cima de Grails. Um exemplo? O site da PepsiCo, por exemplo, que é um caso relatado no site do Grails.

Minha opinião? Se você quer uma alternativa dinâmica ao desenvolvimento web rápido para a Plataforma Java, dê uma olhada em Grails. Você não vai se arrepender.

Agora, se para você, desenvolvimento “confiável” e “bem feito” é sinônimo de centenas de milhares de XMLs, JARs, frameworks, e linguagem estaticamente tipada (porque o compilador te faz errar menos), esqueça Grails. (Mas… Uma dica: Sai dessa, meu chapa!!! rsrsrs)

Valeu!