Novo site pessoal

Acesse o meu novo site pessoal em: http://www.alexbs.com.br

Anúncios

Paralização do blog

No momento, estou totalmente sem tempo para dedicar ao blog e não vejo, pelo menos em um futuro próximo, eu voltar a ter o tempo necessário para escrever novos artigos. Por isso, declaro o blog paralizado até segunda notícia.

Construção de um botão elegante com CSS 3

Alguns eventos recentes na minha vida profissional estão me fazendo dar grande foco para a área de programação de interfaces. Por isso, resolvi escrever um post mais prático sobre esse assunto. No post de hoje, vou mostrar como transformar um link HTML (<a></a>) em um botão elegante, estilo Web 2.0, usando algumas das novas propriedades do CSS 3, tais como text-shadow e box-shadow.

Ao final do passo a passo, você deve obter um botão assim:

botao-elegante-3-estados

Botão com diferentes estados para mouse-fora, mouse-sobre e clique.

Primeiro, vamos ver o CSS necessário para dar ao botão a aparência de seu primeiro estado (quando o mouse estiver fora dele).

a.botao-2-0 {
   display: inline-block; /* elemento tipo block que aceita conteúdo ao seu redor (como um inline) */
   width: 200px; /* largura */
   height: 40px; /* comprimento */
   border: 1px solid black; /* borda de 1px, tipo solid, cor preta */

/* border-radius determina o quão curva é a borda. Para dar suporte a browsers mais a
antigos, usamos as notações específicas da engines Webkit (Chrome, Safari) e Gecko (Firefox). Se você não sabe o que é a engine de um browser, veja http://pt.wikipedia.org/wiki/WebKit */
   -webkit-border-radius: 3px;
   -moz-border-radius: 3px;
   border-radius: 3px;

   background-color: #FFC75C; /* cor de fundo */

/* box-shadow define a sombra de um elemento. Como primeiro argumento, coloque inset
para sombra interna (ignore esse argumento para sombra externa). O primeiro valor
define a sombra lateral (inset: valores negativos se referem ao lado direito; para sombras externas, valores negativos se referem ao lado esquerdo); o segundo valor
define a sombra vertical (inset: valor negativos se referem à sombra de baixo; para sombra externa, valores negativos se referem à sombra superior). O último argumento
é o quão borrada é a sombra; quanto maior o valor, mais larga e fraca a sombra
*/
   -webkit-box-shadow: inset -3px -3px 3px #7F5B14;
   -moz-box-shadow: inset -3px -3px 3px #7F5B14;
   box-shadow: inset -3px -3px 3px #7F5B14;

text-align: center; /* texto centralizado */
text-transform: uppercase; /* texto em caixa alta */

/* sombras, mas para textos. Aqui, o inset não pode ser usado, a sobra é sempre externa */
   -webkit-text-shadow: 1px 1px 2px #7F5B14;
   -moz-text-shadow: 1px 1px 2px #7F5B14;
   text-shadow: 1px 1px 2px #7F5B14;

letter-spacing: 4px; /* espaçamento entre as letras */
   font-weight: 900; /* nível de negrito da fonte */
   font-size: 12px; /* tamanho da fonte */
   font-family: Orbitron, sans-serif; /* tipo de fonte */

/* Se não houver quebra de linha no conteúdo, colocar a altura da linha igual
à altura do elemento é uma maneira fácil de se obter centralização vertical */
   line-height: 40px;

/* nível de opacidade. .8 = 80% */
   opacity: .8;
}

Esse código é o suficiente para dar ao botão a aparência do primeiro estado mostrado na imagem do início do post. No entanto, como fazer o botão mudar de estilo quando o mouse estiver sobre ele (ou quando o botão estiver sendo clicado)? Desde o CSS 2, podemos usar pseudo-classes para definir que mudanças de estilo um elemento terá dado o acontecimento de algum evento (como, por exemplo, o ponteiro do mouse sendo posicionado sobre o elemento).

/* Algumas das pseudo-classes disponíveis desde o CSS 2
:link - seleciona links dentro de elementos
:visited - seleciona links visitados
:focus - o elemento tem o foco na tela
:hover - o ponteiro do mouse está sobre o elemento
:active - o elemento está ativo (isso geralmente significa o clique do mouse ou o enter do teclado) */

