Friday, November 24, 2006

Mudança

Esta pequena casa aqui no Blogger tem me servido muito bem há mais de um ano, mas chegou a hora de se mudar.

Estou acabando de desempacotar a última caixa da mudança. Meu novo endereço é http://thiagoarrais.wordpress.com e já tem artigo novo por lá. Este blog não será mais atualizado e quem quiser pode ler tudo que há aqui no novo endereço também. O endereço do feed RSS continua o mesmo: http://feeds.feedburner.com/MergulhandoNoCaos, mas se você tentar abrir a versão web a partir do feed será direcionado para o novo endereço.

Sunday, October 29, 2006

Veteranos e novatos

Este é o último artigo de uma série de três derivados de uma palestra apresentada na FAPE em outubro de 2006.


Muita inovação acontece nas margens do sistema, pelas mãos de quem ainda não faz (ou nunca vai fazer) parte das panelinhas que todo mundo presta atenção.

Quem está em destaque tem uma certa obrigação oculta de continuar fazendo sucesso. Isto não está escrito em lugar nenhum, mas eles se sentem pressionados mesmo assim. Por causa dessa pressão invisível é que eles tendem a se concentrar em atividades de baixo risco. Uma das práticas de baixo risco mais comuns é repetir seu primeiro grande feito à exaustão. Se você já descobriu algo que faz sucesso, porque arriscar? Veja Dan Brown, por exemplo. Depois que ele escreveu O Código Da Vinci e o livro apareceu em listas de mais vendidos do mundo inteiro, ele já o reescreveu algumas vezes. Claro que o título e o enredo mudam toda vez, mas a estória é essencialmente a mesma. Ele faz isso porque dá certo. As pessoas compram os livros dele porque sabem o que esperar.

Repetição não é ruim. Repetição é um dos elementos fundamentais da evolução. Quando os animais se reproduzem eles basicamente se repetem, fazem cópias de si mesmos. Se essa repetição fosse exata, o que chamamos de clonagem, não haveria evolução porque não haveria mudança. Mas na vida real o que acontece é que a estrutura básica é repetida e mudam-se alguns detalhes menores como a cor dos olhos, a espessura dos pêlos e a estatura. A partir destas pequenas diferenças é que ocorre a evolução. O mesmo ocorre com as idéias de sucesso. Sua estrutura principal é repetida e alguns detalhes são modificados. De acordo com a receptividade, estes detalhes são novamente modificados e novas mutações são testadas.

Os veteranos em todos os ramos são muito bons nesse tipo de evolução experimental, eles podem mudar pequenas coisas de modo a gerar coisas novas mas extremamente parecidas com as antigas. Este processo é lento por natureza. Para chegar a um novo produto desse modo é necessário fazer várias modificações e cada uma das modificações precisa ser testada para a aceitação do público. Isto leva tempo.

Mas às vezes o que precisamos não é de evolução lenta. Às vezes precisamos de saltos evolucionários para não ficarmos presos em máximos locais. Para isso é necessário introduzir um elemento inesperado, uma fonte de aleatoriedade qualquer. Na natureza, a reprodução sexuada vem cumprindo muito bem esse papel e nos negócios sangue novo também é muito bom para isso. Os novatos não tiveram as idéias influenciadas pelas limitações atuais do mercado e da tecnologia, por isso têm facilidade para pensar em coisas completamente novas.

Essas limitações podem ser um grande problema. As idéias novas parecem preferir as cabeças mais frescas. Quando se está no meio da selva matando um leão por dia, fica difícil achar tempo para ter grandes idéias e pensar no futuro. Muita gente acaba queimando a língua por causa disso.

Há controvérsias, mas algumas fontes relatam que Thomas Watson, então presidente da IBM, disse em 1943 que talvez houvesse no mundo inteiro mercado para cinco computadores. Era a época da Segunda Guerra Mundial. Os computadores eram usados principalmente para quebrar códigos de mensagens militares e eram grandes a ponto de ocupar várias salas. Naquela época não havia a sala dos computadores, mas as salas do computador.

