Eu e mais uns 10% da população mundial sofremos de um problema de visão que não nôs permite ver em três dimensões, ou seja, não temos a capacidade de perceber a profundidade dos objetos a nossa volta.
Os motivos pra isso são vários, no meu caso, por ser estrábico a diferença entre as imagens que cada olho vê é muito grande e então o cerebro nao consegue fundir as mesmas em uma imagem 3d coerente, desiste de tentar, e faz com que apenas um olho “veja” de cada vez.

Isso me impede por exemplo de ver os efeitos de profundidade em filmes como Avatar.

Mas meus problemas acabaram-se.

Sexta feira estive na fnac da avenida paulista, pra poder ver a nova televisão da samsung led 3d. E pra minha surpresa, com uso do óculos que acompanha a tv e que usa uma tecnologia que faz com que se veja cada imagem com um olho de cada vez, eu consegui ver em três dimensões.

A ironia disso, é que no mundo real, eu não vejo em 3D, mas em uma tela plana, com a ajuda da tecnologia sim.

Agora é só esperar mais uns anos pra poder implantar algo assim direto no cerebro

E os primeiros frutos apareceram, agora é possivel executar o que poderia ser considerado o Hello World do Android.

Na verdade esse código é meio diferente do original java, onde a constante hexadecimal é definida em uma classe, mas isso logo será resolvido.

Agora deixa eu voltar a assistir Fringe.

Comecei a trabalhar nas horas vagas em um projeto open source.

O Boojay, um emissor de bytecode java para a linguagem Boo.

Minha ideia primaria é poder usar Boo para o desenvolvimento de software para Android, e no embalo retribuir a comunidde Boo trabalhando no boojay e no monolipse.

Name – TIM CONNECT FAST 72403
APN – tim.br
proxy – not set
port – not set
Username – tim
Password – tim
Server – not set
MMSC – not set
MMS proxy – not set
MMS port – not set
MCC – 724
MNC – 03
APN type – not set

O MNC pode ser 02, 03 ou 04, dependendo da região.

A extensibilidade se dá na forma de macros e atributos sintaticos que modificam o código gerado no momento da compilação, e também em mudanças no próprio compilador, através do conceito de pipelines de compilação.
Para se entender melhor, quando você usa o compilador booc, o mesmo executa uma série de passos, que começa com o parsing do arquivo, execução das analises semanticas, transformações na AST e por fim geração do assembly (exe ou dll). Isso é o que é conhecido como pipeline padão de compilação.
O compilador booc já vem com várias outras pipelines definidas, e permite também que o programador defina outras.

Uma das pipelines bem interessantes que já vem com o compilador é a pipeline chamada boo, essa pipeline executa todo o processo de compilação normal, com todos os passos e todas as transformações que são aplicadas a AST e no final, invés de gerar um assembly, gera uma saida boo com todo o código que seria compilado para a criação do assembly.

Parece abstrato demais ? Vamos ao código então, o velho e bom Hello World.

Esse é um código mínimo em Boo que escreve a mensagem “Hello World” na tela, mas você pode se perguntar, esse não é um executavel .Net ? Cadê o static void Main… ?

Vamos usar a nossa nova conhecida, a pipeline boo, pra descobrir. Salve o programa no arquivo hello.boo e rode:

E você terá:

A saída mostra o código que seria compilado depois de todas as mágicas executadas pelo compilador.

Note o uso do parâmetro -p:boo, é ele que diz ao compilador pra usar a pipeline boo e não a padrão.

Um detalhe, a chamada a print virou um System.Console.WriteLine, porque print é uma macro que ao ser executada expande para a chamada equivalente WriteLine.

Isso é só uma pequena parte do que pode ser feito com as pipelines, de geração de código em outra linguagem, verificação de padrões de desenvolvimento, compilação em memória, code completing, as possibilidades são várias.

Quais caracteristicas Boo tem que estão ali pra atender esse objetivo ?

Parecido com Python.

Python é uma linguagem que é conhecida pela sua elegância e sua capacidade de expressar uma grande quantidade de informação de uma forma sucinta, copiando o básico da sintaxe de Python, Boo já começa com o pé direito nesse quesito.

Açúcar sintático para patterns comuns de programação.

Boo suporta uma gama de construções de forma simplificada, listas, hashtables, arrays. Alem dessas estruturas, formas simples de criação de objetos, uso de expressões regulares, formatação de strings e vários outros detalhes fazem de Boo uma linguagem que necessita de pouca digitação.

Alguns exemplos:

Declaração automática de variáveis.

Em Boo, um assignement cria uma nova variável local naquele escopo.

Inferencia automatica de tipos.

Uma coisa verdadeira no mundo da computação, é que muitas vezes nós programadores somos preguiçosos, só as vezes é claro. Exemplo, da do um método como o a seguir:

Não está na cara que o método two, retorna um tipo inteiro ? e que dois contem um inteiro também ? Então porque devemos escrever códigos assim:

Na verdade em Boo não é necessário, a primeira versão funciona perfeitamente, gerando código equivalente a segunda versão, tendo assim todas as vantagens de código estaticamente tipado.

Fica a cargo do programador decidir qual código escrever. Eu como bom programador sei qual versão prefiro .

Classes não são necessárias.

