Esbarrei com este projeto que achei bastante interessante, como um link às vezes é mais verboso do que mil palavras:

- Droplet

Neste 14/11/2009, o portal Embarcados e o grupo C & C++ Brasil com a produção da Tempo Real Eventos realizou, no Hotel Century Paulista em São Paulo, a edição 2009 do Seminário C & C++ para Sistemas Embarcados. Mais uma vez esta foi uma experiência extremamente gratificante,  principalmente pela satisfação que alguns colegas, amigos e o público em geral demonstraram durante o desenvolvimento do seminário e pós sua realização.

O DQ, da Tamid, realizou em seu blog algumas notas e abaixo segue alguns comentário que não representa nem 1% do que foi o seminário:

- O evento iniciou com uma palestra sobre Interfaces de Periféricos com Microcontroladores em C do DQ, que mostrou-se um excelente conteúdo para um Hands On com o subtítulo de “21 formas de piscar um led com linguagem C em vários microcontroladores”!

- Na sequência foi a palestra do Luiz Barros, sobre Otimização de C++ para Sistemas Embarcados, que foi bem interessante e acabei em vários momentos dando meus pitacos, curiosamente mais uma vez confirmei que em aplicações com a plataforma SH4, C++ tem sido amplamente utilizado, durante o evento desenvolvedores de cinco empresas deram este feedback para mim.

- Durante o almoço, entre bits e bytes, conversamos de flamewares (e lembrei da lei do ricbit), assembly vs C++, surgiu a conversa de um projeto que me relataram muito inusitado de um sistema, onde… bom, deixa eu voltar para os relatos do seminário! :^p

- Após o almoço, o Alessandro Cunha, da TechTrainning, apresentou uma palestra que foi muito pontual tanto no assunto quanto no tempo consumido. Nos primeiros contatos com ele, fiz uma sugestão besta de tema e ele conseguiu extrair algo de bom da besteira que apresentei e formatou uma obra prima: Projetando Sistemas Embarcados com Baixo Consumo de Energia, com dicas preciosas que cativaram o público.

E encerrando o conteúdo técnico do seminário,  o Luiz Barros desmistificou o “Desenvolvimento de Device Driver para GNU/Linux”, derepente surgiram algumas pessoas no evento e quando fui conferir descobri que elas vieram apenas para ver esta palestra, alguns até começaram a dizer que perderam o medo do device drivers development. Particularmente nunca tive medo, porém device driver & kernel development é uma arte negra…

Anteriormente ajudei a enumerar 17 formas de acender um led e derepente, não mais que derepente, fez-se a teatralização da piada:

- “quantos engenheiros são necessários para acender um led”

do qual eu participei desta teatralização como coadjuvante, no qual entrei mudo e sai calado e depois me disseram que a resposta seria:

-  ”um de hardware, um de firmware e um de software” (tsc)…

Mas o Alessandro Cunha foi além e pensou em escrever o livro 2001 formas de acender um led, mas nem só de led foi o seminário! Houve CAN, RS232, SPI, microcontroladores, C, C++ e felizmente tive a oportunidade rever alguns amigos e realizar alguns contatos preciosos. Particularmente fiquei feliz que uma sugestão que eu dei a Microgênios foi levada a sério e hoje eles também estão produzindo e comercializando a plataforma Arduino no Brasil, assim como troquei figurinhas  sobre os bugs da BeagleBoard com o Luis Barros, conheci um pouco mais sobre a plataforma Tower com vários colegas, vi uma apresentação de uns alunos do Dado, numa EVDK Luminary,  de uns jogos desenvolvidos em eLua que poderiam seduzir muitos aficcionados em jogos; entre muitas outras conversas.

Finalizando oficialmente evento, realizamos um sorte de brindes oferecidos por Texas Instruments, Freescale, Atmel/Kobama, Editora Erica, Tempo Real Eventos, Agit Informática e Microgênios, onde as fotos dos ganhadores podem ser vistas aqui.

Mais uma vez, fui um dos primeiros a chegar no local e um dos últimos a sair do happy hour, que aliás, como sempre, foi uma extensão do evento e o início da organização dos próximos eventos.

Namastê!!!

Uma linguagem com as facilidades sintáticas de Python, porém estática e que gere executáveis com opcodes com pouca dependência e desempenho similar aos de C e que desfrute dos recursos computacionais de concorrência que os atuais processadores e computadores oferecem com facilidade é algo que muitos, a muito tempo desejavam.  Conheço engenheiros que só tem C e Assembly como opção e que sempre costuma afirmar que “odeiam C”, pelos clássicos problemas da linguagem e compiladores.

Para minha surpresa li este artigo ontem no Slashdot:

Go, Google’s New Open Source Programming Language

E como ele fazia referência a um artigo na ARS Technica, fui conferir a notícia:

Go: new open source programming language from Google

Go, como toda linguagem,  nasceu de necessidades, frustrações e certamente surpreenderá,  logo criará uma legião de fãs assim como frustrará muitos outros, mas sendo Open Source e com uma licença BSD-Style ela tem potencial de agregar muitos  desenvolvedores ao seu core-development. Particularmente eu já instalei, comecei a brincar já me frustrei mas amei as goroutines.

O dilema que está em sua motivação é muito parecido com o que alguns já passaram em certos desenvolvimentos, escolher entre uma linguagem com compilação eficiente, execução performática e facilidade de programação; para oferecer tudo isto nativamente numa única linguagem de programação os autores resolveram partir para seu desenvolvimento.

Para quem dizia que eu era meio maluco por gostar de Haskell, Erlang, C++ e Python e uma linguagem ideal seria a que fosse uma composição de características de todas elas, tive uma fantástica surpresa, além de uma (quase) decepção!

A surpresa fantástica, veio pelo fato que o Google busca com este empreendimento:

- “Uma nova linguagem de programação que busca a performance com concorrência embutida, que é quase comparável a C, mas com a sintaxe mais expressiva e compilação rápida” e além de tudo ela tem pedigree! Pois entre seus projetistas estão Robert Griesemer, Russ Cox, Rob Pike (um dos pais da linguagem Limbo e do Plan9) e Ken Thompson;  K, apesar de dispensar apresentações  apenas para recordar ele  é um dos pais da linguagem B,  do UNIX e também trabalhou no projeto do Plan9.

Da ARS Technica eu fui direto para o site do projeto: golang.org

E encontrei mais algumas definições curiosas:

- “Go” buscou inspirações em todas estas linguagens para criar uma de propósito geral, projetada com “systems programming” em mente, “fortemente tipada” (aqui eles não beberam na fonte de Python) e com uso de garbage-collect (tsc) com suporte nativo a programação concorrente  e com gramática compacta e regular, isto tudo soa muito interessante.

Porém, no site do projeto um dos links me chamou muito a atenção:

Go for C++ Programmers

Como o foco dela é “system programming” e por  suas características performáticas, de cara já forçar um replace de C++ era esperado. Será este um grande golpe em C++ ou um golpe mortal na linguagem D? Por outro lado lembro-me da afirmação do Herb Sutter que os programadores C++ são os mais abertos a aprenderem novas linguagens, esta afirmação nem sempre me parece verdadeira, mas para os casos onde ela se aplica (que são muitos) o foco do Google parece estar correto.

Agora, veja esta simples comparação sintática:

Go                           C++
var v1 int;               // int v1;
var v2 string;            // const std::string v2;  (approximately)
var v3 [10]int;           // int v3[10];
var v4 []int;             // int* v4;  (approximately)
var v5 struct { f int };  // struct { int f; } v5;
var v6 *int;              // int* v6;  (but no pointer arithmetic)
var v7 map[string]int;    // unordered_map<string, int>* v7;  (approximately)
var v8 func(a int) int;   // int (*v8)(int a);

De cara ela me irrita  pois var me lembra Pascal, mas a declaração de struct me pareceu mais elegante e prefiro declarações explícitas de funções, classes e métodos, ponto para Go.

Outro detalhe que me chamou a atenção é que por enquanto há compiladores disponíveis para Linux e Mac OS X que geram opcodes para AMD64 (x86 e 64 bits), x86 de 32 bits e está no forno um compilador ARM! Será que ele permitirá compilação bare-metal para produção de firmware? Tenho suspeita que sim.

Vejam algumas diferenças conceituais entre C++ e Go:

• Go não tem classes com  construtores ou destrutores. Mas sim  métodos de classe, uma hierarquia de herança de classes e funções virtuais, ela  fornece interfaces que são utilizadas como os templates de C++; portanto ela oferece programação genérica.
• Go  usa garbage collection.  Não é possível  liberar memória explícitamente.  Este gerenciamento de memória “pretende” ser incremental e  altamente eficiente em processadores modernos.
• Go tem ponteiros, mas não a aritmética de ponteiro. Não é possível empregar um ponteiro para percorrer os bytes de uma string.
• Arrays são valores de primeira classe. Quando um array é usado como um parâmetro de função, a função recebe uma cópia da matriz, não um ponteiro para ele. No entanto, na prática, muitas funções usam “slices” de parâmetros; “slices” suportam os ponteiros para arrays subjacentes. “Slice” é um recurso importante da linguagem.
• Strings são fornecidas pela linguagem. Mas elas não podem ser alteradas depois de sua criação.
• Tabelas hash são fornecidas pela linguagem. Eles são chamados de maps.  Velhos conhecidos de outra linguagens.
• Threads são separadas da execução, e os canais (channels) de comunicação entre eles, são fornecidos pela linguagem.
• Certos tipos (maps e channels)  são passados por referência, não pelo valor. Ou seja, passar um map para uma função não é copiar o map, e  as alterações da função do map são vistas pelo invocador.  Como referências de tipos de C++, porém mais similar como é em Python.
• Go não usa “header files”. Em vez disso, cada arquivo fonte é parte de um package definido, similar a Python, Oberon e Pascal. Quando um package define um objeto (tipo, constante, variável, função) com um nome começando com uma letra maiúscula, esse objeto é visível a qualquer outro arquivo que importe esse package.
• Ela não oferece suporte a conversão implícita de tipo. Operações que misture tipos diferentes requerem casts (que em Go são chamadas de conversions).
• Go não suporta sobrecarga de funções e não suporta os operadores definidos pelo usuário.
• Go não suporta os qualificadores const ou volatile.
• Ela  usa nil para ponteiros inválidos e  C++ usa NULL ou simplesmente 0.

Sobre as diferenças sintáticas recomendo realmente a leitura da página Go for C++ Programmers, mas antes a leitura dos documentos Tutorial, Effective Go,  Language Design FAQ, Language Specification entre outros documentos para o  entendimento de alguns conceitos como as fantásticas goroutines. Porém se o tempo permitir, assista a apresentação do Rob Pike  no Tech Talk, chamada What is Go?

Confesso que algumas características não me agradaram muito, já outras me pareceram muito interessantes (leia-se channels e goroutines), porém ainda é cedo para apresentar uma avaliação. Entrei na Go Nuts! que é a lista oficial da  linguagem e com 2 dias de existência ela já tinha mais de 800 mensagens e 1.200 membros. Será que esta linguagem irá revolucionar? Um ponto positivo é que ela é Open Source porém patrocinada pelo Google, well… tenho minhas suspeitas que sim e em pouco tempo ela irá causar uma reviravolta.

Maiores detalhes acessem o site oficial do projeto: golang.org

PS: Já estou vendo os anúncios de emprego solicitando programadores com 2 a 5 aos de experiência em G0, antes mesmo do lançamento da linguagem completar 1 ano!

É com grande prazer que depois de alguns meses sem postar nada por aqui, venho quebrar o silêncio com uma notícia super interessante.

Depois do sucesso do evento do ano passado, este ano o Portal Embarcados, a Tempo Real Eventos e o grupo C & C++ Brasil realizará a segunda edição do Seminário C & C++ para Sistemas Embarcados.

Com palestrantes  de alto-nível e conteúdo super-interessante,  como o do ano passado, ele está imperdível!

Ele  acontecerá no dia 14 de novembro de 2009, em São Paulo, no Century Hotel, maiores detalhes vejam aqui.

Nos vemos lá.

Nasmastê!

    Em 1996 eu fiquei extremamente feliz quando recebi minha edição da Dr.Dobbs e vi um artigo escrito por brasileiros chamado “Lua: an extensible embedded language”, confesso que fiquei tão surpreso que acabei comentando com vários colegas sobre o artigo e sobre esta linguagem que eu já tinha ouvido falar mas não conhecia ainda e acabei ficando com o estigma de ser o “cara do Lua” por alguns meses. Oito anos depois, ao encontrar um colega de faculdade ele veio me perguntar se eu “ainda” programava em Lua.

    Após 11 anos, tive outra boa surpresa quando conheci o projeto eLua, que é mantido pelo romeno Bogdan Marinescu em conjunto com o brasileiro Dado Sutter  do laboratório LED da PUC-Rio, que basicamente é um projeto que insere Lua no contexto de programação de microcontroladores, oferecendo melhor reusabilidade de código e redução de complexidade e custo de desenvolvimento. 

    Hoje ele tem suporte para as plataformas LM3S, AT91SAM, STR9, STR7, LPC2888, i386 e segundo o Dado Sutter logo o eLua estará suportando novas MCUs, assim como mais exemplos tem sido escritos com boa frequencia e novos módulos estão em desenvolvimento.  Eu o testei no meu AT91SAM7×256 e  fiquei muito entusiasmado com o projeto.   

    Para quem ficou interessado em saber um pouco mais sobre o e-Lua,  o projeto está com um novo site – baseado no Sputnik  que é um Wiki engine 100% escrito em Lua –  e a URL oficial do projeto é   www.eluaproject.net