Nessa situação é fácil imaginar que o mundo teria poucos computadores. Era preciso ter muitos recursos para isso e as únicas entidades com recursos e interesse suficientes para obter um eram uma meia-dúzia de governos.

Já a revista Popular Mechanics, em uma edição de 1949 acertou em cheio. Eles publicaram que "no futuro, os computadores pesarão não mais do que uma tonelada e meia." Algumas décadas depois realmente é difícil achar um computador com uma tonelada e meia. Mas é fácil encontrar um com alguns gramas no bolso de qualquer adolescente.

Em 1977, quando a Apple lançava seu computador pessoal Apple II, Ken Olsen, fundador da Digital Equipment disse que não via razão para alguém querer um computador em casa. A DEC produzia o que eles chamavam de mini-computadores que eram usados principalmente para pesquisa científica. Realmente, ninguém iria querer um desses em casa, mas hoje muita gente não sabe como iria viver sem um computador pessoal.

Os produtos realmente inovadores são surpreendentes porque ninguém acha que precisa deles antes de existirem. Ninguém precisava do computador pessoal antes dele existir. Ninguém precisava de celulares. Ninguém precisava de câmeras digitais. Ninguém precisava de mouses. Mas hoje tem muita gente que não sabe como vivia antes deles.

Todas estas pérolas são de gente que já estava envolvida em seus respectivos nichos há um certo tempo. Eles simplesmente não conseguiam ver os saltos evolucionários. Eles estavam muito ocupados resolvendo os problemas de hoje e não tinham tempo para pensar nos de amanhã.

Os novatos não têm essas limitações ainda. Eles não foram tão expostos à situação atual como os veteranos. O problema deles é outro: recursos.

Semana passada eu li sobre como as telecom estão querendo estratificar a Internet para cobrar direitos de transmissão sobre os meios de alta velocidade. Na ponta dos links da Internet estão os roteadores e eles têm uma fila interna. A idéia é que se você pagar mais, seus pacotes (suas mensagens) tenham prioridade de transmissão. Atualmente, a fila é mais ou menos justa: se você chegar primeiro, você é atendido primeiro. O que eles querem é que algumas pessoas possam furar a fila.

Se elas conseguirem fazer isso (e eu não tenho certeza de que seja possível), vai ser um grande golpe para a inovação. Muitas das idéias inovadoras de hoje saem das cabeças das pessoas comuns e elas não têm os recursos que as grandes corporações têm. Se as filas de transmissão não fossem igualitárias, não seria possível que um programador de São Francisco inventasse e testasse o BitTorrent. Se os grandes provedores de conteúdo tivessem preferência de tráfego, ele não poderia fazer suas experiências usando sua conexão residencial comum. Os pacotes dele teriam prioridade extremamente baixa e ficariam um bom tempo presos no congestionamento. Seria preciso convencer algum investidor com bom poder de fogo a financiar o projeto. E os investidores podem não ser muito receptivos à inovação.

Inovar é arriscado e quando você é velho e famoso, não pode se dar ao luxo de fazer papel de idiota. Mas se você é jovem e desconhecido, ninguém vai ficar sabendo do seu fiasco. Você pode ousar mais quando não tem medo de bancar o idiota.

Monday, October 23, 2006

Aprender, praticar (e aprender um pouco mais)

Este é o segundo artigo de uma série de três derivados de uma palestra apresentada na FAPE em outubro de 2006.


Prática certamente é uma Boa Coisa™. Eu até acredito que tem algumas coisas que não dá para aprender sem praticar. Para estas (e elas são muitas) é mais interessante estudar um pouco, praticar um pouco, depois estudar mais um pouco e repetir o ciclo eternamente. Você não pode dizer que sabe sobre alguma coisa antes de usá-la de verdade. Mas conhecimento prático somente, não é suficiente.

