Resolvi falar sobre CoffeeScript porque algumas pessoas com poder de influência em diversas comunidades estão evangelizando essa aberração.
História
Vou começar pelo começo, aproximadamente entre os anos de 99 e 2009 a comunidade Javascript passou se degladiando sobre o futuro da linguagem, uma parte defendia algo próximo ao ActionScript [exemplo fácil só para um termo de comparação], com classes e outras características que não existem na linguagem que é prototype-based. Venceu a turma conservadora, que defendia js se manter como estava.
Para terem uma idéia da confusão, hoje existe a especificação ECMA 262 versão 3 e versão 5, justamente porque a 4 ficou no meio dessa briga e nunca chegou a existir.
Desculpas
De 2006 pra cá algumas linguagens antigas como ruby e python influenciaram todas as comunidades de desenvolvedores com argumentos – dos quais concordo em parte – como expressividade, facilidade na leitura por humanos com menos ruído sintático em vez de apenas performance ou outra característica técnica que poderia muito bem ser trabalhada em um nível inferior (Como por exemplo, para cada linha que voce evita de escrever em Python, existem centenas em C que fazem o trabalho).
Primeiro argumento do uso de Coffeescript é justamente sobre ruído sintático do Javascript, mas inventaram uma SINTAXE NOVA que não é igual a Ruby e nem Python, mas há métodos e características de ambas para justificar seu uso. Ora bolas, porque não terem implementado um subset direto do Ruby?
Incluíram o Pattern Klass como funcionalidade dessa linguagem sendo que Frameworks antigos como Prototype já implementavam isso.
Em Javascript você consegue Closure, Currying e outras construções funcionais porque function é um cidadão de primeira classe na linguagem, consegue ter Mixin até mais fácil do que em Ruby porque além de dinâmico é de tipos fracos.
A justificativa de se usar Coffeescript por causa de sintaxe é a mesma de muitos que usam Groovy porque a “curva” de Java seria menor. Falácia grave. O problema de um desenvolvedor não aprender uma sintaxe porque é assim ou assado já demonstra em muito que ele não quer aprender as características da linguagem e vai continuar “programando em Java” usando Groovy.
Isso é muito comum, já passei por muito programador PHP programando em Ruby como PHP ou programador Java programando em javascript como Java.
Alguns entusiastas de Ruby defendem o uso porque lembraria a sintaxe que se sentem familiar e por ironia citam List Comprehensions, funcionalidade que existe no Python e não no Ruby. Como voce contorna isso no Ruby? Vamos parar com a covardia e sair da zona de conforto?
Problemas
Eu tenho um problema com linguagens intermediárias com Enhanced, mas vá lá, podemos viver com isso.
javascript tem muitos problemas, mas não é apenas sintaxe, precisamos normalizar todas as versões e especificações e atacar as fraquezas conhecidas, não sair criando pseudo-linguagem.
List Comprehensions que já citamos, tem na versão 1.7 que o SpiderMonkey implementa (usado pelo Firefox) , mas o V8 (usado no Chrome, Safari e no node.js) não implementa, Rhino implementa e assim vai, uma confusão só. Os navegadores basicamente implementam a versão 1.5 que é equivalente a ECMA 262 – versão 3 que chamamos de ES3 (ECMA Standard 3), o V8 implementa a ES5 e mantém compatibilidade com 1.5. SpiderMonkey implementa a 1.5, mas não tem compatibilidade entre ES5 e 1.5, se quiser usar funcionalidades definidas na ES5 tem que usar versão 1.8. Confuso? É assim mesmo.
Se Javascript não se encaixa no seu projeto, não a use, é porque não serve mesmo, agora tentar mudar as características (como assincronismo, só para aproveitar o momento e bater em ferramentas como Step) para se encaixar é querer usar a furadeira para pregar um prego.
Se você é obrigado, já que não existe outra alternativa na camada de apresentação em Webapps (RIP ActionScript 🙁 ), use os frameworks modernos que já implementam o Crossbrowser aceitável (nunca vai ser decente) e se beneficiam de sua idiossincrasia. Coffeescript só está em evidência por causa do node.js, já que há várias bibliotecas e até Frameworks implementados com isso, se a discussão aqui for navegador, nem invente.
Eu por exemplo sinto mais falta de incluírem o “method_missing” na especificação do que interpolação de strings.
Ainda pra completar há uma rivalidade entre os defensores de Frameworks como entre o jQuery e Mootools que não sei de onde surgiu, mas nós humanos somos assim mesmo, brigamos por religião e por Framework.
Javascript é de tipos fracos, dinâmicos, sem classes, orientada a protótipos e assíncrono… aprenda a linguagem. Já basta de uma linguagem a mais para cada chilique de desenvolvedor por causa de um “{” ou “;”. Como alguém, que não lembro quem foi, escreveu no twitter dias desses: “Antigamente todo mundo queria seu próprio Framework, hoje todo mundo quer sua própria linguagem”.
Aproveite e vá me assistir no QCONSP 2011 que vou demonstrar algumas coisas bacanas de se fazer com Javascript e como a sintaxe não atrapalha 🙂
Typically chemist’s shop can sale to you with discreet treatments for various heartiness problems. There are numerous of safe online pharmacies that will deliver medications to your address. There are divers medicines for each afflictions. Learn more about “viagra manufacturer coupon“. Maybe “viagra discount coupons” is a so complicated matter. Matters, like “coupons for viagra“, are coupled numerous types of health problems. If you need to take recipe medications, ask your dispenser to check your testosterone levels before. Sometimes the treatment options may switch on erectile dysfunction remedies or a suction device that helps get an erection. Keep in mind web-site which is ready to sell erectile disfunction drugs like Viagra without a prescription is fraudulent. When you purchase from an unknown web-site, you run the risk of getting counterfeit remedies.
Genial, a tempos queria falar sobre a adoção de CoffeeScript e não tinha saco de escrever um texto. Você resumiu completamente meu pensamento sobre esse assunto.
Muito bom o artigo Milfont. Sou da mesma opinião, não com o mesmo embasamento, mas agora lendo o seu texto, compreendo que sempre estive certo em meu pensamento em relação ao CoffeeScript.
Tooooooooma distraído!
Estou pesquisando coffeeScript nos últimos dias. O que me atraiu foi o que sempre me incomodou um usar javascript especialmente jQuery.
E para mim remover a duplicidade function(…) { } é uma otimização e um refactoring bem útil. Não vejo nenhum grande problema nisso.
Caraca, parece que você está meio bravo …
Antes de falar sobre o CoffeeScript, queria mencionar o “Como voce contorna isso no Ruby? Vamos parar com a covardia e sair da zona de conforto?” Não entendi qual seria o problema de usar iteradores e blocos em algo como (levando em conta o exemplo da Wikipedia linkado)
(0..100).select{|e| e**2>3}.map {|e| e*2}
ou mesmo
(0..100).inject([]){|m,v| v**2>3 ? m << v*2 : m}
Particularmente é um idioma que me agrada mais. Mas eu sou suspeito de falar, lógico. 😉
Sobre o CoffeeScript: eu gosto de JavaScript faz trocentos anos, antes mesmo do Ajax e de todo mundo achar ele "cool", quando a turma achava um treco meio … fedido, sei lá. Dito isso, usa o CoffeeScript quem quiser, não vejo problema, desde que eu possa continuar utilizando o JavaScript numa boa. 🙂
Abraço.
Primeiro, desculpas pelo comentário curto. Estava meio apressado e pode ter parecido agressivo.
Deixa eu me explicar melhor…
quis dizer que gosto da sintaxe do coffeescript não por ignorância na sintaxe do javascript, é sim o inverso. Justamente porque conheço a sintaxe do javascript é que as vezes prefiro usar o “sintatic sugar” que o coffeescript provê.
Também não acho que ele deva substituir o javascript, até porque pra mim o compilador coffeeScript não faz muito comparado com um “compilador médio”, e acho que coffeeScript está mais para substituição de macros e maneiras de usar atalhos curtos, por isso nem acho que coffeeScript deva merecer o título de uma linguagem nova, pra mim é só javascript com macros. Certo?
Eu entendo a sua preocupação quando fala que a cada chilique que um desenvolvedor dá é criada uma nova linguagem, eu concordo com o fato, mas acho que no final sempre vai existir uma convergência.
E mais, acredito que esse processo não linear de criação, misturas e destruição de linguagens é mais eficiente que evoluir linearmente uma linguagem única.
É como se fosse uma maneira de resolver o problema em paralelo, com diferentes tentativas de soluções rodando em paralelo até que muitas são provadas erradas no caminho até que as que sobram dão uma visão mais clara de uma solução melhor.
Por mais que esse ruído de milhares de linguagens sendo criadas nas esquinas seja caótico e irritante, no fundo acredito que ele é benéfico para programadores em geral.
[]s!
#TaQ
Justamente isso, qual o problema de usar funções de alta ordem como map e reduce?
Claro que List Comprehensions vai mais além e a vantagem de sua utilização é justamente quando voce deseja extrair um subconjunto de n conjuntos com apenas um filtro, coisa que com funções de alta ordem voce vai ter que empilhar função sobre função.
Exemplo abaixo que montei com o Firebug aqui:
https://gist.github.com/1106606
Agora faz o mesmo com Map/Filter pra ver a complicação 🙂
#Daniel Teixeira
O problema é voce querer escrever javascript como se fosse Ruby, é a mesma coisa quando voce quer escrever ruby como se fosse Java, acredite em mim, isso é um problema seríssimo que passo em vários projetos.
Javascript pode não ser a coisa mais legível do mundo [LISP é pior :)], pode ter um ruído muito maior do que ruby e python, mas voce consegue um código bem expressivo usando as qualidades e até os defeitos da linguagem.
Mas peraí, me perdoe se te entendi errado, mas nesse caso então o que você acha ruim é o jeito de fazer as coisas com os iteradores e blocos, correto?
Do jeito que você falou de “covardia” e “zona de conforto” estava achando que era outra coisa mais braba. 🙂
#TaQ
Eu me expressei errado então.
Acho que nós estamos concordando 🙂
O que eu falo é o seguinte, rubystas dando desculpa para usar List Comprehensions quando isso não existe em ruby, mas em Python. Falei de sair da zona de conforto é justamente sobre isso, ñ dar desculpas para aprender como fazer em outra linguagem e usar um argumento que não tem nem na linguagem que voce está acostumado.
No próprio ruby contornamos a falta de LC com funções de alta ordem como Map, Filter, etc. Em Js seria a mesma coisa, só que com sintaxe um pouco diferente [nem tanto assim].
Para completar eu mostrei como fazer LC com js [que pena que só o SpiderMonkey implementa] e que a verdadeira vantagem é quando voce tem que extrair de n conjuntos, porque se for apenas um conjunto o map/reduce resolve fácil.
Excelente post, compartilho da mesma idéia, mas confesso q ficou ainda mais interessante com os comentarios do Daniel e do Taq. Mesmo não sendo a favor do coffeScript, acho q são esses debates q elevam a nossa comunidade 🙂
Bicho, desencana com esse lance de “desculpa para alguma coisa”, por que muitas vezes é “desculpa de peidorreiro”, conhece essa? 😉 È o que você falou, tem muitas vezes que não tem muita consistência … e enche o saco. 🙂
Mas também se você usar algumas palavras como “covarde” blá blá blá a sua própria consistência na argumentação fica meio perdida, como nesse caso que eu não entendi direito o que você quis dizer. Desencana um pouco da coisa, como disse acima, nesse lance do CoffeeScript o importante é que dá para continuar usando JS de boa. Quem gostar de um ou do outro tem a liberdade de fazer do jeito que bem entender. A longo prazo se tanto “meta” por aí ajuda ou atrapalha sabe Deus, mas eu sou um cara meio tosco, prefiro algumas coisas do jeito tradicional. 😉
Bem, eu discordo da ideia de que ter uma meta linguagem ou uma forma diferente de usar uma linguagem seja algo ruim. Estas iniciativas como o coffee script (ou o moonscript) são excelentes naquilo que se propõem. Elas, além de poder criar uma forma melhor de se trabalhar com uma linguagem, e usufruir de seus frameworks e bibliotecas, ela também cria um laboratório vivo. Te permite testar funcionalidades sem alterar a linguagem mãe, o que poderia acarretar grandes problemas para software legado.
Mesmo não gostando do resultado como um todo (não vejo beleza no coffee script), a ideia é ótima. Não há porque “desgostar” da iniciativa já que programa em coffeescript quem quer.
Boa postagem = ] Ficou bem legal a revisão histórica do JS.
Pingback: Nodejs vs Rails, ou a ironia de quando apertam no meu calo. - Blog de desenvolvimento da Milfont Consulting, Client e Server-side