CMilfont

Desde semana passada eu perguntei a alguns amigos qual é a diferença entre:

e

Poucos souberam responder, o que é um problema, já que tem muita gente programando em javascript e não conhece os fundamentos básicos da linguagem.

Essa semana eu deixo um novo desafio, verifiquem abaixo esse código e me digam se há algo de errado ou não, tente justificar nos comentários

Nessa briga dos BIGPLAYERS pelo mercado de RIA um dos aspectos que mais se destacam não é a tentativa de reativar velhas idéias ou tecnologias, porque na informática os conceitos vem e vão, mas sim em algo que passa despercebido em todas as análises que leio: "Todos usam a ECMAScript". O foco sempre é direcionado à questão de que são linguagens de marcação, mas esquecem que mesmo sendo uma linguagem de marcação, todas utilizam como DSL para extender sua plataforma uma ENGINE baseada no ECMAScript.

Desde o Adobe Flex, passando pelo Laszlo, Microsoft Silverlight até à nova arma da SUN, o JavaFX, todos usam um dialeto da ECMAScript.

O poder do javascript já é reconhecido de longa data, desde STANDALONES ENGINES como Rhino (Mozilla) ou Embedded JavaScript (usado no servidor Samba 4) até o kernel do Acrobat Reader, todos os benefícios de uma linguagem dinâmica são explorados com um SUBSET da ECMAScript. A Adobe praticamente tem um porte no núcleo de todos os seus produtos para suportarem a extensão com javascript, desde o citado Acrobat, passando pelo Flash ao novíssimo Flex usando como base o ActionScript.

Sources Javascript

A SUN utilizou a linguagem F3 (Javascript + XML) no JavaFX, a Adobe vai de ActionScript, a Microsoft com seu XAML implementa usando o JScript.NET e o Laszlo usa a linguagem LZX que tem seu próprio motor, vejamos códigos entre os 4 produtos principais que se destacam nessa luta:

Silverlight:

Laszlo:

…

… 

Flex:

JavaFX:

Como podem ver, apesar da diferença visual entre os códigos, eles conservam a essência da ECMAScript e possivelmente haverá uma tendência natural para que surjam idéias de integração entre as ferramentas.

Velhos problemas

Mudando um pouco de assunto nesse tema, essa nova tendência resgata velhos e incômodos problemas, que cada tecnologia é mundo fechado e a interoperabilidade é novamente descartada, a idéia de RIA não é nova, tivemos tecnologias interessantes como o XUL e até especificação com o XForms (que tentava ordenar uma forma de interface dinâmica na própria linha do XHTML) e não vingaram.

Hoje nós temos especificações organizadas pelo W3C que tentam orquestrar um ponto em comum entre as diversas plataformas no ambiente WEB. Sofremos por falta de uma estrutura dinâmica que torne a acessibilidade WEB semelhante ao ambiente DESKTOP. O RIA segue um segmento de que cada fornecedor tem suas próprias especificações, mesmo usando tecnologias semelhantes, cada uma tem seu modelo final.

A indústria sempre vai brigar pelo MARKET SHARE e um dos pontos que influencia suas receitas é a inovação que invariavelmente passa pelas tecnologias emergentes e os HYPES. Quantos produtos voces conhecem que não executam nada superior aos seus concorrentes mas que tem um plano de Marketing mais elaborado e uma visibilidade melhor?

Na minha opinião, a fragilidade desse tipo de tecnologia está justamente no ponto da interoperabilidade. Vamos e voltamos nesse mesmo ponto até que se chegue em especificações que agradem a todos.

Como eu mencionei o fato de que são linguagens de marcação e cada fornecedor tem seu próprio conjunto de tags, a interoperabilidade pode ser alcançada pelo dialeto comum que eles utilizam, no caso a ECMAScript. O caminho para essas tecnologias não morrerem, vai ser um jeito de fazer com que essas ferramentas conversem entre si, e na minha opinião a única forma seria pelo javascript.

Um dos assuntos corriqueiros que volta e meia surgem em fóruns ou listas de discussões é o surgimento de uma linguagem "x" ou súbito interesse sobre ela por parte da mídia especializada.

Tomem como exemplo o Ruby, desde meados da década de 1990 que a linguagem existe, mas somente com o surgimento do "Ruby on Rails" que a linguagem alçou ao posto de "destaque do ano", isso como algo por volta de 10 anos depois de sua criação. Subitamente os velhos Rubistas se viram lado a lado com centenas de joviais newbies insuflando a gordura normal que toda tecnologia candidata a Hype provoca.

Mas a atenção atraiu hackers que antes estavam apenas com Python, Perl, Lisp ou outra linguagem não "Enterprisey". Assim como também atraiu boa gente de Java e C#.

Brigas desnecessárias já foram travadas entre Java vs Perl, Java vs Python, Java vs C#, Java vs Lisp, etc. (Me refiro especificamente sobre Java porque acompanho mais de perto o Java, mas aconteceram e acontecem brigas entre as outras também). Ultimamente acompanhamos discussões entre Java vs Ruby.

