Na época havia um rivalidade entre o VB6 e o Delphi. Estavamos todos empolgados com a nova forma de fazer aplicativos Windows arrastando e soltando componentes.
Os dois eram players de mercado tão grandes quanto o Java e o C# são hoje e, se você não fosse para um, certamente iria para o outro. Havia muito hype em cima da VCL e do quanto era fácil fazer componentes usando essa tecnologia. O Delphi também pegou (como meu caso) muita gente que veio do C++, por causa do C++ Builder.
Eu comecei pelo C++ Builder, e fazia-se muita propaganda que o Delphi era igualmente poderoso, mas com uma sintaxe menos chata.
Por incrível que pareça, outra coisa que se gostava no Delphi é que ele vinha com um enorme manual, com mais de 300 páginas, que era uma ótima referência. Acreditem, nos anos pré-internet, isso era um super diferencial.
[quote=ViniGodoy]
Por incrível que pareça, outra coisa que se gostava no Delphi é que ele vinha com um enorme manual, com mais de 300 páginas, que era uma ótima referência. Acreditem, nos anos pré-internet, isso era um super diferencial.[/quote]
Eu usei delphi na década de 90, e felizmente já tinha internet nessa época.
Atualmente programo pouco mas ainda realizo suporte em sistemas desenvolvidos em Delphi e a ferramenta nunca me deixou na mão. Ela é suportada pela empresa Embarcadero e continua evoluindo.
Para um novo sistema provavelmente utilizaria C# mas certamente Delphi atenderia perfeitamente .
Agora , Também existe um monte de projetos Obsoletos em Java por conta de frameworks que não deram certo ou estão ultrapassados .
E a leis de procura e oferta de mão de obra , já fez com que profissionais Java fossem muito bem remunerados mas atualmente não observo isso no mercado.
Enquanto que Delphi , pode esta seguindo o caminho de Cobol que em função da pouco demanda de profissionais fez com o que os salários aumentassem pois o legado existe e o cliente não esta nem ai se o software foi desenvolvido em Delphi, C , C# , VB etc … desde que o software o atenda.
Atualmente , continuo estudando novas tecnologias mas meu foco principal no momento e a fluência na lingua inglesa.
Delphi não vai seguir o caminho de COBOL porque um é para aplicações front-end o outro para regras de negócio.
É mais provável que Java siga o caminho do COBOL se as empresas forem lentas ao trocar seu domain model em OO, por um domain model em linguagem funcional. Na verdade, alguns dizem que Java já é o novo COBOL.
Não acho que isso vá acontecer, pois Delphi é uma “linguagem” fácil de aprender, e gente busca somente o dinheiro e não a satisfação de trabalhar com uma determinada linguagem tem de monte por aí. Enquanto Delphi tiver pagando o que o mercado paga para desenvolvedores, imagino que vai ter pessoas sendo contratadas.
[quote=ImpossiveI] Delphi não vai seguir o caminho de COBOL porque um é para aplicações front-end o outro para regras de negócio.
É mais provável que Java siga o caminho do COBOL se as empresas forem lentas ao trocar seu domain model em OO, por um domain model em linguagem funcional. Na verdade, alguns dizem que Java já é o novo COBOL.[/quote]
O que ele quis dizer com seguir o mesmo caminho, é que os profissionais Cobol são mais valorizados, pois existem mtos sistemas legados que precisam de manutenção e não tem profissional suficiente pra atender a demanda.
E outra, Delphi não é pra aplicações front-end
[quote=ImpossiveI][quote=misterzire]
Enquanto que Delphi , pode esta seguindo o caminho de Cobol que em função da pouco demanda de profissionais fez com o que os salários aumentassem pois o legado existe e o cliente não esta nem ai se o software foi desenvolvido em Delphi, C , C# , VB etc … desde que o software o atenda.
[/quote]
Delphi não vai seguir o caminho de COBOL porque um é para aplicações front-end o outro para regras de negócio.
É mais provável que Java siga o caminho do COBOL se as empresas forem lentas ao trocar seu domain model em OO, por um domain model em linguagem funcional. Na verdade, alguns dizem que Java já é o novo COBOL.[/quote]
O que mais tem dentro de código em Delphi e VB , por exemplo , são as regras de negócio
Claro , que em muitos casos amparados por uma enorme gama de procedures , functions , triggers no lado do banco de dados mas isso , dependerá de quem desenvolveu.
Isso não vai acontecer com delphi, porque delphi não é linguagem de negócio, mas uma ferramenta RAD e geralmente não tem sentido dar manutenção em sistemas feitos usando ferramentas RAD. É mais fácil, rápido e menos custoso, criar outra aplicação.
[quote=ImpossiveI]
Isso não vai acontecer com delphi, porque delphi não é linguagem de negócio, mas uma ferramenta RAD e geralmente não tem sentido dar manutenção em sistemas feitos usando ferramentas RAD. É mais fácil, rápido e menos custoso, criar outra aplicação. [/quote]
Como assim nao tem sentido dar manutencao em sistemas em Delphi? Tem milhoes de empresas que fazem isso
O que mais tem dentro de código em Delphi e VB , por exemplo , são as regras de negócio
Claro , que em muitos casos amparados por uma enorme gama de procedures , functions , triggers no lado do banco de dados mas isso , dependerá de quem desenvolveu.[/quote]
Então o banco de dados é o novo COBOL, e não Delphi ou VB.
[quote=igor_ks][quote=ImpossiveI]
Isso não vai acontecer com delphi, porque delphi não é linguagem de negócio, mas uma ferramenta RAD e geralmente não tem sentido dar manutenção em sistemas feitos usando ferramentas RAD. É mais fácil, rápido e menos custoso, criar outra aplicação. [/quote]
Como assim nao tem sentido dar manutencao em sistemas em Delphi? Tem milhoes de empresas que fazem isso
[/quote]
Se o que esta falando é verdade deveria ter milhares de vagas para programadores Delphi?
[quote=ImpossiveI][quote=igor_ks][quote=ImpossiveI]
Isso não vai acontecer com delphi, porque delphi não é linguagem de negócio, mas uma ferramenta RAD e geralmente não tem sentido dar manutenção em sistemas feitos usando ferramentas RAD. É mais fácil, rápido e menos custoso, criar outra aplicação. [/quote]
Como assim nao tem sentido dar manutencao em sistemas em Delphi? Tem milhoes de empresas que fazem isso
[/quote]
Se o que esta falando é verdade deveria ter milhares de vagas para programadores Delphi?[/quote]
Não existem milhões, mas existe sim uma quantidade significativa de vagas para desenvolvedores Delphi. Na cidade em que moro, por exemplo, é mais fácil arrumar um emprego com Delphi do que com C#. Java então, nunca vi.
[quote=Júlio Murta]
Não existem milhões, mas existe sim uma quantidade significativa de vagas para desenvolvedores Delphi. Na cidade em que moro, por exemplo, é mais fácil arrumar um emprego com Delphi do que com C#. Java então, nunca vi.[/quote]
Sim, existem muitas aplicações feitas nessas linguagens, só não acho que essas vagas tem o mesmo status/salário que o programador COBOL tinha, ou que o DBA tem hoje em algumas empresas.
[quote=ImpossiveI][quote=Júlio Murta]
Não existem milhões, mas existe sim uma quantidade significativa de vagas para desenvolvedores Delphi. Na cidade em que moro, por exemplo, é mais fácil arrumar um emprego com Delphi do que com C#. Java então, nunca vi.[/quote]
Sim, existem muitas aplicações feitas nessas linguagens, só não acho que essas vagas tem o mesmo status/salário que o programador COBOL tinha, ou que o DBA tem hoje em algumas empresas.[/quote]
Atualmente não. Mas eu também imagino que daqui alguns anos (quem sabe 15 ou 20) algo parecido possa acontecer. Mas para isso é necessário avaliar outros fatores significativos. Por exemplo, aplicações Delphi em geral resumem-se a ERPs em empresas de pequeno-médio porte (alguns casos grande), já o COBOL é famoso por sua utilização em bancos, algumas com operações críticas implementadas décadas atrás. Migrar uma aplicação que já funciona há quase 20, 30 ou até 50 anos e que envolve o dinheiro de milhares de pessoas é uma responsabilidade muito maior que migrar um ERP desktop pra web.
No fim das contas, só chegando lá vivo pra saber rs
[quote=Júlio Murta]
Atualmente não. Mas eu também imagino que daqui alguns anos (quem sabe 15 ou 20) algo parecido possa acontecer. Mas para isso é necessário avaliar outros fatores significativos. Por exemplo, aplicações Delphi em geral resumem-se a ERPs em empresas de pequeno-médio porte (alguns casos grande), já o COBOL é famoso por sua utilização em bancos, algumas com operações críticas implementadas décadas atrás. Migrar uma aplicação que já funciona há quase 20, 30 ou até 50 anos e que envolve o dinheiro de milhares de pessoas é uma responsabilidade muito maior que migrar um ERP desktop pra web.
No fim das contas, só chegando lá vivo pra saber rs[/quote]
Discordo. Se uma operação não é crítica hoje, não tem porque passar a ser daqui 15 ou 20 anos.
[quote=ImpossiveI][quote=Júlio Murta]
Atualmente não. Mas eu também imagino que daqui alguns anos (quem sabe 15 ou 20) algo parecido possa acontecer. Mas para isso é necessário avaliar outros fatores significativos. Por exemplo, aplicações Delphi em geral resumem-se a ERPs em empresas de pequeno-médio porte (alguns casos grande), já o COBOL é famoso por sua utilização em bancos, algumas com operações críticas implementadas décadas atrás. Migrar uma aplicação que já funciona há quase 20, 30 ou até 50 anos e que envolve o dinheiro de milhares de pessoas é uma responsabilidade muito maior que migrar um ERP desktop pra web.
No fim das contas, só chegando lá vivo pra saber rs[/quote]
Discordo. Se uma operação não é crítica hoje, não tem porque passar a ser daqui 15 ou 20 anos.
[/quote]
Mas o que não seria uma operação crítica nesse caso? Migrar um ERP Desktop para Web? Também há os seus riscos, dependendo da implementação. Mas também há o custo benefício, que esqueci de mencionar.
[quote=Júlio Murta]
Mas o que não seria uma operação crítica nesse caso? Migrar um ERP Desktop para Web? Também há os seus riscos, dependendo da implementação. Mas também há o custo benefício, que esqueci de mencionar.[/quote]
Se pode terceirizar, normalmente não é crítico pro negócio. Agora resta saber quantas empresas que desenvolve seu próprio ERP?
[quote=ImpossiveI][quote=Júlio Murta]
Mas o que não seria uma operação crítica nesse caso? Migrar um ERP Desktop para Web? Também há os seus riscos, dependendo da implementação. Mas também há o custo benefício, que esqueci de mencionar.[/quote]
Se pode terceirizar, normalmente não é crítico pro negócio. Agora resta saber quantas empresas que desenvolve seu próprio ERP?[/quote]
Não sei se é bem assim. Penso que muitas empresas deixam informações vitais sobre o seu negócio na mão de terceiros quando contratam uma solução de gestão empresarial. E, como você mesmo disse, poucos desenvolvem o próprio ERP. Logo, informações críticas como faturamento, compras, financeiro e outras acabam sim sendo terceirizadas.
Eu havia me referido ao aspecto mais técnico da coisa. Por exemplo, mesmo que seja algo simples é comum ver ERPs por aí que não são desmembrados em aplicação Server e aplicação Client, sendo a aplicação Server responsável por guardar as regras de negócio e o Client uma mera carcaça. Isso permite portar o Client para outras plataformas (Web, mobile) de maneira muito menos dolorida do que migrar um ERP desktop para Web que acessa diretamente o banco e possui várias regras de negócio no evento click dos botões
Gostaria apenas de agradecer a imensa participação no tópico, além de me esclarecer as dúvidas, trouxe uma boa discussão sobre plataformas e desenvolvimento de sistemas atuais.
Não acham que seria interessante condensar algumas coisas daqui para um “guide” ou recomendações gerais?
Esse subfórum é meu favorito, é aqui que a mágica acontece