Iniciando aplicativo Desktop, porque escolher C++?

[Fellipe Henrique]

Bom dia amigos,

Primeiramente me desculpem pelo post, não quero aqui criar flames.. é que só quero uma opinião de quem é do ramo do C/C++..

Hoje, estou querendo iniciar um projeto para sistema desktop, sim.. desktop.. já tenho um sistema Web, mas alguns clientes não querem usar via web, e sim na empresa.. e as vezes (quase sempre) não há como instalar meu sistema web na empresa por alguns motivos, tais como: a empresa não pode dispor de um servidor linux (que é necessário em meu sistema web) entre outros..

Alguns sistemas meus foram feitos em Delphi, o que é bastante  razoável, sendo que para desenvolver desktop nele é beem fácil.. mas tenho alguns problemas com ele: 1) a cada ano uma nova versão com novos problemas. 2) Ide super hyper pesada 3) linguagem defasada. 4) Sem acesso fácil à internet, seja por meio de webservices ou outra coisa...

Então queria ver com os amigos, o que levaria a empresa a trocar o desenvolvimento Delphi pelo C++ (estamos pensando usar o Qt), sendo que teria quer ter ao mínimo essas necessidades: 1) Ser compilável e portável para Windows, MacOs... 2) Facilidade de acesso a internet (consumir webservices e etc).. 3) Facilidade de acessos as chaves de criptografia (certificados).  4) Nao possuir visual "antiquado" igual win32...

Acredito que seria isso amigos, como não uso o C++ profissionalmente, não saberia responder e ter embasamento para "peitar" o delphi nesse quesito..

Conto com a ajuda dos amigos.. abraços e obrigado desde já...

T.·.F.·.A.·.     S+F

Fellipe Henrique P. Soares

e-mail: > echo "lkrrovknFmsgor4ius" | perl -pe \ 's/(.)/chr(ord($1)-2*3)/ge'

Blog: http://fhbash.wordpress.com/

GitHub: https://github.com/fellipeh

Twitter: @fh_bash

[Francisco Lopes]

Melhor coisa que vc faz mesmo, vai de Qt 5 e problema resolvido. Open-source, multiplataforma, IDE leve que roda em Windows, Linux e Mac. Utilizando QML vc consegue interfaces bonitas suportando estilos, e poder fazer/prototipar grande parte em Javascript e QML.

--
Antes de enviar um e-mail para o grupo leia:
http://www.ccppbrasil.org/wiki/Lista:AntesdePerguntar
--~--~---------~--~----~------------------------------
[&] C & C++ Brasil - http://www.ccppbrasil.org/
Para sair dessa lista, envie um e-mail para ccppbrasil-...@googlegroups.com
Para mais opções, visite http://groups.google.com/group/ccppbrasil
--~--~---------~--~----~--~-~--~---~----~------------

[Gianni]

Qt é o mais parecido com Delphi que eu conheci. Há muito tempo eu programava
em delphi também. Quando vi que o Delphi estava estagnando, fiz uma pesquisa
por linguagens e toolkits.

O Qt com o designer e os QtSql e seu Model/View chegou o mais perto do que eu
usava no Delphi.

> *Fellipe Henrique P. Soares*

>
> e-mail: > echo "lkrrovknFmsgor4ius" | perl -pe \ 's/(.)/chr(ord($1)-2*3)/ge'

> *Blog: http://fhbash.wordpress.com/ <http://fhbash.wordpress.com/>*
> *GitHub: https://github.com/fellipeh <https://github.com/fellipeh>*
> *Twitter: @fh_bash*

[André Tupinambá]

Fellipe,

Trabalho com um sistema desktop utilizando C++ e Qt. Atualmente está rodando somente em Linux mas existe a possibilidade de existir uma compilação para Windows em algum momento no futuro. A escolha da tecnologia (C++ e Qt) foi feita muito mais por questões de desempenho (é um sistema científico) do que outros requisitos.

Essa escolha tem seus prós e contras. Qt é um framework robusto e bem mantido, você não vai ter problemas para utilizá-lo. Para as principais plataformas você vai ter um bom conjunto de ferramentas para trabalhar (compilador, IDE, libs, etc.). O Qt ainda tem o QML que você pode utilizar para fazer suas interfaces e prototipar com javascript (nós não usamos no trabalho).

Em compensação, encontrar profissionais C++/Qt no mercado não é tão simples como nas outras linguagens (apesar que aqui na lista ter vários muito bons). A linguagem também não é tão "produtiva" quanto outras podem ser, C++ é mais complexo e isso leva a mais erros e mais tempo para ter algo pronto.

Profissionalmente eu não iniciaria um desenvolvimento desktop com C++ se não fosse estritamente necessário (apesar de trabalhar em um). Não é o seu caso por causa da multiplataforma, mas em Windows prefiro sempre usar C# para fazer app desktop. Não sou fã de Java, mas se não existir processamento pesado a ser feito é uma possibilidade. Mas de qualquer maneira C++/Qt é uma opção melhor que Delphi, isso sem dúvidas. Delphi já está muito ultrapassado, não existe mais como ter comparação com as ferramentas atuais.

[]'s

André Tupinambá

--

[Fellipe Henrique]

Boa noite, obrigado pelas dicas...

Realmente para Desktop, o delphi ainda tem um caminho difícil de sair.. mas ele está estagnado, e não permite eu desenvolver em MacOS X e ter os mesmos fontes compilados para Windows..

Sei que a curva de aprendizado no C++ é alta, principalmente se compararmos com o Delphi, mas hoje, alguns profissionais já nem sabem Pascal mesmo, e ter que ensinar Pascal, C++, C#... não vejo tanta diferença assim..

Vendo o Qt.. me preocupei com algumas perguntas que ele fez ao realizar o download... com o Qt não posso vender meu sistema? Ele tem que ser openSource?

T.·.F.·.A.·.     S+F

Fellipe Henrique P. Soares

e-mail: > echo "lkrrovknFmsgor4ius" | perl -pe \ 's/(.)/chr(ord($1)-2*3)/ge'

Blog: http://fhbash.wordpress.com/

GitHub: https://github.com/fellipeh

Twitter: @fh_bash

[Marcos Roberto]

Sim, você pode. Porém a restrição é que a linkagem com o Qt seja dinâmica. Que é o padrão dos downloads.

[Thiago Adams]

O primeiro filtro da pergunta sobre qual GUI usar é geralmente se é multiplataforma.

Neste caso não vou sugerir Win32 justamente por ser apenas windows.

Mas vou abrir um parenteses aqui, para esclarecer algumas coisa sobre a Win32.

Um programa feito com Win32 não vai se parecer antigo. Justamente pelo contrário, pois a GUI se atualizada junto com o SO. Ou seja, se você usar win32, o botão do windows 10 vai ser parecer com o windows 10 e não com o XP, isso é automático.

Sito algumas adições recentes da interface desktop para windows.

 - Direct2D

 - Ribbon

 - Novos dialogs de messages e ações

Tudo foi a partir do windows vista.

Aqui tem um exemplo de interface usando Win32.

http://www.elipse.com.br/port/trendexplorer_screenshots.aspx

Em relação a performance, nada vai ser mais rápido, e menor do que a solução usando a API nativa diretamente. É um dilema parecido ao desenvolver para celular. Ao usar uma API nativa o programa tende a ficar melhor.

[Matheus Lima]

já que falaram em GUI multiplataforma, o que achama do WxWidgets?

--
Antes de enviar um e-mail para o grupo leia:
http://www.ccppbrasil.org/wiki/Lista:AntesdePerguntar
--~--~---------~--~----~------------------------------
[&] C & C++ Brasil - http://www.ccppbrasil.org/
Para sair dessa lista, envie um e-mail para ccppbrasil-...@googlegroups.com
Para mais opções, visite http://groups.google.com/group/ccppbrasil
--~--~---------~--~----~--~-~--~---~----~------------

--

Matheus Lima

Graduando em Engenharia de Teleinformática - UFC

[Thiago Adams]

Esqueci de falar dos pontos negativos da GUI win32.

É o abandono total da MS durante a última década na melhoria da IDE para gerar código nativo.

Se você usar a ribbon por exemplo é tudo muito manual.

[Gianni]

Quando escolhi o Qt, tentei fazer um protótipo em WxWidgets. Achei super
confuso a forma de trabalhar, e o resultado ficou 'feio'. Além do fato do
WxWidgets não fazer nem 1% do que o Qt faz (Rede, File-system, Xml, e todos os
widgets gráfricos, OpenGL, QML, etc).

[Fellipe Henrique]

Tentei fazer o download, e só consigo se eu selecionar openSource... pq qualquer outra coisa, ele abre um download de 30 dias.. achei confuso isso.. posso continuar dessa forma mesmo?

T.·.F.·.A.·.     S+F

Fellipe Henrique P. Soares

e-mail: > echo "lkrrovknFmsgor4ius" | perl -pe \ 's/(.)/chr(ord($1)-2*3)/ge'

Blog: http://fhbash.wordpress.com/

GitHub: https://github.com/fellipeh

Twitter: @fh_bash

[Francisco Lopes]

Sim, se seguir a LGPL, que como ja foi comentado, basta usar ligacao dinamica com as libs do Qt que fica tudo OK.

[]s

[Shander Lyrio]

Eu sempre acho estranho quando alguém fala que Delphi está estagnado. O que eu tenho visto é ele evoluindo muito, mas muito rápido. Hoje é extremamente simples criar um aplicativo multiplataforma que roda em Windows, Mac, android e iOS com a mesma base de código sem alterar nem uma única linha. Programação paralela? Trivial! Unicode?? completamente!

Eu comecei a trabalhar com delphi assim que ele surgiu em sua versão 1, parei na versão 7. Há cerca de 1 ano atrás resolvi dar uma olhada em como estava o meu velho amigo e fiquei muito surpreso com o que eu vi. Tão surpreso que acho até estranho ouvir falar que Delphi está estagnado. Me custa acreditar que estamos falando do mesmo Delphi.

​Apesar de não utilizar Delphi hoje, principalmente porque trabalho muito mais com software embarcado ​onde C/C++ reinam, não descartaria de jeito nenhum a hipótese de utilizá-lo em um sistema comercial. Mas talvez o Delphi que eu conheço seja diferente do Delphi defasado que os amigos conhecem.

Uma coisa a se levar em consideração é que o Delphi é caro, a Embarcadero cobra bem por todas as facilidades que você tem para desenvolver sistemas utilizando Delphi.

--
Shander Lyrio

--
Shander Lyrio

--

[Fellipe Henrique]

Olá Shander,

Primeiramente me desculpe falar de delphi aqui no grupo de C++...

Mas nesse ponto eu posso discutir, já que venho do mundo delphi, e sou desenvolvedor delphi desde a primeira versão, e parei na XE7.. ou seja, na penúltima..

Para desktop windows, realmente até o momento não vi, não achei nada que compare ao uso e facilidade do Delphi.. ele realmente é bom! Mas como eu acompanho o mundo delphi há décadas, posso opinar o que acho ruim.

Vamos por partes:

1) Multi-plataforma

