Eclipse+QtEnvoyé par dj.motte
Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter
Oui
Non
Sans Opinion
Eclipse+Qt
...complexité croissante ET INUTILE de Windows...
Si ça se trouve, les développeurs de Windows sont sous Linux ou sur Mac !(comme les concepteurs de produits OGM Monsanto refusent de manger leurs propres produits ! [taper "cafeteria monsanto ogm" dans un moteur de recherche] )
Pour en revenir au sujet, il est toujours plus simple de faire un menu contextuel ou un drag and drop avec C++ Builder qu'avec Qt et Qt Creator...
Je pense que C++ Builder a encore un peu de temps avant que Qt soit aussi facile et convivial que lui...
Les dernières informations affirment que Windows ne séduit plus les professionnels, et que la plupart d’entre eux pensent a passé a Mac OS ou Linux, alors je pense qu’il est temps que c++builder passe en multiplateformes, sinon il perd la bataille avec qt creator.
Certes qu’un clone de ce langage existe déjà sous Linux (Kylix), mais la maison doit voir de plus prêt la conversion du code, et l’amélioration de ce langage sur les autres plateformes, et essayé d’avoir une seule version pour toutes les plateformes (je veux dire la conception et la structure du langage).
De ma part je pense que builder va encore tenir quelques bonnes années, a cause de sa richesse de composants, et sa simplicité d’utilisation, jusqu'à l’apparition de nouvelles versions de qt, qui vont être plus riche en terme de composants et en plus compatible avec toutes les plateformes
Moi j'ai très vite oublié C++ Builder pour Qt et plus jamais je remettrai la main sur Builder. J'ai l'impression qu'il est mort depuis longtemps même !
Je ne connais pas Qt, mais j'utilise Builder, et je suis toujours surpris par la vitesse de développement qu'il permet et la stabilité des diverses versions. C'est peut être le problème de Borland, d'ailleurs. Chaque version est suffisament bonne pour que les utilisateurs n'aient pas besoin de la suivante (cf BC 3.1, Builder 6, Delphi 3...).
Sur la possible mort de Builder, je ne peux résister à une petite anecdote...
En 1998, je travaillais comme directeur technique d'une petite boite de développement. Le hasard des rachats de notre maison mère nous avait ramené un logiciel, leader sur son marché (le dépouillement de sondages), développé en C++, version Borland. Nous développions également en C++, mais avec Visual, et mon chef, visionnaire (la situation actuelle le prouve), avait bien compris que dans le combat qui l'opposait à Microsoft, Borland perdrait, et qu'il valait donc mieux passer à Visual tout de suite.
Le premier grand projet de l'équipe de développement (2 personnes), après le rachat, fut donc le passage de Borland à Visual.
Le premier développeur (orienté interface) démissionna 6 mois plus tard, parce que débuguer du code qui marchait, c'est très fatigant. Le second tint un an de plus, suffisament pour que le logiciel soit porté... Mais sans développeurs, il était devenu inmaintenable. Le code a donc été vendu, pas vraiment repris, et a fini par mourir (même si je sais que les versions anciennes du logiciel, développées avant le portage, tournent encore dans tous les instituts de sondage français).
En gros, avoir raison trop tôt sur la défaite de Borland a tué un logiciel plein d'avenir...
Personnellement, je vais rester sur Builder tant que la position sera tenable, elle l'est tout à fait aujourd'hui. La portabilité vers Linux ou MacOS n'est pas réellement un problème: dans le monde de l'entreprise, ces OS sont rares. La compatibilité Boost est plus gênante, mais je pense qu'elle existe à un niveau minimal (j'arrive à utiliser des bouts de Boost avec mon vieux Builder 6).
Pour la suite, la question se pose... Utiliser Qt, ou d'autres frameworks C++, ou des choses comme FLEX/AIR, qui permettent un graphisme plus élaboré... Quelque part, je pense qu'on pourrait bien retrouver une situation ancienne, où pas mal de programme commerciaux avaient
- une interface utilisateur en VB, facile à faire et à changer
- des moteurs en assembleur, sales mais efficaces
Là, on aurait
- des interfaces dans une variété de XML programmable (FLEX, ou tout autre produit du meme genre)
- des moteurs en C ou en C++, débarassés des librairies
Francois
Pourrais tu développer, perso QT je ne connais pas, je suis un vieux utilisateur de borland qui pour moi a été un précurseur dans le RAD.
On pourrait imaginer:
- Coût d'acquisiton,
- coût de formation,
- facilité de prise en main,
- Composant free et payant,
- Nb d'utilisateur (communauté active),..
- rapidité de mise en oeuvre/développement d'un projet,
-...
je pense qu'on pourrait avoir un taux comparatif de l'usage forum par outil C++ par les administrateurs ?? pour vérifier les tendances et activités ...
Répondre avec citation
Partager