Elmord's Magic Valley

Computers, languages, and computer languages. Às vezes em Português, sometimes in English.

Divagações sobre a vadiagem, dominação mundial, e outras pertinências

2013-02-05 01:43 -0200. Tags: life, mind, comp, wrong, em-portugues

A situação ao final de julho do ano passado era a seguinte: depois de muitos semestres com uma quantidade apreciável de disciplinas menos-que-maravilhosas, eu teria um semestre com apenas 10 créditos de cadeiras, uma monitoria mui pouco time-consuming, morando sozinho, sem ninguém para me perturbar, ridiculamente próximo da universidade. Eu teria uma quantidade de tempo livre sem precedentes desde o início da faculdade. Eu poderia me dedicar a desenvolver a linguagem de programação perfeita. Eu poderia estudar todas as línguas que quisesse. Eu poderia aprender a tocar a shakuhachi que estava pegando pó um ano e meio. Eu poderia me dedicar a fazer o que quer que fosse.

Foi um dos semestres mais improdutivos dos últimos cinco anos.

Não que eu não tenha feito nada. Eu li uma quantidade praticamente nociva de blogs e papers e manuais e artigos da Wikipédia nesse período. Mas eu não produzi muita coisa nesse período: foi muito mais input do que output.

A moral da história é que muitas vezes a desculpa de não fazer as coisas por "não ter tempo" é um fraude. Ok, há pessoas que trabalham quarenta mil horas por semana e estudam e realmente não têm tempo de fazer mais muita coisa. Mas esse nunca foi o meu caso. Com exceção de uns poucos períodos em que o curso estava meio demás e eu tinha trabalho da bolsa para fazer, eu sempre tive um bocado de tempo livre, e se não o aproveitei direito foi por vadiagem, ou falta de motivação.

Na verdade eu andei fantasticamente desmotivado de fazer qualquer coisa nos últimos tempos, por mil motivos (sic), e por motivo nenhum. Não tenho bons conselhos a oferecer em termos de motivação. O que eu sei é que: (1) é incrivelmente fácil postergar indefinidamente, especialmente quando se tem alguma outra atividade que não exija esforço para consumir o tempo com; e (2) a Internet provê uma fonte infinita de atividades que não exigem esforço. Assim, limitar o tempo que se consome na Internet parece uma boa estratégia para levar uma vida mais produtiva. (No geral, as pessoas não gostam de ficar muito tempo sem fazer nada; normalmente elas acham alguma distração para ocupar seu tempo com. Elimine as distrações e o que sobra é o trabalho a ser feito.)

Nem todo o tempo que eu perco na Internet é totalmente inútil; pelo contrário, muito desse tempo eu passo lendo material técnico sobre coisas que me interessam e que são relevantes para o que eu gostaria de desenvolver. E aí reside um perigo, porque é muito fácil nesse caso justificar o tempo que se consome lendo ao invés de produzindo. Acontece que essa tal de humanidade já fez muita coisa, e se o camarada for parar para pesquisar tudo o que existe de "prior art" antes de fazer algo, vai acabar não fazendo nada. Pesquisar o que existe é importante (e freqüentemente muito interessante), mas uma hora a gente tem que parar de ler e pôr a mão na massa.

Outra fonte de postergação indefinida em desenvolvimento de software (pelo menos para mim) é se perder em questões de design e nunca decidir nada. (Heh.) Para projetos suficientemente grandes (e.g., linguagens de programação e respectivas implementações, sistemas operacionais), design é um problema tão grande ou maior do que implementação, pois há uma quantidade enorme de decisões de design a se tomar e possibilidades a explorar; decidir o que exatamente o software deve fazer, quais são seus objetivos, são as questões difíceis. Mas embora pensar com calma sobre design seja importante (afinal o objetivo é criar uma linguagem (por exemplo) que ofereça alguma vantagem significativa sobre o que existe), para sairmos do lugar, em algum momento temos fixar certas decisões (para valores suficientemente fluídos de 'fixar'), mesmo que não tenhamos certeza de que seja a solução ótima (ou que tenhamos certeza de que não é, mas não temos nada melhor no momento), e partir para a implementação. Assim, temos um produto concreto para experimentar e para nos guiar no processo de decisão. Em todo caso, produzimos alguma coisa, que se não é ideal, com alguma sorte é pelo menos um avanço em algum aspecto em relação ao que existe.

And now for something slightly different

Tendo tratado a questão da inércia, falemos da dominação mundial.

Em algum ponto de suas vidas, algumas pessoas têm o seguinte pensamento: "Os ambientes computacionais modernos estão completamente errados. Se eu fosse começar tudo do zero, eu faria tudo diferente. Hmm, começar do zero...", e começam a arquitetar como seria o sistema ideal e todas as features legais que ele teria. Algumas se arriscam a levar o projeto adiante. Afinal, não pode ser tão complicado criar um sistema operacional, não é mesmo?

Normalmente esses projetos não acabam bem.