A bala de prata

Sempre que uma tecnologia tem maior "Market Share", ela será alvo das críticas principais, assim foi com o Delphi e VB quando o Java pretendia ser a líder de mercado, lembro que todas as críticas eram destinados a essas duas plataformas, o pessoal de Perl e Java eram até aliados na guerra contra VB nessas horas.

Mas linguagens são criadas e pensadas para resolverem problemas especificos ou voltadas a trabalhar em um contexto especifico, seja ele necessitário ou mercadológico.

Dificilmente voce conseguirá desenvolver toda e qualquer aplicação em apenas uma linguagem ou plataforma, mas isso não quer dizer que uma aplicação fica melhor com Java ou com C#, porque ambas praticamente são do mesmo contexto, não é essa diferença que enfatizo, e sim se o contexto favorece a determinada linguagem.

Eu fui infelizmente um defensor dos monoglotas, até o início de 2005 eu praticava apenas Java e via com maus olhos toda e qualquer linguagem pelo simples preconceito, na verdade era mais  uma discriminação por autodefesa. E olhe que conheci Clipper, C e Pascal na faculdade, trabalhei com Delphi um tempo e tinha um bom conhecimento com Javascript(pelo menos eu achava). Não sou psicólogo mas imagino que eu me apavorava com a possibilidade de ter que reaprender toda a sintaxe de uma nova linguagem, novos frameworks, novas APIs e tudo mais. Olhe que estávamos ainda no auge do Struts-like.

Admirável mundo novo

Com o surgimento do Ajax e consequentemente a popularização do Javascript como linguagem OO, me especializei a fundo na ECMA-262 como tinha feito com o Java mas nunca com outra linguagem. 

Esse novo mundo que conheci me trouxe mais dúvidas do que certezas. Assim como voce só aprende inglês se submergir na cultura de Shakespeare, voce só aprende uma linguagem de programação se penetrar no contexto ao qual ela foi pensada para sua concepção.

Como entender Closures quem vinha de Java?

A tendência natural era achar que era a mesma coisa de "Inner Classes". Quando voce realmente entra no contexto, as nuances antes não percebidas quase magicamente saltam aos olhos.

Como falei em um post anterior, se voce que faz um curso regular em uma Faculdade de Ciência da Computação e aprende a construir uma linguagem, aprender várias linguagens é algo singelo.

Como soluciona isso?

No estudo do Javascript como linguagem orientada a objetos (e não mais uma auxiliar para formatação de data e validação de inputs HTML), me deparei com contexto inéditos para mim, e problemas antes sequer diagnosticados.

Isso me provocou a natural curiosidade nerd de conhecer outras linguagens, pelo menos teoricamente.

Conceitos como Closure, Currying, Continuation, Design By Contract, Actor model, Lazy evaluation, Tail recursion, Quine e tantos outros (só para citar algumas features de algumas  boas linguagens) voce não conhecerá na faculdade, e imagino que nem na pós e nos mestrados da vida. Devo admitir que nem haveria espaço para tanto, a faculdade (como sempre enfatizei) é apenas um local para socialização, algo como: "entre um networking e um fórum".

Solucionar um problema não é conhecer sua resposta e sim as perguntas necessárias, conhecer antes de tudo a pergunta certa. Eu posso criar uma aplicação qualquer em java, isso vai me custar uma quantidade "y" de recursos, com a plataforma/linguagem "z" eu construiria em "y/2" dos recursos.

Quantas linguagens voce está disposto a aprender?

Conhecer outras linguagens é conhecer outras culturas, é abrir mais uma janela para o conhecimento.

"Infomação não é conhecimento, conhecimento não é sabedoria…" [Frank Zappa]

Concordo com o Zappa, a sabedoria está mais ligada à capacidade de responder a um determinado questionamento do que simplesmente a ter mais informações. Mas uma informação é crucial para determinar o rumo de uma investigação, quando voce está planejando a resolução de determinado problema, quanto mais subsídios puderem embasar sua avaliação, melhor.

Em outras palavras, se voce conhece mais culturas, voce tem a chance de encontrar não somente uma resposta ao problema, mas sim a melhor resposta. Vou mais além, poderá até diagnosticar o problema, antes de sequer ser sabido.

Selecionei as linguagens que pretendo aprender por contexto, como prototype-based (IO, Self, Lua e Javascript) , Funcionais (Erlang, Scheme, Haskell) e assim por diante, não me preocupo com sintaxe ou decorar APIs, mas como e porque elas foram desenvolvidas. Pode ser que eu nunca as use em algo, quem sabe, mas no mímino me abrirá a mente para enfrentar os problemas do cotidiano com mais tranquilidade.

Hoje li esse post do Daniel Q. Oliveira no meu reader sobre essa discussão no GUJ. Interessante porque me faz refletir esse momento que estou vivendo, acompanhem porque pode se traduzir em novos posts de gente que tem sempre muito a compartilhar, só feras na discussão.