Não funciona as mil maravilhas que a Embarcadero fala... eu tentei usar, porém para isso você deve reescrever praticamente seu produto inteiro para usar o "novo" firemonkey, porque se você for usar a VCL (biblioteca padrão), não compila a não ser para Windows.. Então temos problemas aí: Reescrever praticamente todo o código da VCL pro Firemonkey e "confiar" no firemonkey, que é recém criado e cheio de bugs.. eu mesmo já reportei diversos para a Embarcadero há 3 anos, e minha surpresa? Ainda não foram solucionados..

2) Delphi está "estagnado"

Apesar das pseudo-evoluções o delphi sim está estagnado em alguns pontos.. vou citar alguns: 

a) Acesso a internet: A melhor forma de se fazer acesso é usando o DataSnap, que veem de um componente antigo chamado Indy, que possui um problema sério de desempenho e consumo de memória... eu mesmo postei um problema sério quanto a isso e sem nenhuma solução.. não conseguia colocar 50 máquinas acessando via internet num servidor DataSnap..

b) Consumo WebService: O delphi não fornecia acesso fácil ao consumo de WebServices.. problema mais visível no uso dos WS da SEFAZ para consumir a NF-e.. problemático.. passei muitos problemas com isso..

c) IDE Super, hyper, extremamente lenta e pesada!!! 4GB de RAM somente pra IDE, no mínimo...  ;)

d) Acesso à banco de dados usando modelos.. praticamente não existe.. é usado uma abstração feita para ser simples e fácil de usar, e realmente é.. mas experimente ir no banco de dados e mudar um campo VarChar(6) para varchar(8) para ver como o delphi dá pau direto.. em todo lugar que você usa esse campo, traduzindo... facilidade de manutenção é baixa.. mudança em banco de dados, requer que você no mínimo verifique em todos os arquivos o uso deste campo para "refazer o dataset"... isso me matava, e foi um dos motivos de praticamente querer sumir da frente do Delphi.

3) Delphi virou um Produto muito lucrativo!

Ah.. isso não deveria ser um problema, mas é.. e eu comecei a ter problemas com ele a partir do momento em que a Embarcadero começou a solucionar problemas/bugs importantes e extremamente chatos, nas versões novas! Ou seja, sempre deixando um buraco nas versões para ser corrigido nas próximas, fazendo você sempre atualizar o produto.. isso enche o saco (com o perdão da palavra)  principalmente pelo preço que se paga pelo produto. E agora, eles praticamente estão "introduzindo" bugs propositais para que o usuário faça a inscrição no programa deles [1]

Isto posto, por isso eu acredito que se não houver uma mudança, o Delphi está fadado ao fracasso.. porque só quem compra o delphi, é quem possui sistemas antigos e que precisam manter.. porque novos softwares, novas empresas.. dificilmente vão usar o Delphi, por conta disso tudo que eu estou falando..

[]s

[1] - http://www.adug.org.au/misc/settingtrap/

T.·.F.·.A.·.     S+F

Fellipe Henrique P. Soares

e-mail: > echo "lkrrovknFmsgor4ius" | perl -pe \ 's/(.)/chr(ord($1)-2*3)/ge'

Blog: http://fhbash.wordpress.com/

GitHub: https://github.com/fellipeh

Twitter: @fh_bash

[JuciÊ Andrade]

On Saturday, August 1, 2015 at 3:23:08 PM UTC-3, Fellipe Henrique wrote:

Hoje, estou querendo iniciar um projeto para sistema desktop, sim.. desktop.. já tenho um sistema Web, mas alguns clientes não querem usar via web, e sim na empresa.. e as vezes (quase sempre) não há como instalar meu sistema web na empresa por alguns motivos, tais como: a empresa não pode dispor de um servidor linux (que é necessário em meu sistema web) entre outros..

 

Você vai ter que incorrer nos custos de reescrever sua aplicação em outra linguagem porque o cliente não quer colocar na intranet um Linux. Difícil esse cliente, hein Fellipe?

 

Olha, sugiro que você reavalie os custos de desenvolvimento pra ver se vai valer a pena.

 

Um abraço.

[Rodrigo Avancini]

Boa noite Felipe,

Como você esta querendo migrar para uma aplicação desktop e de acordo com as características citadas, como a turma já sugeriu, Qt te atende perfeitamente.

Só tente evitar o uso excessivo em toda parte do sistema, tente deixar sua camada de domínio mais enxuta se possível. Senão vc terá um código dominado pelo Qt. Se um dia acontece algo com ele, seu código vai junto..

O Qt tem um puta recurso viciante, o signal e slot..

Qt é a Roda!

Abç,

Rodrigo 

[Gianni]

On Sunday 02 August 2015 20:22:48 Rodrigo Avancini wrote:
[...]

> Senão vc terá um código dominado
> pelo Qt. Se um dia acontece algo com ele, seu código vai junto..

O Qt é LGPL então você sempre vai ter a opção de fazer um fork dele e
pronto... e se por acaso alguma empresa comprar o Qt e fazer ele só fechado, o
pessoal do KDE tem um contrato que diz que eles vão imediatamente poder
liberar o Qt com licença MIT...

Portanto esse risco é praticamente nulo.

[Fellipe Henrique]

2015-08-02 20:16 GMT-03:00 JuciÊ Andrade <oju...@gmail.com>:

 Difícil esse cliente, hein Fellipe?

Cara, nem me diga..

A questão é que para ele(s) tanto faz.. o problema é que eu não tenho como instalar um linux na empresa... e não estou conseguindo achar uma solução... por isso pensei no desktop..

Porque olhe só, meu sistema precisa: Linux, Python,  MariaDB, Redis, memcache e wkhtmltopdf 

Então, não tem como eu simplesmente colocar um Apache no windows pra rodar ele... :(

E quando eu digo "empresa", na maioria das vezes é uma micro-empresa (ou nano-empresa, como queira), que tem 2 computadores no máximo em Rede... então não há como eu colocar um deste computador como servidor Linux... a vezes é apenas 1 computador só.. 

Sim! Eu vivo em uma roça!! rsrrss.. aqui na região 80% das empresas são assim.. não possuem um "servidor"...

Meu sistema, funciona na internet, mas eu conseguiria fazer ele funcionar sem problemas em uma intranet.. mas eu tenho este problema!

Tentei pensar em uma forma de virtualizar uma VM em linux com meu sistema, usando o VirtualBox.. mas eu tenho um problema com isso também: Como fazer o virtualbox iniciar a máquina virtual, quando o usuário "abrir" o Windows dele... entendeu? Porque o cara mal sabe o que é desktop (maioria dos usuários aqui da região é assim mesmo)... quanto mais abrir VirtualBox, e iniciar uma VM...

Então.. estou aberto a sugestões... qualquer coisa me ajuda, pq eu já esgotei meus miolos tentando achar uma solução pra isso....

[Marcelo Geyer]

Mais perigoso que uma licença fechada não existe. Não há como
comparar. Se por ventura o Delphi vier a ser descontinuado, ou se for
comprado por uma empresa que queira simplesmente "matar" o produto,
deixará os desenvolvedores que usam esta tecnologia sem pai, sem mãe,
irmãos e até primos de terceiro grau!!

> --
> Antes de enviar um e-mail para o grupo leia:
> http://www.ccppbrasil.org/wiki/Lista:AntesdePerguntar
> --~--~---------~--~----~------------------------------
> [&] C & C++ Brasil - http://www.ccppbrasil.org/
> Para sair dessa lista, envie um e-mail para
> ccppbrasil-...@googlegroups.com
> Para mais opções, visite http://groups.google.com/group/ccppbrasil
> --~--~---------~--~----~--~-~--~---~----~------------



--

Marcelo E. Geyer
Standard Net Tecnologia e Informação

[Fellipe Henrique]

2015-08-02 20:50 GMT-03:00 Marcelo Geyer <estani...@gmail.com>:

Mais perigoso que uma licença fechada não existe. Não há como
comparar. Se por ventura o Delphi vier a ser descontinuado, ou se for
comprado por uma empresa que queira simplesmente "matar" o produto,
deixará os desenvolvedores que usam esta tecnologia sem pai, sem mãe,
irmãos e até primos de terceiro grau!!

Motivo do qual eu sai do Delphi, e estou tentando não voltar... ainda mais agora, sendo provado que estão incluindo bugs propositais para que as pessoas "assinem" o subscription deles... por isso decidi ir pra Web, usando Python... assim não fico preso a empresa alguma..

Mas um sistema web, tem o problema que eu discuti no email anterior, que até o momento não consegui solucionar...

[Marcelo Geyer]

Há formas de você levantar uma VM quando o Windows for iniciado. Uma busca pela web você encontrará algumas soluções.

--

[Rafael Silva]

Delphi é uma linguagem?

*** smoke bomb -> vanish -> buahahahahahahaha ***

[Rodrigo Madera]

Felipe,

Primeiramente bem-vindo!

Segundo, obrigado pelos esclarescimentos do Delphi. Já ouvi povo falar que continua ativo e povo falar que não. E teu email, junto com o de Shander, me deu uma boa perspectiva.

O Delphi foi sensacional há 15 anos atrás, quando comecei a ver ele de longe (por ter me interessado por C++Builder), e na minha opinião deveria ter ganhado mais premios dos que ganhou pela violenta produtividade.

Mas, direto ao assunto, eu recomendaria você não rescrever nada. Por mais simples que seja teu projeto, aparentemente ele está há vários anos acumulando amadurecimento (pelo que entendi nos teus emails).

C++ não é nada barato. E tarde ou temprano você irá precisar de ajuda. Pesquisa o preço desse povo. Da pra contratar alguns de outras com o preço de um.

Ainda mais se você consegue resolver com VMs. Dai será brincadeira de criança você deixar solucionado o problema.

Já pensou em montar teu ambiente em hospedagem terceirizada e fazer teus clientes usarem internet para usar um servidor? Internet boa é encontrada nos teus clientes?

Se realmente decidir que tem o dinheiro pra investir em uma solução C++, então realmente Qt parece ser uma boa solução por você querer um ambiente desktop. Mas ainda fico curioso se não vale a pena ser em Java, que além de ter profissionais mais baratos tem muita mais oferta de ferramentas, e uma GUI aceitável.

Fraternais saudações,

Madera

[Rodrigo Madera]

Esse tal contrato, tem link dele?

Já vi contratos serem anulados. Ainda mais nos EUA, onde eles são sagrados.

Do ponto de vista legal, não acho problema usar Qt, pois um fork resolveria e à partir dali se corre atrás. Mas ficaria com receio de confiar apenas em um contrato, que uma grande empresa pode vir a lutar contra.

Madera

[Fellipe Henrique]

Olá Rodrigo,

Obrigado pela resposta, meu sistema já se encontra na internet, porém nesse tipo de empresa não é possível usar a internet, porque na cidade quem fornece à internet é a oi, com o velox, e tem vezes que ficam sem internet quase que 2 dias!

Então eles não querem depender da internet, pois se isso acontecer, de ficar sem internet, a empresa para. Ficar sem internet 2 dias já aconteceu, mas não é comum... O que é comum é ficar sem internet por 3 a 4 horas uns 2 dias, e quando a tem internet a velocidade não é lá essas coisas!

Ah! Sim, não é cidade, é roça! Rsrsrs, mas é a realidade das cidades vizinhas..

Abraços!

--
Sent from my iPhone

[Francisco Lopes]

huh? o cara tá reclamando de lentidão do Delphi, imagina lentidão de GUI Java. Até hj eu nunca vi nada de GUIs java que sejam aceitáveis, seja IDE, seja uma programa feito em tal IDE. A única coisa em Java que tem uma gui aceitável com qual lidei é o Android, e naquelas ainda.

[Rodrigo Madera]

2015-08-02 23:23 GMT-03:00 Francisco Lopes <obl...@gmail.com>:

huh? o cara tá reclamando de lentidão do Delphi, imagina lentidão de GUI Java. Até hj eu nunca vi nada de GUIs java que sejam aceitáveis, seja IDE, seja uma programa feito em tal IDE. A única coisa em Java que tem uma gui aceitável com qual lidei é o Android, e naquelas ainda.

Não é tão assim não. Se souber fazer, fica bastante usável e com gráficos adequados. A questão é saber fazer.

Mas dai estamos entrando em terrenos perigosos.

Só acho que C++ não é solução pra tudo, por mais apaixonado que eu seja por ela.

Madera

[Shander Lyrio]

On 08/02/2015 05:48 PM, Fellipe Henrique wrote:
> 1) Multi-plataforma
>
> Não funciona as mil maravilhas que a Embarcadero fala... eu tentei
> usar, porém para isso você deve reescrever praticamente seu produto
> inteiro para usar o "novo" firemonkey, porque se você for usar a VCL
> (biblioteca padrão), não compila a não ser para Windows.. Então temos
> problemas aí: Reescrever praticamente todo o código da VCL pro
> Firemonkey e "confiar" no firemonkey, que é recém criado e cheio de
> bugs.. eu mesmo já reportei diversos para a Embarcadero há 3 anos, e
> minha surpresa? Ainda não foram solucionados..