a.botao-2-0:link, a.botao-2-0:visited, a.botao-2-0:focus, a.botao-2-0:hover, a.botao-2-0:active {
    color: black;
    text-decoration: none;
}

/* Quando o elemento estiver em foco (ou com o ponteiro do mouse sobre ele), aumentamos
sua opacidade para 100% */
a.botao-2-0:focus, a.botao-2-0:hover {
    opacity: 1;
}

/* Quando o botão estiver sendo clicado (ou ativado com o enter) mudamos as sombras da caixa
e do texto de forma que ele fique com a aparência de um botão afundado */
a.botao-2-0:active {
    -webkit-box-shadow: inset 3px 3px 3px #7F5B14;
    -moz-box-shadow: inset 3px 3px 3px #7F5B14;
    box-shadow: inset 3px 3px 3px #7F5B14;
    -webkit-text-shadow: -1px -1px 2px #7F5B14;
    -moz-text-shadow: -1px -1px 2px #7F5B14;
    text-shadow: -1px -1px 2px #7F5B14;
}

Como explicado nos comentários do código, o segredo para dar a aparência de afundado para o botão é trabalhar com a pseudo-class :active e trocar as sombras internas de posição (de direita e baixo para esquerda e cima). Nesse exemplo, estou usando a fonte Orbitron (Ultra-Bold 900), que pode ser obtida em www.google.com/webfonts. Para conveniência, criei também uma página HTML já com os estilos para o botão. A página de exemplo pode ser baixada clicando aqui (File > Download).

Quaisquer dúvidas ou observações, basta deixar um comentário nesse post mesmo.

Espero que esse tutorial tenha sido útil para vocês. Até a próxima!

Obs: Este tutorial foi testado nos seguintes navegadores: Google Chrome (24.0.1312.57 m), Mozilla Firefox (18.0.1) e Internet Explorer (9.0.8112.16421). No IE, a fonte Orbitron não será carregada (e ocorrerá o fallback para sans-serif), mas isso é assunto para um outro post xD

Entrevista com Yukihiro “Matz” Matsumoto – Parte 3

Parte 3 (e final) da entrevista na RubyConf China com o criador de Ruby, Yukihiro “Matz” Matsumoto. A tradução para o Português é de minha autoria e a versão em Inglês pode ser lida no blog de Fred Wu. Se você perdeu as outras partes, clique aqui para acessar a parte 1.

<- Ir para a Parte 2

Zhou: Você mencionou MRuby ontem e o tópico da sua apresentação amanhã será Ruby 2.0. Você poderia falar um pouco sobre os destaques em MRuby e Ruby 2.0?

Matz: Como discutimos anteriormente, MRuby é desenvolvida para rodar já embarcada em dispositivos, ela não tem tudo o que Ruby possui. Como resultado, muitos equipamentos que tradicionalmente não podem utilizar Ruby, como máquinas de venda, controladores e robôs vão em breve poder utilizar MRuby. Talvez em alguns anos, nós possamos ver Ruby sendo usado em computadores e carros.
Ruby 2.0 indica duas mensagens. Primeiramente, no próximo ano o desenvolvimento de Ruby terá completado 20 anos. Que melhor número de versão pode haver para celebrar esse momento especial?! Contrário ao que pode parecer, da [versão] 1.9 à 2.0 as mudanças não foram tão grandes como da 1.8 para a 1.9. Na verdade, nossa meta para a 2.0 é que ela seja compatível por completo com a 1.9. Seus aplicativos 1.9 devem rodar sem problemas na 2.0 [o contrário, no entanto, não é necessariamente verdade].

Em segundo lugar, Ruby 2.0 oferece alguns novos recursos. Por exemplo, usar monkey patching para adicionar ou substituir funcionalidades tem efeitos globais e pode causar conflitos e bugs. Para evitar situações tais como essa, Ruby 2.0 limita o escopo de monkey patching por meio de Refinements. Conforme equipes maiores e projetos maiores adotam Ruby, o monkey patching com escopo controlado irá mostrar sua importância. Há muitas outras funcionalidades em Ruby 2.0 que foram desenvolvidas para atender a times e projetos grandes.

 

