A Era do Javascript

Leia no novo blog

Meus primeiros contatos com Javascript datam de uma época distante, onde o Netscape era o mais popular browser da Internet! Eu usava um servidor Sun e estudava um produto chamado Netscape One, que vinha com uma tecnologia de script do lado servidor chamada de LiveScript. Ela já era também disponível no browser, mas não prestava para muita coisa na época. As tecnologias quentes eram o CGI e o SSI. Eu me interessava também pela novidade do momento, a tal de PHP 3 ! Se minha memória não falha, estou falando do período de 95 a 98.

Tecnologias como Java Applets nunca "pegaram", sempre foram consideradas lentas demais, pesadas demais. Já com o Javascript, além de lento, não se podia fazer muita coisa. A maior parte dos trabalhos se limitava a validação de campos e tarefas menores com strings e datas. Jogos em Javascript, só de forca e da velha. Nessa época eu escrevia CGI's em C++ e lembro da magia que foi aprender a programar em Perl.

Javascript nunca foi uma linguagem "seria" até alguns anos atrás, quando ficou impossível de ser ignorada. No lançamento do iPhone, muitos ficaram chocados com idéia inicial da Apple de aplicações web com Javascript... depois é que eles liberaram aplicações nativas. Isso já em 2007... mas a maioria dos celulares tinha browsers de Internet sofríveis, muitos sem Javascript. Hoje vemos compiladores de e para Javascript, compactadores, obfuscadores e uma infinidade de livros. Javascript está instalada na maioria dos computadores do mundo, incluindo telefones celulares e mesmo sistemas embarcados. Você pode até mesmo usar Javascript para instrumentar seu programa escrito em Java ou C++! É impossível ignorar a força do Javascript. A prova final para mim foi há algumas semanas quando vi uma pequena máquina virtual, suficientemente completa para rodar o kernel do Linux em Javascript, fora jogos como Doom e emuladores diversos, completamente escritos ou portados para Javascript!

A impressão que tenho é o mesmo que aconteceu na década de 80, onde para se ter velocidade programava-se em Assembly, mas era difícil e cada micro tinha o seu próprio Assembly incompatível. Isso era nítido na programação de jogos. Até nas revistas, os programas eram escritos parte em Basic, parte em Assembly. Com o passar do tempo, ficou prático escrever em Pascal e C, compiladas e muito mais fáceis que Assembly. Com o Javascript acontece a mesma coisa, quando começo a ver a quantidade de compiladores que agora geram códigos em Javascript, tenho a mesma impressão. Como escrever grandes programas em Javascript ainda é difícil, diversas bibliotecas e ferramentas podem ser utilizados para reduzir este esforço. Uma dessas ferramentas é a CoffeScript, que dá uma sintaxe limpa ao Javascript, inspirada em Python. É como se essas linguagens estivessem fazendo o trabalho que C e Pascal fizeram antes e o Javascript sendo o novo Assembly universal, afinal é suportado pela maioria dos micros e é multiplataforma. Não falo aqui que o Javascript substitui o Assembly, nada disso. Apenas um posicionamento das linguagens como ferramenta num cenário de aplicações global.

Como tudo agora é na ou para a Web, Javascript é incontornável. A popularização do suporte a HTML 5 nos browsers só vem a ajudar. Nos últimos anos, motores Javascript de alta performance se popularizaram no Google Chrome, FireFox, Safari e até mesmo no Internet Explorer! Canvas, WebGL, bancos de dados locais, web sockets, web workers, tudo disponível em praticamente qualquer browser, via Javascript! 

Multitarefa e Multiprocessamento

Leia no novo blog

Ao começar a escrever este post, lembro que julho foi um mês realmente atarefado, sem novos posts no JungleCoders. Mas foi um mês onde voltei a ler sobre as questões de hoje sobre multiprocessamento. Alguns anos atrás, havia menos processadores que usuários :-) Era a época dos computadores de grande porte ou mainframes.

