Comparar linguagens de programação, seja discutindo na boa seus méritos e defeitos ou se digladiando em guerras santas do tipo “a ‘minha’ é melhor do que a ’sua’”, é um dos esportes preferidos da galera de informática em geral. Sendo pesquisador justamente da área de linguagens de programação, eu obviamente sou cheio de opiniões a respeito, mas eu evito entrar nos bate-bocas, que costumam ser sempre cansativos e repetitivos (ah, como eu mudei).

Esses dias, porém, li e ouvi alguns comentários que me deram vontade de dar um meta-pitaco no assunto. Dois alunos meus em sala de aula:

– Semestre passado o professor mandou fazer um trabalho de implementação, só que tinha que ser em Lisp.
– Lisp? O que é isso?
– Uma linguagem de programação lá, que o professor disse que era “melhor”.

Não sei se o tal professor disse isso, ou se foi a interpretação do aluno. Mas infelizmente comentários assim são muito comuns, ainda que não faça sentido considerar uma linguagem “melhor” em termos absolutos (melhor do que o que?) ou mesmo em termos relativos de forma não-qualificada. Por mais “tosca” que seja a linguagem X, quase sempre há algum aspecto em que dá pra fazer alguma qualificação do tipo “X é melhor que Y… no aspecto Z”, mesmo que Z seja algum aspecto menos técnico, como “é mais fácil de achar programadores pra contratar” — talvez no frigir dos ovos esse aspecto seja decisivo no negócio. Porém, dá pra argumentar também que nesse caso, não se está comparando as linguagens, mas sim o mercado de trabalho.

E é aí que eu quero chegar. O problema das discussões comparando linguagens é que em boa parte delas, não se está comparando as linguagens em si.

Comparar linguagens é, em primeiro lugar, comparar a especificação da linguagem. Sistema de tipos, estruturas de controle, sintaxe, semântica, biblioteca padrão, APIs para o mundo exterior. No nível mais fundamental, uma linguagem de programação é isso. Claro que isso não é a história completa, mas eu quero fazer um contraste do “resto todo” com a discussão sobre as “linguagens em si”.

Essa não é a história completa porque há muitos outros aspectos que acabam entrando em discussões sobre linguagens, de uma forma meio misturada. Pra citar alguns:

Desempenho - quando se fala de performance, não se está falando das linguagens, mas das suas implementações. Sem contar no “detalhe” de que algumas implementações são mais rápidas que outras em alguns aspectos e piores em outros. Nesse aspecto, o Benchmarks Game é particularmente incompleto porque eles arbitrariamente decidiram incluir só uma implementação de cada linguagem (quando ele ainda se chamava “Computer Language Shootout” tinha várias). Então, se alguém diz “PHP é mais rápido que Python”, está falando da implementação default, CPython? Ou da otimizada, PyPy? Tem uma boa diferença (e o Benchmarks Game usa a mais lenta). E PHP? A implementação original ou o HipHop, o tradutor pra C++ criado pelo Facebook? E estes não são os únicos.

E a linguagem em si? Ainda assim, em vários casos o design da linguagem em si afeta sim a performance que se consegue tirar das implementações: é um dos motivos pelo qual a implementação do tracing compiler de Lua (LuaJIT) tende a ser mais rápida do que a de JavaScript (V8) — a linguagem é menor e mais facilmente otimizável. Evidência disso é que a Mozilla definiu um subset de JS, asm.js, para ser uma implementação voltada a alto desempenho.

Ecossistema - linguagens não existem no limbo, então o suporte em volta é importante: bibliotecas, ferramentas de build, gerenciadores de pacotes, debuggers, IDEs (pra quem gosta), etc. Botei isso tudo sob o guarda-chuva de “ecossistema”, mas certamente esses itens são bem diferentes entre si e têm impactos diferentes (botei eles mais ou menos em ordem de importância pro meu gosto pessoal). Note que eu diferencio as bibliotecas padrão (que eu citei lá em cima na “linguagem em si”) das bibliotecas extras. Essas últimas são uma decisão de design do seu projeto; das primeiras não tem como fugir.

E a linguagem em si? Isso tudo é importante e afeta a produtividade de quem programa, claro. Mas, como no caso do desempenho, há uma diferença fundamental de discutir as linguagens em si: todas essas peças do ecossistema são trocáveis e a linguagem continua sendo a mesma. Você troca do Make pro CMake, mas C++ ainda é C++. Você troca de JQuery para Underscore, mas JavaScript ainda é JavaScript. Você pode optar por usar ou não RubyGems ou o LuaRocks. (E sim, acredite se quiser, há quem programa em Java sem IDE. ;) )