Zhou: Até onde eu sei, a maior parte das linguagens de programação populares são da América e da Europa – entretanto existem Lua, do Brasil, e Ruby, do Japão. Você também mencionou isso em seu livro e você disse que a sensação é de solidão. Então, qual é a causa disso e o que podemos fazer a respeito?

Matz: Bem, em relação à Lua você pode incluir ela em América / Europa também porque o Brasil é parte da América do Sul (risadas). No sudeste asiático, no entanto, há apenas Ruby e é solitário. Europa e América ainda permanecem as regiões mais poderosas no que concerne linguagens de programação. A Ásia, apesar de sua população massiva, não compete nisso, e a sensação é mesmo a de solidão.
Eu não tenho certeza em relação a outros países, mas no Japão pelo menos há diversas pessoas trabalhando no desenvolvimento de linguagens de programação, infelizmente nenhuma outra além de Ruby é bem conhecida. Se mais pessoas estão interessadas em programação e na criação de linguagens de programação, tem de haver uma ou outra que vão se destacar, certo? Há outro obstáculo no Japão: linguagem. A maior parte dos japoneses fala apenas Japonês e não consegue falar Inglês bem. Por mais engraçado que possa parecer, há linguagens de programação escritas inteiramente em Japonês. (Zhou: Na China também há linguagens de programação escritas inteiramente em Chinês). Na China também? Eu suspeitava! Não importa o quão interessantes essas linguagens sejam, elas nunca vão influenciar alguém além das pessoas do seu próprio país.

Fazendo um comentário à parte, eu uma vez recebi um email de um americano. Ele disse: “Você é japonês, mas Ruby parece ser americana porque é escrita em Inglês, por que não há linguagens de programação escritas em Japonês?” Eu respondi dizendo que existiam sim linguagens escritas em japonês, só que ele não as conhecia e, mesmo que o fizesse, não seria capaz de as utilizar.

No Japão, mais e mais pessoas estão interessadas em programação, talvez porque tanto online quanto em meus livros eu sempre falo o quão divertido programação pode ser. Muitas pessoas estão agora encarando o desafio de desenvolver novas linguagens de programação. Dessas novas linguagens, mesmo que apenas 0,1 % delas tenham algum sucesso, eu acho que é uma vitória. Eu não sei quantas pessoas querem encarar o mesmo desafio na China, Coréia e em outros países da Ásia, mas se as pessoas pudessem olhar além de “linguagens de programação são criadas para nós, nós apenas passivamente as aceitamos” e pensassem “criar novas linguagens de programação pode também ser divertido”, então eu tenho certeza que algumas delas terão sucesso.

Falando sobre projetos open source, não são muitos deles que são do Japão, China e Coréia, e eu acho que esse pode ser um ponto de partida para muitos [desenvolvedores]. Há muitas razões para isso, por exemplo a de que Inglês é difícil de aprender… (Zhou: E o GitHub também é difícil de usar?) Haha, o GitHub pode ser acessado da China? (Zhou: Pode sim, pode sim…) Ah, então até que não é tão ruim assim. Mas o Grande Firewall da China ainda tem um enorme impacto, muitos recursos não podem ser acessados daqui, certo? (Zhou: É verdade, por exemplo o site da linguagem de programação Go é bloqueado.) Sério? Isso é porque ela é feita pelo Google? (risadas) De qualquer forma, eu acho que ainda há muitas dificuldades para encarar. Também, no Japão muitos programadores ainda passam a maior parte do tempo trabalhando (para botar comida na mesa), é muito difícil para eles contribuírem para projetos open source. Há dez anos ninguém ligava para open source no Japão, mas atualmente as pessoas estão começando a perceber a importância do open source, e o número de projetos open source está crescendo. Eu acredito que a China em breve vão seguir esse padrão também, eu estou aguardando por isso.

No começo ninguém sabe o que vai ter sucesso. Quando eu comecei com Ruby, eu não poderia ter previsto o seu sucesso. Então eu acho que para uma linguagem de programação, o tempo correto é muito importante – e você nunca saberá até você ter tentado. Eu acho que na China podem também haver linguagens que vão emergir no tempo certo e irão acabar se tornando sucesso global.

 