Não estou nem comentando o que a Embarcadero fala, eu estou falando
das minhas experiências testando novamente o Delphi depois de vários
anos. E o Firemonkey tem funcionado muito bem sim, principalmente no
XE8. Como você disse que o sistema está em Web e você quer reescrever
para desktop, não tem essa de de reescrever nada da VCL, faria o mesmo
se fosse mudar para C++ com Qt. Pode postar o link dos diversos bugs
para eu dar uma olhada, acho estranho não serem corrigidos depois de 3 anos?

> 2) Delphi está "estagnado"
>
> Apesar das pseudo-evoluções o delphi sim está estagnado em alguns
> pontos.. vou citar alguns:
>
> a) Acesso a internet: A melhor forma de se fazer acesso é usando o
> DataSnap, que veem de um componente antigo chamado Indy, que possui um
> problema sério de desempenho e consumo de memória... eu mesmo postei
> um problema sério quanto a isso e sem nenhuma solução.. não conseguia
> colocar 50 máquinas acessando via internet num servidor DataSnap..

DataSnap é a pior forma de se fazer acesso à internet. Sempre foi a
pior e eu nunca vi alguém em sã consciência falar que usou isto em
ambiente de produção sério. A biblioteca Indy é bem antiga, mas tem sido
bem desenvolvida no decorrer dos anos, principalmente depois que começou
a fazer parte do Delphi por padrão, é excelente e muito rápida. Centenas
de componentes Indy fazendo requisições paralelas não fazem nem cócegas
em consumo de memória ou processamento. Mas o DataSnap é lixo, sempre
foi, desde que lançou, nunca vi um case de sucesso que usasse ele.

> b) Consumo WebService: O delphi não fornecia acesso fácil ao consumo
> de WebServices.. problema mais visível no uso dos WS da SEFAZ para
> consumir a NF-e.. problemático.. passei muitos problemas com isso..

O fato de 8 em cada 10 sistemas comerciais que existem hoje serem
feitos em Delphi não corroboram com o que você está dizendo. Consumir
qualquer WebService com Delphi é uma baba.

> c) IDE Super, hyper, extremamente lenta e pesada!!! 4GB de RAM somente
> pra IDE, no mínimo... ;)

Engraçado que eu acho ela extremamente rápida e olha que eu ainda
uso ela num virtualbox já que quase não uso Windows, abri aqui agora um
pequeno projeto de testes que fiz estes dias e a IDE inteira está
consumindo 356MB de memória. Criei vários projetos (Firemonkey e VCL),
coloquei varios componentes e o consumo de memória não passou de 500MB.

> d) Acesso à banco de dados usando modelos.. praticamente não existe..
> é usado uma abstração feita para ser simples e fácil de usar, e
> realmente é.. mas experimente ir no banco de dados e mudar um campo
> VarChar(6) para varchar(8) para ver como o delphi dá pau direto.. em
> todo lugar que você usa esse campo, traduzindo... facilidade de
> manutenção é baixa.. mudança em banco de dados, requer que você no
> mínimo verifique em todos os arquivos o uso deste campo para "refazer
> o dataset"... isso me matava, e foi um dos motivos de praticamente
> querer sumir da frente do Delphi.

Você acessa banco de dados usando os componentes DB? Então você não
quer performance, você quer facilidade e plug em play e isto você não
vai encontrar pronto em lugar nenhum. Ou você programa direito,
codificando, usando o que a linguagem oferece ou você se contenta com os
componentes padrão prontos, se quiser a segunda opção paga-se o preço
para ter acesso ao banco de dados colocando 3 componentes na tela sem
escrever nenhuma linha de código. Sê você utiliza esta abstração simples
e fácil de usar, tem que sentar e chorar onde ela é deficiente, é como
diz o velho ditado: "Se come do meu pão, aguenta o meu rojão".

> 3) Delphi virou um Produto muito lucrativo!
> Ah.. isso não deveria ser um problema, mas é.. e eu comecei a ter
> problemas com ele a partir do momento em que a Embarcadero começou a
> solucionar problemas/bugs importantes e extremamente chatos, nas
> versões novas! Ou seja, sempre deixando um buraco nas versões para ser
> corrigido nas próximas, fazendo você sempre atualizar o produto.. isso
> enche o saco (com o perdão da palavra) principalmente pelo preço que
> se paga pelo produto. E agora, eles praticamente estão "introduzindo"
> bugs propositais para que o usuário faça a inscrição no programa deles [1]

Está seguindo a tendência de todos os softwares fechados que
conheço. Não vender o sistema em si, mas vender uma subscrição de
atualizações por um determinado período. A ferramenta que eu utilizo
para manter meus bancos de dados PostgreSql funciona da mesmíssima
forma, até o Windows vai funcionar assim. Qt não vai te cobrar nada para
utilizá-lo, mas nem de longe você terá as mesmas facilidades do Delphi,
vai ter que escrever código na mão para tudo.

> Isto posto, por isso eu acredito que se não houver uma mudança, o
> Delphi está fadado ao fracasso.. porque só quem compra o delphi, é
> quem possui sistemas antigos e que precisam manter.. porque novos
> softwares, novas empresas.. dificilmente vão usar o Delphi, por conta
> disso tudo que eu estou falando..

Na verdade eu não estou vendo isto. Haja visto o fato de que Object
Pascal tem subido de forma consistente no índice Tiobe. As pessoas tem
voltado a pesquisar por ele, é claro que o índice tiobe não indica "uso
em novos projetos", mas demonstra que o interesse voltou a subir e isto
é graças aos avanços que a Embarcadero tem conseguido.

De qualquer forma, a julgar de tudo o que li em suas postagens, o
que posso te adiantar é que se você espera encontrar no Qt um
desenvolvimento mais suave do que você tinha no Delphi, pode esquecer,
se pensa em ser mais rápido fazer as coisas usando Qt, também pode
esquecer. C++ é uma linguagem para gente grande que não tem medo de
codificar. Os componentes prontos para Qt não passam nem perto do que
existe no Delphi, nem em número, nem em facilidades. Tudo será mais
trabalhoso e mais caro de se fazer em C++ e isto é o preço que se paga
para se ter controle sobre tudo o que o seu código faz. Eu já uso Qt há
alguns bons anos, é muito bom e produtivo (quando comparado com o que se
tem para C++), antes utilizava WxWidgets, mas não se pode comparar ao
que o Delphi faz. Se o Delphi vale o preço que a Embarcadero está
cobrando? não vou entrar nesta discussão, cada um sabe onde seu calo
aperta. Porque eu utilizo C++ com Qt ao invés do Delphi? Porque quase
todos os meus sistemas rodam no Linux, apenas 1 precisou rodar no
Windows (e o Delphi ainda não compila binário para Linux).

Voltando à sua pergunta inicial, "porque escolher C++?"

* C++ te dá mais controle sobre o que o seu sistema faz;
* C++ roda mais rápido se você sabe o que está fazendo;
* C++ consome menos memória se você sabe o que está fazendo;
* É mais fácil portar um programa escrito em C++ para diversas
plataformas;
* Programar em C++ torna você um profissional capaz de programar em
praticamente qualquer dispositivo;

Feito o merchan para C++, agora eu vou te fazer uma pergunta: Já
passou pela sua cabeça utilizar o Python com o qual o seu sistema já é
feito hoje e utilizar uma biblioteca tipo PyQt? Você aproveitaria toda a
regra de negócios que você tem hoje feita em Python, reutilizaria
praticamente todo o seu código e teria o seu sistema desktop com a mesma
interface que teria usando Qt diretamente com C++, é claro que ficaria
um pouco mais lento do que com C++, mas reaproveitar quase todo o seu
código não valeria o preço?

Abraços e boa sorte na sua jornada,

--
Shander Lyrio

[Francisco Lopes]

On Sun, Aug 2, 2015 at 11:40 PM, Shander Lyrio <shande...@gmail.com> wrote:

On 08/02/2015 05:48 PM, Fellipe Henrique wrote:

1) Multi-plataforma Não funciona as mil maravilhas que a Embarcadero fala... eu tentei usar, porém para isso você deve reescrever praticamente seu produto inteiro para usar o "novo" firemonkey, porque se você for usar a VCL (biblioteca padrão), não compila a não ser para Windows.. Então temos problemas aí: Reescrever praticamente todo o código da VCL pro Firemonkey e "confiar" no firemonkey, que é recém criado e cheio de bugs.. eu mesmo já reportei diversos para a Embarcadero há 3 anos, e minha surpresa? Ainda não foram solucionados..

Não estou nem comentando o que a Embarcadero fala, eu estou falando das minhas experiências testando novamente o Delphi depois de vários anos. E o Firemonkey tem funcionado muito bem sim, principalmente no XE8. Como você disse que o sistema está em Web e você quer reescrever para desktop, não tem essa de de reescrever nada da VCL, faria o mesmo se fosse mudar para C++ com Qt. Pode postar o link dos diversos bugs para eu dar uma olhada, acho estranho não serem corrigidos depois de 3 anos?