Se eu quiser programar, por exemplo, não basta que eu devore o manual de alguma linguagem de programação e comece a escrever meus próprios programas. Eu até posso fazer isso, se eu quiser só programar. Mas se eu quiser fazer bem, é preciso estudar como quem já está nessa há mais tempo faz as coisas. Se eu simplesmente me trancar no meu quarto de madrugada para programar, a excelência vai ser um objetivo distante. Alcançável, mas bastante distante. É preciso ler código dos outros, procurar por construções comuns em vários programas e identificar boas práticas.

Mas isto não é o bastante. Se eu quiser mesmo ser Bom com 'B' maiúsculo, vou precisar estudar algumas coisas que aparentemente não têm nada a ver com o ofício da programação. Coisas como teoria dos grafos, protocolos de comunicação entre computadores e inteligência artificial. Mesmo que eu ache que não vá usar diretamente nada disso, é bom me expor pelo menos um pouco a estes assuntos.

Estudar tudo isso vai alargar meus horizontes de conhecimento. Eu não vou saber nenhum desses assuntos a fundo, mas vou saber que há outros mares para explorar, novas possibilidades. Assim podemos traçar paralelos e estabelecer analogias que podem levar a idéias geniais. Não é preciso mais do que uma breve exposição para isso.

Ter uma noção de cada assunto é ter conhecimento horizontal. É o conhecimento usado para chegar a uma dessas analogias que fazem a maior diferença. Também é o conhecimento usado para impressionar os outros. Você não precisa saber muito de comunicação de computadores para falar em rotedores, pacotes e protocolos.

Se tudo que você quer é ter assunto para conversar, conhecimento horizontal é o que você precisa. Para resolver problemas interessantes, é preciso conhecimento vertical. É preciso se aprofundar em algum nicho, se especializar.

Muitas tecnologias populares começam em pequenos nichos. São usadas por muito pouca gente no início, mas um dia alguém com visão resolve aplicá-las em um contexto diferente e a coisa explode. A Internet é um exemplo disso. Ela começou como forma de comunicação entre centros universitários e era usada também para troca de dados militares. No final da década de 80 e início dos anos 90, foi desenvolvida a base para a Web moderna e a partir daí a coisa explodiu. Claro que isso é uma simplificação da realidade (e o que não é?), mas ilustra o ponto de que um especialista que estuda um assunto a fundo pode ver oportunidades que os demais nunca vão imaginar.

Mas especialização demais também pode ser uma armadilha. Ela começa a ser perigosa à medida que se desiste do conhecimento horizontal pelo vertical. Fazer isso é desistir de idéias brilhantes ligando um campo do conhecimento ao outro. Especialização demais pode estreitar a visão a ponto de só permitir enxergar o próprio nariz.

Wednesday, October 18, 2006

Como (tentar) prever a criatividade

Este é o primeiro artigo de uma série de três derivados de uma palestra apresentada na FAPE em outubro de 2006.


Previsibilidade é quase o oposto de criatividade. À primeira vista, podemos colocar criatividade e previsibilidade em dois extremos do mesmo eixo. Para aumentar uma, é preciso diminuir a outra.

Previsibilidade vs. Criatividade

No extremo da previsibilidade temos organizações que têm somente capacidade de repetição. Suas atividades são facilmente gerenciadas por serem extremamente previsíveis. Uma forma de alcançar este grau de previsibilidade é inventar sempre a mesma coisa. O problema é que repetir a mesma coisa várias vezes não é inventar. Por isso que esses lugares altamente previsíveis são extremamente chatos para se trabalhar. Você está sempre fazendo as mesmas coisas. Escrevendo o mesmo relatório para o mesmo gerente.

Henry Ford No lado extremo da previsibilidade, temos fábricas tradicionais, com linhas de montagem e tudo mais, como as que Henry Ford projetou. Nestas fábricas tudo é extremamente previsível. Se colocarmos uma peça no começo da linha, podemos saber com uma boa precisão quando ela passará por cada um dos estágios. Essa previsibilidade é alcançada através de muita padronização e repetição.