Zhou: No livro, quando você está falando sobre Dart, você menciona que o ecossistema [de desenvolvimento] é muito importante para uma linguagem de programação. O que é preciso fazer para garantirmos um bom ecossistema?

Matz: Do ponto de vista do usuário, a coisa mais importante é quais benefícios a linguagem de programação pode oferecer. Antes de Rails aparecer, muitos usuários de Ruby, incluindo eu próprio, achavam Ruby uma linguagem amigável, e esse era o motivo pelo qual gostávamos de a usar. Depois que Rails nasceu, mais e mais pessoas gostam de usar Ruby porque é muito produtivo desenvolver sistemas Web usando Rails. Então eu acho que se você puder comunicar aos seus usuários quais são os benefícios por usar a sua nova linguagem de programação, isso irá ajudar com sua adoção e aumentar as chances de sucesso.

 

Zhou: Muito obrigado, Matz! Você tem mais alguma coisa para dizer aos programadores chineses?

Matz: No livro The World of Code eu mencionei que a programação provavelmente vai se desenvolver e evoluir na forma de código aberto. Novas gerações de linguagens de programação e softwares provavelmente vão emergir como projetos open source. As pessoas estão felizes em usar o software livremente desenvolvido por outras, e se inspirar por isso, e trabalhar em seus próprios projetos open source e causar um pequeno impacto no mundo – aí você se torna um engenheiro de software de nível mundial. Os engenheiros de software que eu encontro na China são todos muito trabalhadores e adoram aprender. Espero que mais dessas pessoas assumam o desafio, e se tornem programadores de nível mundial que irão causar um bom impacto.

Entrevista com Yukihiro “Matz” Matsumoto – Parte 2

Parte 2 da entrevista realizada na RubyConf China 2012 com o criador de Ruby, Yukihiro “Matz” Matsumoto. Para ler a parte 1, clique aqui. A tradução para o Português é de minha autoria e a entrevista em Inglês pode ser lida no blog de Fred Wu. Inicialmente, eu iria dividir a entrevista em duas partes, mas resolvi criar também uma terceira parte (devido ao fato da entrevista ser mais longa do que eu avaliei a princípio) que será publicada aqui no blog na próxima segunda-feira. Espero que gostem!

<- Ir para a Parte I

Zhou: Muitos acreditam que a popularidade de Ruby se deu por causa de Ruby on Rails e você concorda com isso em seu livro. O que você acha que fez Rails tão bem sucedido?

Matz: Primeiro e mais importante, [Ruby on Rails] se beneficiou do rápido crescimento da Web – quase toda plataforma de desenvolvimento de software está mirando no campo da Web. O que era antes desenvolvido usando a tradicional arquitetura Cliente-Servidor pode ser agora implementado na Web. O número de aplicações que podem ser desenvolvidas para a Web cresceu, e isso é importante. Em segundo lugar, Ruby é otimizado para um desenvolvimento mais fácil e uma maior produtividade de desenvolvimento. Eu acho que esses dois motivos combinados fizeram Rails ter sucesso. Além disso, Ruby também tem poderosas qualidades tais como meta-programação e extensibilidade por meio de monkey patching. Por meio dessas funcionalidades, classes básicas podem ser aprimoradas, e DHH [David Heinemeier Hansson, criador do framework Ruby on Rails] criou Rails usando essas poderosas características de Ruby. Para pessoas que nunca tocaram em Ruby, por exemplo aqueles programadores Java que gostam de linguagens “inflexíveis”, eles ficarão tipo “Huh? Você pode fazer isso?” – e eu acho que essa é também uma das razões pela qual Rails é tão popular.

Zhou: É dito que DHH iria criar um framework Web usando PHP, mas acabou mudando para Ruby.

Matz: Sim, e eu acho que a razão para isso pode ser a limitação de PHP em meta-programação. Depois que Rails foi lançado, uma série de frameworks PHP saíram baseados em Rails, tais como Symfony e CakePHP. PHP, no entanto, não tem muitas das poderosas funcionalidades encontradas em Ruby, e puramente da perspectiva de desenvolvimento eu ainda acho que Rails é o mais poderoso. Aliás, eu na verdade encontrei DHH antes, na Dinamarca. Naquela época ele ainda não tinha começado a aprender Ruby ainda, talvez esse encontro tenha tido um pequeno impacto nele.