Killer applications - eu poderia botar isso junto com o ecossistema, mas achei que merecia um item próprio. De certa forma, a história das linguagens de programação e suas comunidades é a história das suas killer applications. Não tem como pensar em Ruby sem pensar em Rails, não há como falar de Lua sem citar o seu sucesso na indústria de jogos, de C e não falar de coisas baixo-nível tipo Unix, e assim por diante. E sim, muita gente vai escolher uma linguagem por causa de um framework específico, ou porque ela é “a linguagem que todo mundo usa pra fazer tal coisa”.

E a linguagem em si? Bom, muitas dessas killer applications das linguagens se derivam do design delas, afinal muitas linguagens foram criadas pra fazer alguma coisa específica: todo mundo fala maravilhas da linguagem R para estatística porque afinal, ela foi feita pra isso (e por consequência hoje tem milhares de bibliotecas prontas para estatística). Em outros casos, é quase uma casualidade: Python e Ruby são similares o suficiente para que o Rails pudesse ter sido criado em Python, e de fato hoje não faltam frameworks em outras linguagens que são de certa forma clones “de espírito” do Ruby on Rails.

“JavaScript” vs. “JavaScript: The Good Parts”: enough said.

Nesses casos, o que resta, além de diferenças menores de design dos frameworks (que, sendo, parte do ecossistema, sempre podem ser trocados), são as diferenças fundamentais das linguagens em si. E quão importantes essas diferenças são, já que a (bem) grosso modo dá pra implementar qualquer coisa em qualquer linguagem? São muito. Coisas como a sintaxe, sistemas de tipos, gerência de memória, são diretamente ligadas aos tipos de bugs que a gente tende a produzir quando programa. Você pode arranjar a melhor IDE, o melhor debugger, usar as melhores bibilotecas e frameworks, e ainda vai ser mordido vez que outra por regras de conversão de tipos bizarras. Como disse o Roberto esses dias, você pode ser a pessoa mais cuidadosa do mundo com todos os cantos escuros da linguagem e escolher um “subset seguro” pra trabalhar, mas quando você tiver que dar manutenção do código de outra pessoa (seja colega de trabalho ou código de alguma biblioteca), diga adeus ao “subset seguro”. O resto todo em volta tem jeito — troca-se a VM por uma mais rápida, troca-se a biblioteca por uma mais elegante — mas não há como fugir dos problemas da linguagem em si.

É por isso que PHP e JavaScript, mesmo com os melhores compiladores e as melhores bibliotecas do mundo, ainda vão ser linguagens “toscas”. Por outro lado, linguagens funcionais como Haskell (ou Lisp!), mesmo com toda a sua elegância conceitual, não são linguagens populares, em parte porque falta a elas toda a infraestrutura em volta pra serem uma opção pragmática. Felizmente, porém, o mundo não é feito só desses dois extremos. A gente tem que lembrar que a linguagem é o meio para um fim e que a linguagem que a gente programa não é o nosso time do coração no qual morreremos abraçados. Esses dias mesmo falei para um amigo que eu acho que ele não deve focar em se especializar pra ser um “programador Java” ou um “programador Python”, mas simplesmente um bom programador, e que essa polivalência acabaria rendendo mais em longo prazo. As lições mais importantes que a gente aprende nessa vida de programação se aplicam a todas as linguagens, e como nas linguagens naturais, quanto mais linguagens a gente aprende, mais fácil é aprender uma próxima. (Aliás, aprender uma nova linguagem é uma das melhores maneiras de se “reciclar” mentalmente.)

Moral da história: escolha a linguagem que resolve o seu problema, mas tendo a opção, escolha uma linguagem decente!

Quick-and-dirty notes so I remember how to do it later. This is may all be mostly automatic in some distros (Ubuntu?) but here’s how to do it “by hand”. I may streamline the process myself for my machine in the future, but this is a minimal process that works.

My setup:

• Samsung Galaxy S3 SGH-T999, not rooted
• my own hacked up version of GoboLinux, so this should work on any distro

The steps:

1. Install Droid NAS on your phone. Their description say it “most probably […] won’t work” on Linux, but it is based on Bonjour (aka mDNS protocol) and SMB, and there are Linux clients for that.
2. Create a directory for your local mount point (mine is /Mount/Phone) and then mount it like this:
   

   mount -t cifs -o port=7777 //192.168.0.106/"SD Card" /Mount/Phone

   (You can find your phone’s IP with avahi-browse -altr, if avahi-daemon is running).

TODO: convince mount.cifs to use a logical name instead of IP there. Might need to use avahi and nss-dns for that; by the way, if you get an error such as “Connection “:1.10” is not allowed to own the service “org.freedesktop.Avahi” due to security policies in the configuration file” when using avahi-daemon, follow the instructions found here).