Arquivo → November, 2008
“Windows 2008 Server está fabuloso! Está igualzinho o Linux!” (ou por que software livre importa)
Recentemente ouvi a pérola que dá o título deste post de um colega que, após sair de uma demonstração de produtos Microsoft, ficou fascinado com a modularidade do novo sistema operacional, cuja interface gráfica agora pode ou não ser instalada. Por trás desta ingenuidade, no entanto, esconde-se uma realidade assustadora.
(é um bom exemplo de pateticidade, ou seja, a aparência comica que disfarça uma realidade infeliz)
Minha resposta foi óbvia: “hmm… entendi. Então você vai abandonar toda a liberdade que o software livre te dá em troca de algo que imita o que você já possui e ainda pagar para obter esta perda! Você é um ‘gênio’! ” A pessoa ficou meio atordoada com a resposta (provavelmente me considerou um xiita ou simplesmente um esnobe), o que é normal quando vemos o objeto de nossa ilusão desfazer-se diante de nossos olhos.
Mais uma vez, o problema do determinismo linguistico se aplica. Como a maior parte de nós em nossa formação basicamente só vimos produtos Microsoft, tudo aquilo que é diferente desta nos parece ameaçador. Como de uns anos pra cá a baixa qualidade dos produtos desta se mostrou evidente (o crescimento do Linux e da Apple expõe isto de forma gritante), muitos se sentem aliviados ao ver que os produtos da Microsoft estão “iguaizinhos os softwares livres”.
O ponto óbvio é: tudo isto que hoje é visto como “fabuloso”, “inovador” e “criativo” já existe há décadas FORA da plataforma Microsoft. Não se trata de uma novidade em si, mas sim de uma novidade nos produtos Microsoft. Como a maior parte dos profissionais da área só conhecem produtos desta empresa, acaba-se por criar a ilusão de que, de fato, são novidades absolutas.
(mais uma vez o mito da caverna se apresenta)
Observe que normalmente só vemos dois polos: Microsoft e Linux. Muitos vão para o Linux simplesmente por causa do custo. Linux é visto como algo cuja única vantagem consiste no preço. O fato de possuir uma qualidade superior nem é levado em consideração nestes casos. O importante é apenas reduzir o custo. E com isto se esquece o que de fato vêm a ser o software livre.
Só pra lembrar, um software é considerado livre se fornece quatro liberdades ao usuário:
- Liberdade de usar o software como, onde e quando quiser
- Liberdade de acesso ao código fonte do software, assim como de alterá-lo.
- Liberdade de distribuir o software
- Liberdade de distribuir a sua versão modificada do software
Uma vez compreendidas estas liberdades (o que farei aqui), fica nítido que voltar a usar software proprietário é no mínimo retrocesso.
Liberdade de uso do software: este é a liberdade mais óbvia. O usuário deve poder usar o software onde e como e quando quiser. Parece estranho pensar nisto em um primeiro momento. Afinal de contas, quando compro por exemplo uma licença do Office, eu o uso como, quando e onde quiser, certo? Errado. Leia sua licença.
LIberdade de acesso ao código fonte, assim como de alterá-lo. A primeira vista, esta liberdade pode até parecer descartável. Afinal de contas, somente programadores irão compreender o que significa aquele “monte de texto maluco”, correto? Errado. Possuir acesso ao código fonte implica em saber o que de fato o software faz, como funciona e se está de fato trabalhando corretamente. Você pode até mesmo não entender nada de programação. Mas o fato de existirem pessoas que saibam, e que auditam este código continuamente fornece uma segurança muito maior ao usuário.
E por que alterá-lo? Simples: se o software faz quase o que você precisa, ele não faz o que você precisa. Neste caso, o que você faz? Espera indefinidamente por uma versão que faça o que você precisa?
Liberdade de distribuir o software: os usuários de software proprietário podem até não perceber, mas encontram-se divididos. Divididos porque não podem compartilhar as ferramentas que utilizam. Se um usuário pode redistribuir o software que recebeu, ele e aqueles que o receberem na realidade se unem. Todos irão falar o mesmo idioma.
Liberdade de distribuir versões modificadas do software: se sua modificação solucionou seu problema ou resolveu um defeito do software em questão, nada mais natural do que passá-la pra frente. É neste ponto que o software livre apresenta sua qualidade superior.
Um software proprietário ao qual você possua acesso ao código fonte não lhe permite alterar seu código. E mesmo que permita, não lhe permite distribuir suas modificações. Afinal de contas, é proprietário. Se você soluciona um bug neste tipo de software, o máximo que poderá fazer consiste em enviar sua sugestão de reparo a seu fabricante e este, talvez, a incorpore em uma nova versão. No caso do software livre, o reparo é imediato. Encontrou um bug? Envie-o para a comunidade. Esta não aceitou sua solução? Sem problema: publique a sua versão modificada em seu site.
Outra vantagem: se você possui a liberdade de distribuir versões modificadas do software, você é um fornecedor também. Consequentemente, a partir desta liberdade, torna-se impossível que o software em questão possua um único fornecedor. É o fim do vendor lock in!
Após entender o porquê das quatro liberdades, fica nítido que voltar ao modelo proprietário é retrocesso (retrocesso é minha maneira educada de dizer burrice). Infelizmente, a maior parte dos “profissionais” de nossa área que usam software livre sequer leram alguma vez a GPL ou qualquer licença. Software livre para estas pessoas equivale a software gratuito. E gratuito é diferente de livre. E por ignorância, veremos diversos casos de retrocesso rolando por ai.
Não se trata aqui de benevolência ou trabalho comunitário. Longe disto! Trata-se de um modelo justo visando o benefício do usuário (que é quem realmente interessa no final das contas) e, ao mesmo tempo, evita que o desenvolvimento da tecnologia seja definido por um número pequeno de fornecedores. Há um interesse economico FORTE por trás do software livre. Convenhamos: o modelo proprietário já expos que não aceita a proliferação de concorrentes (atualmente os fabricantes de software de peso consistem apenas em Microsoft, Apple, Adobe, Sun, Symantec e Oracle. Antes do predomínio da Microsoft, no entanto, haviam BEM mais).
Aliás, a justificativa que ouvi da mesma pessoa foi: “mas a integração do Windows com os produtos Microsoft já vale a pena”. É… vale “muito” a pena cair DE NOVO no mesmo golpe do fornecedor único “geninho”…
PS: outro bom argumento que escuto: “produtos proprietários são mais fáceis de usar”. Cara, não são. Na realidade, são tão fáceis de usar quanto os livres. A diferença é que como você só OS conhece, eles na realidade estão ocultando sua incompetência lhe fornecendo a ilusão de poder.
Java 7 vai ter a cara do Groovy?
Confesso: sou louco por Groovy! Sendo assim, fico muito feliz ao ver que dentre as novas features previstas para o Java 7, encontram-se itens que me fizeram adorar Groovy. Ao imaginar como será o código gerado na nova versão do Java caso estas features passem, percebe-se nítidamente que será incrivelmente parecido com Groovy. Basta listar alguns novos recursos:
Closures: previsto para o Java 7 (muito provável de não ser mais incluído na especificação). Tal como podemos hoje fazer em Groovy
def minhaClosureDuplica = {x -> x * 2}
, se a JSR passar, poderemos ter o mesmo em Java. E acredite, elas realmente quebram um tronco!
Operadores com BigDecimal: eis algo que acho incrívelmente chato em Java. Em Groovy, operamos com valores do tipo BigDecimal assim como fazemos com tipos primitivos numéricos. Agora, ao que tudo indica, o mesmo poderá ser feito com Java.
Switch com strings: eis algo que há muito tempo sinto falta em Java. Em groovy, qualquer tipo de objeto pode ser usado como comparação dentro de um switch. Em Java, por enquanto, apenas tipos inteiros ou enums. Ao que tudo indica, isto irá mudar também. Nada mais lógico, visto que no final das contas, o switch nada mais é do que um if encadeado.
Propriedades: há bastante discussão a respeito de incluir ou não propriedades a la Groovy no Java 7. Pessoalmente, achava esta inclusão uma grande bobagem até começar a programar em Groovy, aonde só crio métodos gets e sets se quiser incluir alguma lógica de negócio dentro dos mesmos. Acredite: realmente poupa MUITO tempo e linhas de código (um dos recursos que mais uso no Netbeans consiste no encapsulador de atributos).
Interpolação de strings: assim como em Groovy, vemos este recurso também em Ruby, PHP e diversas outras linguagens. Demorou para aparecer em Java também!
A inclusão de novos recursos na linguagem é interessante, no entanto, surge a dúvida: será realmente uma boa idéia este jogo de “eu também” que vemos ocorrer no Java? Não estaríamos correndo o risco de poluir a linguagem, tornando ainda mais difícil escrever novos compiladores para a mesma?
Meu lado egoista vê com bons olhos estas novas inclusões (tornam Java mais perto de algo no qual adoro trabalhar). Já meu lado pragmático teme que no futuro Java vire um balaio de gato.
Uma linguagem de programação pode te tornar estupido?
Ludwig Wittgenstein
Ambientes de desenvolvimento rápido suprimem os sintomas de impotência ao criar a ilusão de poder.
Corolário Weissmann sobre desenvolvimento
Aquela infindável discussão “minha linguagem de programação é melhor que a sua”, que nada mais é do que um reflexo de nossa infância “meu brinquedo é melhor que o seu”, devo confessar, sempre chamou minha atenção. Fico horas e horas me divertindo com estes tópicos. É quando me pergunto: uma linguagem de programação pode emburrecer um indivíduo? Cheguei a conclusão de que sim. E muito.
Quando fiz o curso de Filosofia, fiquei muito impressionado com o conceito de determinismo linguistico, ou seja, o fato de que a linguagem que usamos modela nosso pensamento. Alguns filósofos vão além. Wittgenstein, por exemplo, chega a afirmar (e eu concordo plenamente) que os limites do mundo (pode ser entendida aqui a percepção do mesmo) de um indivíduo correspondem aos limites de sua linguagem. Realmente, trata-se de um ponto válido visto que o mundo só recebe o nosso feedback a partir da nossa linguagem e vice-versa. Transmitimos ao mundo aquilo que captamos a seu respeito e em seguida processamos a partir de nossa linguagem.
E de onde vêm a nossa linguagem? Bem, esta é fruto do ambiente no qual estamos (ou seria algo intrínseco?). O ambiente influencia nossa linguagem. Há alguns exemplos hoje considerados banais, como o esquimó que consegue perceber n variações distintas do branco, que são refletidas em sua própria linguagem (há um nome para cada variação). Outro bom exemplo é o brasileiro: nós conhecemos diversos tipos de banana. Curiosamente, para um estrangeiro, todas as bananas são iguais. E nosso vocabulário expõe esta riqueza: banana nanica, caturra, etc.
Edsger W. Dijkstra
O que me faz pensar na seguinte citação de Dijkstra: ”the college pretending that learning BASIC suffices or at least helps, whereas the teaching of BASIC should be rated as a criminal offence: it mutilates the mind beyond recovery.“. No caso, esta frase foi dita na palestra “The threats to Computer Science”, que tratava do modo como a ciência da computação é ensinada nas faculdades. Aliás, atualmente há inclusive gente que usa um argumento bastante similar no que diz respeito ao Java.
A pergunta que se faz portanto é: pode uma linguagem de programação “mutilar” a mente de um desenvolvedor? Na minha opinião, sim. Em minha experiência, já vi diversos casos de desenvolvedores que criam coisas incrívelmente interessantes em Visual Basic mas não conseguem de modo algum sair desta linguagem. Até tentam aprender outras, mas sempre acabam voltando ao Visual Basic, o que justifica-se pelo fato de que trabalhar com algo com o qual já se está confortável é mais seguro.
Algo muito similar observo com Java. Visto a sua aplicação com sucesso em diversos ambientes distintos (móvel, desktop, web, etc.), muitas vezes o desenvolvedor fixa-se no Java e dele não sairá jamais. Assim como no caso do Visual Basic, trata-se novamente da mesma justificativa: “se já sei Java tão bem, por que me arriscar com outras linguagens ou ambientes?”. No caso do Visual Basic, a deficiência fica mais nítida pelo fato de ser uma linguagem ultrapassada. Neste sentido, quem programa em VB possui uma vantagem em relação a quem programa em Java. Há menos arrogância (“por que aprender outra coisa se Java já é uma linguagem de ‘ponta’?”), e portanto a necessidade de se aprender algo novo se torna mais nítido. Mas em ambos os casos, ambas as linhas de raciocínio levam em consideração apenas o medo de se tornar obsoletos tecnologicamente (mais especificamente, para o mercado), ignorando um problema que é ordens de magnitude mais sério: o determinismo linguistico.
O que nos leva a pensar no papel do desenvolvedor: espelhar/reproduzir/criar no ambiente computacional uma solução necessária no ambiente real. Ora, dado que, como já mencionei anteriormente, nosso mundo (percepção) é resultado de nossa linguagem, e as linguagens de programação são a nossa percepção do ambiente digital em que atuamos, o fato de conhecermos apenas uma linguagem de programação contribui para que nosso raciocínio criativo torne-se também limitado. Pior ainda se a única linguagem que conhecermos nos apresentar uma descrição limitada deste ambiente.
Focar-se em uma única linguagem consiste em ignorar o porquê de sua criação: resolver problemas presentes na época de sua introdução. São linguagens de uso geral? Sim, com certeza. Neste caso, não deveriam nos dar uma visão ampla? Com certeza, porém foi criada visando também superar algumas das limitações presentes em sua época de desenvolvimento. Se não fosse assim, existiria hoje provávelmente uma (no máximo duas) linguagem de programação. Logo, o argumento de que “aprender outra linguagem é trivial, pois só muda a sintaxe” mostra-se como falacioso.
Para ilustrar o raciocínio, irei expor de modo fenomenologico o desenvolvimento de um profissional fictício. Este profissional começará sua carreira com o Visual Basic 6, o que ilustra muito bem o comportamento que já observei com alguns profissionais. Escolhi o Visual Basic 6 só por se tratar de um ambiente de desenvolvimento rápido (outros poderiam entrar em seu lugar portanto).
Hegel - O germe da fenomenologia moderna
Num primeiro estágio, todo software é composto por uma série de formulários a partir dos quais o usuário envia seus dados e então, através de uma série de eventos, faz o que deve fazer. Não há muita preocupação com módulos ou algo similar. Apenas com os eventos. O trabalho consiste basicamente em agrupar componentes em uma janela, incluir os eventos necessários, compilar a aplicação, entrega-la ao cliente e, conforme o tempo for passando, ir dando manutenção no produto final.Com o passar do tempo, a complexidade do software aumenta. Isto fica nítido a este profissional pelo número de formulários criados. São diversos, e em diversos momentos, ocorre a necessidade de se copiar código de um formulário para outro. Quando o uso do famigerado Control-C/Control-V começa a dar muito trabalho a este desenvolvedor, ele começa a perceber que programar realmente é algo “difícil”.
É quando o usuário passa para o segundo estágio. Surgem os famosos módulos. Neles é possível incluir todo aquele código que até então era copiado de um formulário para outro. Fantástico! Agora basta referenciar estes métodos nos formulários e pronto. O trabalho diminuiu.
O tempo passa e a aplicação continua crescendo. Desta vez, o cliente quer que o sistema se comunique com clientes externos. Já tenho módulos, o que facilita, no entanto, um novo paradigma surge. A web. Como a web funciona? O que devo fazer?
Neste exato momento, o profissional trava. Gastou tanto tempo pensando no desktop que ao se deparar com a web, pelo fato de sua linguagem favorita não lhe oferecer suporte fácil a este novo paradigma, simplesmente não sabe nem por onde começar. “Engenharia de software? Coisa pra gente besta. Há até alguns recursos no Visual Studio. Um tal de ASP… Lembra muito o VB. Será que eu uso ele? HTTP? Que é isto? Eu poderia também procurar algum componente que resolva meu problema…”
Chega-se a seguinte solução: “vou disponibilizar o banco de dados para eles. Assim, eles enviam seus dados aqui pra dentro de acordo com as regras que eu venha a definir e pronto. Problema solucionado. Sou um gênio!”
Lógicamente, a solução irá se mostrar um fracasso. É quando este profissional é expulso do segundo estágio de evolução e aprende outra linguagem de programação. No caso, Java.
Terceiro estágio: aprendendo Java. “Aprender Java é fácil, porque todas as linguagens são iguais. Só muda a sintaxe” pensa nosso pobre profissional. Ao iniciar seu trabalho com Java, a primeira coisa que procura saber é como são criados os formulários, e começa a achar a plataforma um lixo enquanto não encontrar um editor visual que lhe permita trabalhar assim como fazia no caso do Visual Basic. Quando finalmente o encontra, aí sim começa a trabalhar. Cria então algumas classes, lotadas de métodos estáticos. Estas classes “utilitárias” corresponderão para este usuário aos módulos com os quais estava habituado ao trabalhar com Visual Basic.
Algumas aplicações desktop são criadas, já é possível escrever no banco de dados, e tudo anda bem, até que o mesmo profissional percebe a necessidade de criar uma aplicação web. E é neste ponto que dá de cara com a parede de novo. Como não aprendeu orientação a objetos direito (no VB não havia isto. Haviam classes e tal, mas nunca entendeu ao certo para que serviam), não consegue entender como um servlet funciona. Consequentemente, não consegue aprender a trabalhar com outros frameworks. Diz que o Java é um lixo, que o bom mesmo era o VB, aonde conseguia fazer tudo de forma fácil, sem estas “frescuras”.
Repare na constante: como aprendeu a programar usando apenas um ambiente de desenvolvimento, sempre que ocorrer uma mudança, irá tentar trabalhar assim como fazia no ambiente inicial. Se o mesmo profissional, ao iniciar o seu trabalho, tivesse começado com duas ou mais linguagens, vamos supor: Visual Basic e C, ou qualquer outra, o mesmo não teria ocorrido.
Ao se acostumar com o ambiente visual, o programador passa a ignorar que por trás dos seus lindos formulários, há uma estrutura complexa que é preciso conhecer para que se possa progredir. Ambientes de desenvolvimento rápido como Visual Basic ou Delphi banalisam a nossa tarefa.
Curiosamente, se o profissional fictício acima tivesse começado sua carreira aprendendo apenas C, possuiria uma visão mais abrangente? Com certeza. Isto porque linguagens como o Visual Basic ou qualquer ambiente visual apenas suprimem os sintomas de impotência incluindo a ilusão de poder. Nosso programador fictício ao criar seus formulários se sentia incrívelmente podroso. Afinal de contas, estava criando algo realmente útil com apenas alguns cliques do mouse. No entanto, esta ilusão desaparece a partir do momento em que precisa interagir com algo mais complexo. No caso de quem começou usando C/C++ ou outra linguagem que não ofereça este tipo de ambiente, as coisas são mais difíceis no começo.
Este outro desenvolvedor possuirá a visão de baixo pra cima, ao contrário do primeiro. Consequentemente, ao evoluir, ficará mais simples para este compreender as camadas posteriores. Afinal de contas, são desenvolvidas com base naquela da qual está partindo, e não o contrário. Este outro desenvolvedor vê a sua percepção do ambiente digital evoluir conforme vai conhecendo estes novos frameworks ou bibliotecas.
Qual seria a solução portanto? Começar pelo assembler? Claro que não, mas pelo menos fugir dos ambientes de desenvolvimento rápido o máximo possível e, se possível, sempre conhecer pelo menos duas linguagens de programação distintas (melhor ainda: ao menos dois paradigmas). Isto quer dizer também que todos os ambientes de desenvolvimento rápido são um veneno terrível? Não! Só que devemos utilizá-los apenas após possuir uma base teórica/prática sólida sobre os fundamentos da computação.
(não vou chover no molhado e dizer “quanto mais linguagens aprendermos, melhor”, pois é óbvio demais)
No final das contas, não é a popularidade de uma linguagem que torna um profissional competente (COBOL tá aí pra provar isto), mas o modo como lida com o determinismo linguistico.
PS: outro bom exemplo de determinismo linguistico. Windows!
Aqueles que só usam Windows, acham comum os erros que o sistema apresentam, e jamais reclamam. No entanto, no dia em que passam a usar outro sistema, como o Linux ou Mac OS, nunca mais retornam ao mesmo. Isto porque sua linguagem cresceu (ele conhece mais de um sistema operacional) e, consequentemente, possui uma visão mais ampla do mundo.
JDBC: Maldito Access: como resolver o problema “não é possível abrir mais tabelas (can’t open more tables)”
Então aconteceu com você: um belo dia teve de programar em Java acessando o maldito “banco de dados” Access… Seu código está escrito corretamente e a aplicação é iniciada. No início, tudo vai bem, você até se surpreeende com o fato de estar funcionando, até que, sem mais nem menos, começam a surgir excessões com as mensagens “Não é possível abrir mais tabelas” ou, em inglês: “can’t open more tables”.
É um daqueles momentos nos quais você realmente pensa em matar o infeliz que optou por usar este “banco de dados”. Mesmo consultas que só envolvam uma tabela começam a disparar esta excessão e, mesmo que você feche todas as suas instâncias das classes ResultSet e PreparedStatement, ou mesmo suas conexões com o banco, o erro persiste.
A impressão que temos é que só é possível trabalhar com este (argh) “banco de dados” se estivermos programando em VB ou VBA. Na prática, esta é a realidade, e, como irei mostrar a seguir, a solução para este problema não poderia ser mais tosca. Todo o problema está no driver de acesso ODBC ao Access.
Este driver, desenvolvido pela Microsoft (lógico) suporte apenas 1024 consultas a um banco Access. Sendo assim, você precisa fechar todas as consultas ou statements que venha a executar com relação a este banco. O mais interessante é: não basta chamar o método close() das classes ResultSet e PreparedStatment e, para minha surpresa, também não é necessário ficar criando e fechando sucessivas conexões com o “banco” Access.
Basta seguir o seguinte procedimento:
- Conecte-se ao “banco”. Você poderá reaproveitar sua conexão com o arquivo do Access. O problema não é com ela (bônus para você, pois não precisará mais sacrificar sua performance abrindo e fechando conexões a cada consulta).
- Instancie o seu objeto ResultSet ou PreparedStatement, e em seguida faça o que tem de fazer.
- Finalizada a execução, chame o método close da sua classe.
- Como se não bastasse chamar o método close(), defina a sua instância do objeto como null.
De tempos em tempos (vamos supor, de 20 em 20 execuções, por exemplo) chame o garbage colector do Java para limpar as variáveis não utilizadas. Pasme: somente assim as consultas são fechadas com o “banco e dados” em questão.
É uma gambiarra? Com certeza. A performance vai ser prejudicada? Pode apostar. É uma solução elegante? Nem um pouco. Mas por outro lado, você está usando uma das piores opções que existem. Só o fato de estar usando Access já é uma gambiarra, sendo assim, infelizmente, sofra as consequências.
Descobri esta solução enquanto desenvolvia uma “aplicação” que precisava do Access (no meu caso, o 97) no Netbeans. Ao executá-la no ambiente da IDE, o erro não aparecia. Ao executá-la independentemente, o erro aparecia (e sempre). Constatei então que o Netbeans chama o garbage colector constantemente, ao passo que minha aplicação não. Visto que já sabia do bug do driver, somei 2 + 2 e resolvi tentar esta solução. Para minha surpresa, funcionou melhor que o esperado. A perda de performance não foi tão grande e, para minha surpresa, a excessão simplesmente desapareceu.
Tudo bem: o principal problema com o Access foi resolvido. No entanto, faça um favor a você e aos futuros programadores que, por desventura venham a dar manutenção em seus sistemas: ESQUEÇA O ACCESS!
Alguns fatos bem interessantes sobre LISP
John McCarthy: o "papi" do Lisp
LISP sempre me impressionou. Como algo como (defun fatorial (n) (if (<= n 1) 1 (* n (fatorial (- n 1))))) pode ser compreendido e, além de ser escrito por humanos, gerar programas de computador que realmente façam alguma coisa? Como alguém consegue entender isto? Quem programa em LISP é feliz? A resposta é: sim, e MUITO.
LISP sempre me fascinou por seu aspecto intelectual. Você realmente pensa mais (ou melhor, pensa de um modo radicalmente diferente) quando está programando nesta linguagem. Acha Ruby, Python e Groovy linguagens divertidas de se programar? Acredite: LISP é MUITO mais. Comecei a aprender LISP no curso de matemática discreta. Naquela época, enquanto aprendia recursividade, LISP se mostrou um laboratório extremamente útil para meu aprendizado. Porém, desde então, nunca fiz algo realmente útil com a linguagem. Até agora (mais sobre minhas experiências com Lisp em posts futuros)…
Este “não fazer nada de útil” com Lisp acabou aumentando a minha curiosidade a respeito de suas aplicações. Que bicho de fato é este tal de Lisp e em que é usado? No que ele é melhor do que outras linguagens e por que deveria me interessar por ele? E é aqui que entra minha lista de “fatos bem interessantes sobre Lisp”.
Para começar, Lisp não é mais apenas uma linguagem. Atualmente consiste em uma família de linguagens, todas inspiradas no Lisp original desenvolvido por John McCarthy em 1958. A propósito, Lisp foi a segunda linguagem de alto nível desenvolvida (a primeira foi FORTRAN), o que nos leva a ver o poder desta criatura: 50 anos depois ainda é usada (claro, sofreu diversas alterações neste período) em projetos de grande porte e, não satisfeita, possui recursos que só recenemente começamos a ver aparecer em outras linguagens de programação.
Lisp nos trouxe algumas novidades bem interessantes:
- Uso de condicionais: choque-se. Condicionais do tipo if-then-else só aparecem pela primeira vez no Lisp. Em FORTRAN este tipo de construtor ainda não existia. Até então, podia-se contar apenas com o abominável goto.
- Garbage Colector. Achou que foi o Smalltalk que introduziu este recurso? Java? Nada… Lisp!
- Recursividade. Lisp foi a primeira linguagem a implementar este conceito com sucesso.
- O tipo de dados função. Em Lisp, funções são um tipo de dados assim como inteiros, booleanos ou strings. Você pode passar funções como parâmetros para outras funções ou mesmo armazená-las como variáveis. Incrível pensar que só recentemente, com o advento das closures é que este conceito começou a se tornar popular.
- Todas as variáveis são ponteiros. Não, não foi o Java que introduziu este conceito.
- Uma sintaxe que até hoje é sem precedentes. Apesar de parecer complexa, a sintaxe do Lisp é a mais simples e eficaz que conheço: apenas parênteses representando listas e funções.
Exemplo de lista em Lisp: (a b c d)
Exemplo de função em lisp (+ a b)
Ou então algo mais complexo: (+ (- b a) (* c d))
Incrível pensar que só com isto sistemas inteiros são construídos. - A idéia de que é possível escrever programas de computador inteiramente compostos por funções.
E, acredito, não listei todas as novidades que o Lisp trouxe. Saindo das novidades, vamos pra os fatos:
- O nome Lisp vêm de List Processor. Listas são a estrutura básica por trás da linguagem.
- Não se trata de uma linguagem que adota apenas o paradigma funcional. Na realidade, os paradigmas orientado a objetos e procedural também estão presentes.
- A primeira plataforma popular para desenvolvimento de lojas virtuais, a Viaweb (hoje Yahoo! Store), foi desenvolvida inteiramente em Lisp e, segundo um de seus criadores, Paul Graham (fanático por Lisp, diga-se de passagem), foi o principal fator para seu sucesso.
- Por ser funcional, se adapta muito bem ao grande desafio dos programadores atuais: a programação paralela.
- Usa cartão de crédito? Saiba que Lisp é uma das tecnologias mais utilizadas na detecção de fraudes.
- Lisp é a principal linguagem usada em estudos de inteligência artificial (isto todo mundo sabe)
- Desenvolvimento de aplicações em Lisp é rápido. Quer criar um protótipo rápido de sua aplicação? Em Lisp é possível. Isto porque, como é interpretada (pode ser compilada também), todas as alterações feitas por você automaticamente estarão disponíveis em seu ambiente de desenvolvimento. Consequentemente, o ciclo escreve-compila-testa vira apensa escreve-testa.
- É considerada por muitos linguagem mais poderosa do mundo. Uma linha de código Lisp equivale em alguns casos a dezenas de linhas de código escrito em C/C++ ou Java. Quando você desenvolve algo em Lisp, após concluir seu trabalho, percebe-se que, mais do que um sistema, uma nova linguagem de programação foi criada.
(a propósito, um fato escondido: é uma linguagem excelente para a criação de DSLs) - Lisp não é um ermitão. Você pode usar OpenGL, ODBC, bibliotecas nativas, enfim, o que quiser
- Muita gente usa Lisp.
Agora uma pergunta pode aparecer: “se Lisp brilha no escuro como você está dizendo, por que então não está todo mundo programando em Lisp?”. Acredito que a popularidade só não é maior devido aos seguintes fatores:
- As pessoas acham que Lisp é difícil sem nem ao menos tentar. Ao se depararem com um mundarel de parênteses, desesperam-se e correm desesperadas para algo com uma sintaxe próxima do C. Este mito cai por terra ao vermos quão simples é sua sintaxe.
- A existência de vários dialetos que apresentam pequenas diferenças entre si: Alegro, Common Lisp, Arc, Mac Lisp, Scheme, etc.
- Apesar de existirem bindings para práticamente todas as tecnologias em uso atualmente, não há um número grande de bibliotecas para, por exemplo, desenvolver aplicações web.
- A falta de uma IDE realmente produtiva para a linguagem.
No entanto, se levarmos em consideração o número de linguagens inspiradas por Lisp (Java, Python, C#, Ruby, Perl, Smalltalk e muitas outras), percebemos que, na realidade, você pode até não conhecer Lisp, mas com certeza aqueles que criaram sua linguagem favorita quase que com certeza se inspiraram ao menos em parte nela.
A pergunta que se deve fazer no frigir dos ovos é: “vale a pena aprender Lisp?”. Minha resposta é: sim, e MUITO, mesmo que você jamais a use. Isto porquê trata-se de uma daquelas linguagens que realmente abre a nossa mente para outras possibilidades de programação. A partir do momento em que você toma conhecimento dos conceitos básicos por trás do Lisp, fica mais fácil entender de onde surgem estas “novidades” que vemos surgir recentemente, como closures, coletor de lixo, programação funcional e paralela, etc. Isto sem mencionar o determinismo linguístico, que é a maior tragédia que pode ocorrer a um programador (mas isto é assunto para um outro post).
O único problema em aprender Lisp é: uma vez aprendido, você sempre sentirá sua falta ao programar em qualquer outra linguagem.
Quer experimentar Lisp?
Se quiser, é possível experimentá-lo online.
Ou então, melhor ainda: baixe o Common Lisp e experimente em seu computador.
Link: As técnicas de Ajax mais procuradas
Lendo alguns blogs hoje, topei com o seguinte post: Most Wanted Ajax Techniques: 50+ Examples and Tutorials.
No link, encontram-se listadas algumas das técnicas que, realmente, são aquelas que mais queremos entender a respeito de Ajax seguidas de alguns exemplos bem interessantes.
Vale à pena dar uma olhada. ;)
http://www.noupe.com/javascript/most-wanted-ajax-techniques-50-ajax-examples-and-tutorials.html
Sabendo história, Microsoft vira carta FORA do baralho – (LINQ to SQL entra na lista)
Apostou no LINQ to SQL? Acreditou ser uma tecnologia MARAVILHOSA e que teria um futuro brilhante por ser um “produto Microsoft”? Más notícias: a banca caiu. Em um post recente, a equipe de desenvolvimento do projeto basicamente declarou o fim do mesmo, tal como citado no próprio post:
We’re making significant investments in the Entity Framework such that as of .NET 4.0 the Entity Framework will be our recommended data access solution for LINQ to relational scenarios. We are listening to customers regarding LINQ to SQL and will continue to evolve the product based on feedback we receive from the community as well.
Descobri esta novidade ao visitar um outro blog e, sinceramente, soou como uma música que já ouvi algumas vezes. E uma que, sinceramente, sinto me aliviado por não mais me afetar. Só para lembrar algumas tecnologias da Microsoft nas quais milhares de pessoas investiram e, de repente, do dia para a noite, viram todo o seu investimento ser jogado no lixo (siga os links abaixo para sentir uma pontinha de medo caso ainda esteja desenvolvendo para a plataforma Microsoft):
Visual Basic (pré .net). Lembram-se quando saiu o Visual Basic .net? Que maravilha! Só tinha um problema. Se você quisesse atualizar sua aplicação feita com uma versão anterior da linguagem, teria de reescrever práticamente do ZERO todo o seu código. Isto porque o VB.net não era o Visual Basic com o qual todos estavam acostumados. Era simplesmente OUTRA linguagem de programação.
Chegaram até a criar um assistente, que nos fornecia uma lista ENORME de mudanças a serem feitas na sua aplicação. A lista era (e ainda é) tão absurda, que faria MUITO mais sentido, simplesmente escrever algo como “REESCREVA DO ZERO”.
Visual Fox Pro. Declarado extinto pela Microsoft há mais ou menos uns dois anos atrás. Ninguém o usa, certo? Errado. O índice TIOBE em 2006 apresentava o FoxPro na 12ª posição.- Visual J#. Uma maneira bem bacana de migrar suas aplicações para .net, certo? Errado: a Microsoft também o extinguiu. Neste caso, não foi lá grande prejuízo, uma vez que de cara, as pessoas não engoliram a tecnologia. Lembram do Microsoft J++?
- .net 1.0. Como ouso colocar a plataforma .net na lista de tecnologias abandonadas pela Microsoft? Simples: eram tantas as incompatibilidades com as versões posteriores, que em diversos casos, aplicações inteiras tiveram de ser reescritas! Caso precisasse utilizar código compilado com uma versão mais antiga do framework, sabe o que você deveria fazer? Rezar!
- VBA. Chocante: a Microsoft está agora com planos de matar o VBA também (pro Mac, já não existe mais). Este será substituido por um SDK para desenvolvimento de aplicações para o Office. Muita gente não se lembra, mas o VBA era licenciado pela Microsoft a outros desenvolvedores. O AutoCad, por exemplo, oferecia suporte a VBA. Adios amigos! VBA não será mais licenciado!
- VB Script: alguém se lembra dele? A resposta da Microsoft ao JavaScript. O que houve com ele? Bem: a partir de 2007, não serão incluídos novos recursos na linguagem. Traduzindo: foi pro saco.
- DAO/Jet. Sim: muita gente considera o DAO (biblioteca para acesso a bancos de dados) um lixo fedorento, medíocre, ridículo e repugnante. No entanto, MILHOES de aplicações foram escritas usando esta biblioteca. E o que ocorreu? Morta também. Substituída pelo ADO.
ADO é bem melhor que o DAO/Jet, no entanto, o suporte a DAO simplesmente desapareceu.
Se você já precisou lidar com bancos de dados legados no formato Access 97, sabe do sofrimento que estou falando. 
Active X: qual foi a última vez que você ouviu falar nele? Só pra lembrar, era a resposta da Microsoft aos applets Java. BILHOES foram investidos na tecnologia, que se mostrou ineficiente, insegura e, com o tempo, foi aos poucos sendo esquecida (e todo aquele investimento? também?)
Da mesma família do ActiveX, podemos também nos lembrar de uma sopa de letrinhas extremamente divulgada que acabou virando pó: COM, COM+, DCOM.- Active Desktop: quando foi lançado o Explorer 4 (aliás, ainda hoje considero a melhor versão do Explorer), este veio com um novo recurso chamado Active Desktop. Com ele, você poderia incluir pequenos widgets no seu desktop, e foi inclusive um dos argumentos de venda para o Windows 98, uma vez que possibilitaria aos fabricantes de computadores maior customização de seus sistemas. Pois é, mais um pra lista. Foi substituido pelo Windows Sidebar no Windows Vista que…
- Windows Sidebar: também excluído. Lembra daquela irritante barra lateral do WIndows Vista? Aquela que a Microsoft tentou fazer com que novamente, milhões de desenvolvedores desenvolvessem mini aplicativos para a mesma? Pois é: no Windows 7, este recuso será substituido por algo semelhante aos Widgets do Mac OS X.
Estas são apenas algumas das tecnologias das quais me lembro (com certeza há mais algumas). Todas possuem algo em comum: um imenso alarde, milhares de desenvolvedores apostando nas mesmas, e em seguida, a Microsoft as abandonando, deixando bilhões de linhas de código para serem migradas para alguma outra tecnologia (normalmente, da própria Microsoft).
Dos casos citados, provavelmente o mais grave consiste no do Visual Basic. Afinal de contas, no que diz respeito ao número de aplicações corporativas escritas usando a linguagem, equivaleria (levando em conta as devidas proporções) ao COBOL. O mínimo que estes desenvolvedores poderiam esperar da Microsoft era compatibilidade das versões posteriores do produto com o VB 6.
(Só para lembrar: C++, que foi um pulo gigantesco em relação ao C possuía retro-compatibilidade total (pode-se argumentar que C++ seria outra linguagem, mas o exemplo continua válido). Isto sem mencionar o Delphi, que mesmo o 2008 ainda é compatível com a primeira versão da linguagem.)
Então, com base neste post, devemos acreditar que a Microsoft é uma empresa cruel, nojenta, sem ética, fedorenta e malvada? Claro que não. O que se verifica aqui é a ineficiência do modelo fechado/proprietário. Coloque-se na posição da Microsoft: são produtos que não se mostram mais tão interessantes quanto eram no momento do lançamento. Do ponto de vista administrativo, a Microsoft está correta. Se estas tecnologias fossem abertas, com certeza os desenvolvedores que apostaram nas mesmas não sofreriam um prejuízo tão grande, pois haveria mais de um fornecedor.
Observando o outro lado da cerca, aonde se encontram as tecnologias abertas, percebe-se um cenário radicalmente diferente. Há uma comunidade realmente ativa, aonde todos colaboram para o desenvolvimento da plataforma. Não é como no caso de tecnologias fechadas, como por exemplo o Delphi ou o Visual Basic, nos quais a comunidade consiste apenas em consumidores de novos plugins e componentes para seus ambientes de desenvolvimento. Nas tecnologias abertas, a comunidade atua no desenvolvimento das mesmas. Se um fornecedor resolver sair do jogo, não há problema: há outros. Mesmo que todos os fornecedores desapareçam, situação esta ainda mais improvável, ainda existiriam as especificações completas das mesmas, ou mesmo o código fonte. Na realidade, não seria exagero dizer que, no caso das tecnologias abertas, a comunidade é o principal fornecedor.
O mais triste que percebo é que ainda hoje muita gente investindo alto em tecnologias proprietárias cujo roadmap não é nem de longe garantido. Há pouco tempo atrás, em uma apresentação de um produto “fantático” de uma empresa da Bahia, que promete “revolucionar” o desenvolvimento de aplicações, perguntei: “qual o roadmap deste produto?”. E a resposta que obtive dos apresentadores foi: “road o quê?”.
E depois nos dizem que aprender história é perda de tempo…
Links legais:
a lista de softwares descontinuados pela Microsoft (reparem no número de bobagens que realmente, TINHAM de ser descontinuadas)