Zhou: Ruby está sendo amplamente usado para a Web, mas um tópico quente entre os leitores chineses é a direção em que Ruby está se desenvolvendo fora da Web. Algum comentário sobre essa questão?

Matz: Verdade, muitos projetos Web usam Ruby, por exemplo frameworks Web como Rails e Sinatra etc O mundo da programação, no entanto, é muito mais do que simplesmente a Internet, e eu sempre quis que Ruby saísse da Web para outras áreas. No futuro próximo, eu gostaria de ver Ruby ser usado em três campos:

1. Computação científica. Nesse campo, linguagens como Python, R e Matlab são as escolhas populares. Eu espero que Ruby em breve se torne um deles. Na verdade, nos estamos desenvolvendo um projeto chamado SciRuby, e nos esperamos que ele nos ajude com a adoção [de Ruby] na computação científica.

2. Computação de alta performance. Essa área é de certa forma relacionada com a computação científica – usar supercomputadores para realizar operações computacionais. Comparado com C++, Ruby é mesmo muito lento, e esse é o motivo pelo qual as pessoas acham que Ruby não é adequado para computação de alta performance. Na Universidade de Tóquio, um estudante pesquisador está trabalhando em um projeto para compilar código Ruby para código em C antes da compilação para código binário. O processo envolve técnicas como a inferência de tipos, e em cenários ótimos a velocidade atinge 90% daquela de um código C escrito à mão. Até agora só há um paper publicado, nenhum código aberto ainda, mas eu estou esperando que no próximo ano tudo seja revelado.

3. Sistemas embarcados. Para micro dispositivos como celulares, equipamentos médicos e robôs, Ruby não é realmente apropriado devido ao seu [alto] uso de memória e APIs. Portanto, precisamos de algo mais apropriado para esses sistemas embarcados nos quais o consumo de memória tem de ser baixo e as APIs tem de ser otimizadas. MRuby é desenvolvido para isso.

Zhou: O Twitter foi principalmente construído usando Rails, mas eu li uma notícia recentemente sobre o surto de tráfego durante o período da eleição presidencial nos EUA e o Twitter está agora migrando para outras plataformas para ajudar com a escalabilidade. Qual é a sua visão sobre isso?

Matz: Há muitas razões eu acredito. Primeiro de todas, ninguém poderia ter previsto o grande sucesso do Twitter – quem teria pensado que um serviço que essencialmente fornece 140 caracteres de texto para blogar se tornaria uma das maiores redes sociais. Durante seu rápido crescimento eles adicionaram uma série de novas funcionalidades, e eu acho que Ruby contribuiu para isso – permitiu que muitas novas funcionalidades fossem pensadas e implementadas em uma curta quantidade de tempo. O Twitter não poderia ter previsto a quantidade de tráfego com a qual eles lidam agora, então é justo dizer que eles agora atingiram o limite de sua arquitetura desenvolvida tempos atrás.
Para resolver esse problema, o Twitter precisa desenvolver uma nova arquitetura do início para lidar com o sempre crescente tráfego. Entretanto, Ruby ainda pode ser usado para reescrever a arquitetura (risadas). Mais seriamente, no entanto, quando uma plataforma atinge seu limite, há algumas maneiras de resolver os problemas tal como reescrever a arquitetura e mudar para outra linguagem / plataforma etc. Eu acredito que a maneira mais eficiente de se fazer isso é reescrevendo a arquitetura, e isso é exatamente o que o Twitter tem feito. Durante o processo de reescrita, os engenheiros do Twitter quiseram encarar mais desafios, então eles escolheram Scala. Pelo motivo de Scala ser uma linguagem compilada, seu desempenho é ótimo, então é uma boa escolha para a nova arquitetura.
Minha opinião é a de que quando o seu sistema está ainda na fase de crescimento, é muito mais importante ter a habilidade de reagir rapidamente a mudanças, e isso é o que uma linguagem altamente flexível como Ruby oferece. A partir do momento em que o seu sistema atinge um ponto de maturidade, estabilidade e sucesso, aí ter uma nova arquitetura que economiza recursos faz sentido. O Twitter apenas escolheu usar Scala por seus componentes principais, a interface Web e muitas de suas ferramentas internas ainda estão usando Ruby. Por sinal, eu fiz uma visita ao Twitter no último mês e lá conversei com muitos de seus engenheiros – Ruby ainda está sendo bastante utilizado (risadas).