2) Delphi está "estagnado" Apesar das pseudo-evoluções o delphi sim está estagnado em alguns pontos.. vou citar alguns: a) Acesso a internet: A melhor forma de se fazer acesso é usando o DataSnap, que veem de um componente antigo chamado Indy, que possui um problema sério de desempenho e consumo de memória... eu mesmo postei um problema sério quanto a isso e sem nenhuma solução.. não conseguia colocar 50 máquinas acessando via internet num servidor DataSnap..

DataSnap é a pior forma de se fazer acesso à internet. Sempre foi a pior e eu nunca vi alguém em sã consciência falar que usou isto em ambiente de produção sério. A biblioteca Indy é bem antiga, mas tem sido bem desenvolvida no decorrer dos anos, principalmente depois que começou a fazer parte do Delphi por padrão, é excelente e muito rápida. Centenas de componentes Indy fazendo requisições paralelas não fazem nem cócegas em consumo de memória ou processamento. Mas o DataSnap é lixo, sempre foi, desde que lançou, nunca vi um case de sucesso que usasse ele.

b) Consumo WebService: O delphi não fornecia acesso fácil ao consumo de WebServices.. problema mais visível no uso dos WS da SEFAZ para consumir a NF-e.. problemático.. passei muitos problemas com isso..

O fato de 8 em cada 10 sistemas comerciais que existem hoje serem feitos em Delphi não corroboram com o que você está dizendo. Consumir qualquer WebService com Delphi é uma baba.

c) IDE Super, hyper, extremamente lenta e pesada!!! 4GB de RAM somente pra IDE, no mínimo... ;)

Engraçado que eu acho ela extremamente rápida e olha que eu ainda uso ela num virtualbox já que quase não uso Windows, abri aqui agora um pequeno projeto de testes que fiz estes dias e a IDE inteira está consumindo 356MB de memória. Criei vários projetos (Firemonkey e VCL), coloquei varios componentes e o consumo de memória não passou de 500MB.

d) Acesso à banco de dados usando modelos.. praticamente não existe.. é usado uma abstração feita para ser simples e fácil de usar, e realmente é.. mas experimente ir no banco de dados e mudar um campo VarChar(6) para varchar(8) para ver como o delphi dá pau direto.. em todo lugar que você usa esse campo, traduzindo... facilidade de manutenção é baixa.. mudança em banco de dados, requer que você no mínimo verifique em todos os arquivos o uso deste campo para "refazer o dataset"... isso me matava, e foi um dos motivos de praticamente querer sumir da frente do Delphi.

Você acessa banco de dados usando os componentes DB? Então você não quer performance, você quer facilidade e plug em play e isto você não vai encontrar pronto em lugar nenhum. Ou você programa direito, codificando, usando o que a linguagem oferece ou você se contenta com os componentes padrão prontos, se quiser a segunda opção paga-se o preço para ter acesso ao banco de dados colocando 3 componentes na tela sem escrever nenhuma linha de código. Sê você utiliza esta abstração simples e fácil de usar, tem que sentar e chorar onde ela é deficiente, é como diz o velho ditado: "Se come do meu pão, aguenta o meu rojão".

3) Delphi virou um Produto muito lucrativo! Ah.. isso não deveria ser um problema, mas é.. e eu comecei a ter problemas com ele a partir do momento em que a Embarcadero começou a solucionar problemas/bugs importantes e extremamente chatos, nas versões novas! Ou seja, sempre deixando um buraco nas versões para ser corrigido nas próximas, fazendo você sempre atualizar o produto.. isso enche o saco (com o perdão da palavra) principalmente pelo preço que se paga pelo produto. E agora, eles praticamente estão "introduzindo" bugs propositais para que o usuário faça a inscrição no programa deles [1]

Está seguindo a tendência de todos os softwares fechados que conheço. Não vender o sistema em si, mas vender uma subscrição de atualizações por um determinado período. A ferramenta que eu utilizo para manter meus bancos de dados PostgreSql funciona da mesmíssima forma, até o Windows vai funcionar assim. Qt não vai te cobrar nada para utilizá-lo, mas nem de longe você terá as mesmas facilidades do Delphi, vai ter que escrever código na mão para tudo.

>>> Parei de ler aqui.

Isto posto, por isso eu acredito que se não houver uma mudança, o Delphi está fadado ao fracasso.. porque só quem compra o delphi, é quem possui sistemas antigos e que precisam manter.. porque novos softwares, novas empresas.. dificilmente vão usar o Delphi, por conta disso tudo que eu estou falando..

Na verdade eu não estou vendo isto. Haja visto o fato de que Object Pascal tem subido de forma consistente no índice Tiobe. As pessoas tem voltado a pesquisar por ele, é claro que o índice tiobe não indica "uso em novos projetos", mas demonstra que o interesse voltou a subir e isto é graças aos avanços que a Embarcadero tem conseguido. De qualquer forma, a julgar de tudo o que li em suas postagens, o que posso te adiantar é que se você espera encontrar no Qt um desenvolvimento mais suave do que você tinha no Delphi, pode esquecer, se pensa em ser mais rápido fazer as coisas usando Qt, também pode esquecer. C++ é uma linguagem para gente grande que não tem medo de codificar. Os componentes prontos para Qt não passam nem perto do que existe no Delphi, nem em número, nem em facilidades. Tudo será mais trabalhoso e mais caro de se fazer em C++ e isto é o preço que se paga para se ter controle sobre tudo o que o seu código faz. Eu já uso Qt há alguns bons anos, é muito bom e produtivo (quando comparado com o que se tem para C++), antes utilizava WxWidgets, mas não se pode comparar ao que o Delphi faz. Se o Delphi vale o preço que a Embarcadero está cobrando? não vou entrar nesta discussão, cada um sabe onde seu calo aperta. Porque eu utilizo C++ com Qt ao invés do Delphi? Porque quase todos os meus sistemas rodam no Linux, apenas 1 precisou rodar no Windows (e o Delphi ainda não compila binário para Linux). Voltando à sua pergunta inicial, "porque escolher C++?" * C++ te dá mais controle sobre o que o seu sistema faz; * C++ roda mais rápido se você sabe o que está fazendo; * C++ consome menos memória se você sabe o que está fazendo; * É mais fácil portar um programa escrito em C++ para diversas plataformas; * Programar em C++ torna você um profissional capaz de programar em praticamente qualquer dispositivo; Feito o merchan para C++, agora eu vou te fazer uma pergunta: Já passou pela sua cabeça utilizar o Python com o qual o seu sistema já é feito hoje e utilizar uma biblioteca tipo PyQt? Você aproveitaria toda a regra de negócios que você tem hoje feita em Python, reutilizaria praticamente todo o seu código e teria o seu sistema desktop com a mesma interface que teria usando Qt diretamente com C++, é claro que ficaria um pouco mais lento do que com C++, mas reaproveitar quase todo o seu código não valeria o preço? Abraços e boa sorte na sua jornada, -- Shander Lyrio

[Francisco Lopes]

Sim eh verdade, mas o pessoal do Qt ja a uns tempos nem foca tanto em promover C++ como meio pra lidar com GUI, apesar de ao mesmo tempo nao depreciar. Fora o oficial QML, js, etc, tem os pyQt e xQt da vida se for do interesse.

Madera

[Gianni]

On Sunday 02 August 2015 21:44:59 Rodrigo Madera wrote:
> 2015-08-02 20:40 GMT-03:00 Gianni <nasus....@gmail.com>:
> > On Sunday 02 August 2015 20:22:48 Rodrigo Avancini wrote:
> > [...]
> >
> > > Senão vc terá um código dominado
> > > pelo Qt. Se um dia acontece algo com ele, seu código vai junto..
> >
> > O Qt é LGPL então você sempre vai ter a opção de fazer um fork dele e
> > pronto... e se por acaso alguma empresa comprar o Qt e fazer ele só
> > fechado, o
> > pessoal do KDE tem um contrato que diz que eles vão imediatamente poder
> > liberar o Qt com licença MIT...
> >
> > Portanto esse risco é praticamente nulo.
>
> Esse tal contrato, tem link dele?

https://www.kde.org/community/whatiskde/KDE_CommitmentLetter_120917.pdf

> Já vi contratos serem anulados. Ainda mais nos EUA, onde eles são sagrados.
>
> Do ponto de vista legal, não acho problema usar Qt, pois um fork resolveria
> e à partir dali se corre atrás. Mas ficaria com receio de confiar apenas em
> um contrato, que uma grande empresa pode vir a lutar contra.

Não precisa confiar... isso é só um + pois tem o LGPL que resolve. O pessoal
do KDE com certeza iria fazer um fork da versão LGPL para eles, pois o KDE
todo é LGPL/GPL e depende fortemente do Qt.

[Josue Andrade Gomes]

Em sábado, 1 de agosto de 2015 15:23:08 UTC-3, Fellipe Henrique escreveu:

Bom dia amigos,

Primeiramente me desculpem pelo post, não quero aqui criar flames.. é que só quero uma opinião de quem é do ramo do C/C++..

Hoje, estou querendo iniciar um projeto para sistema desktop, sim.. desktop.. já tenho um sistema Web, mas alguns clientes não querem usar via web, e sim na empresa.. e as vezes (quase sempre) não há como instalar meu sistema web na empresa por alguns motivos, tais como: a empresa não pode dispor de um servidor linux (que é necessário em meu sistema web) entre outros..

Alguns sistemas meus foram feitos em Delphi, o que é bastante  razoável, sendo que para desenvolver desktop nele é beem fácil.. mas tenho alguns problemas com ele: 1) a cada ano uma nova versão com novos problemas. 2) Ide super hyper pesada 3) linguagem defasada. 4) Sem acesso fácil à internet, seja por meio de webservices ou outra coisa...

Então queria ver com os amigos, o que levaria a empresa a trocar o desenvolvimento Delphi pelo C++ (estamos pensando usar o Qt), sendo que teria quer ter ao mínimo essas necessidades: 1) Ser compilável e portável para Windows, MacOs... 2) Facilidade de acesso a internet (consumir webservices e etc).. 3) Facilidade de acessos as chaves de criptografia (certificados).  4) Nao possuir visual "antiquado" igual win32...

Acredito que seria isso amigos, como não uso o C++ profissionalmente, não saberia responder e ter embasamento para "peitar" o delphi nesse quesito..

Conto com a ajuda dos amigos.. abraços e obrigado desde já...

Se você tem um experitise em Delphi já considerou o Lazarus (baseado no FreePascal)?

É uma IDE muito leve, multiplataforma (Linux, Windows, Mac OS X), com muitos componentes prontos e uma comunidade ativa.

http://www.lazarus-ide.org/

 

[Fellipe Henrique]

2015-08-03 10:05 GMT-03:00 Josue Andrade Gomes <josue...@gmail.com>:

Se você tem um experitise em Delphi já considerou o Lazarus (baseado no FreePascal)?

É uma IDE muito leve, multiplataforma (Linux, Windows, Mac OS X), com muitos componentes prontos e uma comunidade ativa.

Sim, já considerei, porém ainda não está no ponto de se apostar o produto de uma empresa nele... algumas coisas não batem legal, como por exemplo, herança de telas...

