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
Je n'affirme pas connaitre la roadmap ! je donne un avis personnel.
Après même si je partage pas ton enthousiasme concernant l'avenir de Delphi, ton raisonnement est logique et cohérent.Tu semble donc avoir bien réflechi au problème et ne pas agir bêtement par nostalgie mal placée. Bonne chance dans ton projet et bonne chance à Delphi par la même occasion.
Personnellement aucun, mais ce sera du .Net AVANT d'être du delphi et pas l'inverse.Envoyé par RamDevTeam
Tous les pro-delphi tout au long de ce thread, moi j'ai toujours trouvé que la vitesse n'avait de sens que si le confort d'utilisation s'en retrouvait amoindri.2- Qui a parlé de la vitesse ?
D'ailleurs, pour avoir migré une appli win32, en appli delphi.net, je n'ai pas trouvé de différence de performance pénalisante pour l'utilisateur.
Maintenant on n'est pas dans un débat win32 vs .net
Non et pourtant je m'y suis intéressé lors du choix de mon outil de développement, seulement vu le peu de documentation et de ressources que j'ai pu trouver sur internet à son sujet, je me suis découragé. J'ai au moins découvert que les chaines OCL étaient ni type-safe, ni vérifiées à la compilation et ça me pose un énorme problème personnellement, tu pourras toujours répondre que toi tu t'en fiches mais ce n'est pas du tout mon cas... J'entrerai pas dans le débat pour te prouver que j'ai tort ou raison.Connais tu précisement ECO pour pouvoir le comparer à d'autres ORM ?
Mais étant donné que delphi.net fait partie de la plateforme .Net dont la spécification est établie par microsoft, ce n'est plus comme en win32 ou borland ou codegear avaient toutes les cartes en main.Ensuite pourquoi conservé delphi.net ? Une application a un certain cycle de vie et quand les projets sont conséquent, il faut assurer leur pérénnité.
on ne change pas d'outils de dev en fonction de la mode du moment.
Borland (je devrais dire CodeGear), a un principe depuis delphi 1 qui est la "portabilité" de son code de version en version. La compatibilité ne veut pas dire la reprise à 100%, mais en tout cas, peu d'adaptation.
Par ailleurs je tiens à signaler que java est un modèle de pérennité lui aussi.
C'est ce que sortent tous les anti-microsoft à tort ou à raison, vb6 et vb.net sont DEUX langages différents à mon sens, le deuxième ayant juste voulu garder la syntaxe familiaire au VB. Pour ce qui est des nouveautés de .Net à venir telles que WPF et WCF, si tu veux continuer à utiliser les winforms et les webservices tels qu ils le sont actuellement c'est ton droit, et ça continuera de fonctionner ainsi. C'est tout de même le développeur qui en général fait le choix technologique en fonction d'un cahier des charges. Notre application est entièrement en framework 2.0 et ce n'est pas parce que les 3.5 arrive qu'on va se sentir obligé de tout passé en WPF, ça marche très bien ainsi, ça tourne sous w2k, sous Xp et sous vista sans problème pourquoi changer?Sur les projets que je met en place, je ne veux pas tout mettre à la poubelle quand microsoft décide de faire des changements. Il suffit de voir les pb du passage de vb6 à vb.net pour comprendre ce que je veux dire.
Pour moi, s'enfermer dans une sphère microsoft, c'est ce risque là.
Lorsque j'ai procédé a l'évaluation de developper studio, on bossait encore sur le framework 1.1, et vu les enrichissements amenés par le 2.0 sur le plan du remoting et du langage lui-même (support des génériques), ça m'aurait beaucoup contrarié de pas en profiter.La seul chose qui peux démarquer une société comme codegear, c'est bien évidement d'apporter un gain aux développeurs, que soit via les focntions de l'IDE, via la compatibilité du code, via des fonctionnalités supplémentaires (comme ECO). Alors avoir un peu de retard sur la version de .net est franchement un détail.
Je vois qu'on se rejoint sur plusieurs point.
- Sur la vitesse, tant que la différence n'est pas pénalisante pour l'utilisateur, tout va bien.
- Pour ECO, j'ai eu le même frein concernant la documentation très très limitée. J'ai pu faire mes premiers pas et trouver des aides sur le groupe de news de borland, ainsi que sur via certains blog soit de la team ECO soit de spécialiste indépendant.
- La vérification de chaines OCL uniquement la création et non à la compilation peut poser un problème lors d'évolution du schéma, ceci étant, aucun système ne peut analyser les chaines OCL généré par le code, or dans le cas de certains requêtes (ex:recherche multi-critère), il n'y a que la solution de création dynamique du code OCL.
Pour ne parler que d'ECO, il a le mérite de respecter les standard OCL et non comme LINQ de déformer le standard en place pour en faire une version microsoftienne.
Concernant le choix des technologies, des outils, il n'y a pas à mon sens de "meilleur" (tant que ce ne sera pas des robots qui feront notre boulot).
- Pour qu'un développeur soit productif, il faut qu'il soit à l'aise avec ses outils.
- Pour que le client soit satisfait, il faut qu'il ait une solution agréable, "rapide", et surtout qui réponde à ses besoins
- Pour que l'éditeur du logiciel soit satisfait, il faut que les délais soit respecter et qu'il ai la garantie de la maintenabilité de ses produits.
Je pense (visiblement comme toi) qu'il ne faut pas se laisse aveugler par la course à la dernière version, (ca c'est valable sur des projets type notepaduniquement.
Concernant le remoting, si j'en avais eu besoin tout de suite, j'aurais effectivement démarré autrement. Là, je sais que je vais pouvoir évoluer dans ce sens si besoin.
Je vois que nous nous sommes parfaitement compris
En effet, tout dépend des besoins, en général on veut une productivité maximale pour les développeurs, des efforts de maintenance les plus petits possibles et la satisfaction de ses clients. C'est avec tous ces éléments en tête qu'on tâche de faire les meilleurs choix.
Migrer une application dont tout le monde est satisfait juste pour pouvoir se dire qu'on est à la pointe du progrès, c'est typiquement l'erreur qui fait qu'on se retrouve à réinventer la roue chaque année avec des modifications que personne ne veut vous payer.
Juste pour dire un truc sur la vitesse, en sortant de l'école d'ingénieur j'étais impressionné du nombre de mes camarades qui ne juraient que par le C++ au point d'aller jusqu'à dire ouvertement que les langages managés étaient que des trucs de merde faits pour les gosses qui savent pas programmer.
Mais ils retombent tous sur terre lorsqu'ils se rendent compte à quel point la productivité, la maintenabilité et la sécurité du code sont importants lorsqu'on se lance sur des grands projets... Souvent plus important que la satsifaction personnelle de constater que l'application ne met que 12ms au lieu de 120ms pour rendre la main a l'utilisateur lorsque ce dernier clique sur un bouton!!!
PS: En relisant mon dernier post j'ai l'impression d'avoir été un peu aggressif, c'était pas voulu désolé.
Java et Delphi sont quand meme assez différents, je connais tres bien les produits borland, j'utilise actuellement Together et CaliberRM.
J'ai utilisé 2 mois il y a 3/4 ans Delphi 8 for .NET
Et Delphi 5 et 6 avant pendant plusieurs années.
Et ma conclusion est : Borland plus jamais.
Depuis 3/4 ans ils sont en train de couler tout ce qu'ils touchent.
Together ca marchait bien avant que Borland reprenne le truc, maintenant les dernieres versions qu'ils sortent ne sont meme plus utilisables. Tu as des bugs tellement enormes des fois que tu te demandes si tu es le seul a utiliser le programme. Dans l'export XMI de tog2006, les multiciplicités sur les attributs ne sont plus exportées... Borland nous a fait une correction (certes rapidement) mais pour tog2007 qui est sorti entre temps. On passe sous tog2007, impossible de charger notre projet "fonctionnalité non supportée". Visiblement cela serait un probleme de licence. Bref je crois qu'on est bloqué sur tog2005 jusqu'a ce que borland coule.
Delphi 8 for .NET c'était un désastre, c'était une version alpha pas une release, ils ont sauté des etapes. ECO ca ramait comme pas possible.
Non, la question c'est VS .NET ou Java aujourd'hui, Delphi c'est l'histoire maintenant. Code gear, je doute qu'ils arrivent a redresser la barre, ils ont accumulé un trop gros retard sur Visual Studio. Et quel est leur creneau ? le developpement win32 ca a vocation a disparaitre, pourquoi prendre la copie (delphi) plutot que l'original ? Autant windev ils ont un positionnement et un bon produit mais delphi non.
En plus je suppose que Code gear c'est Borland qui s'est coupé une jambe de manière à contenir l'épidémie. Je doute qu'ils travaillent dans une ambiance très positive.
Désolé pour les pro delphi, c'est mon opinion, je ne cherche pas a etre blessant.
Donc si tu as utilisé plusieurs version de delphi, tu peux convenir que jusqu' à la version 7 incluse, delphi a toujours était un excellent produit. C'est seulement après que borland a lâcher doucement ses investissements sur les EDI pour mettre l'accent sur d'autres outils
La version 8 .net est reconnue comme une véritable catastrophe, il s'agissait plus d'une sortie commerciale qu'autre chose.
Le véritable tournant a été entrepris avec la création de CodeGear
Bien sûr delphi a un train de retard sur VS sur certain point, mais aussi de l'avance sur d'autre, tu parler d'ECO, la version IV est largement supérieur à LINQ. D'ailleurs pour info, la team ECO travaille aussi sur la création d'un plugIn ECO pour Visual Studio.
Enfin, là on dérive un peu
bonne nouvelle pour eux, ils survivront peut etre au nauffrage de borlandla team ECO travaille aussi sur la création d'un plugIn ECO pour Visual Studio.
Le probleme c'est surtout que Microsoft a débauché toutes les pontes de chez Borland, et qu'ils ne s'en sont pas remis.C'est seulement après que borland a lâcher doucement ses investissements sur les EDI pour mettre l'accent sur d'autres outils
C'est dommage qu'un aussi bon outil finisse comme ça. Je crois aussi que les gars de Delphi ont eu tort de se baser que sur la plateforme Windows (Kylix a été pratiquement lâché en cours de route).
Le créateur de Delphi qui lache lui aussi son joujou pour en créer un autre (C#), ça ! ça fait mal
Je crois que j'ai changé de langage vraiment à temps
c'est bien vrai : on aurai cru le recrutement de Chelsea !
Au fait, ils ont gagnés quoi Chelsea ?
Vous avez un bloqueur de publicités installé.
Le Club Developpez.com n'affiche que des publicités IT, discrètes et non intrusives.
Afin que nous puissions continuer à vous fournir gratuitement du contenu de qualité, merci de nous soutenir en désactivant votre bloqueur de publicités sur Developpez.com.
Répondre avec citation
Partager