Zhou: Plataformas móveis se tornaram quentes e mais quentes nos últimos anos devido ao aumento no uso de smartphones, tablets e outros dispositivos móveis. Em termos de linguagem de programação, Android usa Java e o iOS usa Objective-C. Sobre linguagens de script como Ruby, como você as vê nesse contexto?

Matz: Sem sombra de dúvida, até agora para desenvolver em Android você usa Java e para o iOS você utiliza Objective-C. Mas isso cria uma enorme barreira, já que você teria que reescrever seu aplicativo se você quisesse o trazer de uma plataforma para outra. Projetos como PhoneGap e Titanium tentam resolver esse problema, com linguagens como JavaScript e Lua para oferecer compatibilidade entre diferentes plataformas. Para Ruby, há um projeto chamado Rhodes – você pode usar Ruby para escrever aplicativos que irão rodar em iOS, Android e Blackberry.
Nos velhos dias, dispositivos móveis eram muito menos poderosos do que PCs, e se aplicativos não pudessem rodar a toda velocidade eles eram então inúteis. Hoje, no entanto, dispositivos móveis se tornaram significativamente mais velozes, e o uso de frameworks que suportam múltiplas plataformas se tornou muito mais prático. Eu acho que essa forma de se desenvolver para plataformas móveis irá se tornar mais e mais popular. Por sinal, nós falamos de MRuby antes, e usar MRuby para o iOS e para o Android já está em curso, provavelmente mais aplicativos serão desenvolvidos usando MRuby em um futuro próximo.

-> Ir para a Parte 3

Entrevista com Yukihiro “Matz” Matsumoto – Parte 1

A RubyConf China 2012 aconteceu em Shanghai nos dias 17 e 18 de novembro. Graças a um tweet, tive acesso a uma tradução para o inglês de uma entrevista realizada com o grande Yukihiro “Matz” Matsumoto, cientista da computação japonês responsável pela criação da linguagem de programação Ruby. A entrevista foi realizada pelo tradutor Zi Heng Zhou. A tradução para o inglês foi feita por Fred Wu e pode ser acessada em seu blog.

Na entrevista, Matz fala sobre seu novo livro The Future of Computing (infelizmente, disponível apenas em japonês por enquanto), sobre a criação de Ruby, sobre o futuro da programação e sobre projetos interessantes da comunidade Ruby (como MRuby, uma implementação minimalista da linguagem com foco em micro-dispositivos, tais como celulares, equipamentos médicos e robôs).

A tradução para o Português é de minha autoria. Não sou tradutor profissional, mas fiz o máximo para manter alta fidelidade em relação à versão em inglês. Pelo fato da entrevista ser grande, resolvi dividir ela em duas três partes. A segunda parte será lançada segunda que vem. Espero que gostem!

Zhou: O novo livro do Sr. Matsumoto, The Future of Computing, foi lançado mais recentemente neste ano e está sendo traduzido para o chinês para ser publicado no ano que vem, em data ainda indeterminada. O seu livro anterior, The World of Code, recebeu grandes elogios dos leitores chineses. Qual é a diferença entre esse livro e o seu novo lançamento?

Matz: The World of Code tem 14 tópicos no total, e cada tópico cobre o básico – eles cobriram mais amplitude do que profundidade. O novo livro, por outro lado, tem um tópico definido – reflexões sobre as tecnologias emergentes no futuro, por isso o campo coberto é mais estreito e com maior profundidade do que o último livro. Além disso, o novo livro discute muitas coisas por escala temporal, tais como a história e as mudanças desde a invenção da computação, e o impacto da computação no futuro de nossas vidas. Por isso, são pensamentos tanto do passado como do futuro. O mundo da computação está mudando rapidamente, e o propósito deste novo livro é discutir a direção que a computação está tomando para o futuro.