Com a chegada do processador pessoal, iniciou-se a época do um para um, porém eram máquinas pequenas, com sistemas operacionais simples. Embora houvesse um processador por usuário, não havia sistema operacional, muito menos recursos no hardware, para suportar a troca de tarefas. Isso claro, para computadores pessoais, pois já existiam os super-micros e sistemas operacionais mais completos, como o Unix entre muitos outros. Com a evolução do Microsoft DOS e do próprio IBM PC, programadores começaram a se utilizar das interrupções de hardware para simular o multiprocessamento, eram os anos dos programas TSR (Terminate and Stay Resident). Quem nunca usou programas como Norton Guides ou Sidekick? Mas os mais populares eram os tais reloginhos que ficam no canto superior da tela. Todo programador DOS tinha que implementar um... Ok, o Mingo pode dizer que o Amiga já tinha multitarefa de verdade, mas poucos felizardos tiveram acesso a estes sistemas.

Para salvar a linhagem do IBM PC, surgiu o Intel 80286. Mas o pobre DOS continuava monotarefa, exceto pelos TSRs... A IBM lançou o OS/2 e renovou as esperanças de um sistema multitarefa para pobres mortais. Para empresas, o Novell Netware e variantes de Unix já existiam. Com a chegada do Intel 80386 a coisa ficou realmente séria e o Windows 3.0 começou a convencer que a multimídia seria o futuro. O novo sistema permitia que vários aplicativos rodassem ao mesmo tempo, mas não podiam ser mal comportados. Se uma tarefa resolvesse tomar conta do sistema operacional para si... descobríamos que se tratava de multitarefa cooperativa... era o fim. Novas versões do OS/2 surgiram com um novo termo, a tal multitarefa preemptiva. Com a preemptividade, o sistema operacional podia recobrar o controle da máquina, mesmo que uma das tarefas não contribuísse muito para isso.

Bom, o OS/2 nunca pegou realmente para usuários domésticos, sendo relegado a pequenos feudos corporativos e segundo lendas urbanas sobrevivendo até hoje em bancos. O Windows 95 trouxe a preemptividade para os sistemas da Microsoft e para nós, pobres usuários. O grande problema é que às vezes o sistema operacional travava... deixa isso pro passado :-) O sistema foi se estabilizando e agora temos outros tipos de problema. Máquinas domésticas passaram a ter 2 ou 4 processadores e sistemas como Windows XP e Linux têm dado conta da tarefa de utilizar os recursos destas máquinas, mas com uma restrição: se a aplicação é desenvolvida com um só thread, esta não pode ser distribuída para mais de um processador :-( Pode parecer pouca coisa, mas se você não tomar cuidado por ter a aplicação rodando mais lentamente numa máquina com dois processadores.

A grande questão hoje é como escrever programas para este novo mundo? Agora temos vários processadores para nossas aplicações, porem programar com threads ainda é muito difícil. Algumas pessoas acreditam que há necessidade de mudarmos a forma que programamos hoje. Outros acreditam em compiladores inteligentes, capazes de decidir que partes do código podem ou não ser executadas em paralelo. Apesar de não parecer grande problema, a Intel sinalizou que já possui processadores com 80 núcleos no laboratório. Imagine um dia ter uma máquina dessas e ter seu pobre programa rodando a apenas 1/80 do poder total da máquina :-) ?

Como nada é aceito por todos ao mesmo tempo, já existem várias abordagens para este problema. Uma delas é utilizar outras linguagens de programação, com paradigmas diferentes como Erlang ou Haskell. Meu pobre Python está longe disso. Segundo o Guido, a solução é utilizar vários processos e morar na casa mal assombrada dos IPC (Inter-process Communication). Pelo pouco que sei, Ruby anda pior ainda neste quesito. Java, C/C++/C# (*.net) estão bem, mas toda a dor de múltiplos threads fica para o programador.

Uma luz vem do mundo dos jogos, pois os processadores gráficos das placas de vídeo possuem mais de 30 pipelines. Rodando a mais de 500 MHz, estes processadores ficam sem uso quando não estamos jogando, um poder de processamento desperdiçado. Tanto a NVidia quanto a ATI prometeram publicar os compiladores para suas GPUs, mas já avisaram que a forma de programar é diferente.