[angelo]

Bom dia,

aproveitando o gancho da conversa e essa tendencia de se criar sistemas que rodam na nuvem (a la saas )

Para contornar essa situação de lentidão do cliente x internet ruim ou boa.. O pode fazer também é colocar a aplicacao rodando em servidor de Terminal Services, em algum datacenter, ou um amazon ou azure da vida.  

É a tendencia que ta em moda... remoteapps

"E como eu pago o custo disso ?"  Bom, a sua carteira de clientes, você que já fechou varios contratos, eles estão pagando o mensal para usar a aplicacao que o negócio deles depende muito... isso deve ser usada para cobrir os custos.

E digo mais, será bem menos estressante que colocar app numa maquina e banco de dados em um servidor fora da rede e com tempo de resposta variavel. Dentro do ambiente de terminal, a aplicacao e o banco estao na mesma rede, nao tem problemas de latencia pra enfrentar.

Ou focar na web, sair de app e criar a solucao na web (pagina) se assim o negócio permitir. No cliente se possivel, só colocar ferramenta de integracao.. (base dele x base sua, ou xmls..)

[]s angelo

[Rodrigo Strauss]

Se você precisa de algo multiplataforma, Qt com C++ me parece a melhor opção.

Se é só Windows, sugiro que você teste pessoalmente C#/Windows Forms e C++/Qt e veja o que melhor te atende em termos de produtividade, componentes de terceiros, velocidade de runtime e consumo de memória.

Rodrigo Strauss
http://www.1bit.com.br
@rodrigostrauss

[Djalma Rosa dos Santos Filho]

Rodrigo, 

Desculpa a curiosidade, mas por que você não indicou o Python para GUI?

Abraço,

Djalma

[Rodrigo Strauss]

Eu acho que para GUI o ideal é ter um ambiente integrado - uma IDE - com designer, compilador, debugger e tudo mais. Não conheço nada em Python que ofereça a experiência do Visual Studio ou do Qt Creator.

Sempre dá pra fazer UI na mão, mas eu prefiro algo prático. E Windows Forms é a coisa mais prática que eu conheço. A API do Qt é melhor e mais redonda, mas o ferramental do C# é fenomenal. UI não é alta performance, não é rocket science. A linguagem mais produtiva geralmente resolve melhor.

Nunca usei Python para UI porque nunca senti necessidade. No entanto, para web só uso Python, mais especificamente web2py.

Rodrigo Strauss
http://www.1bit.com.br
@rodrigostrauss

[Lucas Nunes]

Sobre o wxWidgets, atualmente ele faz várias coisas que o Qt faz.

E não acho que o resultado fica "feio" ele utiliza a API nativa do SO, então a aparência vai ser a mesma padrão do SO.

É até uma vantagem isso. O único problema é o estilo de programação dele que é meio chatinho.

Mas, tem algumas ferramentas que ajudam (wxCrafter, CodeLite).

[Djalma Rosa dos Santos Filho]

Pra falar a verdade, eu também estou com um problema parecido com esse do Fellipe. No meu caso, é um sistema muito antigo que eu peguei escrito em Delphi 7 para manutenção, uma versão do ano de 2002 com muito menos recursos do que o atual XE. Fazia mais de 14 anos que não programava em Delphi, lembra aquele filme "A Volta dos Mortos Vivos", mas estou encarando a situação como uma oportunidade de negócio.

Tenho conseguido compensar essa falta de recursos da linguagem com interoperabilidade, escrevendo DLL COM no Visual C++ e importando no Delphi, inclusive para a dificuldade que foi mencionada de acesso à internet / web services.

O cliente está interessado em uma atualização tecnológica, foi cogitada a migração para o Delphi XE8, mas acho que não compensa, vou inclusive usar como argumento as decepções que aqui foram expostas, eu já desconfiava que não compensaria, agora fico ainda mais certo disso com a opinião de quem já usa a versão mais nova. Acho que vai ser muita dor de cabeça fazer a migração para o XE para apenas eliminar o BDE, compilar para 64 bits e ter uma biblioteca de programação paralela (que não sei se vou usar), e, no final, continuar amarrado a uma tecnologia proprietária e cara.

Para escolher uma outra linguagem, como programador eu me sinto naturalmente tentado a ir para o C++ que é a linguagem que eu mais gosto e domino. Eu também sou fã do QT e concordo com o Strauss que ele seja mesmo bastante completo, até parece aquela propaganda do Posto Ipiranga, onde você encontra todos os serviços e produtos em um só lugar. Mas, do ponto de vista do negócio, a dificuldade de encontrar profissionais de QT no mercado, como também já foi mencionado, na hora de montar uma equipe pode pesar e aumentar bastante o custo de desenvolvimento.

Então, estou mesmo chegando à conclusão que o meu +1 pode ir mesmo para o C#  pela popularidade, praticidade e facilidade de aprender. Inclusive, não sei se é verdade, mas, nos primórdios do .NET se falava que a Microsoft contratou a equipe da Borland que fez o Delphi para projetar o Windows Forms, lenda ou não, parece haver semelhanças.

Por fim, acredito que no requisito portabilidade parece muito positiva a recente sinalização de mudança da Microsoft, que, no ano passado, anunciou e disponibilizou no github o .NET como opensource e multiplataforma, mesmo que ainda seja apenas a stack server. Lembrando que, mesmo não estando incluído nessa iniciativa o Windows Forms, ainda assim, há como portar a aplicação Desktop para Linux e OSX com o Mono, AFAIK.

[Francisco Lopes]

Concordo, ia falar a mesma coisa, se a sincronia do nome do botao com o metodo eh algo preocupante, e o numero de programadores, melhor opcao eh C# mesmo (ugh), melhor que java inclusive, imo.

Sim, o designer principal da linguagem C# era o designer (um dos?) do Delphi. Hans alguma coisa.

[]s

[Francisco Lopes]

On Mon, Aug 3, 2015 at 9:35 PM, Francisco Lopes <obl...@gmail.com> wrote:

On Mon, Aug 3, 2015 at 7:22 PM, Djalma Rosa dos Santos Filho <drsant...@gmail.com> wrote:

Pra falar a verdade, eu também estou com um problema parecido com esse do Fellipe. No meu caso, é um sistema muito antigo que eu peguei escrito em Delphi 7 para manutenção, uma versão do ano de 2002 com muito menos recursos do que o atual XE. Fazia mais de 14 anos que não programava em Delphi, lembra aquele filme "A Volta dos Mortos Vivos", mas estou encarando a situação como uma oportunidade de negócio.

Tenho conseguido compensar essa falta de recursos da linguagem com interoperabilidade, escrevendo DLL COM no Visual C++ e importando no Delphi, inclusive para a dificuldade que foi mencionada de acesso à internet / web services.

O cliente está interessado em uma atualização tecnológica, foi cogitada a migração para o Delphi XE8, mas acho que não compensa, vou inclusive usar como argumento as decepções que aqui foram expostas, eu já desconfiava que não compensaria, agora fico ainda mais certo disso com a opinião de quem já usa a versão mais nova. Acho que vai ser muita dor de cabeça fazer a migração para o XE para apenas eliminar o BDE, compilar para 64 bits e ter uma biblioteca de programação paralela (que não sei se vou usar), e, no final, continuar amarrado a uma tecnologia proprietária e cara.

Para escolher uma outra linguagem, como programador eu me sinto naturalmente tentado a ir para o C++ que é a linguagem que eu mais gosto e domino. Eu também sou fã do QT e concordo com o Strauss que ele seja mesmo bastante completo, até parece aquela propaganda do Posto Ipiranga, onde você encontra todos os serviços e produtos em um só lugar. Mas, do ponto de vista do negócio, a dificuldade de encontrar profissionais de QT no mercado, como também já foi mencionado, na hora de montar uma equipe pode pesar e aumentar bastante o custo de desenvolvimento.

Então, estou mesmo chegando à conclusão que o meu +1 pode ir mesmo para o C#  pela popularidade, praticidade e facilidade de aprender. Inclusive, não sei se é verdade, mas, nos primórdios do .NET se falava que a Microsoft contratou a equipe da Borland que fez o Delphi para projetar o Windows Forms, lenda ou não, parece haver semelhanças.

Por fim, acredito que no requisito portabilidade parece muito positiva a recente sinalização de mudança da Microsoft, que, no ano passado, anunciou e disponibilizou no github o .NET como opensource e multiplataforma, mesmo que ainda seja apenas a stack server. Lembrando que, mesmo não estando incluído nessa iniciativa o Windows Forms, ainda assim, há como portar a aplicação Desktop para Linux e OSX com o Mono, AFAIK.

Concordo, ia falar a mesma coisa, se a sincronia do nome do botao com o metodo eh algo preocupante, e o numero de programadores, melhor opcao eh C# mesmo (ugh), melhor que java inclusive, imo.

Sim, o designer principal da linguagem C# era o designer (um dos?) do Delphi. Hans alguma coisa.

Inclusive, eh a impressao que tenho, Delphi tambem nao tem como ponto forte numero de programadores disponiveis por aqui, ainda mais dessas versoes novas.

[JuciÊ Andrade]

Fellipe, já que você pediu ideias, há ainda outra maneira de rodar Linux no Windows, sem usar VMs. É usando colinux. Usei durante anos e atendia bem pro que eu precisava.

 

Esse projeto já tem uns 10 anos. O último commit foi em dezembro.

http://sourceforge.net/projects/colinux/

 

O colinux é um serviço Windows. Assim, quando você liga a máquina, sobe o Windows e também o Linux. Ficam os dois rodando juntos, ao mesmo tempo. O melhor de tudo: é leve. Se você não disser pra ninguém que tem um linux rodando ali, não dá pra perceber.

 

Eu lembro que quando eu usei tinha a limitação de um core apenas. Ou seja, o serviço que rodava o Linux não aproveitava todos os cores da máquina. Não sei se ainda é assim. Também não sei se isso chega a ser um problema para a sua aplicação. Dá uma olhada.

 

Um abraço.

 

[Francisco Lopes]

On Mon, Aug 3, 2015 at 9:35 PM, Francisco Lopes <obl...@gmail.com> wrote:

On Mon, Aug 3, 2015 at 7:22 PM, Djalma Rosa dos Santos Filho <drsant...@gmail.com> wrote:

Pra falar a verdade, eu também estou com um problema parecido com esse do Fellipe. No meu caso, é um sistema muito antigo que eu peguei escrito em Delphi 7 para manutenção, uma versão do ano de 2002 com muito menos recursos do que o atual XE. Fazia mais de 14 anos que não programava em Delphi, lembra aquele filme "A Volta dos Mortos Vivos", mas estou encarando a situação como uma oportunidade de negócio.

Tenho conseguido compensar essa falta de recursos da linguagem com interoperabilidade, escrevendo DLL COM no Visual C++ e importando no Delphi, inclusive para a dificuldade que foi mencionada de acesso à internet / web services.