No outro extremo estão as organizações que escolheram abandonar totalmente a previsibilidade em favor da criatividade. Essas inventam coisas maravilhosamente interessantes, mas não se pode confiar muito nelas para estabelecer prazos. Você sabe que dali vai sair alguma coisa surpreendente, mas ninguém sabe dizer quando. Estes lugares também são muito chatos para se trabalhar, porque parece que nunca vão acabar de construir nada. Sempre há um último retoque para ser feito. Sempre aparece um novo projeto interessantíssimo para deixar o anterior inacabado.

Leonardo Da VinciÉ deste lado que ficam alguns artistas, como Leonardo da Vinci. Ele era conhecido por atrasar as encomendas e tem gente que diz que às vezes ele até colocava alguns significados ocultos nas telas. Fazer uma encomenda a ele era receita certa para uma boa dor de cabeça. Ele não ia entregar no prazo e no final o que ele entregasse podia não ser muito bem aquilo que você tinha pedido. No entanto, ninguém pode dizer que ele não era criativo. O cara era a inovação em pessoa, inclusive foi pioneiro em muitas áreas de pintura, engenharia e anatomia.

É natural perguntar quantos carros uma fábrica pode produzir por dia. Mas não faz sentido nenhum perguntar a nenhum pintor que se preze quantos quadros ele pode fazer por mês. Cada quadro é uma obra única e o tempo de produção pode variar demais para que estimativa seja minimamente precisa.

Nenhum dos dois extremos é bom. A boa notícia é que não precisamos escolher entre preto ou branco. Há vários tons de cinza entre eles que podemos explorar.

Previsibilidade mais Criatividade

Ao contrário do que possa parecer, não precisamos escolher entre uma e outra. Previsibilidade e criatividade não estão no mesmo eixo. As duas são ortogonais. Não precisamos necessariamente diminuir uma para aumentar a outra. Não é preciso ser imprevisível para ser criativo. Talvez as variáveis não sejam tão independentes como queiramos, mas também não são tão intrincadas que não dê para separá-las um pouco.

A menos que você esteja querendo reconstruir alguma coisa que já tenha construído, desenvolver software é um processo criativo. Só que nem todo programador pode se dar ao luxo de fazer como Da Vinci e desrespeitar prazos e demandas. É preciso ter algum grau de previsibilidade para agradar os clientes.

Para lidar com este problema é que foi inventada a iteratividade. O segredo é projetar o software em ciclos curtos chamados de iterações. No início de cada iteração, a equipe combina com o cliente o que deverá ser produzido durante um certo período de tempo e ao final deste período o cliente recebe um sistema funcional que pode ser testado. Pode ser que o sistema seja bem pequeno, minúsculo. Mas ele evoluirá ao longo do tempo até chegar uma hora que o cliente diga 'está bom, era isso que eu queria' e os programadores possam procurar um novo projeto.

Uma boa forma de se enganar é não entregar software rodando ao final da iteração. Você pode, no lugar disso, entregar um calhamaço de documentos, só para provar que não ficou parado o tempo todo. A idéia é que quem quer que esteja pagando pela sua empreitada possa validar esses documentos e dizer 'continue, você está no rumo certo' ou 'não é bem por aqui, acho que devemos mudar de estratégia'.

Quando se usa um documento para esse tipo de comunicação, uma de três situações pode ocorrer. A primeira é o cliente validar seu documento e assinar embaixo, só que ele estava pensando em uma coisa quando leu e você estava pensando em outra bem diferente quando escreveu. A segunda é ele não concordar com o que você escreveu e implicar com as menores coisas para ter certeza que você entende o que ele está querendo. Essa segunda situação pode facilmente descambar para um fluxo eterno de remendos ao documento que impede que a coisa de verdade seja construída. A terceira possibilidade é que ele valide o que você escreveu e esteja pensando no mesmo que você. Mas é mais fácil ganhar na loteria do que isso acontencer.

