Entrei no site da venda de ingressos pro Guns n’ Roses às 10 da noite (22:02 talvez?).

“Sua posição na fila é 25504”.

Fui até uma meia-noite e pouco olhando o número cair lentamente, até que o Rakan me lembrou que eu sei programar, aí eu escrevi esse script abaixo pra “tocar um alarme” quando a fila chegasse perto no final. Botei o computador do lado da cama e fui dormir. 7 da manhã do dia seguinte, acordo ao som de Nightrain ao vivo. Acompanhei os momentos finais da fila e, enfim, consegui comprar o meu ingresso!

Meu amigo Evandro postou o link para um belo texto, a que ele precedeu com o seguinte epigrama, cirúrgico:

Meritocracia individual vs meritocracia social.

Desvendando a espuma: o enigma da classe média brasileira

Recomendo bastante a leitura.

Acho bem interessante levantar essa questão do significado de “meritocracia”. É uma palavra cuja conotação foi mudando em tempos recentes.

Há alguns anos o termo definitivamente não estava na ordem do dia. Eu nunca tinha ouvido ninguém falar.

O primeiro contato que tive com o termo era dentro de comunidades de software livre, pra explicar como as coisas funcionam lá. Ali, eu achei uma ideia ótima. Sempre fui defensor.

Recentemente, teve essa inversão. A tal “classe média reacionária” de que o texto fala começou a defender o status quo de qualquer desigualdade. E fazer isso sempre em nome da tal meritocracia. Aí as coisas começaram a ficar estranhas pra mim. Não demorou pro pessoal de esquerda abraçar o discurso “abaixo a meritocracia!”. Eu, que não nego que sou de esquerda, fiquei olhando com uma cara de “ei, peraí, mas mas…”

Aí o texto (e o preciso destaque de cinco palavras do Evandro) desata esse nó claramente. Tem uma diferença fundamental entre as meritocracias do parágrafo anterior e a do anterior a esse. A meritocracia no mundo do software livre é uma meritocracia entre membros que têm condições iguais. Todo mundo ali é programador, tem formação, acesso a computador, internet, etc. Dadas todas essas condições, aí realmente fica aquela coisa do “quem contribui mais, apita mais”. Na outra, é uma “meritocracia” onde muito poucos têm sequer chance de mostrar algum mérito. E se a maioria está de fora, é mesmo o mérito que define quem está no topo?

Só que até na meritocracia bonita do software livre a coisa tem uns furos não totalmente aparentes. E nem estou considerando que estamos olhando só pro universo da informática, o que já é uma restrição. Quem não tem o perfil típico tem dificuldades pra entrar nas “panelas”, não importam seus méritos. Vide os casos de sexismo em conferências e comunidades de desenvolvedores, por exemplo. Cadê a meritocracia? Outro ponto foi levantado por um amigo no Twitter. “Open-source development is not as much as a meritocracy as it is a have-enough-time-ocracy”… Acaba que os mais presentes/insistentes muitas vezes “vencem pelo cansaço” as discussões.

Igualitarismo é às vezes visto como o contrário do culto ao mérito. Afinal tem o problema do “freeloader” que se encosta no “sistema”, etc. Mas o que eu acho é que estruturas como a do software livre geram condições mais igualitárias por design. Considere o conceito do copyleft, por exemplo: “usou o código aberto, agora abre o seu código também”. Isso acaba abrindo mais espaço para o verdadeiro mérito se destacar, uma vez que o “campo de jogo” está mais nivelado. Software livre sozinho não resolve, vide os problemas que apontei. Além disso há modelos mais e menos simétricos de software livre. Mas acho que aponta um tipo de modelo possível. É diferente do igualitarismo “top-down” de Estado. Infelizmente, vejo essa ideia expressa muito pouco em outros lugares.

É preciso, como disse o texto, criar uma outra cultura do mérito. Além disso, precisamos de novos conceitos de igualdade. Afinal, ambos estão em falta.

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!

Como não ficar no escuro em caso de segmentation fault:

1) Compile o programa com símbolos de depuração

Use a flag “-g” do gcc para compilar o programa com símbolos de depuração. Certifique-se que todos os objetos estão compilados com “-g”. Você pode precisar dar “make clean”.

2) Seu ambiente deve estar com “core dump” habilitado

Ao ocorrer um “segmentation fault”, o Linux pode gerar um arquivo que é imagem da memória do programa na hora que ele “deu pau”, o chamado “core dump” (curiosidade: o “core dump” tem esse nome por causa da memória de ferrite dos anos 1950-1970, que era chamada de “magnetic-core memory“, ou simplesmente “core”). Com o arquivo de “core dump”, podemos fazer a análise post-mortem do processo e descobrir por que ele explodiu.

Digite “ulimit -c” no seu shell. Se ele retornar “0”, o sistema não irá gerar os arquivos “core”. Digite “ulimit -c unlimited” para remover a restrição de tamanho aos arquivos core. Esta é uma configuração por processo, que é herdada pelos processos filhos (portanto, só vale no terminal onde foi digitada). Para torná-la “permanente”, você pode configurar isso no seu .bash_profile, .zshrc ou equivalente.

3) Rodando o gdb

Com o binário e o core dump na mão, rode o gdb:

gdb ./meu_programa_bugado core

(Dependendo da distro, o arquivo core pode ter o número do processo no seu nome, como “core.1234”)

4) Comandos básicos do gdb

Com esses comandos básicos, podemos analisar os dados de um core dump:

• bt - (ou backtrace), mostra a pilha de execução, indicando o arquivo e linha onde seu programa caiu. bt full mostra também as variáveis locais de cada função na pilha.
• up e down - sobem e descem níveis na pilha. Útil para usar o comando:
• print expressão - o comando print é bastante poderoso: ele pode exibir variáveis e usar boa parte da sintaxe de C. Use-o para inspecionar seus dados:
• print x
• print ((char*)x)[4]
• print &x
• print x->y
• …
• quit - porque eu sempre erro e escrevo exit!

Há muito mais que se pode aprender sobre o gdb — é um debugger completo capaz de depurar o programa enquanto roda (gdb -p pid), lidar com threads, etc… mas esse conjunto pequeno de comandos apresentado aqui já é uma mão na roda para decifrar os “segmentation faults”!