Para cada linguagem, incluindo as maravilhosas whitespace e o brainfuck possuem razões para existir (mesmo que seja a vontade do sujeito que as criou).
C surgiu para ser uma alternativa mais simples e didática que o B (cara, sempre me perguntei quão complexa é B. Pior, quão complexa é A, deve ser A de assembly).
Java veio para excomungar os ponteiros.
PHP veio para simplificar o desenvolvimento web.
Ruby veio para simplificar o desenvolvimento.
Javascript veio para f*** tudo.
3 curtidas
Gostei dessa do JavaScript. (Essa foi a melhor de longe)
1 curtida
Porque valeria esse investimento?
1 curtida
Manutenção, segurança, portabilidade. Quem gosta de [Delphi] Access Violation! e erros dos mais diversos de endereçamento de memoria que ninguem sabe de onde vem deve mesmo continuar indo no cliente de vez e sempre e tacando a culpa em virus, desatualização do windows, deve mesmo continuar com ele. Em Java você vê a Exception e vai cavando e chega no Erro e sabe como resolver. E os mesmo erros quando ocorrem são os mesmos em todas as plataformas. Manutenção não é um detalhe qualquer.
1 curtida
Deixa eu ver se entendi, dizer se é viável ou não sem entender o cenário?
É a mesma coisa de dizer um valor em dinheiro pra fazer uma viagem sem saber qual o destino. Eu acho confuso isso.
1 curtida
Conhecer o cenário é sim importante. Digamos que seu Cliente queira um sistema comercial multi plataforma. Você correria o risco de programar em Delphi e ficar usando tudo que é solução de terceiros para rodar nas ditas plataformas, sabendo que cada solução foi implementada de uma forma ? Independentemente da sua resposta ou de qualquer outro, tem coisas que a gente já sabe do que a linguagem ou linguagem/plataforma é capas.
1 curtida
Comecei a trabalhar com Java em 2002, trabalhava em uma solução de automação de força de vendas para Desktop, Web e Mobile (Pocket PC, celular e Palm Top).
Na versão mobile para Pocket PC utilzávamos uma versão da IBM J9 para Windows CE 4.0 em conjunto de J2ME CDC com Personal Profile e SWT.
Na versão mobile para Celular utilizávamos J2ME CLDC com MIDP.
Na versão para Palm Top era inviável usar Java, então desenvolvemos utilizando HB++.
Para desktop utilizávamos Java 1.3 com SWT.
Para a versão WEB utilizávamos Servlets com um servidor TomCat e Struts.
Para fazer os Pocket PCs conectarem à internet foi necessario desenvolver classes nativas com JNI de forma a conseguir acessar a portas IR que comunicavam com o modem.
O grande desafio sempre era a otimização no tráfego de dados pois os planos de telefone na época eram caros e o cliente pagava pela quantidade de bytes trafegados.
Todas as versões trocavam mensagens entre si através de um protocolo próprio baseado em RMI mas utilizando HTTP e compressão de dados.
Também desenvolvemos uma ferramenta que parseava as interfaces Java e gerava os Stubs na linguagem HB++ pro PalmTop.
Nos Pocket PCs o desafio era o espaço, os equipamentos tinham somente 32MB de memória, 16MB eram consumidos pelo sistema operacional e a máquina virtual Java ocupava cerca de 10MB, sobrava quase nada para a aplicação.
Portanto foi desenvolvido um SGBD próprio, otimizado para Pocket PC, pois os SGBDS que existiam para Pocket PC eram enormes, ou você instalava o banco de dados, ou a aplicação, não havia espacço para ambos.
Depois fui para outras empresas, mas sempre com foco em desenvolvimento Java, tanto que já utilizei muitas tecnologias com Java ao longo desses anos: JNI, JNA, CDS, RMI, JSP, JSF, GWT, JPA, SOAP, Bluetooth…
A primeira IDE que utilizei foi o IBM VisualAge for Java, mas ele foi descontinuado em 2003 ou 2004.
Tentei me adaptar ao Borland JBuilder, mas era horrível, parecia um Delphi que gerava código mal feito em Java.
Tentei me adaptar ao NetBeans, mas era horrível, muito engessado e lento.
Tentei me adaptar ao Forté for Java, mas também era horrível (era baseado no NetBeans).
Tentei me adaptar ao Sun One Studio, mas também era horrível (também era baseado no NetBeans).
Então parti para o IBM WebSphere Application Development Studio, que era leve, mas não tinha editor visual para SWT, JFaces, AWT ou Swing.
Meses depois surgia o “The eclipse Project”, que era um IBM WebSphere Application Development Studio com menos plugins e gratuito.
Hoje continuo utilizando o eclipse como principal ambiente de desenvolvimento.
5 curtidas
Claro, manter em Delphi se o cenário continua o mesmo no Windows onde a aplicação já roda.
1 curtida
Acredito que independente de linguagem, se a aplicação é mal construída tudo fica dificil de se fazer, manutenção, encontrar erros aleatórios como você citou, qualquer coisa fica complexa…
O único contato que tive com aplicações Delphi, foi logo quando comecei a trabalhar na área, dava manutenção em um sistema Delphi, e cara, não sofri com os problemas que você relatou, tive uma experiência bem tranquila.
2 curtidas
Entender o cenário com certeza é necessário, mas com as informações que foram fornecidas no tópico, o que me leva a entender é simplesmente que existe um sistema em Delphi atualmente, logo se é Delphi devem estar usando windows, e querem agora migrar pra Java, mas até então não citou a necessidade de se fazer isso, na minha concepção seria uma troca de 6 por meia dúzia.
Agora se ele explicar melhor o cenário, qual a motivação real que levou ao pensamento de migrar o produto de tecnologia aí eu avaliaria a minha resposta com base nisso, caso contrário contunuo pensando que é um esforço desnecessário.
2 curtidas
Na real, não.
Embora o mercado pague relativamente mal a profissionais delphi, ainda assim é muito mais difícil você encontrar um (quem dirá 5, 10) para manter.
É o caso? Não sei.
Porém, em java, você consegue encontrar vários com muita facilidade.
Eu sei que depende muito de região para região, mas, é fato. Assim como você vai encontrar muito mais profissionais php que java e javascript muito mais que php e assim por diante.
Sem falar no próprio ciclo de vida do sistema. Será que realmente vale a pena manter um sistema legado? Não necessariamente migrar para java, mas, já pensou na quantidade de coisas que já pipocaram e ainda pipocam como novidade?
Óbvio: sem conhecer o real cenário, tudo o que falamos é especulação baseada em experiências próprias.
3 curtidas
Vendo o cenário por este lado, pensando em mão de obra de profissionais, realmente é um ponto relevante a se considerar em um processo de migração.
Concordo com esse seu ponto de vista!
1 curtida
Verdade, mas olha o verbo “era” muito lento. As jvms evoluiram pacas. Somente pra citar, tenho aqui um programa consagrado no mercado forex e bolsa, chamado mt4, feito em c++, desenvolvi um similar em javaFX para opcoes binarias, mas serve para forex e bolsa tambem.
Tem coisas aqui que o em javaFX tá dando um pau no mt4 de deixa-lo descadeirado.
E a memoria tá similar, pouca coisa maior que no mt4.
Agora tenta comparar a segurança do em javaFX com o em C++, primeiro que até agora o em javaFX não tá dando aquelas travadinhas de vez em quando comuns em programas escritos em C++, claro por varios fatores, nem sempre por causa da linguagem.
1 curtida
Se eu perguntar para um professor universitário de programação se vale a pena migrar de Delphi Desktop para Java Desktop, o que ele me responderá?
1 curtida
Se tu quer saber a opinião dele tem que perguntar diretamente para ele, não tem como eu ou qualquer outra pessoa responder!
1 curtida
Não existe nenhum professor universitário de programação que está inscrito no GUJ?
1 curtida