Delphi Prism – Futuro e previsões
Ao invés de ficar falando o que tem e o que não tem no Delphi Prism, pois estas informações já são abundantes nos outros sites e blogs, vou falar sobre o que eu acho que vem por ai, e por que eu acho que uma nova era está se iniciando para o Delphi.
Na história do Delphi em relação ao .NET, o projeto de manter a compatibilidade com Win32 era interessante no sentido de prover um caminho para quem precisasse desenvolver para .NET, mas levar o paradigma existente na VCL para .NET obrigava a CodeGear a refazer muito do que já existe em .NET de um jeito diferente, é nadar contra a corrente, e o modelo proposto pelo Delphi Prism fará com que se utilize os recursos existentes, podendo investir em melhorias reais que realmente beneficiarão os desenvolvedores.
Ok, novo caminho a seguir decidido, então por que criar algo que já existe? A parceria com a RemObjects é mais um acerto, pois os desenvolvedores da CodeGear podem focar os recursos melhorando o Delphi Win32, DBExpress, criando o Delphi Win64, etc. Enquanto a RemObjects mantém e melhora o Delphi Prism.
O que mais gostei da parceria é que tendo os recursos bem focados, o Win32 tende a implementar muita novidade que só existe no Delphi Prism, e sequer o C# tem, então agora podemos ver melhorias reais na linguagem e nas bibliotecas.
- No desenvolvimento nativo melhorias na linguagem para maior compatibilidade com Prism
- Suporte a outras plataformas
- Desenvolvimento WEB
- RTTI melhorado, para compatibilizar e unificar o código das bibliotecas, como DataSnap e DBX
- Para o Prism, melhoria da biblioteca para compatibilidade com RTL
Citei apenas alguns que pude lembrar agora, apenas para mostrar como esta mudança tende a trazer grandes melhorias para o Delphi, expandindo linguagem, bibliotecas e plataformas.
Pra quem tem medo da continuidade do projeto, pensando no que aconteceu com o Kylix e agora com o Delphi.NET, precisa ver o lado positivo da mudança.
O Kylix foi um grande projeto, e só foi descontinuado por que não rendeu financeiramente. A equipe que o mantinha é a mesma que mantém a versão para Win32, continuar com o Kylix iria comprometer mais ainda a qualidade e a evolução do principal produto. Você continuaria investindo seus esforços em um sistema que não consegue vender ou pagaria salário para uma equipe o desenvolver, se a receita de venda não cobrisse as despesas, mesmo depois de 3 versões, algo entre 3 ou 4 anos?
O Delphi.NET estava nadando contra a corrente e também consumindo muito recursos, enquanto se distanciava cada vez mais dos benefícios da plataforma .NET, a descontinuação do Delphi.NET, é em favor de algo melhor, uma evolução que vai colocar a linguagem de igual pra igual com outras linguagens como C# e VB.NET, e trazer melhorias inovadoras, além é claro de servir como incentivo quase obrigatório, para mais melhorias na versão nativa.
Está bem claro que este modelo só pode trazer benefícios, pois a CodeGear não precisará tirar recursos do desenvolvimento nativo, a RemObjects é a responsável pelo Delphi Prism e decide sobre as melhorias da linguagem, e até agora só se mostrou eficiente neste quesito. A tecnologia pertence a RemObjects, que investiu muito no Oxygene, então mesmo que a CodeGear venha a abandonar o produto, a RemObjects vai continuar, pois além do investimento no produto em si, ela o utiliza para criar outros produtos, que também são fontes de renda da empresa.
Pra quem desenvolve para Win32 nada muda, mas ajuda a reforçar a confiança no produto e aguardar muitas melhorias no Desenvolvimento Nativo. Pra quem precisa desenvolver para .NET, Linux e Mac, as portas estão abertas com um produto maduro e cheio de recursos.
Referências
outubro 31st, 2008 at 17:38
“..O Kylix foi um grande projeto…”, hum, vejamos:
- Tenta instalar o kylix em uma distro mais nova…
- Tenta portar seus projetos, refazendo códigos, forms, usando a CLX…
- Contorne os componentes de terceiros limitados/inexistentes…
Sendo assim, ofereça uma nova versão do Delphi com estes pequenos detalhes citados e veja o sucesso de vendas que será. Depois você questiona o vendedor se o produto terá continuidade e a resposta: Sim, terá, estamos fazendo apenas uma pausa porque focamos esforços no .NET ….
Os projetistas do Kylix deveriam olhar para o próprio umbigo e reconhecer que o “atalho que tentaram fazer” não deu certo (ninguém quer ficar reescrevendo os projetos). As versões posteriores ao Delphi 7 (conclusão de muitos), foram péssimas, ficando a sensação de estarmos comprando um produto em estágio alfa ou beta – erros visíveis, impossíveis de sairam desapercebidos da linha de produção.
Bom, águas passadas não movem moinhos, portanto fica a questão: Como esta a qualidade do Delphi 2009 testada por quem já migrou seus projetos ?
Ainda não testei, pois aguardo o suporte oficial do driver InterXpress da Upscene (espero que saia antes de expirar o meu direito de update que termina no final de dezembro deste ano, senão é mais um custo a considerar na migração).
Embarcadero deveria aproveitar e colocar ciclos de 2 ou 3 anos para o Delphi e utilizar este tempo para: Fazer pesquisa de opinião (ouvir o que seus clientes realmente querem e não as “possíveis tendências” de mercado), colocar recursos relevantes, assegurar um produto de qualidade (rápido, estável, baixíssima taxa de bugs). Haveria mais vendas de licenças, porque teria um gama boa de recursos ofertados que justifiquem o investimento – Hoje a grande maioria fica se perguntando se vale a pena migrar.
outubro 31st, 2008 at 21:48
Concordo plenamente Anderson, ainda uso Delphi 7 e estou totalmente satisfeito, principalmente meus clientes.
Conheço diversos amigos que se aventuraram nas outras versões do Delphi por puro modismo e sei o que eles passam com seus projetos e IDEs cheias de Bugs e updates…
Para Win32 Delphi sem dúvida, para .NET VS na cabeça.
novembro 3rd, 2008 at 00:38
Dener,
Delphi 2007 e 2009 são excelentes produtos, mesmo tendo licença do Delphi 8, 2005 e 2006, nunca consegui usá-los em produção, mas não da pra comparar com as versões mais recentes, e como um usuário que pulou do Delphi 7 para o 2007 para o dia a dia, posso afirmar que o 2007 tem muitos recursos que valem a pena, e o 2009 muito mais ainda.
Mas nada melhor do que estar satisfeito com um produto, então se não o Delphi 7 atende completamente, não há por que atualizar, mas é bom saber que se precisar dos novos recursos, mudar para o 2009 é um bom caminho.
Quanto ao Prism, ele é um plugin para VS, então usando Prism, vc estará no VS, e tudo que tem nele, menos o que a MS propositalmente não permitir.
novembro 3rd, 2008 at 00:44
Anderson,
Como disse, o Kylix “foi” um grande projeto, para o que ele foi planejado na época, o Linux evoluiu tanto, que não daria pra quem projetou e implementou o Kylix naquele momento prever o que iria acontecer.
Como você torço para que a Embarcadeiro não cometa a cadeia de erros cometidos pela Borland, mas ainda é muito cedo, ela pegou um ciclo de Delphi na metade, com decisões tomadas, espero que de agora em diante as coisas sejam melhores, e é como vejo a estratégia para .NET com o Prism, até agora posso dizer que parece uma decisão acertada, mas só teremos o resultado disto no futuro, eu penso que quando tivermos a próxima versão de Delphi em mão, para podermos ver o que do Prism eles portaram para a versão nativa, para aumentar a compatibilidade, sabendo assim se seremos realmente beneficiados ou se seremos apenas consumidores que eles esperam empurrar produtos.
novembro 6th, 2008 at 14:12
Olá Cesar,
Acompanho seu blog há algum tempo, e já trocamos algumas mensagens no forum da CodeGear.
Me permita discordar de seu ponto de vista sobre o Prism.
Primeiramente deixe-me expor diferenças importantes que vejo sobre o “mundo” dos desenvolvedores, que vejo claramente quando troco idéias com outros desenvolvedores. No meu ponto de vista, poderíamos agrupar os desenvolvedores em 3 grupos:
1- Os que trabalham em empresas desenvolvendo sistemas para uso próprio. Por exemplo, quem trabalha no Itaú, desenvolvendo software para o próprio Itaú.
2- Os independentes, que desenvolvem software sob encomenda, ou como fábrica.
3- Os que trabalham em empresas que desenvolvem produtos (softwares prontos, os chamados “softwares de prateleira”)
Então… vamos analisar o impacto que a descontinuação de produtos causa em cada grupo:
No grupo 1, não faz a menor diferença. Desde que seu sistema esteja atendendo ao que se presta, não faz a menor diferença se ele está escrito em Delphi 5, 7 ou 2009. Seu sistema existe para suprir uma demanda, e não para gerar receita.
No grupo 2, o seu ciclo de envolvimento com o software geralmente é mais curto (o mais curto dos 3 grupos). Você usa o que tem a mão que irá atender melhor o seu cliente, com o menor custo e maior benefício. Tanto faz se você vai usar Delphi 2009 hoje e daqui a 2 anos a CodeGear descontinuar o Delphi. O software já estará feito, entregue, pago, e acabou-se.
No grupo 1, o qual eu me incluo, a história é um pouco diferente. Você desenvolve um software como produto. E como produto ele deverá muitas vezes ter um ciclo de vida longo. Para te dar um exemplo, tenho software hoje, feito em Delphi desde o início, completando 11 anos, em constante atualização.
Neste cenário muitas vezes você é obrigado a fazer o que o cliente ou o mercado de seu produto exigem. Por exemplo: O gerente de TI do seu cliente foi a uma palestra da Microsoft e lá ele “descobriu” que se ele só permitir rodar .NET em seu servidor ele terá muito mais “segurança”. O cara não manja nada e a única coisa que ele sabe de .NET é que é da Microsoft. Aí ele te liga e diz: A partir do final do mês que vem, quero que aquele seu sistema esteja em .NET.
Aí… bem… Você não se preocupa. Você usa Delphi, e não VB6, certo? Então para você é super fácil. VCL.NET existe para isto e você rapidamente agrada seu cliente (que pediu um softare .NET por puro modismo, sem saber ao certo o que quer, mas ele PAGA para isto!). Melhor de tudo! Você consegue manter um único fonte para 95% de seu sistema, com duas versões: Uma Win32 e uma .NET (para aqueles que foram na palestra da MS).
Aí um belo dia vem a CodeGear e fala: Não tem mais VCL.NET. Bem… Aí a sua solução deixou de ser viável. Você não poderá manter por tempo indeterminado seu sistema baseado em uma tecnologia descontinuada certo? Afinal, você quer que seu sistema viva mais 11 anos!
Solução proposta pela CodeGear: Reescreva tudo em um pseudo-Delphi, mantenha dois fontes distintos.
Por mim, eu poderia até preferir o Prism sobre o VS/C#, mas não existe forma de vender esta idéia para os “tomadores de decisão”, ou seja, a direção da empresa. Na prática, ninguém quer saber se o Prism faz 3 coisinhas melhor que o C# e se é pascal. Empresas sérias querem minimizar riscos. Uma vez que o mal pior já aconteceu (ter que reescrever o sistema) correr risco de novo com a empresa que fez isto? Sem chance! Você, no meu lugar, aconselharia a ir para o Prims?
Ou seja, se aqui na empresa deixarmos de comprar 20 cópias de Delphi e comprarmos 20 cópias de Visual Studio ano que vem, a culpa é realmente de quem???? Pura, única e exclusiva da CodeGear.
A RM Sistemas, aqui em Belo Horizonte, hoje do grupo TOTUS – maior grupo de informática da américa latina, comprava CENTENAS de cópias de Delphi por ano. Adivinha em quê eles estão desenvolvendo hoje? Pergunte a alguém que já trabalhou lá o porquê disso… Você verá que ninguém aguenta mais esta mudança de rumo e riscos crescentes de ter que reescrever seu sistema a cada 2 anos.
IMO, a CodeGear não quer saber disto, desconhece a existência de tais fatores e de fato desconhece o mercado.
O pessoal da CodeGear dá mais ouvidos a desenvolvedores independentes do que às empresas que desenvolvem. O próprio perfil dos usuários do forum da CodeGear é assim. Mas são as empresas que compram muitas cópias de Delphi que são o fruto da receita da CodeGear. Me parece que eles esquecem disso!
Eu tenho certeza que o Prism irá agradar aos desenvolvedores independentes e pequenas software houses, mas vai continuar sendo uma ferramenta de nicho, como o Oxygene é, e o Delphi está se tornando cada vez mais rápido.
Não sei se você tem contato com o pessoal da RemObjects, mas ao passo que os caras da CodeGear são pelo menos cordiais e atenciosos, os da RemObjects são arrogantes, pretenciosos e se acham donos da verdade. Sorry, mas imagine comprar um software de alguém que pensa que está te fazendo um favor em te vender??? Mais um ponto contra!
Conheço poucos desenvolvedores que gostam mais de Delphi do que eu. Não só do Delphi, como produto, mas do Pascal, como linguagem. Infelizmente está cada dia mais difícil manter-se fiel ao velho e bom Delphi.
Bem, desculpe pelo longuíssimo post e um abraço!
Alexandre Machado
novembro 7th, 2008 at 08:12
Me desculpe Alexandre, tenho que discordar de você, e concordar com o César, hj eu acredito que está mais fácil de se manter fiel ao bom e velho Delhpi sob a guarda da Embarcadero/CodeGear sim, uso as seguintes versões o D7, D2007, D2009, para mim são excelentes versões, tenho sim alguns probleminhas com elas, mas nada que desanime, em especial a D2009, que se mostroiu bem mais rápida, estável que consome menos memória que a D2007, o D2009 se mostra um excelente trabalho que ainda pode ser melhorado mais, mas já se mostrou uma versão de trabalho que pode ser mantida por longos anos e tenho a certeza que a Commodore virá melhor ainda a ponto de superar a D7. Pelo o que acompanho e leio, sob a guarda da Embarcadero, que já trabalha com o desenvolvimento de ferramentas de modelagem de Banco de Dados, acho quase que impossível serrem cometidos os mesmos erros da época da Borland, pois a mesma, estava saindo do foco de desenvolvimento de ferramentas de desenvolvedor para ferramentas de gestão de ciclo de software, o chamado ALM.
Já a VCL.NET foi um grande erro mesmo, o foco de criar uma ferramente plugin, já se mostrou acertado ao usar o eclipse como base para JBuilder, para .NET foi a melhor decisão possível, pois com o César disse aproveita o melhor do .NET (com ressalvas de ser somente o que a MS liberar).
Bem é isso!!!
Abraços
abril 1st, 2010 at 21:33
[...] (http://www.upscene.com/) tamb©m faz essa migra§£o, inclusive de metadata. …Delphi Prism Futuro e previses | Cesar RomeroAo inv©s de ficar falando o que tem e o que n£o tem no Delphi Prism, pois estas [...]