A insistência em construir as coisas do zero, embora tenha seu apelo, tem um custo (freqüentemente subestimado) muito maior do que o benefício. Mesmo que seja viável escrever um sistema operacional inteiro "from the ground up", com todos os detalhes exatamente corretos, o tempo que se perde implementando funcionalidades básicas do sistema (gerência de hardware, alocação de memória, agendamento de tarefas, e uma miríade de outras coisas) é tempo que poderia estar sendo usado para implementar as features que realmente interessam, e que poderiam ser implementadas sobre um sistema operacional existente. Mesmo features que "contradizem" o sistema operacional existente muitas vezes podem ser implementadas com uma pequena dose de gambiarra. Quer um mecanismo de segurança baseado em capabilities, ao invés das permissões tradicionais do Unix? Coloque um servidor de capabilities e autenticação a rodar como root, rode as aplicações clientes com um usuário não-privilegiado, e faça o daemon transferir file descriptors para os programas não-privilegiados segundo as permissões dos programas. Deselegante? Mais complexo do que o necessário? Talvez, mas é fantasticamente mais rápido de desenvolver do que criar um sistema operacional do zero só para experimentar com segurança por capabilities. De brinde, você pode continuar executando suas aplicações convencionais em paralelo com o seu sistema alternativo. Na pior das hipóteses, você pode alterar o kernel ou criar um módulo para o kernel para conseguir o que quer, o que ainda há de ser mais produtivo do que começar do zero. Depois que você estiver com seu sistema funcionando sobre o outro (i.e., depois que você descobrir o que exatamente você quer que o sistema faça), você pode começar a pensar em substituir a camada de baixo por algo mais puro e ideal. Da mesma forma, se você estiver desenvolvendo uma linguagem de programação compilada, provavelmente é melhor aproveitar a infraestrutura de um compilador existente (e.g., fazendo seu compilador gerar C ou bytecode LLVM) do que gerar assembly na mão. Ou se você pretende criar uma interface gráfica, use o X (e algum toolkit gráfico pré-existente, se possível). Em suma: dê preferência por construir sobre frameworks existentes, e foque nos aspectos realmente inovadores do projeto.

Se a idéia de construir sobre as bases tortas dos sistemas existentes lhe desagrada, lembre-se de que mesmo eliminando o sistema operacional, você ainda terá que construir sobre as bases tortas das arquiteturas existentes. Não seria ótimo se a arquitetura oferecesse suporte a capabilities em hardware, ou alguma ajuda com tipagem dinâmica e verificação de limites de vetor? Ou se simplesmente o conjunto de instruções fosse minimamente ortogonal, e não a bagunça que são o x86 e x86_64? A moral da história é que, sendo economicamente inviável para nós reles mortais criar uma arquitetura nova e mandar fabricar (e convencer o mundo a comprá-la), teremos que lidar com a sujeira das arquiteturas presentes; e se vamos lidar com alguma sujeira, podemos igualmente lidar com a sujeira de um sistema operacional existente, o que dá muito menos trabalho (em tese).

(Curiosamente, há (pelo menos) um projeto lunático de sistema operacional que, embora hesitante a princípio, levou a decisão da "pureza" às conseqüências lógicas e virou um projeto de arquitetura, implementado em FPGA. O autor do projeto tem ciência de o quão imprática é a idéia, mas não está nem aí.)

Meu último conselho para dominar o mundo: não queira demais. Ou melhor, queira, mas dê um passo de cada vez. Se você tentar iniciar o projeto de um sistema que resolve todos os problemas do mundo, é possível que você sequer termine de projetar e comece a desenvolver o sistema, ou comece a desenvolver mas não saiba como seguir adiante. Defina subprojetos com ambições menores, e resolva um, ou alguns, problemas de cada vez; assim você terá foco o suficiente para poder saber o que fazer. Use o Grande Objetivo Final como guia para saber para onde ir, e não como uma especificação cujos itens devem ser todos satisfeitos de uma vez, e caminhe gradativamente em direção a ele. Talvez você nunca o atinja, mas pelo menos você está andando para a frente.

Comentários / Comments (3)

Cayo, 2013-02-05 09:55:11 -0200 #

Eu gosto desse teu blog.


Pier Gerlofs Donia, 2013-02-05 20:58:37 -0200 #

O negócio é usar a programação orientada a blocos. As features novas são então apenas combinações diferentes de blocos existentes, os superblocos, que têm tudo a ver com a dominação mundial, que nem na Guerra Fria.
E o logo da LLVM é muito maneiro. Me lembra "Quantos elfos domésticos são necessários para alimentar o DRAGÃÃÃÃÂÂÃÂOOOoooo?"
(a resposta está no verso)


Vítor De Araújo, 2013-02-07 16:33:20 -0200 #

Um dia vão criar um mecanismo de inferência baseado nos thought processes do Hélio. As conseqüências serão aterradoras. :P


Deixe um comentário / Leave a comment

Main menu

Recent posts

Recent comments

Tags

em-portugues (213) comp (148) prog (71) in-english (62) life (49) unix (38) pldesign (37) lang (32) random (28) about (28) mind (26) lisp (25) fenius (22) mundane (22) web (20) ramble (18) img (13) rant (12) hel (12) scheme (10) privacy (10) freedom (8) esperanto (7) music (7) lash (7) bash (7) academia (7) copyright (7) home (6) mestrado (6) shell (6) android (5) conlang (5) misc (5) emacs (5) latex (4) editor (4) etymology (4) php (4) worldly (4) book (4) politics (4) network (3) c (3) tour-de-scheme (3) security (3) kbd (3) film (3) wrong (3) cook (2) treta (2) poem (2) physics (2) x11 (2) audio (2) comic (2) lows (2) llvm (2) wm (2) philosophy (2) perl (1) wayland (1) ai (1) german (1) en-esperanto (1) golang (1) translation (1) kindle (1) pointless (1) old-chinese (1)

Elsewhere

Quod vide


Copyright © 2010-2024 Vítor De Araújo
O conteúdo deste blog, a menos que de outra forma especificado, pode ser utilizado segundo os termos da licença Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International.

Powered by Blognir.