Terminal Velocity

Não, não se trata de um fenômeno físico, nem de um videogame, e muito menos de um filme com Charle Sheen. Já que passo a maior parte do dia na frente de um emulador de terminal (a famosa "tela preta com as letrinhas"), observei que em alguns casos a user experience (se é que posso falar assim de CLI) é mais fluida e agradável do que em outros.
Em outras palavras, bandwidth de saída de caracteres na tela é bastante variável.
Isso é evidente em programas que subvertem a ideia do texto linear, os fabulosos TUI, tais como Vim ou Midnight Commander. Não é tão evidente em libcaca ou icat, pois são poucas as pessoas que sabem o que é isso e um número ainda menor encontra alguma utilidade para eles.
Felizmente, tendo reduzido "usabilidade" em "bandwidth", quantificar a métrica se torna fácil. É só pegar um texto grande, jogar na tela e cronometrar. "Texto grande", no caso do meu teste, foi o código-fonte do Perl v5.16.0, "colorificado" através de source-highlight:
find ~/perl-5.16.0 -type f -name '*.[cht]' -or -name '*.p[lm]' -exec \ source-highlight --failsafe --infer-lang -f esc --style-file=esc.style -i {} \; |
Depois, listei esse arquivo em cada emulador de terminal, dentro de VMs respectivos de cada OS (isso é, VM de Linux, de Windows e de Mac OS). VM fez-se necessário para "nivelar por baixo": seria injusto comparar VMs de Windows e Linux com o Mac OS nativo. Não mexi em configurações/preferências dos emuladores de terminal: fontes, cores e tamanho da tela são os default de cada "fabricante". O resultado está no gráfico no começo do post, e também nessa tabela:
| Terminal | Time (sec) |
|---|---|
| iTerm2.app (Mac) | 12.72 |
| Terminal.app (Mac) | 41.03 |
| xterm (Mac) | 41.52 |
| mintty (Win32) | 14.86 |
| xterm (Linux) | 29.70 |
| Gnome Terminal (Linux) | 61.68 |
| 80x24 text-mode console (Linux) | 276.68 |
O que salta aos olhos é que justamente o Linux, o sistema que contribuiu tanto para o "revival" do CLI, é o que tem emuladores de terminal mais lentos. E o terminal mais simples (aquele que no Linux é acessível via Ctrl+Alt+F1; a telona DOS clássica) é, contra-intuitivamente, o mais ineficiente!
É claro que esse benchmark é muito tosco. Talvez seria mais representativo utilizar a mesma fonte em todos os terminais testados, e também maximizar a tela dos mesmos (a quebra de linhas longas costuma ser custosa), além de desabilitar o histórico de scrollback. Fonte com/sem antialiasing e uso/não-uso de ANSI escape sequences também interferem na velocidade da saída. Mas, enfim: a diferença de velocidade é suficientemente grande e perceptível. Portanto, duvido muito que algum ajuste fino deixará Gnome Terminal mais rápido do que iTerm2.app.
InterNOT Explorer

Antes de me taxarem de hater ou fanboy: já usei muito o Internet Explorer. Também já usei muito o Netscape, Mozilla, Opera, Firefox e Chrome. E "muito", para mim, traduz como "por mais de um ano". Só não usei o Safari pois a primeira coisa que fiz ao migrar para Mac foi instalar um navegador familiar, para não se sentir tão deslocado.
Acredito que usei todos esses navegadores no seu auge, dadas as circunstâncias: Opera era imbatível nos Lentium com 32MB de RAM da faculdade. Firefox era absurdamente mais leve do que o Mozilla, e tão completo quanto. Depois que engordou, migrei pro Chrome. Netscape Gold não tinha muitas alternativas na época do Windows 3.11. E o Internet Explorer... Por um bom tempo estava na vanguarda, era leve e com recursos (proprietários) muito interessantes.
Como sempre acontece, tudo o que sobe, tem que descer. Hoje, todos os webdevelopers odeiam o Internet Explorer e vibram com a perda do browser share pelo mesmo, porém, parafraseando o Mark Twain, "os rumores sobre a sua morte são, sempre, um tanto exagerados". Independente da métrica adotada (pois, dependendo da métrica, o share do IE varia de 16.7% a 32.31%, na metade de 2012), o declínio da popularidade é evidente.
Esta seria a história do lado dos usuários. Mas o que me chamou atenção, recentemente, é a história do lado dos webdevs. Especialmente essas três notícias:
- Startup afirma ter economizado 100 mil Obamas deixando do lado a compatibilidade do seu produto com o Internet Explorer;
- Online shop cria "imposto Internet Explorer": clientes usando esse navegador pagam mais (a justificativa é a dificuldade de manter uma versão compatível do site);
- jQuery 2.0 abandonará o suporte a Internet Explorer 6, 7 e 8.
Seria equivocado afirmar que são essas as medidas que colocarão os últimos pregos no caixão do infame navegador da Microsoft. Para mim, estas são as evidências de que o seu share está, de fato, baixo o bastante para ser desprezado.
Extreme WYSIWYG
Essa semana, Slashdot nos contemplou com dois deliciosos eye-candies na área de interface e usabilidade:
Gliimpse
Devo confessar que, se eu tivesse como utilizar esse tipo de preview para redigir HTML, esse blog teria updates muito mais frequentes :P
Não me habituei com nenhum editor WYSIWIG, e até os meus slides faço em POD e renderizo com S5.
Realmente, me parece uma bela de uma mão na roda!
Light Table
Light Table - a new IDE from Chris Granger on Vimeo.Demais esse conceito de IDE + REPL, que está para virar protótipo!
Só vejo um porém. Exemplificando metaforicamente: a melhor definição de uma "linguagem de programação" que conheço é "capacidade de produzir loop infinito". Por isso, falar "programador HTML", por exemplo, é meio que nonsense. Agora, apesar do loop infinito ser tão importante na teoria, não é nada bom na prática. Por exemplo, digitar
:(){ :|:& };:na linha de comando do Linux ou Mac e dar ENTER leva ao suicídio do sistema operacional. Enfim, quem já programou em JavaScript e usoualert()para debugar, sabe do que estou falando:)Agora, o cara usou um exemplo muito feliz: IDE dele é totalmente voltada para linguagens funcionais, tanto que a menor unidade de código, para ele, é a função. Por obséquio, linguagens funcionais não tem loop! Tem recursão, que até pode ser infinita, mas convenhamos: quem domina programação funcional, dificilmente vai cometer essa gafe...
Concluindo: a ideia é genial, mas daria certo para poucos. O meu palpite é que surgirá a versão dessa IDE para trabalhar com JavaScript, tanto client- quanto server-side (Node.js), pois JavaScript, surpreendentemente, é funcional (tecnicamente falando, JavaScript é quase um Domain Specific Language de Scheme, que é dialeto de Lisp).