O cliente está interessado em uma atualização tecnológica, foi cogitada a migração para o Delphi XE8, mas acho que não compensa, vou inclusive usar como argumento as decepções que aqui foram expostas, eu já desconfiava que não compensaria, agora fico ainda mais certo disso com a opinião de quem já usa a versão mais nova. Acho que vai ser muita dor de cabeça fazer a migração para o XE para apenas eliminar o BDE, compilar para 64 bits e ter uma biblioteca de programação paralela (que não sei se vou usar), e, no final, continuar amarrado a uma tecnologia proprietária e cara.

Para escolher uma outra linguagem, como programador eu me sinto naturalmente tentado a ir para o C++ que é a linguagem que eu mais gosto e domino. Eu também sou fã do QT e concordo com o Strauss que ele seja mesmo bastante completo, até parece aquela propaganda do Posto Ipiranga, onde você encontra todos os serviços e produtos em um só lugar. Mas, do ponto de vista do negócio, a dificuldade de encontrar profissionais de QT no mercado, como também já foi mencionado, na hora de montar uma equipe pode pesar e aumentar bastante o custo de desenvolvimento.

Então, estou mesmo chegando à conclusão que o meu +1 pode ir mesmo para o C#  pela popularidade, praticidade e facilidade de aprender. Inclusive, não sei se é verdade, mas, nos primórdios do .NET se falava que a Microsoft contratou a equipe da Borland que fez o Delphi para projetar o Windows Forms, lenda ou não, parece haver semelhanças.

Por fim, acredito que no requisito portabilidade parece muito positiva a recente sinalização de mudança da Microsoft, que, no ano passado, anunciou e disponibilizou no github o .NET como opensource e multiplataforma, mesmo que ainda seja apenas a stack server. Lembrando que, mesmo não estando incluído nessa iniciativa o Windows Forms, ainda assim, há como portar a aplicação Desktop para Linux e OSX com o Mono, AFAIK.

Concordo, ia falar a mesma coisa, se a sincronia do nome do botao com o metodo eh algo preocupante, e o numero de programadores, melhor opcao eh C# mesmo (ugh), melhor que java inclusive, imo.

Sim, o designer principal da linguagem C# era o designer (um dos?) do Delphi. Hans alguma coisa.

Desculpa, "Anders alguma coisa". Anders Hejlsberg.

[Thiago Adams]

Acho que o Forms do C# assim como o WPF estão com os dias contados. Se é que já não podemos afirmar isso que são tecnologias legadas e serão feitos apenas correções. 

A MS não quer ter bases de códigos separados e tecnologias separadas.

Eu diria, baseado no movimento que está sendo feito nos celulares e nos aplicativos para windows runtime e no proprio asp 5, é que a única coisa que vai sobrar do NET é a linguagem em si e partes do NET framework, e tudo vai compilar nativo.

Como já disse várias vezes, o mundo vai voltar como era antes, na época do VB.

O windows RT é o novo VB / NET.

[Wander Lairson Costa]

O Windows RT então veio pra substituir o .NET e não a Win32?

--
Best Regards,
Wander Lairson Costa

[Thiago Adams]

Primeiramente eu acho que o windows RT veio para acabar com o problema interno da MS de ter vários times separados fazendo código similar. 

O NET (tradicional) claramente foi abandonado para desenvolvimento mobile. 

Ao invés dele agora tem o windows rt e o C# que compila nativo, assim como tem um C++ CLI.

Essa mudança e unificação consumiu anos de energia da MS e tem a sua conclusão agora com o windows 10.

A pergunta o que vai acontecer com o desktop NET tradicional? 

Vai continuar o problema de ter mais de uma tecnologia? Adianta ter o xaml do windows rt e mais o do NET? 

A minha resposta é claro que não, alguma coisa vai ter que acontecer no desktop NET tradicional NET, só que eles não tiveram tempo p isso ainda.

Os passos tem que ser dados um de cada vez. A novidade maior do windows 10 é que diminuiu a diferença dos apps desktop tradicionais para os do windows rt, ja que agora, ambos rodam janelados.

Na minha opinião a diferença teria que ser praticamente irreconhecível mas não é. Foi um erro absurdo do windows 8 e disse isso desde o primeiro dia.

Enquanto isso... o velho e seguro win32 para desktop vai bem.

Se o desktop tradicional vai ser substituído pelos aplicativos windows RT? Acho que é bom ficar de olho no office pois ele é que geralmente puxa as tendencias no desktop.

Eu não sinto firmeza nenhuma estes aplicativos windows RT. 

[P.]

Em terça-feira, 4 de agosto de 2015 10:09:04 UTC-3, Thiago Adams escreveu:

 

Enquanto isso... o velho e seguro win32 para desktop vai bem.

Se o desktop tradicional vai ser substituído pelos aplicativos windows RT? Acho que é bom ficar de olho no office pois ele é que geralmente puxa as tendencias no desktop.

Eu não sinto firmeza nenhuma estes aplicativos windows RT. 

A API de sistema win32 não vai sumir do Windows no nosso tempo de vida, com certeza.
Agora, programar para o sistema de janelas do Windows é um pesadelo.
Eu não iniciaria um novo projeto de aplicação interativa usando esse sistema nem que me pagasse....
hm.
aí tem que ver
P.

[Marcos Roberto]

Realmente programar "a la petzold" é muito difícil, ainda mais para quem já experimentou coisas como GTK, Qt e até FLTK. Ver aquele código enorme para criar uma janela com coisas estranhas é muito difícil. 

--

[Thiago Adams]

As vezes a IDE/Framework/Linguagem dos sonhos gera um pesadelo de aplicativo. 

E outras vezes o pesadelo de IDE/Framework/Linguagem gera o aplicativo dos sonhos.

Qual dos pesadelos é o menos pior?

Até o momento nenhum cliente me pediu para ver se o código era bonito e fácil de fazer.

Por outro lado, toda vez que houver um produto concorrente eu vou perguntar "Qual micro ele exige? Quanta memória ele consome? Quanto tempo demora para abrir/usar? Quanto fácil é o download e instalação e atualização?  que são fatores muito influenciados pela tecnologia usada.

Agora para falar do Java, por exemplo,  sinceramente eu espero que com os novos browsers nunca mais nenhum site me peça para atualizar o java.

[Thiago Adams]

Uma coisa que influência na qualidade final x velocidade de desenvolver é se é um produto para durar 10 anos, ou se é um serviço.

E também que tipo de concorrência se enfrenta.

Um exemplo de uma bela concorrência atual são os browsers e engine de javascript. No lado do server, azure x amazon e outros com serviços cloud.

Prestem atenção na tecnologia usada nestes softwares de alta concorrência por qualidade.

[Rodrigo Madera]

Muito interessante a discussão como um todo. Estou tendo uma visão diferente dos movimentos da Microsoft com esses inputs.

Porém, gostaria só de comentar uma pequena coisa:

2015-08-04 11:00 GMT-03:00 Thiago Adams <thiago...@gmail.com>:

Até o momento nenhum cliente me pediu para ver se o código era bonito e fácil de fazer.

No caso, pra mim, já. E não somente isso, senão que tão fácil era um iniciante começar a dar manutenção, que tão fácil seria extender ele, e como fazer as coisas com o mínimo possível de linhas.

O código que escrevemos uma hora ou outra será mantido por outros. A não ser que seja um projeto pessoal e descartável.

A legibilidade e simplicidade do código é muito importante se o projeto é sério. E em código simples não tem lugar pra bug se esconder.

Madera

[Thiago Adams]

Tem outra coisa também é quem faz lib. O produto final é código.

Mas voltando a questão do código em si,  a qualidade de um código pode ser definida por alguns critérios. 

É fácil eu dizer que gosto de código simples, limpo, de fácil manutenção, sem acoplamento e coeso. Dá para dizer "código bonito" que é mais subjetivo ainda.

Mas tudo é muito subjetivo. 

Tem gente que pode achar um código cheio de templates bonito, outros um codigo estilo java OOP bonito. Outro acham C horrível, javascript horrível etc.

[Rodrigo Madera]

Thiago,

Os *gostos* de cada um pouco valem.

As perguntas são bem diretas e definidas: Fácil de manter? Iniciante consegue manter?

Estou falando de todo o espectro, seja lib ou aplicação ou o que for.

Se um zé-ruela abaixo da média consegue manter, é código de fácil manutenção. Os detalhes complexos (como a TMP) tem que ficar escondida pros natos mexerem.

Madera

[Thiago Adams]

E como a gente tira da subjetividade para a seguinte afirmação?

É fácil de manter. 

A minha resposta para isso é conhecer as pessoas, sabendo o que cada um já fez ou uma simples afirmação  "já passei por isso" ajuda estabelecer uma comunicação aonde mesmo falando algo genérico ( é quase como livro de auto ajuda) de alguma forma a pessoa já viveu aquilo na prática e vai entender a mensagem sobre uma questão de design de código e se pode estabelecer um critério em comum do que é ruim ou bom.

Uma outra expressão que gosto muito é "macaco velho". É um tipo de lição que já se aprendeu, que já se viu muitas vezes. 

É como no desenho do carros o  Doc Hudson x Relâmpago McQueen correndo na terra. :)

[Rodrigo Madera]

Você precisa usar a distribuição Gaussiana pra isso. A famosa média.

Se você recrutou bem, poderá saber o nível to teu time. Não é tão dificil assim.

Madera

[Thiago Adams]

Ainda sobre a questão do que é fácil...

Acho que muitos/todos concordam que fazer "script" é mais fácil do que programar.

O que eu quero dizer com "fazer script"?

Fazer um "script" é chamar código de terceiros que esta preparado para fazer uma tarefa e vai responder apropriadamente para cada pedido que não faça sentido. O código de terceiros é feito de tal forma que o "script" é restrito e simples. 

Exemplo..

Uma coisa é implementar uma classe que envia e-mails através de um protocolo smtp.

Outra coisa é pegar uma classe "SmtpClient" e colocar destinatário, assunto e corpo da mensagem e chamar "Send". Este segundo caso é que eu chamo fazer um script.

Nos dias de hoje com stack overflow e "script" se faz muita coisa e essa é a massa de programadores.

[Rodrigo Madera]

2015-08-04 16:33 GMT-03:00 Thiago Adams <thiago...@gmail.com>:

Nos dias de hoje com stack overflow e "script" se faz muita coisa e essa é a massa de programadores.

Perfeito. Agora que temos um parâmetro estabelecido, te pergunto:

É fácil de manter?

;-)

Madera

[Alexandre Riveira]

Aproveitando esse ganho. Manter também vai contar as atualizações das bibliotecas exemplo o Qt. Pergunto alguém teve problema para portar qt 4 => qt 5. Foi dificil ? Porque se acontecer de você ter que reescrever tudo quando troca a versão ai lascou !


Alexandre Riveira

[Bruno Sanches]

Você precisa usar a distribuição Gaussiana pra isso. A famosa média.

Se você recrutou bem, poderá saber o nível to teu time. Não é tão dificil assim.

Mexicano,

acho que se recrutar bem fosse algo simples, não teríamos tantos artigos, discussões, etc sobre contratação. Como é o caso do Joel, Microsoft, google, facebook, etc. Contratar bem não é algo simples, o que torna todo o resto difícil na minha opinião.