Para algumas utilizações como em scripts, muitas vezes a declaração de uma classe só pra deixar o compilador feliz não faz muito sentido.
Vocês já viram maior cambiarra do que o famoso “public static void main” ? Poxa, eu só queria escrever um hello na tela e tenho que declarar uma classe ? com um método public static ?? que recebe uma lista de parâmetros que eu não estou interessado ???

Ainda bem que em Boo, meu HelloWorld pode ser simplesmente

Esse post já esta meio grande, no proximo falaremos de expressividade. Até lá espero aprender o que isso quer dizer.

Cheers.

Uma das features interessantes de  Scala é que ela permite ao programador extrair informações de objetos usando pattern matching, por exemplo se você tiver o seguinte tipo chamado Email:

Seria possivel testar se um objeto é do tipo Email, e ao mesmo tempo retornar o name e domain com o seguinte código:

No caso de unknownObject ser declarado como:

A saida seria “georges at gbenatti.net”

Já se unknownObject fosse declarado como:

A saida seria “It’s not an email”

Mas não seria muito legal se fosse possivel fazer essa segunda opção funcionar ? Ai entra a elegância de Scala, você pode definir extractors que permitem que sejam extraidos dados de determinadas estruturas, sejam elas árvores, listas e até mesmo strings.

Um extractor é um objeto Scala que define um método unapply. A responsabilidade do unapply é fazer o matching de um valor e o separar em seus componentes, para o caso acima o extractor poderia ser definido assim:

Definido esse extractor poderiamos reescrever o match da seguinte forma:

E ele funcionaria tanto com objetos da classe Email quanto com strings no formato name@domain, ou seja, código final do usuário simples e elegante.

Até mais pp pessoal…

Começando simples. Porque Boo ? O que Boo traz de novidade que você não conseguiria com outras linguagens ?

Os seguintes objetivos, retirados do Boo Manifesto devem dar uma idéia:

A clean and wrist-friendly syntax:
- Syntactic sugar for common programming patterns
- Automatic Variable Declaration
- Automatic type inference
- Automatic type casting
- Classes are not needed

Expressiveness:
- First class functions
- First class generators
- Duck Typing

Extensibility:
- Syntactic Attributes
- Syntactic Macros
- Extensible Compilation Pipeline

De todas essas features acho que o que mais diferença Boo, é a combinação de uma linguagem estaticamente tipada com uma capacidade muito grande de se extender a mesma, através de atributos, macros e a inserção de modificações na compilação.

Em um próximo post vou explicar brevemente o que são esses termos. Caso estejam com muita pressa, leiam o manifesto, ja que provavelmente vou copiar de lá mesmo a maioria dos exemplos

Cheers, até a próxima.

Já as linguagens estáticas normalmente não tem essa capacidade, algumas, como por exemplo Boo implementam essa possibilidade através de dispatch in runtime para os métodos que necessitam dessa caracteristica, já Scala tem uma solução bem elegante.

Por exemplo, digamos que você queira definir um método que espere um objeto que tenha as propriedades name e age, uma forma comumente usada em linguagens estáticas seria a seguinte:

Definir uma interface com os métodos que interessam:

Escrever as classes implementando BasicProperties e o método recebendo como parametro um objeto do tipo BasicProperties:

E então você poderia chamar o método assim:

Se você tivesse uma classe tipo:

Você não poderia usar um objeto desse tipo como parametro para printProp, já que a classe não herda BasicProperties.

A solução está na capacidade que Scala tem de definir algo que poderia ser chamado de anonymous interfaces, no caso, o método printProp seria escrito assim:

Como se você estivesse definindo como parametro um tipo anonimo, que tem um método name do tipo String e um método age do tipo Int

E então poderia executar:

Como se ve, um código muito parecido com o escrito em Ruby e Python, mais ainda com uma caracteristica de documentação, já que o método é explicito sobre o que ele necessita.

O objetivo era extrair o nome do service como uma string e as entries como um map de key values.

O servico como string é bem facil, considerando que o xml esta em uma variavel serviceXml, teriamos:

O que isso faz é basicamente pegar o attributo service do nó em questão e com esse dado pegar o nó como text.

A segunda parte é um pouco mais complexa então vamos por parte, primeiro pegamos as entries:

Esse codigo executa basicamente um XPath extraindo do xml o nó “extra” e deste a lista de nós “entry”

Então, para cada entry extraimos uma tupla com o valor da key e o value:

Aqui usamos um for expression para percorrer a lista entries e retornar (usando yield) uma tupla que contem o valor da key e o inner text da entry

E por fim criar um Map com esses dados:

Por fim, como construir um Map apartir de uma lista, ou nesse caso de um generator ?

Maps podem ser contruidos usando de um numero variavel de tuplas usando algo como Map(tupla1, tupla2, tuplaN).

Se tentarmos usar Map(entriesTuple) o compilador vai reclamar falando que esse metodo nao pode ser executado com uma Seq[(String, String)], ou seja, uma sequencia de tuplas contendo duas Strings.

Temos que dar um jeito de passar essa Seq como um numero variavel de argumentos, e os desenvolvedores de Scala nos deram uma forma de fazer isso, quando temos que passar uma lista para um método que espera um número variavel de argumentos podemos fazer assim:

Essa anotação diz ao compilador para expandir os parametros

Juntando tudo temos:

Muita explicação pra pouco código, assim é Scala

Cheers