Zhou: Falando sobre a história da computação, você tocou em alguns pontos relacionados com a lei de Moore neste último lançamento, certo?

Matz: A lei de Moore descreve a regra de mudança durante a história do hardware. O livro discute não só as mudanças na computação por si só, mas também as mudanças nos ambientes que a cercam.

Zhou: Sobre o tópico da evolução das linguagens de programação, Paul Graham disse em The Hundred-Year Language que os principais galhos da árvore evolutiva passam pelas linguagens que possuem os menores, mais enxutos núcleos. No novo livro você parece sustentar uma opinião diferente. Você pode nos dizer o porquê? E qual é sua posição a respeito da evolução das linguagens de programação?

Matz: Paul ama Lisp e Lisp bate perfeitamente com as características das linguagens de programação descritas em sua dissertação, e por isso Paul calcula que as linguagens de programação daqui a 100 anos vão se parecer com Lisp. Na realidade entretanto, Lisp está por aí há mais de 50 anos, e para ser honesto não é uma das linguagens populares. Na minha opinião, isso pode ter acontecido porque a maior parte dos programadores não acha Lisp suficientemente charmosa. Em outras palavras, há uma lacuna entre as linguagens tão chamadas de “menores, mais enxutos núcleos”, “bonitas”, e a expectativa dos programadores. Seria compreensível se o charme de Lisp não tivesse sido aceito por todos em um ou dois anos, mas por mais de 50 anos não ter se tornado popular, será que não poderia ser por fundamentalmente não ter correspondido à nossa expectativa? Existe uma enorme diferença entre linguagens amigáveis ao ser humano e linguagens que possuem os “menores, mais enxutos núcleos”, e eu receio que a lacuna entre elas pode não se fechar mesmo em 100 anos. Em relação a como futuras linguagens de programação irão se parecer, eu acho que elas terão um modelo de runtime semelhante ao de Lisp e serão facilmente compreensíveis por humanos. De repente, Ruby se parece muito mais próxima disso, não é?

Zhou: Sr. Matsumoto, você é o pai de Ruby. Nós sabemos que durante o design de uma linguagem de programação pode haver diferentes decisões a serem tomadas, tal como se a linguagem terá tipagem dinâmica ou estática, se vai ser baseada em protótipos ou classes etc. Quando você estava criando Ruby, qual foi a decisão mais difícil que você teve de tomar?

Matz: Antes de Ruby, eu na verdade já havia criado outra linguagem de programação enquanto estava na universidade, e essa linguagem tinha tipagem estática, similar a Eiffel. Eu gostava de linguagens com tipagem estática, mas a que criei durante a universidade era mais para propósitos acadêmicos. Então, eu criei Ruby e acho que foi a decisão correta [ter escolhido tipagem dinâmica] – pode não ter sido a decisão mais difícil, mas foi certamente a maior decisão. Agora que a decisão de ser uma linguagem dinâmica havia sido tomada, linguagens como Smalltalk, Lisp e até um certo ponto Perl tiveram influências em Ruby. Ruby oferece mixins, e mixins não eram muito comuns na época em que Ruby foi criada. Mas porque eu não gosto de herança múltipla, eu sempre acreditei que deveria existir um caminho mais fácil para se atingir resultados semelhantes, então eu desenvolvi mixins em Ruby.

Zhou: Olhando para trás, há algo em Ruby que você gostaria de ter feito diferente?

Matz: No começo meu objetivo era substituir Perl como minha ferramenta de trabalho, então eu peguei emprestado várias ideais de Perl, tal como usar o cifrão ($) para definir variáveis especiais. Olhando agora para Ruby, ela me parece um pouquinho exagerada e muito semelhante a Perl. Há algumas outras coisas, mas principalmente eu acho que ela é muito semelhante a Perl. Naquela época, antes dos Ruby idioms serem formados, haviam muitas coisas que foram emprestadas de Perl. Hoje, eu acho que muitas dessas coisas [emprestadas de Perl] não são mais necessárias graças aos idioms de Ruby e de Ruby on Rails.

-> Ir para a Parte 2