Quem já trabalhou com IPC e threads sabe que o pode ser feito, mas não de graça. Como os softwares tem se tornado cada vez mais complexos, como resolveremos a questão de criar softwares capazes de aproveitar os recursos de multiprocessamento de nossas máquinas? Eu particularmente acredito na utilização de linguagens com novos paradigmas que propiciam a abstração dos threads, mas no fundo desejo que algo de novo surja na área de compiladores e que todos nós possamos continuar a programar como sempre programamos. Como nem só os computadores são multitarefas, eu resolvi acrescentar o estudo deste tipo de problemas a minha já enorme lista :-) Talvez eu troque meu sistema operacional...

Linguagens, teclados e Ruby

Hoje, pela segunda vez esta semana, eu li um texto que me chamou a atenção sobre a hipótese de Sapir-Whorf, isto é, a maneira que a linguagem pode influenciar o comportamento e a forma de pensar das pessoas. Eu fiz um paralelo entre linguagens de programação e teclados.

Lendo sobre Ruby, fiquei observando os inúmeros símbolos e a freqüência que estes são utilizados na linguagem. Para um pobre coitado como eu, que usa um teclado Belga no trabalho e um teclado Francês em casa... os símbolos importam muito. O criador da linguagem Ruby, Yukihiro Matsumoto , utilizava provavelmente um teclado Japonês. Ok, é parecido com o teclado QWERTY ocidental... mas fica aqui meu registro quanto aos símbolos e linguagens. Lembro que li anteriormente um texto sobre como a @ foi escolhida como símbolo do e-mail e como alguns símbolos foram escolhidos no FORTRAN devido ao reduzido teclado da época (1956~1957) e depois usados por outras linguagens. Uma página que encontrei e que ilustra a dureza daqueles tempos pode ser vista aqui.

O "Mat" não teria utilizado tantos pipes("|") se estivesse usando um teclado francês ou belga :-). Eu estou estudando Ruby novamente devido ao RubyOnRails. Ando tendo novas idéias para sites e francamente, escrever em PHP está fora de questão. Eu continuo programando em Python. Eu acho Python uma linguagem muito mais clara que o Ruby, fora meu vício com a identação e meu ódio a chaves (antes mesmo de utilizar teclados estranhos) e end qualquer coisa. Talvez uma busca mais demorada no Google pudesse indicar outro framework para aplicativos web em Python. Mas meu problema de usar o Python para esta tarefa é que eu não quero utilizar vários frameworks, criando um monstro ainda maior, eu quero instalar um pacote único. Resolver o problema. Com Python, eu teria que utilizar vários pacotes com nomes de bichos e frutas que eu não sou doido suficiente para usar. Existem alternativas em Python amadurecendo, mas ainda longe do que eu posso obter hoje com o Rails.

Com certeza existe arte na programação, mas eu preciso testar algumas idéias rapidamente. Quando estas idéias são novos sites, fica claro que o belo cede lugar para o rápido, funcional e seguro. Eu poderia fazer alguma coisa em Java, mas eu estou realmente tentando diminuir a complexidade desta tarefa, reduzindo o número de frameworks no meu futuro site.

O César ainda não escreveu sobre Ruby e eu acho que não vou conseguir convencê-lo a escrever nada mesmo. Então vou aproveitar a necessidade e postar aqui um pouco do que vi diferente em Ruby.

Voltando a hipótese de Sapir-Whorf, fico analisando a forma como as pessoas pensam pela linguagem de programação que elas mais se identificam. É fácil, basta lembrar de um programador C++ e de um programador Java. Programadores em Visual Basic, Python, Perl ou PHP também invocam lembranças diferentes a minha mente. Embora todos sejam profissionais, sempre tem algo no comportamento destes que marca nossa lembrança, como uma característica e até mesmo como um novo estereótipo. Alguns programadores gostam de trabalhar com coisas difíceis ou coisas que os outros consideram difíceis.