T+

[Alex Queiroz]

2015-08-04 22:03 GMT+02:00 Alexandre Riveira <alex...@objectdata.com.br>:
> Aproveitando esse ganho. Manter também vai contar as atualizações das
> bibliotecas exemplo o Qt. Pergunto alguém teve problema para portar qt 4 =>
> qt 5. Foi dificil ? Porque se acontecer de você ter que reescrever tudo
> quando troca a versão ai lascou !
>

Quando uma versão nova é lançada a anterior não para automaticamente
de funcionar.

--
-alex
http://unendli.ch/

[Alexandre Riveira]

Ok, mas portar o seu aplicativo para essa nova versão como é ?

Alexandre Riveira

[Rodrigo Madera]

Adoraria que na prática fosse assim. Mas pode acontecer sim.

Tive que rescrever muita coisa pra portar meu software que usa OpenCV do 4.8 pro Qt 5.

Madera

[Rodrigo Madera]

2015-08-04 17:21 GMT-03:00 Bruno Sanches <bcsa...@gmail.com>:

Mexicano,

acho que se recrutar bem fosse algo simples, não teríamos tantos artigos, discussões, etc sobre contratação. Como é o caso do Joel, Microsoft, google, facebook, etc. Contratar bem não é algo simples, o que torna todo o resto difícil na minha opinião.

Sim sim. Concordo.

O que eu quero dizer é: você sabe QUEM está na tua equipe. Então se na prova o cara mostrou conhecimento 60% de uma prova (por exemplo), você sabe o que esperar dele. Se o cara corrigiu tua prova, você sabe bem os desafios que ele poderá tocar.

Faz sentido?

Madera

[Marcelo Zimbres]

Eu entendo o Thiago, quando ele fala sobre a subjetividade da qualidade do código e o Madeira, quando diz que dá sim pra definir a qualidade. Mas eu entro com um terceiro ponto de vista. Eu atualmente acho que código é praticamente secundário com respeito a qualidade do software. Você pode seguir a risca o Scott Meyers, Sutter etc e ainda assim errar gravemente nos algoritmos e estruturas de dados que usa. Aí seu software tem uma cara linda pra qualquer critério moderno mas é uma catástrofe nos quesitos básicos. Uma pequena lista do que me preocupa atualmente

1) Estruturas de dados corretas?
2) Quão fragmentados estão seus dados na memória? Tem localidade de cache? Performance se mantém constante durante a execução do programa?
3) Algoritmo correto? Quanto você gasta de CPU?
4) Quanto de memória você usa? Isso é o mínimo? Não está desperdiçando?

O usuário em geral percebe primeiro esses requisitos primeiro.

Uma vez que eles estejam cumpridos, aí sim faz sentido se preocupar com código em sí.

Marcelo

[angelo]

Thiago,

Isso nao depende só do browser... Mas de quem teve a idéia de  usar o Java no browser.. dentro da aplicacao..

[Rodrigo Madera]

2015-08-04 17:39 GMT-03:00 Marcelo Zimbres <mzim...@gmail.com>:

Eu entendo o Thiago, quando ele fala sobre a subjetividade da qualidade do código e o Madeira, quando diz que dá sim pra definir a qualidade. Mas eu entro com um terceiro ponto de vista. Eu atualmente acho que código é praticamente secundário com respeito a qualidade do software. Você pode seguir a risca o Scott Meyers, Sutter etc e ainda assim errar gravemente nos algoritmos e estruturas de dados que usa. Aí seu software tem uma cara linda pra qualquer critério moderno mas é uma catástrofe nos quesitos básicos. Uma pequena lista do que me preocupa atualmente

1) Estruturas de dados corretas?
2) Quão fragmentados estão seus dados na memória? Tem localidade de cache? Performance se mantém constante durante a execução do programa?
3) Algoritmo correto? Quanto você gasta de CPU?
4) Quanto de memória você usa? Isso é o mínimo? Não está desperdiçando?

Exatamente!! Sensacional colocação!

Sensacional colocação. E eu vejo que iniciantes não tem essa noção. Até os caras que nasceram com o dom mas ainda estão em processo de lapidação não tem essa noção.

Como diria o grande Linus: "Dane-se o código. Me mostra as estruturas de dados que eu te digo se está certo".

Queria um real por cada uso inadequado de containers, por exemplo. Sem mencionar os algoritmos.

Como disse Thiago, nossa indústria está cheia de script kiddies, sim. Mas vamos aproveitar e "tirar proveito" deles traduzindo as complexidades em pedaços administráveis por eles, pra nos ajudarem.

Madera

[Rodrigo Madera]

Complemento: Um debate polêmico [1] sobre a fala do Linus que mencionei. Como sempre, polêmico.

Madera

[1] http://programmers.stackexchange.com/questions/163185/torvalds-quote-about-good-programmer

[Rafael Silva]

Quer recrutar bem? Faça você mesmo.

RH não sabe nada, infelizmente. RH na verdade afasta muitos candidatos bons.

Att.

[Rafael Silva]

*Nada de programação.

Faltou esse adendo.

[Rodrigo Strauss]

Djalma, me parece que é uma aplicação com banco de dados. Janelas + banco de dados é algo que funciona muito bem em C#. Do ponto de vista de negócios, ainda mais com coisas vindo de Delphi, usar C# faz mais sentido. Mais profissionais e profissionais acostumados com esse tipo de aplicação e zilhões de componentes de terceiros, sem falar no Stack Overflow, empresas disponíveis com essa expertise, drivers de banco de dados melhores, etc. LINQ é algo mágico e extremamente produtivo. WinForms é Win32 para .NET. Eu acho que eu morro antes do Win32.

Rodrigo Strauss
http://www.1bit.com.br
@rodrigostrauss

[Djalma Rosa dos Santos Filho]

Exatamente, Strauss. Arquitetura Cliente/Servidor Delphi + Oracle e com muitas regras de negócio relativamente complexas no PL/SQL.

O momento é de apagar incêndio, mas, acredito que vai chegar o momento do redesign da arquitetura e da escolha de novas tecnologias, inclusive o banco de dados pode mudar para reduzir custos com licença, estou pensando no PostgreSql, até mesmo pela semelhança com o Oracle e a facilidade de migração.

Eu concordo com o seu ponto de vista e torço muito pela sua longevidade, mas, com tantas mudanças no Windows, por que você tem tanta certeza não vai acontecer com o WinForms o mesmo que aconteceu com o VB6?

Djalma

[Rodrigo Strauss]

Porque a linguagem VB6 morreu. Winforms = Win32. O Office é Win32. O Chrome é Win32. Tudo é Win32. O Windows Explorer é Win32. A API do Windows 8 e 10 é COM, que é bem suportado pelo C#. E quando você precisar migrar a migração em C# será muito mais fácil, já que desenhar telinha é um uso muito comum em C#. 

Rodrigo Strauss
http://www.1bit.com.br
@rodrigostrauss

[Thiago Adams]

2015-08-05 13:05 GMT-03:00 Rodrigo Strauss <rod...@1bit.com.br>:

Porque a linguagem VB6 morreu. Winforms = Win32. O Office é Win32. O Chrome é Win32. Tudo é Win32. O Windows Explorer é Win32. A API do Windows 8 e 10 é COM, que é bem suportado pelo C#. E quando você precisar migrar a migração em C# será muito mais fácil, já que desenhar telinha é um uso muito comum em C#. 

WinForms usa a Win32, porém é um wrapper NET Managed . Se usar Win32 fosse garantia o Delphi também estaria garantido.

Eu acho que o NET todo managed vai acabar. É um chute, mas é baseado no que ocorre no mobile + asp 5 e considerando que ninguém quer ficar mantendo várias base de código, uma para windows rt e outra para NET managed e vários compiladores e otimizadores.

Inclusive colocar open source é uma maneira de fazer uma transição.

Tentando achar algum suporte para o que eu disse achei o seguinte. 

http://www.infragistics.com/community/blogs/devtoolsguy/archive/2015/06/10/the-future-of-wpf-beyond-the-net-framework-4-6.aspx

Tem que haver um caminho para as aplicações atuais. Eu diria que vão abandonar o forms e achar vão fazer um merge do WPF com XAML do windows rt e depois começar a lançar o c# nativo para desktop usando o windows rt com uma certa quebra de compatibilidade. 

 

Outro detalhe, é que o próprio C# deve compartilha o back end do C++.

Compiling Apps with .NET Native

https://msdn.microsoft.com/en-us/library/dn584397(v=vs.110).aspx

• .NET Native uses the same back end as the C++ compiler, which is optimized for static precompilation scenarios.

De modo geral eu acho que futuro do desenvolvimento desktop está nebuloso no windows.

Extrapolando agora todas as "previsões"...

Sobre a linguagem C#  acho que terá como competidores o swift e minha previsão é que o typescript entre em um mundo compilado em um futuro próximo tornando-se a ponte web-dekstop e talvez server.

 

[Rafael Silva]

Adams,

Obrigado por trazer isso a minha atenção, no principio pensei que você era louco, mas agora me parece que loucos são os caras da M$.

https://msdn.microsoft.com/en-us/library/dn807190(v=vs.110).aspx

No momento sem comentários, parece que a merda irá voar no ventilador de uma forma que não me agrada como prog .Net.

Tipo, o novo Ngen (chamado de native tool chain xpto) agora gera o código estático e aonde ele errar o programador vai e arruma na mão.

APLAUSOS M$, PARABÉNS! Só que não.

A M$ realmente deu o upper hand para o Qt World Summit 2015, 1° palestra vai ser, "tired of shit in WinRT come to Qt".

Vou parar de escrever que a raiva está me consumindo...

Att.

[Thiago Adams]

Se você programa em C# a linguagem está salva  e o NET Core está salvando o que dá para salvar do framework antigo.

E veja também que uma parte do que eu falo é realidade e outra é um chute.

Compilar nativo não é um motivo para ficar feliz?

O C# é necessário. É necessário uma linguagem fácil  alto nível com coleta de memória. Este espaço existe e sempre será preenchido por uma ou mais linguagens e visa atrair programadores para fazerem programas de 0 ou 1 dólar na loja das plataformas.  O desktop, continua tão potente e os programas estão tão ruins, que daqui a pouco até os browser com javascript vão concorrer contra os aplicativos nativos. (ver Visual Studio Code)

A linguagem de alto nível que eu aposto é TypeScript. Que é feito pelo cara que fez o Delphi e depois o C#. Por que eu digo isso?

Porque é a linguagem que compila para javascript e é tipada. Sendo tipada a porta está aberta para ser compilada de forma um pouco mais eficiente. E gerando javascript que é a linguagem mais portável que existe para criar webapps. Veja que hoje é possível gerar com typescript aplicativos para celular, para web e para server usando node.

Estão sendo cavados dois túneis que vão se encontrar. De um lado uma competição para gerar compiladores/interpretadores javascript mais poderosos. A google agora apoia do typescript.

O typescript está de um lado que gera javascript mas está tipado e acompanhando o padrão do javascript para não se perder no caminho.