Esse problema não acontece com software rodando. Quando o produto está vivo na frente do cliente, não há espaço para interpretações erradas. O sistema faz exatamente aquilo que está fazendo ali, ao vivo, na frente dele. Se algo estiver errado ou puder ser melhorado, o produto é um objeto concreto para servir de instrumento na discussão. Ninguém vai precisar adivinhar o que o outro está pensando.

A chave para o equilíbrio entre previsibilidade e criatividade através de iterações está em achar um tempo de iteração que seja pequeno o suficiente para que as estimativas não fiquem muito distorcidas e grande o suficiente para permitir que alguma coisa de útil seja feita. Tudo isto ainda permitindo que a equipe possa exercitar sua criatividade.

Wednesday, October 04, 2006

15 Mega de fama

Grande idéia de Bill Seaver, blogueiro do Tennessee. Os quinze minutos de fama são passado. Hoje em dia 15 Mega de fama são muito mais comuns.

Anônimos de toda parte do mundo estão experimentando pequenos momentos de fama através da mídia digital. Quando todo mundo é especial, ninguém é especial.

Wednesday, September 27, 2006

Uma pequena grande idéia

Qual é o padrão de projeto que você mais usa? Que pequena estrutura insiste em aparecer quase que espontaneamente no seu código?

Eu particularmente nunca cheguei a contar quantas vezes uso cada padrão, mas tem um que com certeza estaria bem no topo da lista dos mais usados se eu contasse. Dica: não é o Singleton. Também não é nenhum dos padrões do clássico GoF. É um padrão bem pequeno e localizado que às vezes é chamado de Null Object. Muito provavelmente você já deve conhecer ele, seja por este ou outro nome. Isso de nomes diferentes para os mesmo padrões acontece com freqüência, já que muitos deles brotam em vários locais, várias cabeças, diferentes de forma independente.

Suponha que você esteja construindo uma wiki como parte de uma ferramenta de acompanhamento de projetos. Somente usuários autenticados podem editar páginas nesta wiki. Isso pode ser resolvido com algo parecido com isso (Ruby):

1 def edit
    @page = find_page(params[:page_name])

    if current_user.nil? ||
5      !page.editors.include?(current_user.login)
      redirect_to :action => 'show',
                  :page_name = params[:page_name]
    end
  end

Mas aquela linha cinco está particularmente feia. Podemos esconder essa verificação num método bem nomeado na classe User.

1 class User
    def can_edit?(page)
      page.editors.include? self.login
    end
5 end

Ainda há bastante espaço para melhoria aqui. Esse trem de chamadas de método da linha três está bem grande e pode ser diminuído, mas vamos primeiro ver como ficou a nova definição de edit:

1 def edit
    @page = find_page(params[:page_name])

    if current_user.nil? ||
5      !current_user.can_edit?(@page)
      redirect_to :action => 'show',
                  :page_name = params[:page_name]
    end
  end

Já melhorou bastante, mas aquela verificação de nulidade que ficou na linha quatro ainda está me incomodando. Há tantos detalhes embutidos nesta pequena chamada current_user.nil? que podem fazer a cabeça de alguém explodir. Para entender isso é preciso saber que current_user é igual a nil quando o usuário não está autenticado. Além disso, a regra que diz que os usuários devem estar autenticados e autorizados a editar a página está toda codificada nesta pequena linha de código. É responsabilidade demais para uma única linha.

Eu não quero ser responsável pela explosão de nenhuma cabeça, portanto vou procurar algum modo de melhorar isto. Seria melhor se pudéssemos dizer somente current_user.can_edit?(@page), mas não podemos fazer isso porque o objeto nil (sim, nil, assim como qualquer coisa em Ruby, também é um objeto) que representa o usuário não autenticado não responde ao método can_edit?. Por isso precisamos de todo esse tratamento desajeitado para o caso especial.