Esses padrões de comportamento são também visíveis quando você aprende uma nova língua estrangeira. Quem nunca teve vontadade de dizer que o programa está correndo ?

Do Jaca ao Java

Leia no novo Blog

Em Python your Life, eu disse que não gostava de Java. E realmente não gostava.
Conheci Java no Internet World 1996, no Rio de Janeiro :-) Minha última visita a cidade maravilhosa. Solteiro, com algum dinheiro no bolso... ah... Copacabana e os barzinhos do Rio... putz, lembrei que já em 96 eu deixei o relógio em casa, com medo de assaltos. Mas o Rio é lindo.

Bem, a Sun apresentou o Java e principalmente as diferenças entre o Java e o JavaScript. Eu tinha um pequeno provedor em Manaus e usávamos um servidor Sun. Eu sofria para escrever os programas do provedor em C++, lembro que passei 2 semanas para achar os arquivos binários do GCC para microSparc... viva o Google (naquela época o melhor era o AltaVista). O Java era grátis e o compilador da Sun custava uns US$3.000,00 (sem os manuais...), me apaixonei por Applets e por um bom tempo Java era só Applets.

Mas para mim, a linguagem nunca fora nada mais que um C++ disfarçado. Eu não tinha problemas com ponteiros, até achava normal trabalhar com eles e ter seg faults aqui e ali :-)
O problema é que na época eu não via nada além disso. Por que fazer algo em Java se eu já tinha minhas bibliotecas em C e C++? Não era tão claro para mim as vantagens de ser multiplaforma. E Java 1.0 ninguém esquece... No Windows, eu tinha o Delphi e no Linux tinha também o C/C++, era só recompilar. Para mim, o Java ficou sendo uma forma legal de enriquecer home pages com applets ou de deixar meus CGIs mais lentos que em C/C++.

O tempo passou e a linguagem Java se popularizou. EJB, Java 2, Hibernate e Tomcat foram aparecendo. Mas nesta época eu já não estava mais programando e sim gerenciando. Perdi o desenvolvimento do Java.

Só considerei Java seriamente no Desktop depois de ver o Eclipse e sua biblioteca.
Depois começamos a fazer programas para um cliente no exterior, usando Java e o BEA. Comecei a gostar, mas realmente fiquei preocupado quanto a produtividade dos programadores, precisava de muito framework para fazer algo funcionar. Programador Java não ganha pouco, graças a Deus :-) Haja máquina e dinheiro com licenças... um estagiário começou a trabalhar com Tomcat e o tigre comeu o pobre rapaz :-) Não foi um recomeço amigável. Nesta época eu comecei a chamar Java de Jaca. Era grande e ninguém conseguia comer sozinho :-)

Ano passado, eu comecei a desenvolver um aplicativo novo para Web, usando Ajax e múltiplos Threads. Adivinhem que linguagem eu escolhi para desenvolver meu pequeno monstro? Java. Fiquei impressionado com as melhorias do Java 5, principalmente com templates e operações com lista. A biblioteca da linguagem também é excelente, fora o Eclipse com seu preço amigável. Criei o servidor e este passa muito bem. Inclusive, migrei alguns utilitários de baixo nível escritos em Visual C++ e .Net para Java. Semana passada instalei o servidor pela primeira vez no Linux e ficou muito bom, não precisei alterar nada. Troquei o banco de dados de MySQL para Firebird 1.5 e depois para o Firebird 2.0. Não precisei mudar quase nada, graças ao Hibernate.
Ok, o servidor usa uns 47 MB de Ram só para ele... mas um pente de 512 MB custa uns €30,00. Eu custo bem mais caro. Entre comprar o pente e perder meus cabelos debugando código reentrante em C++... prefiro comprar o pente :-)

Já estou usando o Java 6, não precisam ficar preocupados.