A coisa mais inteligente que pode ser feita agora é trabalhar em um compilador nativo meio hibrido typescript e javascript. Acho que a MS está fazendo isso com o Chakra. Inclusive já existe uma versão do node.js que não usa o V8 da google.

[Rafael Silva]

Você pode até ter razão, mas não da forma que eles fizeram.

Segue:

https://msdn.microsoft.com/en-us/library/dn600636(v=vs.110).aspx

"Not all metadata lookup failures in apps developed using the .NET Native tool chain result in an exception. Some can manifest in unpredictable ways in an app."

Código que foi escrito e testado pelo Compilador do C# pode explodir no Nativo... Não sei como isso pode vir a ser bom, as vezes nem exception, pode ser simplesmente access violation. Programador C# nem sabe o que é isso man.

Toda a vantagem que o C# tinha com reflection e dynamic foi jogada na lata do lixo com essa ideia da M$, desse jeito melhor vir de C++.

Att.

[JuciÊ Andrade]

On Wednesday, August 5, 2015 at 4:35:36 PM UTC-3, Rafael Silva wrote:

 

Vou parar de escrever que a raiva está me consumindo...

 

 

Pô, mas aí é que é bom escrever!! 8^D 

[Basilio_Miranda]

Caro Felipe Henrique,

Pelos indicativos que tenho (empíricos, é certo) só vejo pessoas querendo sair do Delphi, inseguras quando à sua continuidade.

Para intefaces, certamente eu escolheria Qt.

Por 4 motivos:

1) você pode escrever as interfaces em C++, e usar folhas de estilo (CSS) para a aparência da interface; as folhas de estilo podem ser escritas por um "designer", se você tiver um.

2) você pode escrever as interfaces em QML (um mix de javascrit, CSS e extensions de Qt), o que pode ser feito por um "designer",  e então você se ocupa do código C++ para o processamento, que é onde C++ fará diferença.

3) você pode escrever as interfaces em HTML + javascript e, no javascript, invocar funções C++ para processamento. A interface também fica por conta do designer, e tudo o que você tem que informar a esse profissional é quais funções(e com quais argumentos) as funções C++ devem ser invocadas (e em qual evento).

4) Licença LGPL - você não paga, exceto por algumas poucas "features", e pode distribuir o seu binário sem o código fonte. A hipótese de que essa forma de licenciamento seja descontinuada é muito remota, até porque a KDE Qt Open Foundation tem o direito legal de criar o seu "fork" caso alguma licença "open source" de Qt sofra um corte, em novas versões. Esse não é um direito sujeito a longas discussões jurídicas. É um direito estabelecido.

Para todo o resto, isto é para o processamento, em escolheria C++ com Qt. Não porque seja a única solução. Mas porque é muito mais produtiva .

Posso usar um pouco de Boost, posso usar um pouco de outras bibliotecas, conforme o caso, mas o meu "mainstream" é esse: C++ & Qt.

 Recomendo. O prêmio de produtividade não é pequeno. E com eficiência que não encontraremos em outras linguagens. Mas, é lógico, que para certas situações, onde perfomance não é um problema, eu poderia escolher Java, ou até linguagens de script. Às vezes sinto saudades do Perl e do Awk... Mas hoje temos o Python.

Enfim, linguagem é uma ferramenta. Não deve ser uma devoção. Embora eu prefira C++, sei que nem sempre é a melhor escolha.

Produtividade é uma palavra-chave no ramo em que atuamos. Outra é "performance" (**quando** performance é um requisito inescapável). Neste último caso C++ & Qt constituem um saudável equilíbrio entre produtividade e performance.

Recomendo.

Abraços,

Basilio Miranda.

Em sábado, 1 de agosto de 2015 15:23:08 UTC-3, Fellipe Henrique escreveu:

Bom dia amigos,

Primeiramente me desculpem pelo post, não quero aqui criar flames.. é que só quero uma opinião de quem é do ramo do C/C++..

Hoje, estou querendo iniciar um projeto para sistema desktop, sim.. desktop.. já tenho um sistema Web, mas alguns clientes não querem usar via web, e sim na empresa.. e as vezes (quase sempre) não há como instalar meu sistema web na empresa por alguns motivos, tais como: a empresa não pode dispor de um servidor linux (que é necessário em meu sistema web) entre outros..

Alguns sistemas meus foram feitos em Delphi, o que é bastante  razoável, sendo que para desenvolver desktop nele é beem fácil.. mas tenho alguns problemas com ele: 1) a cada ano uma nova versão com novos problemas. 2) Ide super hyper pesada 3) linguagem defasada. 4) Sem acesso fácil à internet, seja por meio de webservices ou outra coisa...

Então queria ver com os amigos, o que levaria a empresa a trocar o desenvolvimento Delphi pelo C++ (estamos pensando usar o Qt), sendo que teria quer ter ao mínimo essas necessidades: 1) Ser compilável e portável para Windows, MacOs... 2) Facilidade de acesso a internet (consumir webservices e etc).. 3) Facilidade de acessos as chaves de criptografia (certificados).  4) Nao possuir visual "antiquado" igual win32...

Acredito que seria isso amigos, como não uso o C++ profissionalmente, não saberia responder e ter embasamento para "peitar" o delphi nesse quesito..

Conto com a ajuda dos amigos.. abraços e obrigado desde já...

T.·.F.·.A.·.     S+F

Fellipe Henrique P. Soares

e-mail: > echo "lkrrovknFmsgor4ius" | perl -pe \ 's/(.)/chr(ord($1)-2*3)/ge'

Blog: http://fhbash.wordpress.com/

GitHub: https://github.com/fellipeh

Twitter: @fh_bash

[Fellipe Henrique]

Amigos,

Muito obrigado pela ótima discussão... rendeu bastante.. o que eu vejo é que ainda há mercado e vai existir mercado para Desktop.. pois algumas funções são praticamente impossíveis de se realizar pela web (impressora fiscal, térmica, comunicação com balanças e etc..).

O Delphi não ruim.. desculpe-me se dei essa impressão.. o que me incomoda com ele, é a empresa que o controla, e a forma como ela trabalha com ele. Principalmente com essa novidade de "implantar bugs" para que a pessoa esteja sempre "comprando" a nova versão. Mas o delphi ainda é imbatível no quesito RAD...

Tanto C++/Qt quanto C#, existe uma curva grande de aprendizado e "refatoração" de trabalho. Mas tem a vantagem de compilar e fornecer binários..

Python/Qt seria bom.. juntaria 2 coisas que eu gosto... porém o código seria aberto.. sim, existe como "compilar" porém existiria a perda da performance do produto.

A verdade, esse meu problema não se resume somente em: Sair do Delphi e ir pra C++/Qt...  como puderam perceber, meu problema maior é:  Tenho um produto, que ainda precisa evoluir é claro! Mas esse produto funciona quase que exclusivamente via Web, em alguns casos (aqui na região é a maioria dos casos) não tenho condições de implantar esse sistema na empresa... então a questão é:  compensaria voltar pro desktop? seja qual linguagem for.. porque percebi na discussão é:  sempre queremos o melhor para nosso sistema, novas tecnologias, novas formas de programar.. mas no final,  o que conta é o que entregamos pro cliente.. seja em Delphi, C++/Qt, C#, Python/Qt, Framework Web.. não importa.. o cliente quer o produto e que seja fácil de usar.. as vezes eu tenho que deixar de lado essa vontade de fornecer um produto inovador via web, e voltar ao produto "normal" via desktop mesmo.. não sei...

Abraços..

T.·.F.·.A.·.     S+F

Fellipe Henrique P. Soares

e-mail: > echo "lkrrovknFmsgor4ius" | perl -pe \ 's/(.)/chr(ord($1)-2*3)/ge'

Blog: http://fhbash.wordpress.com/

GitHub: https://github.com/fellipeh

Twitter: @fh_bash

--

[Thiago A. Corrêa]

Qt promete compatibilidade de código e binária só para versões minor, versões major introduzem mudanças na API. Acaba-se aguardando muitas mudanças na biblioteca justamente por causa dessas promessas de compatibilidade. Por exemplo o Qt 5.6 vai ter Long Term Support, e vai ser a ultima versão a compilar com C++98, a partir do 5.7 vai exigir que o S.O tenha um compilador capaz de C++11.

WinCE e QNX 5.6 só vão ter suporte na 5.6, na 5.7 para frente não vai ter mais justamente por causa do compilador.

O 4.8 ainda tem releases quando encontram falhas de segurança.

O que força a mão no update é as distros se você usar as libs do sistema.

[Basilio_Miranda]

Bem, você tem razão Felipe Henrique.

O desktop está com os dias contados, ainda que isso vá demorar.

O futuro é mobile/embarcados e o lado server (serviços).

Cada vez mais interfaces serão web.

Preferencialmente web services, seja usando SOAP, REST ou JSON, ou outra coisa que já surgiu ou ainda vai surgir.

E é possível fazer isso com Qt.

Mas nesse caso é mais fácil usar ou uma linguagem de script ou o gSoap (apenas para desempacotar/re-empacotar o protocolo do web service). Que aí podem enviar as requisições em um protocolo otimizado para um servidor de aplicações. E este pode ser escrito em C++ (mais fácil C++ com Qt) bem como as aplicações que ele pode endereçar (geralmente, bibliotecas carregadas dinamicamente. sem "link" implícito).

Hoje, em minha equipe, dificilmente criamos uma interface desktop. Há casos, em que a interface desktop se impõe. Por exemplo, sistemas de cobrança, que não devem ser executados fora da rede local. Mas na maioria dos casos a interface deve estar na web. Usamos gSoap para criar módulos para os servidores Web (no nosso caso é sempre o Apache, mas ele permite também criar módulos para o MS IIS). Para cada novo web service, primeiro compilamos para criar um cgi. Que dura enquanto durarem os testes. Uma vez concluídos, nós recompilamos o web service para se tornar um módulo do servidor web. É uma flecha. Não tem nada mais rápido que isso (ou pelo menos eu desconheço).

Mas o processamento propriamente dito, nós implementamos em C++ (com o "auxílio luxuoso" de Qt, porque aumenta muito nossa produtividade).

Enfim, tudo é possível atualmente.

A escolha nem sempre é fácil, pois quando não conhecemos uma ferramenta nova, ou fazemos um curso, ou gastamos um tempo maior investigando o funcionamento da mesma.

Mas nós podemos... 

Abraços C & C++ && Qt (notou a precedência dos operadores? Então me diga: o resultado da expressão completa é lógico ou aritmético? ... just kidding...)

Basilio Miranda. 

[Rodrigo Strauss]

Felipe, aqui na empresa começamos a fazer uma interface em Qt, por causa de um requisito de um cliente. Depois de um tempo percebemos o quanto fomos idiotas de seguir esse cliente e refizemos tudo em Web. O produto ficou bem melhor e mais fácil de gerenciar.

Nós temos bastante coisa server side que precisa de performance. Isso tudo é C++ e não existe linguagem mais adequada. 

Rodrigo Strauss
http://www.1bit.com.br
@rodrigostrauss