Mas o usuário não autenticado não precisa ser representado por nil. Ao invés disso, podemos definir uma nova classe chamada UnidentifiedUser que é um Null Object. Ela vai ser uma classe bem pequena, usada simplesmente para tratar o caso especial do usuário não autenticado. Os detalhes sobre tratamento de usuários sem autenticação vão ficar confinados a ela e o restante do sistema poderá tratar todos os usuários uniformemente. Segue o código:

1 class UnidentifiedUser
    def can_edit?(page)
      false
    end
5 end

E acabou. O usuário não identificado só precisa responder que não pode editar nenhuma página, sem exceção. Como isto aqui é Ruby, não precisamos dizer que esta classe herda da User original porque usamos duck typing. Se estivéssemos usando uma linguagem estaticamente tipada, precisaríamos disso (como vamos ver no próximo exemplo que usa Java).

Isso é tudo que precisamos para esta classe, mas ainda precisamos alterar o método current_user, para que retorne um objeto UnidentifiedUser ao invés de nil no caso do usuário não estar autenticado.

1 def current_user
    session[:user] || UnidentifiedUser.new
3 end

Outra forma de alcançar o mesmo efeito é injetar o método can_edit? diretamente no objeto nil, já que Ruby não diferencia tempo de compilação, linkagem e execução. Desse modo não precisamos nem modificar este último método.

Este pequeno padrão se mostra muito útil. Suponha agora que você esteja escrevendo um IDE para alguma linguagem extremamente bela que quase ninguém usa por achar diferente e esquisita. Este seu IDE usa um compilador externo por baixo dos panos e o programador pode escolher se quer ver a saída do compilador. Vamos começar pelo código feio e passar lentamente para uma versão mais elegante. Claro que isso é só minha opinião. Mas este é o meu blog, tudo aqui é só minha opinião. (Java)

1 class Compiler {
  
     // ...
  
5    void compile(IFile target) {
         if (compilerOutputEnabled())
             output.write(
                 "Starting compilation from file "
               + target.getName());
10
         String cmdLine = "ghc --make " + 
             target.getFullPath().toOSString();

         if (compilerOutputEnabled())
15           output.write(cmdLine);

         String output = processRunner.execute(
             sourceFolderFor(target), cmdLine);
20       
         if (compilerOutputEnabled())
             output.write(output);
     }

25}

Eu avisei que iríamos começar pelo código feio... Você também está sentindo o mau cheiro? Essas linhas repetidas perguntando se alguma coisa deve ser relatada não estão te dando coceira? Vamos tratar isso antes que comecem a estourar bolhas.

O objeto output apareceu magicamente para este nosso método. Estamos assumindo que ele foi inicializado pelo nosso Compiler em algum ponto omitido do código. Mas não precisa ser assim. Podemos injetar qualquer Writer se o output for um parâmetro do método.

Vamos escrever então um Writer especial que sabe quando deve escrever de verdade ou não e injeta-lo no método compile por passagem de parâmetro.

1 public CompilerOutputWriter extends Writer {

      // ....

5     @Override
      public void write(char[] cbuf,
          int off, int len)
      {
          if (compilerOutputEnabled()) {
              underlyingWriter.write(
                  cbuf, off, len);
          }
10    }
  }

A responsabilidade de checar se a saída deve ser mostrada agora passou para o objeto CompilerOutputWriter. Podemos tirar as checagens do método compile:

1 class Compiler {
  
     // ...
  
5    void compile(IFile target, Writer output) {
         output.write(
                 "Starting compilation from file "
               + target.getName());

10       String cmdLine = "ghc --make " + 
             target.getFullPath().toOSString();

         output.write(cmdLine);

15       String output = processRunner.execute(
             sourceFolderFor(target), cmdLine);
       
         output.write(output);
20   }

  }