Assim fiz as pazes com o Java. Desculpas aos pobres coitados que quiseram vender Java para mim antes, dou o braço a torcer. Vocês tinham razão. Mas que era uma Jaca, era.

Bandeiras de software

Leia no novo blog

Tecnologia precisa de razão ou motivo para se utilizar? Digo, tecnologias são como bandeiras? Ou como time de futebol?

Eu explico. As bandeiras de software são como vejo questões sobre tecnologias sendo defendidas como o time de futebol do coração. Alias, acho que escolhemos um time de futebol por diversas maneiras: o pai torcia, gostava da cor, ganhou o campeonato quando você era criança...

Eu torço pelo Grêmio, campeão mundial em 1983. Não lembro de jogos de futebol antes da final do campeonato no Japão. Mas nunca fui fã de futebol... só lembro disso em copa do mundo.

Eu uso Linux há bastante tempo, de verdade desde 1996. Mas antes já tinha comprado uns disquetes do Mingo, com o tal Unix de um só disco... e oito terminais!

Eu defendo o uso racional de tecnologia. Nem sempre Linux é bom.

O mesmo acontece com orientação a objetos, sistemas operacionais e linguagens de programação. Se houvesse uma só resposta para todo tipo de problema que estas tecnologias podem resolver, não haveriam tantas tecnologias.

Os problemas mudam, as pessoas que tem os problemas também. Cada caso exige uma análise particular que resultará em soluções também particulares.

Penso em linguagens como Delphi. Na empresa que trabalho, reina o C++ e o Java. Mas existem guerreiros do Delphi. Hoje mesmo eu estava resolvendo um problema com JNI, em outro laboratório. Eles perguntaram por que eu havia escolhido fazer o novo servidor em Java?

Pensei um pouco e respondi que conhecia Delphi, mas que o servidor era uma coisinha com múltiplos threads, acesso a banco de dados e inúmeros candidatos a problemas de concorrência. E para este tipo de problema, o Java é excepcional.

Se eu tivesse que desenvolver algo do zero novamente, eu teria que pensar no problema, antes de escolher a solução. Java não é bom para tudo.

No caso do Linux, temos os guerreiros do Ubuntu, e eu estou para entrar nesse exército. Eu realmente gostaria de ter um desktop Linux hoje. Na realidade, meu computador tem dual-boot, mas para acessar a Web e trabalhar, eu ainda uso o Windows. O Linux fica para minha pesquisa e para alimentar meu nerdismo.

Por outro lado, eu quase que não hesitaria em ter outro servidor Linux. Acho que para servidor Web, SVN, email, etc não tem solução melhor que um bom Gentoo. Mas eu já prescrevi Windows para empresas que tinham dinheiro para isso, mas não para contratar um administrador Linux. Não adianta ter Linux se a cultura da empresa é Windows. Mais batalhas...
Pensando em um novo produto de software. Qualquer um. Você escreveria este para Linux ou Windows? Eu escreveria para Windows, pois acho que o dinheiro ainda está com quem usa Windows. Fica aqui meu protesto contra os piratas que abrem a boca pra esbanjar as versões mais recentes do Sistema Operacional, mas que se recusam em pagar por isso. O Linux sempre foi muito claro para mim. A maioria das empresas em que trabalhei caia para trás quando era informada dos custos reais de software. Era quando o Linux tinha uma chance. Onde o Windows custava menos de R$10,00: sem chance. Não pelo Linux ou pela Microsoft, mas pela minha responsabilidade como profissional de informática, isso sim é uma bandeira que eu defendo!

Ainda assim, sou contra defender o Linux como uma bandeira. Eu também não defendo o Python para qualquer tipo de programa. Quanto mais nos especializamos, temos a tendência de encaixar as coisas dentro daquilo que já conhecemos. É nessa hora que a mente deve permanecer aberta.

Como eu sou um cara esquecido, acabo tendo que rever tudo de novo, sempre. Às vezes não ter memória ajuda :-).

Python your life

Leia no novo blog

