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)

a lista de iniciativas descontinuadas pela Microsoft

18 thoughts on “Sabendo história, Microsoft vira carta FORA do baralho – (LINQ to SQL entra na lista)

  1. Realmente. Programei em VB 6 e me lembro bem quando ele foi descontinuado. Foi isso que me fez olhar com mais atenção o mundo além da Microsoft.

    Responda

  2. Kico,

    Você não entendeu o post do Tim Mallalieu. A frase que foi destacada não fala que o LINQ está sendo desaconselhado. Muito pelo contrário!

    A mensagem que o texto quer passar é que em vez de usar LINQ diretamente sob um banco (SQL Server, por exemplo), é aconselhável que se use o LINQ sob o Entity Framework, que por sua vez ficará sob o banco de dados (SQL Server, Oracle, MySQL).

    Por mais progressista que possa ser, LINQ é um recurso que tem agradado os desenvolvedores .NET e não acredito que o MS vá se livrar dele com tanta facilidade.

    Abraços do Santos.

    Responda

    admin Reply:

    E aí? Beleza, na realidade, eu entendi a mesma coisa que você Santos.
    Não quero dizer que o LINQ irá desaparecer, apenas o provider LINQ to SQL, que deverá ser substituído pelo Entity Framework (pessoalmente, não entendo muito de .net, pois como já mencionei, atualmente só estou trabalhando com tecnologias abertas). Este é o comportamento que você adota quando quer dissuadir seus clientes de usarem determinada tecnologia da qual você queira se livrar.

    Com relação a acabar com o LINQ, você tem toda razão (seriam LOUCOS de fazer isto com uma tecnologia que possui tanto hype atualmente). Realmente, o LINQ eles não acabam, mas um provider ou outro, nada impede.

    Responda

  3. Programei durante muito tempo ( 6 a 7 anos ) em VB6, particularmente era fã de tecnologias como ActiveX, ADO, ADOX, COM e COM+
    Agradeço a Deus por elas terem evoluído e termos hoje o framework 3.5!!!

    Não tenha medo da mudança.
    “changes never change”

    Responda

    admin Reply:

    Opa DAS, na realidade, não tenho medo algum da mudança (também fiquei grato pelo desaparecimento das mesmas!!!).
    O problema é que não havia um roadmap que nos ajudasse, na época, a programarmos a migração de nossos códigos desenvolvidos com esta tecnologia para as que viriam posteriormente. Simplesmente, do dia pra noite, todo o investimento feito na tecnologia virou pó, o que, no mínimo, é um desrespeito com aqueles que investiram nas mesmas, não acha?

    Responda

  4. Sou fâ da tecnologia .Net desde o lançamento e achei uma bênção terem evoluido do VB 6.0, lembro do “DLL Hell”, de resetar o server a cada nova atualização de DLL. No meu ver a MS conseguiu montar uma plataforma que fizesse páreo ao Java. Infelizmente o custo foi a enorme lista de descontinuações de que citou (se esqueceu do Windows DNA).

    Porém não podemos esquecer do histórico descaso da Borland com seus desenvolvedores deixando o Delphi quase à deriva. O Delphi por sinal é uma excelente plataforma com uma comunidade idem!

    Gosto das tecnologias MS e sempre atenderam bem ao meu negócio mas sempre olho as novidades com ressalva e adoto uma regra básica de não entrar de cabeça em uma nova tecnologia da MS com menos de 2 ou 3 anos de idade.

    Responda

    admin Reply:

    Nossa, muito bem lembrado o Windows DNA. Realmente, lembro que uma galera investiu nele também.

    Sabe: no final das contas, o que conta é o seguinte: se for aberto, SEMPRE vai ter alguém para dar suporte,a o contrário do proprietário, que uma vez as vendas caiam, quase que automáticamente é esquecido pelo criador.

    E também muito bem lembrado o caso da Borland. Como programador Delphi sobre pencas nas mãos daqueles incompetentes! :)

    Responda

  5. Concordo com você, durante um certo tempo também passei por maus bocados destas tecnologias, coisas que hoje não passo mais.

    O interessante é que quando o .net chegou na época também havia aderido ao hype, mas com o tempo preferir troca-lo pelo Java (mesmo o java não possuindo o mesmo potencial tecnológico que o .net) pela segurança. De fato tecnologias abertas são bem mais difíceis de morrer, um exemplo disso posso dizer o PHP 4 que a própria Zend quer eliminar, mas muitas empresas passaram a mante-lo justamenta devido a carga de máquinas e sevidores e seus milhões de clientes.

    Outra tecnologia interessante também é o Ruby que começou sua vida como algo distante para depois ser ardualmente aceito hoje em dia, fora outras tecnologias abertas que para de fato morrerem todo mundo deve realmente rejeita-las o que raramente acontece.

    Entretanto ainda vejo muitas pessoas investindo em hypes como asp.net, Delphi (se arrependeram amargamente, na época todos foram para Delphi e pascal enquanto seguir C/C++), o próprio .net, silverlight, entre outros. E muitas vezes não olham os problemas que realmente estão aceitando, mas em se tratando em asp.net vejo que alguns portais como o Terra finalmente substituiu aquele elefante branco (na realidade o asp.net também é fantastico, melhor que JSP e JSF com certeza, mas a maioria e fato nem sabe usa-lo direito, fala de padrões de código para um programador .net recem formado e vai saber o que estou dizendo) pelo PHP 5 (que muitos na época disseram e ainda dizem que está para morrer), rapaz a diferença se tornou evidente, nada de mensagens de erros absurdas ou tantos problemas cabeludos que antes aconteciam.

    De fato não digo que as soluções da microsoft sejam ruins, muito pelo contrário de fato são boas e inovadoras por sinal, vide o .net que tecnologicamente é bem superior a java, entretanto vale o ditado: “soluções microsoft para problemas microsoft”

    Responda

    admin Reply:

    Oi Cristovao,

    interessantes os seus comentários. No entanto, fiquei com uma dúvida: em que pntos o .net é superior tecnológicamente ao Java?

    Digo isto porque básicamente, pela minha experiência até agora não encontrei nenhum ponto que um superasse o outro e vice-versa, saca?

    Responda

    Heaven Reply:

    Os pontos em que o .net são superiores a Java são estes

    Linkagem estática, no caso em java todas as classes que são geradas são guardadas em um simples pacote zipado ao qual devesse montar um arquivo manifest sempre, enquanto em .net assim como é feito em outras tecnologias você usa de linkagem estática tanto para linkar as bibliotecas quanto gerar uma biblioteca ou executavel a partir dos arquivos objects e não simplesmente gerar um um simples zip que será sempre retirado e carregado na memória
    Linguagem intermediária, toda a aplicação .net quando é compilada pela primeira vez ela gera um assembly intermediário que é otimizado apenas durante o uso e execução, só que diferente de Java que deve mutualmente estar recompilando seus bytecodes através do JIT (que obviamente durante estes anos evoluiu de forma assustadora), os opcodes da tecnologia .net são gerados durante as primeiras execuções e guardados em arquivos assembly, que nas execuções posteriores são apenas chamadas não requisitando executar novamente o JIT, uma outra vantagem dessa forma de trabalhar é justamente na construção de compiladores, é bem mais fácil construir um compilador para esta tecnologia utiliando este conceito (conceito este de linguagem intermediária utilizado também no LLVM)
    Acesso direto a ponteiros, não posso considerar isso uma vantagem considerável para em relação se focar no fato que Java tem como principal intuito a segurança, para desenvolvimento de aplicações (no caso jogos) que precisem de desempenho este ponto é bastante considerável, mas a nível corporativo (o caso de Java) isso é completamente desnecessário

    Tem algumas outras vantagens que neste momento não lembro, entretanto as principais vantagens são justamente estas, gostaria muito que a Sun tivesse adicionado pelo menos o suporte a uso de opcodes ao invés de bytecodes, já que de principio já viria o uso de linkagem estática (adeus aos arquivos manifests) e linguagem intermediária, claro que tais vantagens influenciam mais quando se compara a carga de uso da CPU quando se carrega a aplicação, já que com Java toda inicialização é igual a uma nova compilação (por essa razão que aplicações em Java possuem essa carga), enquanto que utilizando mono/.net essa carga só acontece nos primeiros dias de uso, depois a única coisa que o .net faz é apenas validar se esta otimizado carregando assim bem mais rapidamente.

    Responda

    admin Reply:

    Oi Cristovao,

    discordo de você em alguns pontos:
    linkagem estática vs linguagem dinâmica:
    1. o arquivo de manifesto não é obrigatório
    2. é diferente, não é melhor nem pior. Na realidade, em algumas situações é até mais flexível, o que seria uma vantagem

    Linguagem intermediária: aqui o problema é só no startup, de fato: mas após este, dado as otimizações que são feitas em tempo de execução, inúmeras vezes a performance se equipara ou mesmo fica superior à de linguagens como C/C++, ao contrário dos opcodes, nos quais a otimização é feita uma única vez

    (e, contando que 90% das aplicações feitas em Java são executadas em servidores, que por definição não são reiniciados o tempo inteiro, este problema some)

    * Acesso direto a ponteiros: no caso, esta é uma desvantagem do .net conceitualmente falando, visto que o objetivo de uma plataforma móvel como a Java e o .net é justamente evitar que o programador tenha de fazer isto por questões de segurança, comodidade e gerenciamento de memória

    E, numa boa? Estes 3 pontos que você critica nem deveriam ser criticados pela seguinte razão: Java, ao contrário do .net, foi feito para ser multiplataforma (mono ainda é uma piada). E estas são as soluções adotadas justamente para se conseguir isto, saca? Sendo assim, reitero que não são deficiências, mas sim abordagens diferentes, que não são nem superiores nem inferiores, só diferentes. :)

    Responda

    Heaven Reply:

    Interessante,

    Então gostaria de saber como é possível de evitar os arquivos manifests sem ter de usar o argumento classpath do java, pois é esta uma das maiores dificuldades, atualmente minimizadas com o uso de maven (odeio o ant).

    Na realidade o uso do JIT nem sempre é usado somente no startup, já passei por diversas situações que ainda existia o processo de carga por causa do JIT, concordo que o JIT atualmente esta bastante evoluído e realmente isso minimizou esses eventuais problemas que aconteciam antes.

    Mas não são todos os casos em que a performance é superior que em C++ (por favor nunca diga com C, pois isto é uma blasfêmia, se levar em conta que a JVM é escrita em C) na maioria das vezes a melhora da perfomance em Java se trata pelo uso e mult-threads que a própria máquina virtual faz por você, neste caso em máquinas que tenham mais de um núcleo, então existe uma grande chance de a performance ser a mesma ou mesmo superior que a de aplicações escritas em C++, outro fator que fica contra o C++ neste ponto é devido a ausência de um gabarge collector, já que como o desalocamento de memória é feita pelo próprio programador isso faz com que demande tempo de performance (mesmo sendo pequeno ainda se faz relevante a aplicações maiores), neste caso como uma solução para aplicações em C++ seria o uso dos tantos gabarge collectors que existem por ai o que traz um aumento significativo de performance, entretanto para o uso de outros núcleos eu ainda não conheço nenhuma solução para isso a não ser escrever aquele código rabuscado que ninguém entende, no mais ponto para Java nisso.

    Sobre a quantidade de otimizações de bytecodes, na maioria das vezes o resultado tem pouca diferenciação, os resultados otimizadas 90% das vezes são os mesmos, por isso veio a idéia do .net com o opcode.

    E concordo em relação a servidores, assim para uso corporativo Java é perfeito, de forma que as vantagens tecnológicas utilizadas em .net não fazem tanta diferença para corporações, fora o fato que atualmente Java tem muito mais conceitos e idéias que .net (a quantidade de técnicas, padrões e ferramentas).

    Concordo que é bastante flexível o uso de pacotes ao invés de arquivos estaticamente linkados a nível de desenvolvimento (o eclipse usa e abusa deste conceito, pena que netbeans só agora esta caminhando para fazer a mesma coisa), entretanto semelhante a isso se fazem com os arquivos objects, em .net.

    Concordo que conceitualmente falando o acesso direto a ponteiros é uma desvantagem, já que isso trás mais problemas que soluções, mas ainda existem casos que de fato para não se escrever o código em outra tecnologia (como acontece quando precisa de otimização e tem que integrar o código Java com código em C, que é uma aberração) como acontece com Java utilizando JNI, então fica preferível fazer na mesma, claro que tal abordagem é conceitualmente errada, já que de certo é ideal fazer isso em outra tecnologia mesmo e apenas usar na tecnologia atual, o que significa um conceito maior de segurança com respeito da aplicação.

    Também concordo que mono é uma piada, pena que só se tornou uma piada por causa dos próprios desenvolvedores .net que não entenderam que o mono era o mono e não era .net, mas queriam exatamente o contrário, por isso que o mono atualmente é o que é hoje.

    No caso em questão para ser de fato multiplataforma não precisaria a tecnologia seguir tais abordagens, podemos comparar isso ao flash ou mesmo adobe air da própria Adobe aproveitou tudo que tinha de bom no Java e fizeram sua própria runtime que é bastante interessante seus conceitos (apesar de não ter gostado tanto).

    Compreendo a idéia de serem diferentes, mas a nível tecnológico podemos considerar que o primeiro é sempre precursor (o Java é 1995) as tecnologias posteriores tentam sempre aproveitar o que foi bom e correr de suas eventuais falhas.

    Mas sinceramente mesmo tendo estudado a fundo o .net (não somente o framework, mas também a runtime) assim como também estudei e estudo Java, mesmos os fatores, ainda prefiro Java por ter uma visão mais de longo prazo que .net.

    Responda

    admin Reply:

    Oi Cristovao, cara: você tem excelentes argumentos, parabéns!

    E eu entendi errado o que você estava dizendo com relação às dependências. Realmente, neste caso, você tem de incluir os arquivos jar no manifest sim (mas não é lá um problema tão gigantesco assim, é? :) )

    Ou não. há pouco tempo fiquei conhecendo o Apache Ivy (http://ant.apache.org/ivy/), que resolve este problema de forma brilhante.

    E excelente o argumento com relação ao Flash. Não havia pensado nisto.

    E, de fato: só em alguns casos que fica mais rápido (não devia ter escrito C… mea culpa), mas só de estar próximo (e bem) já tá valendo! :)

    Responda

    Heaven Reply:

    Obrigado, principalmente por mostrar sobre o Apache Ivy, se eu tivesse conhecido antes teria evitado tantos problemas, li a documentação e é bastante promissor.

    Ah sim graças aos ótimos posts deste blog sobre groovy e grails foi o que me fez aderir a usar o grails atualmente e graças ao grails foi quando conheci o griffon, que mesmo sem documentação é muito fácil de usar, os códigos exemplos são quase que a própria documentação, tão flexível quanto o grails e permitindo a mesma liberdade, estar sendo gritante a diferença como construia sistemas em swing antes para como venho construindo agora, a quantidade de código necessário para construir é absurdamnte menor, e além de poder criar aplicações em desktop também permite criar aplicações web (usando applets), a nova versão a 0.3 vai trazer o uso fabuloso do pivot (http://pivot.apache.org/) que tornar as aplicações ainda mais ricas (também vai permitir o uso do JavaFX, entretanto para sistemas em RIA o pivot se apresentou mais promissor e com mais recursos).

    Aproveita para dar uma olhada no griffon qualquer dia destes, com toda certeza não vai se arrepender.

    Responda

    admin Reply:

    Que bom que esteja gostando do blog. Farei o possível para melhorá-lo ainda mais.

    Com relação ao Griffon, já passou da hora de ver o bichinho!

    Responda

  6. excelente tópico, excelente bate-papo o nosso sobre plataformas vs futuro. parabéns pelo blog! ;)

    Responda

    admin Reply:

    Olha! Fico feliz que tenha gostado Paulo! Isto me incentiva para continuar!
    Valeu!

    Responda

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>