O código está ficando melhor, mas ainda dá pra deixá-lo mais apresentável. Podemos apagar a classe CompilerOutputWriter por inteiro (você também tem uma ótima sensação quando apaga código?) e introduzir um NullObject que será selecionado quando a saída do compilador for desabilitada. Por exemplo:

1 public class NullWriter extends Writer {

      // ....

5     @Override
      public void write(char[] cbuf,
                        int off, int len)
      { /* ignore */ }

  }

Um NullWriter simplesmente ignora a entrada. O pobre compilador vai achar que está escrevendo alguma coisa, mas qualquer coisa que ele pedir será ignorada. Agora a responsabilidade de saber se o usuário quer ou não ver a saída do compilador é de quem está chamando o Compiler, e ele tem todo o direito de delegar a responsabilidade.

O padrão NullObject é uma forma de tratar casos especiais que substitui a lógica condicional por uma solução mais limpa. Por falar nisso, parece que eliminar lógica condicional é uma Boa Idéia™.

Thursday, September 21, 2006

A linguagem independente de linguagem

A palavra de hoje é modelagem. Quando os programadores ouvem esta palavra, não pensam em porcelana, argila ou massa de modelar. Eles imaginam diagramas, esquemas, retângulos, setas e coisas do tipo. Bem estranho, mas é verdade. O que os programadores chamam de modelagem não passa de uma forma de expressão que usa uma linguagem visual ao invés de uma escrita. Se os esquemas fossem quadros, o código-fonte seria um poema. São artes diferentes e têm públicos diferentes. Do mesmo modo que há gente que consegue apreciar melhor um poema do que um quadro, tem gente que entende melhor código-fonte do que esquemas. Diferentemente do que acontece nas artes, os esquemas e diagramas dos programadores podem ser usados para gerar código-fonte sem nenhuma intervenção humana. Dependendo da tecnologia em uso, este código precisa ser lapidado manualmente para que possa ser finalmente executado por um computador. Pessoas diferentes conhecem linguagens de programação diferentes, por isso alguém teve a idéia de usar os diagramas para permitir liberdade na escolha das linguagens textuais. Usar uma linguagem visual pode ser uma boa idéia, mas não para obter independência de linguagem. Esse objetivo de escrever (ou deveria dizer desenhar?) um programa de forma independente de linguagem é simplesmente inviável. Nunca chegaremos lá, simplesmente porque não dá para projetar nada sem uma linguagem, uma representação, específica. Se você vai escrever alguma coisa, precisa escolher uma linguagem qualquer e, por definição, não existe isso de linguagem independente de linguagem. O que podemos fazer é desenvolver linguagens cada vez de mais alto nível que poderão ser traduzidas para diversas outras de baixo nível. Quando finalmente conseguirmos ficar livres das linguagens de base, vamos descobrir que estamos presos à mais abstrata. Ela pode ser mais produtiva, intuitiva e todo o resto que você queira imaginar, mas ainda é uma linguagem. Isto não é ruim. O propósito de usar linguagens visuais não é poder trocar a linguagem de suporte. De preferência, não devia nem haver uma representação textual intermediária que precise de ajustes manuais. Na Terra dos Modeladores Felizes, diagramas são executáveis do mesmo modo que um conjunto de instruções de máquina. A verdadeira razão de haver linguagens visuais é que algumas pessoas acreditam que elas são mais abstratas e produtivas. Abstração é causa direta da produtividade. A segunda não vem sem a primeira. Não adianta usar uma linguagem visual se ela possui exatamente as mesmas construções de alguma outra textual. Se ela puder ser traduzida para a forma textual com uma correspondência direta, não há ganho de produtividade. Na verdade, é bem provável que haja perda. O ponto é que programadores passam muito pouco tempo realmente digitando (ou desenhando). A parte mais difícil e trabalhosa é feita dentro da cabeça. Acelerar a edição é se concentrar no problema errado. O que queremos mesmo é maior expressividade. Isto pode muito bem vir de uma linguagem visual. Ou não. Afinal, não é qualquer imagem que vale mais do que mil palavras.