Eu sou um cara esquecido. Eu realmente não lembro certas coisas, mas outras eu não esqueço.
Uma vez, ainda no final dos anos 90, putz esqueci em que ano foi... um amigo de faculdade comentou sobre uma tal linguagem "píton". Ele disse ser super prática, muito boa, mesmo sendo script.

Na época eu já trabalhava com Linux e qualquer coisa para ajudar era bem vinda. Baixei o tal do Python e fiz o tradicional imprima os primos, usando listas, claro! Depois um aplicativo para procurar arquivos repetidos no HD. Foi o suficiente para me libertar de Perl, até então a melhor coisa do mundo script para mim.

Passei um tempo sem usar a linguagem. Acho que até 2002, quando um grupo de amigos do trabalho iniciou uma discussão sobre jogos de computador. Como todos eram técnicos, o assunto não era o jogo em si, mas a tecnologia por trás de um jogo. Especificamente, o que mais interessava ao grupo era escolher a melhor linguagem para se codificar um jogo. Como esse tipo de coisa é tão exato quanto religião ou política... resolvi sugerir que cada um tentasse fazer um jogo simples, com a linguagem que achasse melhor.

Eu não gostava de Java, depois explico o por quê. Comecei a brincar com Delphi, que estava a mão na época. Sempre programei em C e não precisava de outro teste para saber o que eu já sabia: C é bom, mas tem coisa melhor hoje em dia. Lembrei da tal linguagem da cobra, o Python (segundo o criador da linguagem, Guido van Rossum, pronuncia-se "Paiton" filme legenda).

Usando Python e Pygame, iniciei um pequeno "shoot them up", tipo Space Invaders, afinal era pra ser um jogo simples. E se o Space Invaders original rodava num Atari com 1 MHz... rodaria em qualquer linguagem script séria.

Comecei desconfiado, testando a performance do pequeno monstro que estava criando. Fiquei surpreso ao constatar que a performance era mais que suficiente para o que eu queria.

A linguagem é realmente interessante: fácil de aprender, multiplataforma, com acesso a todo tipo de bibliotecas de sistema, banco de dados e até jogos! Continuei fazendo o pequeno jogo. Gráficos, sons, suporte a joystick, alteração dinâmica de resolução e suporte a várias línguas. Um jogo realmente simples. Você pode ver o que eu criei em http://invasores.sourceforge.net/.

Quanto aos outros colegas, um iniciou um jogo em Java, acho que até foi em J2ME... mas não chegou a ter cores. Outras tentativas não deixaram rastros. Agora eu tinha provas que Python era boa, não pela superioridade pura e simples de sua simplicidade, mas porque com ela eu podia fazer mais em menos tempo. Produtividade enfim.

Antes eu havia usado o Python para converter banco de dados e realizar operações com arquivos. Desde a experiência com o jogo, eu uso Python para todo pequeno utilitário que eu preciso. E não me surpreendo quando acho outros programas muito bons escritos na linguagem. Esses tempos mesmo, escrevi utilitários para fazer a carga de arquivos CSV para um banco MySql e gerar tabelas em Latex.

Além do poder da linguagem, sua clareza é realmente impressionante. Os tais blocos por identação atenderam a um desejo que eu tinha há muito tempo. Misturar tabs e espaços é complicado, eu sei, mas quando se consegue fazer certo... consegue-se um programa limpo e fácil de ler. Se você consegue ler, consegue aprender.

Eu ensinei lógica de programação para alunos do ensino médio e para algumas pessoas na faculdade. Era terrível ler um programa "desdentado". Mais difícil ainda convencer as criaturas da importância de um código limpo. Esse problema não existe com Python. Será executado como lá está escrito, ou melhor, como se vê. Eu realmente gosto da linguagem.

Além disso tudo, a linguagem vem com todos os acessórios, incluindo-se uma ativa comunidade lusófona em PythonBrasil. Só não aprende quem não quer.

Eu continuo programando em C++ e Java, mas a outra é Python.

Cada um sabe onde seu calo aperta. Python não é bala de prata. Mas como não existe lobisomem... Python your life!