Discussion :

[RamDevTeam]

Est-ce que l'utilisation du Pascal Objet plutot que du C# apporte une différence :
1- en terme de fonctionnalités
2- en terme d'intégration:
Une DLL delphi.net est-elle systèmatiquement utilisable par des applications VB.NET ou Csharp sans ajout d'assemblage particulier ?

En win32, une DLL utilisant des types propriétaires à delphi pour les fonctions exporté imposer la fourniture d'une DLL de borland.

Merci.

[Gregoire.Guyon]

Pascal Objet est moins verbeux !

[Merlin]

Pascal Objet est moins verbeux !

N'exagérons rien, c'est plutôt l'exact contraire :-)

Avec Delphi.net il faut plus de code pour faire la même chose qu'en C#.

Chacun choisit le langage qu'il préfère, on peut "tout faire" en Delphi.net, mais il faut avouer que Delphi se traîne une compatibilité ascendante assez gênante sous .NET, là où C# est plus simple, plus pur et plus agréable à utiliser.
Un simple exemple : les namespaces. Déclaratif sous C#, bricolage sous Delphi.net qui transforme les noms de unit en namespace. Idem pour la transformation cachée des unit delphi en classe, un bricolage pour la portabilité mais qui alourdi le code généré.

Du point de vue de l'efficacité, C# gagne sans conteste le concours.
Mais ce n'est pas le seul point à prendre en compte !
Si tu as une équipe de 50 développeurs formés à Delphi win32 et que tu dois migrer sous .NET, le passage à Delphi.net + vcl.net permettra de gagner des centaines de milliers d'euros en terme de formation et de gain de productivité.

[RamDevTeam]

Pascal Objet est moins verbeux !

N'exagérons rien, c'est plutôt l'exact contraire :-)

Avec Delphi.net il faut plus de code pour faire la même chose qu'en C#.

Je ne pense pas que ce soit systèmatique.

Chacun choisit le langage qu'il préfère, on peut "tout faire" en Delphi.net, mais il faut avouer que Delphi se traîne une compatibilité ascendante assez gênante sous .NET,

Sur certain point, la compatibilité ascendante oblige à être un peu plus bavard. mais, il n'y a pas que des désavantages.

là où C# est plus simple, plus pur et plus agréable à utiliser.
Un simple exemple : les namespaces. Déclaratif sous C#, bricolage sous Delphi.net qui transforme les noms de unit en namespace. Idem pour la transformation cachée des unit delphi en classe, un bricolage pour la portabilité mais qui alourdi le code généré.

Pour les namespaces ca ne me choque pas. je trouve même qu'avoir un nom de unit identique au namespace permet d'avoir une gestion de fichier propre. par contre, je suis d'accord pour la création des classes "cachées"

Cà alourdit la vue modéle surtout quand tu as 100 unit donc 100 classes globales xxxx en plus ....

Du point de vue de l'efficacité, C# gagne sans conteste le concours.

Si tu parle de l'efficacité des développeurs, c'est uniquement les compétences de personnes qui font la différence.
Un bon developpeur Delphi sera aussi efficace qu'un bon développeur C#

Mais ce n'est pas le seul point à prendre en compte !
Si tu as une équipe de 50 développeurs formés à Delphi win32 et que tu dois migrer sous .NET, le passage à Delphi.net + vcl.net permettra de gagner des centaines de milliers d'euros en terme de formation et de gain de productivité.

Quite à migrer, de delphi32 à dotnet, la question n'est pas (pour moi) C# ou Delphi.net mais
(delphi.net + winforms) ou (delphi.net + VCL.net)

il n'y a pas plus de raison d'abandonner le Pascal pour le C# que d'abandonner le VB pour le C#.
Il faut essayer d'avoir une vision à long terme (ce qui n'est plus du tout évident au vue des déclarations de borland)
Si on est optimiste : la nouvelle société va renforcer delphi !
Si on est défaitiste (ou si microsoft rachète), la nouvelle société va faire migrer progressivement Dephi vers Visual Studio ...

[Merlin]

Delphi reste bien plus verbeux que c#. Je ne sais pas ce que tu entends par "pas systématique", ce dont moi je parle c'est le résultat : le nombre de caractères et de lignes de code pour faire la même chose...

Je ne vois pas non plus où seraient les avantages dont tu parles à être plus verbeux. Ce qui compte c'est que le langage soit fortement typé ou non par exemple, ça oui. Si l'un est moins fortement typé que l'autre il a un désaventage. Mais "verbeux", je ne vois aucun cas où cela puisse être avantageux. C'est même tout le contraire : plus il y a de mots pour dire la même chose, plus il y a de risques de bugs, d'inversions, d'omissions, de mauvaises traductions del'idée...

Pour les namespaces, je ne vois ici non plus en quoi être dans l'obligation d'avoir un namespace par nom de fichier avec delphi rend "la gestion de fichiers plus propre".
Un namespace n'a rien à voir avec les fichiers et c'est justement l'un de ses intérêts...

Pour l'efficacité je ne parle pas de celle du développeur, je parle de celle du langage. Un langage est plus efficace qu'un autre s'il permet plus facilement, plus directement, en moins de lignes, d'arriver au même résultat. C'est le cas de C# vis à vis de Delphi qui conserve des constructions assez lourdes héritées de son histoire.

Tu soulèves aussi la question de choisir winforms ou vcl.net. J'en reviens à ce que je disais : si tu as du code à migrer, alors prend vcl.net. Sinon cela n'a strictement aucun intérêt.
La conception de composants par exemple est mille fois plus aisée en Windows forms qu'en VCL.NET qui traine des structures devenues vieillotes avec le temps. Ce n'est qu'un simple exemple mais qui se rencontre tout au long de la VCL. Un autre serait la séparation composants DB et composants non DB. Grand progrès il y a 11 ans avec Delphi 1, totalement dépassé aujourd'hui (les mêmes composants sont DB/non DB sous Windows forms). etc.

Quant au langage, tu dis qu'il "n'ya pas plus de raison d'abandonner Pascal pour C# que VB pour C#". Je crains que tu ne dises cela parce que tu ne connais ni C# ni VB...

[RamDevTeam]

ce dont moi je parle c'est le résultat : le nombre de caractères et de lignes de code pour faire la même chose...

Qu'importe le nombre de caractère si tu va aussi vite à saisir !
A quoi sert code Insigth, ses templates, l'auto-complétion ...

Au premier abord, if () {} else {} et plus rapide à taper que :

if () then
begin
end
else
begin
end;

sauf que ifeb + ctrl-J te le donne.

idem pour un for:
tu tape for + entree, BDS pré-inscrit "for I:=0 to List.count do " et ajoute la déclaration var I:integer; en tête de ta procédure

Ce ne sont que quelques exemples (bien sûr ca existé déja sous D7 mais de manière peut-être moins "accessible")

Maintenant, si je ne me trompe pas qu'une appli soit faite en Delphi.net, c# ou VB.NET c'est bien l'IL qui est généré au final. donc quel différence en terme d'efficacité ?


Au contraire, il y a certains mécanisme plus pratique en C# qu'en Delphi.net (par exemple, l'accès au proriété de ton assembly) mais c'est loin d'être une généralité.

Plus il y a de mots pour dire la même chose, plus il y a de risques de bugs, d'inversions, d'omissions, de mauvaises traductions del'idée...

Est quel rapport avec Delphi.net ? Aucun il me semble !
Je ne vois franchement pas en quoi utiliser Delphi.net plûtot que le C# augmente le risque de bug.
D'autre part à te lire on a l'impression qu'il faut en moyenne 10 fois plus de ligne en delphi.net qu'en C# !

Pour les namespaces, je ne vois ici non plus en quoi être dans l'obligation d'avoir un namespace par nom de fichier avec delphi rend "la gestion de fichiers plus propre".

A chacun ces pratiques, dans *mon* cas, avoir un nom de fichier correspondant au namespace me convient. Mais je suis d'accord avec toi, ca ne devrait pas être une obligation.

Tu soulèves aussi la question de choisir winforms ou vcl.net. J'en reviens à ce que je disais : si tu as du code à migrer, alors prend vcl.net. Sinon cela n'a strictement aucun intérêt.

La VCL apporte un niveau d'abstraction qui a permit de passer très facilement de Win31 vers Win32 puis vers .Net. ce même niveau d'abstraction permettra sans doute de suivre les évolutions de .Net plus facilement.

D'ailleurs, que penses tu de l'abandon des winforms par microsoft ?

Il faut aussi prendre en compte la capitalisation des connaissances. et les côut de formation.

La conception de composants par exemple est mille fois plus aisée en Windows forms qu'en VCL.NET qui traine des structures devenues vieillotes avec le temps.

Effectivement, la création de composant visuels peut se réveler pénible.
Maintenant, tu peut toujours créer ton composant dans une bibliothèque de controles c# et utiliser le wrapper intégrer dans BDS pour en faire un composant de la VCL.

Quant au langage, tu dis qu'il "n'ya pas plus de raison d'abandonner Pascal pour C# que VB pour C#". Je crains que tu ne dises cela parce que tu ne connais ni C# ni VB...

Pour VB, j'ai commencé avec la 3, et je me suis arrêter à la version 6.
Pour C#, je suis loin d'être un pro mais je l'utilise pour la partie modèle.
DLL C# ECO + frontal VCL.NET

Ma remarque était motivé par la lecture régulière des forums de développez.com et de groupes de new dédié au dev .Net, etc ...

Je me permet de recité quelque extrait de la faq .net :

Le grand avantage de .NET est que vous pouvez utiliser de nombreux langages VB, C#, C++ aussi bien que d'autres langages tels que le Perl, Pascal, Cobol. Vous avez sûrement entendu que le C# était le meilleur langage pour .NET. En fait c'est le seul langage conçu pour .NET qui n'a donc nécessité aucun portage. Le C# a quelques fonctionnalités que n'a pas VB .NET mais ce n'est pas une raison pour en faire le meilleur langage. Il n'y a pas de meilleur langage sous .NET, vous devez simplement vous familiariser avec le Framework .NET et utiliser le langage qui vous convient le mieux.

Contenu accessible à l'adresse : http://dotnet.developpez.com/faq.net/?page=langages#3.2

Cdt.

[Merlin]

Qu'importe le nombre de caractère si tu va aussi vite à saisir !
A quoi sert code Insigth, ses templates, l'auto-complétion ...

C'est pas une question de frappe... C'est question de maintenabilité et de vitesse de lecture et de compréhension du code une fois qu'il a été écrit...

Maintenant, si je ne me trompe pas qu'une appli soit faite en Delphi.net, c# ou VB.NET c'est bien l'IL qui est généré au final. donc quel différence en terme d'efficacité ?

On dirait que tu écris des logiciels "kleenex" : tu codes avec des aides pour taper moins et hop! tu compiles et c'est fini tu passes au suivant...

Dans la réalité un code doit être maintenu, relu, testé, la maintenance sera corrective et aussi évolutive, le code passera certainement entre des tas de mains différentes, etc.
De fait, que le code soit plus lisible, moins verbeux, plus clair, est un énorme avantage.
Il est donc, de ce fait, plus efficace.

Au contraire, il y a certains mécanisme plus pratique en C# qu'en Delphi.net (par exemple, l'accès au proriété de ton assembly) mais c'est loin d'être une généralité.

Je vois plein d'exemples de choses que C# fait plus efficacement que Delphi.net et, hélas, je n'en trouve aucun en faveur de ce dernier sur C#...

Est quel rapport avec Delphi.net ? Aucun il me semble !
Je ne vois franchement pas en quoi utiliser Delphi.net plûtot que le C# augmente le risque de bug.

C'est que tu manques d'expérience certainement si tu ne comprends pas. Il s'agit d'un effet "mécanique", plus tu as de lignes de code, plus tu augmentes le risque de bug. C'est comme ça...
Donc Delphi.net augmente ce risque par rapport à C#.

A chacun ces pratiques, dans *mon* cas, avoir un nom de fichier correspondant au namespace me convient. Mais je suis d'accord avec toi, ca ne devrait pas être une obligation.

Tu ne peux pas parler d'un langage en te limitant à "ton cas". L'intérêt même des namespaces est de permettre une construction hiérarchique qui n'a strictement rien à voir avec les noms de fichier.
Quand Delphi.net impose un fichier = un namespace, c'est du bricolage qui enlève 99% de l'intérêt des namespaces.

La VCL apporte un niveau d'abstraction qui a permit de passer très facilement de Win31 vers Win32 puis vers .Net. ce même niveau d'abstraction permettra sans doute de suivre les évolutions de .Net plus facilement.

Je ne pense pas. L'un des intérêts de .NET est la portabilité du code compilé, de l'interopérabilité entre langages. C'est essentiel ça.
En utilisant la VCL tu t'enfermes dans une tour, isolée de tous les autres développeurs.
Je ne pense pas que ce soit une bonne chose d'opter pour l'enfermement.
En revanche, et je le maintiens, s'il y a beaucoup de code existant à migrer la VCL.NET a un avantage.

D'ailleurs, que penses tu de l'abandon des winforms par microsoft ?

Il n'y a aucun abandon et la road map de .NET est connue de longue date. Vu la taille de .NET tous les morceaux n'ont pas été livrés le même jour mais tout le monde sait (tant pis pour ceux qui ne se tiennent pas au courant) que .NET doit être équipé d'un système de gestion de fichier et d'un système d'affichage qui ne faisaient pas partie des premières livraisons.
Donc d'une part Windows forms va continuer d'exister, et d'autre part il est de notoriété publique que .NET n'est pas encore livré "complet" et que cela se fait sur plusieurs années. Cela concerne l'affichage et c'est connu, public depuis longtemps (et les bêta de xaml sont dispos).

Il faut aussi prendre en compte la capitalisation des connaissances. et les côut de formation.

Tu sais ça c'est mon boulot et j'ai une grande expérience de la question... Et puisque tu en parles alors pour résumer disons qu'une formation pour un développeur Delphi 5 qui passe à Delphi.net est de 5 jours, et que la formation pour passer à C# est de 5 jours...
Logique, 80% de la formation concerne .NET peu importe le langage en fait, et 15% concerne les nouvelles constructions comme la surcharge des opérateurs... 5% concerne la syntaxe du langage.
Le coût de la formation est donc exactement le même !

En revanche là où tu aurais pu dire quelque chose c'est en terme de productivité. Un développeur Delphi 5 passant à Delphi.net + VCL.NET mettra certainement moins de temps à être au même niveau qu'il était sous Win32 que celui qui choisira de changer de langage. Il lui faudra une à deux semaines de plus en moyenne pour être à l'aise.
Cela a un coût et doit être pris en compte. C'est pour cela que Delphi.net et la vcl.net ont un intérêt dans certains cas de figure chez certains clients. Mais cela reste "une niche".

Effectivement, la création de composant visuels peut se réveler pénible.
Maintenant, tu peut toujours créer ton composant dans une bibliothèque de controles c# et utiliser le wrapper intégrer dans BDS pour en faire un composant de la VCL.

Donc finalement tout ça pour me dire que j'ai raison et qu'il est préférable de développer en C# ....
Cela me fait penser à ceux qui défendaient VB à l'époque de Delphi 1. Si tu voulais écrire des composants "ya vait ka" les écrire en C++ !
Sauf que 90% des développeurs VB n'ont généralement pas le niveau / la connaissance pour faire du C++...
Idem sous .NET avec Delphi aujourd'hui.
Soit tu connais C# au point d'écrire des libs et on voit mal pourquoi tu n'écrirais pas tout en C# hein... soit tu n'as pas le niveau ou la connaissance pour le faire et tu es donc un peu gêné...
C'est aussi un point essentiel qui rend C# plus efficace que Delphi sous .NET.
Je passe sous silence que le fait qu'écrire un compo sous Delphi, même Windows Forms, oblige à distribuer au minimum une DLL Borland en plus de la lib... Et plus si le developeur utilise sysutils ou des lib VCL...
Delphi s'est fait une réputation à l'époque justement en se fichant de la tête des développeurs VB qui devaient fournir des tonnes de DLL avec leurs applis.
Sous .NET Delphi + vcl contre C# c'est exactement pareil !
Moi je ne suis pas un fanatique à la solde d'un langage ou d'un éditeur, et les arguments importants qui m'ont fait choisir Delphi il y a 10 ans n'ont pas changé. Aujourd'hui ces arguments se retournent contre Delphi au profit de C#.
ça fait un peu de peine, on ressent un peu de nostalgie, ok. Mais bon ce n'est qu'un outil pour travailler on va pas en faire une tonne non plus... Delphi n'a pas de pensée, c'est pas un humain, il ne va pas faire une tentative de suicide si on le quitte hein... faut rester pro tu ne crois pas ?

[RamDevTeam]

à Merlin :
visiblement ta réponse à purement et simplement remplacé mon post précédent. donc je me permet de la reposter

Mes commentaires sur ta réponse suivront.

------ Post d'origine -------------------------

On dirait que tu écris des logiciels "kleenex" : tu codes avec des aides pour taper moins et hop! tu compiles et c'est fini tu passes au suivant...

Si ça t'amuse de retaper trente-six fois les mêmes instructions, ça te regarde. Je préfére me concentrer sur le raisonnement métier.
Tu ne t'ai jamais fait de bibliothèques de codes ?
Maintenant si essayer de taper moins te dérange, utilise un éditeur de texte et créé tes écrans en code. Ca fait kleenex, de poser un zone de texte à la souris .

J'ai l'impression que tu mélange la qualité d'un code et la quantité de code.

Dans la réalité un code doit être maintenu, relu, testé, la maintenance sera corrective et aussi évolutive, le code passera certainement entre des tas de mains différentes, etc.
De fait, que le code soit plus lisible, moins verbeux, plus clair, est un énorme avantage.
Il est donc, de ce fait, plus efficace.

si je suis ton raisonnement, une appli en C++ est forcément moins buggé qu'une appli en COBOL et le c# et LE langage par excellence !

Dans ma réalité, on a pas attendu le C# pour faire des application stable et maintenable, la qualité d'un code et donc sa maintenabilité ne dépend pas de la grammaire d'un langage mais uniquement de l'utilisation qu'on en fait.
Code commenté, indentation correcte, utilisation de convention de nommage, modularité, etc ...

C'est que tu manques d'expérience certainement si tu ne comprends pas

Ne t'en fais pas pour mon expérience. je suis loin du statut étudiant.

L'un des intérêts de .NET est la portabilité du code compilé, de l'interopérabilité entre langages. C'est essentiel ça.
En utilisant la VCL tu t'enfermes dans une tour, isolée de tous les autres développeurs.
Je ne pense pas que ce soit une bonne chose d'opter pour l'enfermement.

La portabilité du code compilé n'est pas encore une réalité pour .Net
Si je veux faire du code vraiment portable j'utilise java.
Quand à l'enfermement, si on devait mettre dans une cage tout les développeurs Delphi.net, il faudrait qu'elle soit grande ;-)
D'ailleurs pour éviter l'isolement, il fallait ne faire que du VB.

Soit dit en passant, ton discours va à l'opposer de :

http://www.e-naxos.com/books.aspx

Développer avec la VCL.NET

Loin d'être une technologie vieillissante ou un simple portage à titre temporaire, la VCL sous .NET est le prolongement de la stratégie Borland visant à accompagner les développeurs sous toutes les plates-formes, de façon native et pérenne, depuis Win16 à .NET en passant par Win32 et Linux, et demain sous Avalon et XAML. Les ouvrages précédents ayant traités en profondeur de la VCL, les chapitres de cette section présentent les nouveautés de VCL.NET et les grands middleware de connexion aux bases de données.

C'est marrant, je ne vois pas notion d'enfermement dans la présentation de votre livre !

[..] Windows forms va continuer d'exister [..]

Au même titre qu'on peut toujours programmer en assembleur sous Xp ou faire des applis win32 ...
Si tu dois faire évoluer tes applis, il sera surement plus simple de faire évoluer une appli VCL.NET qu'une appli purement Winforms.


Le seul intêrêt pour moi à écrire des composants en C# est de les rendre utilisable également pour un projet Visual Studio .Net
Un composant VCL reste un composant Delphi.

Je passe sous silence que le fait qu'écrire un compo sous Delphi, même Windows Forms, oblige à distribuer au minimum une DLL Borland en plus de la lib... Et plus si le developeur utilise sysutils ou des lib VCL...

Quelle importance, ça sert à quoi les installeurs ? D'ailleurs quand tu vois la taille du framework à déployer, c'est pas les quelques malheureuse DLL borland qui sont pénalisante.

[Delphi s'est fait une réputation à l'époque justement en se fichant de la tête des développeurs VB qui devaient fournir des tonnes de DLL avec leurs applis.
Sous .NET Delphi + vcl contre C# c'est exactement pareil ! ]

La réputation de delphi n'était pas uniquement basé sur l'aspect DLL et VBX (qui n'a rien de comparable avec le deploiement delphi.net) mais aussi et surtout sur la différence de performance des applications.
une exe delphi 20 fois plus rapide qu'un "exe" VB ça te rappelle quelquechose ?

Soit tu connais C# au point d'écrire des libs et on voit mal pourquoi tu n'écrirais pas tout en C# hein... soit tu n'as pas le niveau ou la connaissance pour le faire et tu es donc un peu gêné...

Si je devais être géné par un langage, j'aurais changé de métier depuis longtemps ! on est bien loin du RPG 400 ou du COBOL.

Moi je ne suis pas un fanatique à la solde d'un langage ou d'un éditeur, ...

Si cette remarque est à mon sujet, je te rassure, moi non plus.

faut rester pro tu ne crois pas ?

Justement, rester pro ce n'est pas ce limiter au caractère un peu "verbeux" d'un langage ! Mais avoir les meilleurs outils en fonction de tes besoins ! Si je conserve BDS c'est notamment pour ECO qui me permet comme je l'ai dit plus haut de me concentrer sur le métier et non sur le code.

[RamDevTeam]

Merlin a écrit
Et si on suit ton raisonnement, on pourrait donc proouver qu'il faut continuer d'utiliser MS BASIC interpré sous CP/M. Je peux te garantir qu'il y a presque 30 ans je faisais des logiciels très stables avec ce langage sur des Kaypro II ou même avec DACL sur des Xerox 520...

Je vois que toi aussi tu brode autour de mon raisonnement au lieu de le suivre
Il ne faut pas à tout prix vouloir suivre le dernier langage à la mode dès sa sortie.

Je ne conteste pas l'intérêt de C# (je le répéte).

Actuellement ma couche présentation est en delphi.net pour la VCL et la couche application est entrain de migrer progressivement en C#, quand à la couche persistence et Data, elle est déja sous C#

Maintenant, sous pretexte que C# existe, il ne faut pas mettre à la poubelle tout le reste. et cà ne concerne pas que les langages.

Maintenant que SOA est plus à la mode que MVC faut-il pour autant dire qu'il faut arrêter MVC ...

La portabilité du code compilé n'est pas encore une réalité pour .Net
Si je veux faire du code vraiment portable j'utilise java.

Libre à toi d'utiliser une usine à gaz dont la compatibilité n'est pas même assurée si tu utilises une lib Sun ou une lib IBM...

Il n'est pas question de lancer un débat Java vs DotNet
Objectivement, pour l'instant Java reste bien plus portable que DotNet. il faut bien sûr choisir les bonnes lib (ce raisonnement se vaut aussi pour DotNet).

Maintenant, Dotnet n'a pas été simplement créé pour ajouter uen couche à l'API windows mais aussi pour attaquer java sur ce domaine. et il n'y a pas de raison pour que dans le futur, Net x.0 soit un sérieux concurrent.

Ce n'est pas totalement faux. En nombre oui.
Mais professionnellement, il suffit de voir les annonces de job, c'est 95% du C# et pas du VB.Net.

Ca me semble normal. Pour être basique, quite a embaucher de nouvelles ressources, je préfére les faire développer en C# que VB.NET
Dis moi si je me trompe, mais visiblement, bcp de développeur ont été décu du passage de VB6 à VB.NET (ce qui n'a pas été le cas pour le passage D7 -> D2005). Tu as des applis en VB6, Tu dois migrer sur dotnet et recommencer énormément de choses car la migration vers VB.NET nécessite énormément de changement (au vue des commentaires sur les forums). Que fais tu ? VB.NET ou C# ?

Citation:
Le seul intêrêt pour moi à écrire des composants en C# est de les rendre utilisable également pour un projet Visual Studio .Net
Un composant VCL reste un composant Delphi.

Tu oublies VB.net.
De plus tu oublies qu'un composant C# est aussi utilisable sous BDS 2006...

Je crois qu'on s'est mal compris. Je disais justement que si un composant devais être partagable, il fallait mieux le faire en C# (il ne me viendrait pas à l'idée de faire un composant en VB.NET pour l'utiliser dans un aplli Delphi.Net

Tu oublies aussi que par exemple le BDP de Borland utilisable en Delphi.net a été écrit en C# ! Bizarre ce choix non ?

Non logique ! Ca reprend ce que je disais précédement.

Ta réflexion est aussi valable pour VB.NET ...
Dans ce cas, VB.NET poubelle et Delphi.NET poubelle etc...

Et pourquoi pas D7, Est-ce que l'intégralité a été écrit en Pascal ..
Idem pour Windev (même si c pas une grande référence)...
Donc on jette tout et on n'utilise que C# quand on veut faire du dotnet.

Tu oublies certainement que .NET est installé depuis belle lurette avec XP sp2

C'est vrai que tout le monde (je ne parle pas des particuliers) est en XP Sp2 et que plus aucune entreprise ne posséde de poste en W2K Pro.

Il est bien trop tôt pour prendre vista en référence sur l'état du parc client !

Je peux t'assurer que dans les quelques années à venir, qu'il y a encore malheuresusement énormément de PC qui nécessiteront l'installation du framework 1.1 (et encore plus si c'est le 2.0).

a rapidité du code n'est que très relative. le code compilé VB n'était pas forcément si pire que ça.

Je vois que tu inverse le raisonnement que tu tiens sur le C#
A l'époque, si tu voulais une appli performante et la moins buggé possible, il fallait faire du C++ ou Delphi. VB n'était pas si pire mais n'était pas le meilleur non plus. Ne soit pas sentimentalisme ;-)

Moralité faire un pari aujourd'hui sur ECO est professionnellement très risqué

Le risque existe effectivement.

Maintenant ce n'est pas être fanatique ou sentimentaliste de considérer ECO comme un framework extrément puissant n'ayant aucun équivalent dans le monde .net.

[Merlin]

Je vois que toi aussi tu brode autour de mon raisonnement au lieu de le suivre
Il ne faut pas à tout prix vouloir suivre le dernier langage à la mode dès sa sortie.

pour information C# "ne vient pas de sortir" ... ça fait quelques années et s'il s'impose c'est justement pas un effet de mode.

Maintenant, sous pretexte que C# existe, il ne faut pas mettre à la poubelle tout le reste. et cà ne concerne pas que les langages.

Il ne s'agit pas de "mettre à la poubelle" le reste.
Un langage de programmation n'est qu'un outil, rien de plus.
Quand tu as achète une nouvelle voiture qui possèdent des airbags, l'abs, etc. Autant d'options qui sont devenues la norme. Tu ne gardes pas ton ancienne voiture juste par nostalgie.. Tu la revend ou tu la mets à la casse. En écrasant une larme peut-être, si tu es sentimental, mais c'est tout.
Un langage c'est pareil.
Avec dix ans de réflexion derrière lui, le père de Delphi à fait C#, cela n'enlève pas les qualités de Delphi, c'est juste que ça avance dans une direction qui bénéficie de dix ans de plus de réflexion.
ça pourrait être nul, après tout, mais ça ne l'est pas.

Et si tel ou tel langage s'impose par sa modernité et son élégance, techniquement il n'y a guère de raisons de conserver en plus tous les autres qu'on a pratiquer avant. Sinon mes nouveaux projets contiendrait des dizaines de morceux dans des dizaines de langages différents "juste pour pas mettre les vieux langages à la poubelle".. ça serait débile tu ne crois pas ?

Maintenant que SOA est plus à la mode que MVC faut-il pour autant dire qu'il faut arrêter MVC ...

On ne parle pas de mode, c'est toi qui veut absolument aller sur ce terrain. Je comprends qu'il est plus facile de rejeter une mode qu'une motivation technique...
Mais moi je parle technique pas mode :-)

Il n'est pas question de lancer un débat Java vs DotNet
Objectivement, pour l'instant Java reste bien plus portable que DotNet. il faut bien sûr choisir les bonnes lib (ce raisonnement se vaut aussi pour DotNet).

C'est bien plus simple sous .NET. Mais tu as raison, le débat n'est pas de savoir si Java c'est bien ou pas. Moi j'ai mon avis perso sur la question, mais des tas de développeurs pensent le contraire. Même si Java a perdu beaucoup de part de marché en faveur de .NET qui fait part égal, en si peu de temps, et qui, si cela continue, dépassera Java dans peu de temps.

Tu as des applis en VB6, Tu dois migrer sur dotnet et recommencer énormément de choses car la migration vers VB.NET nécessite énormément de changement (au vue des commentaires sur les forums). Que fais tu ? VB.NET ou C# ?

Je ne peux pas de répondre, pour moi VB ça n'existe pas en tant que langage informatique professionnel. Pas plus sous Win32 que sous .NET.
Donc ta question pour moi c'est choisir entre rien et C#, le choix est vite vu dans ce cas :-)

Ta réflexion est aussi valable pour VB.NET ...
Dans ce cas, VB.NET poubelle et Delphi.NET poubelle etc...

T'es vraiment fort, tu arrives à lire dans mes pensées ! :-)
En tout cas concernant VB, c'est sans appel.
Pour Delphi.NET, comme je le dis et le redis, le langage est toujours intéressant, mais il n'a plus les énormes avantages qu'il avait sous Win32. De fait, c'est un excellent choix pour ceux qui doivent réellement reprendre de l'existant ou qui ont de grosses équipes informatiques qu'il faudrait reformer, même si le passage à .NET, même avec Delphi, réclame aussi une formation.

Et pourquoi pas D7, Est-ce que l'intégralité a été écrit en Pascal ..

Ben justement, Delphi est fait en Delphi, notamment toutes ses librairies (la VCL). C'est ça force.
Mais sous .NET on voit que par exemple des libs comme le BDP, ont été développées en C#, plus en Delphi. Pourtant elles auraient été utilisables sous C# aussi. Borland à fait un choix technique important en optant pour C# pour les nouvelles libs au lieu de continuer comme avant à faire tout en Delphi...
Ce choix a un sens profond tu ne crois pas ?
En tout cas il oblige à se questionner...

Donc on jette tout et on n'utilise que C# quand on veut faire du dotnet.

Moi je n'ai pas dit ça.
Je dis simplement qu'un langage est un outil. Le jour où un outil mieux fichu est disponible je l'utilise. Et bien entendu par simple sentimentalisme je ne vais pas me forcer à utiliser tous les anciens outils... donc je n'utilise plus que le nouveau.
C'est toi qui tourne ça d'une façon qui donne un sens très différent à ce que je dis.

C'est vrai que tout le monde (je ne parle pas des particuliers) est en XP Sp2 et que plus aucune entreprise ne posséde de poste en W2K Pro.

Détrompe toi, je ne connais aucun particulier qui n'a pas XP ou au minimum W2000, alors que je connais très entreprise qui ont encore des postes W98, même si pour la majorité le remplacement est prévu cette année...

Il est bien trop tôt pour prendre vista en référence sur l'état du parc client !

Je ne vois pas pourquoi... Toutes les nouvelles machines dans quelques mois seront vendues avec Vista.
Quand je regarde les stats de fréquentation de divers sites dont je m'occupe, on voit bien que XP est majoritaire, suivi de W2000.
Dès que Vista sera sorti, Vista remplacement XP qui prendra la place de W2000 dans les stats...
C'est normal, ça se passe comme ça à chaque fois.

Je peux t'assurer que dans les quelques années à venir, qu'il y a encore malheuresusement énormément de PC qui nécessiteront l'installation du framework 1.1 (et encore plus si c'est le 2.0).

"énormément" non, je ne suis pas d'accord.
La majorité des PC sont aujourd'hui sous XP. Les stations W2000 sont vieillissantes, et dans quelques mois Vista remplacera XP.
Moralité dans un an ou deux, il y aura une écrasante majorité de machines sous Vista qui sera en tête (comme XP aujourd'hui) suivi par un grand nombre de stations XP. Toutes ces machines auront .NET ...

Quant à .NET 2.0 de ce que tu dis on croirait que c'est plus dur à installer. Il faut le même temps pour installer la V 2 que la V 1.1, donc...

Maintenant ce n'est pas être fanatique ou sentimentaliste de considérer ECO comme un framework extrément puissant n'ayant aucun équivalent dans le monde .net.

Techniquement ECO c'est vraiment bien.
Il reste juste aujourd'hui deux choses qui inquiètent : le manque de doc alors qu'on en est à la V 3... et l'avenir tout simplement de ECO au delà même des IDE Borland.
Donc bel édifice technique. Bonne idée de Borland de le distribuer à partir de la version pro depuis BDS 2006, mais conjoncturellement il est difficile de miser aujourd'hui sur ECO. Il faudra attendre la suite des événements.

[RamDevTeam]

Maintenant que SOA est plus à la mode que MVC faut-il pour autant dire qu'il faut arrêter MVC ...

On ne parle pas de mode, c'est toi qui veut absolument aller sur ce terrain. Je comprends qu'il est plus facile de rejeter une mode qu'une motivation technique...
Mais moi je parle technique pas mode :-)

MVC, SOA ne sont certes pas des outils mais pas non plus des modes.
On peut faire la paralèlle avec le client/serveur à une époque.

C'est bien plus simple sous .NET. Mais tu as raison, le débat n'est pas de savoir si Java c'est bien ou pas. Moi j'ai mon avis perso sur la question, mais des tas de développeurs pensent le contraire. Même si Java a perdu beaucoup de part de marché en faveur de .NET qui fait part égal, en si peu de temps, et qui, si cela continue, dépassera Java dans peu de temps.

On est d'accord :-)

Je ne peux pas de répondre, pour moi VB ça n'existe pas en tant que langage informatique professionnel. Pas plus sous Win32 que sous .NET.
Donc ta question pour moi c'est choisir entre rien et C#, le choix est vite vu dans ce cas :-)

Tu va te faire des amis :-)

C'est vrai que tout le monde (je ne parle pas des particuliers) est en XP Sp2 et que plus aucune entreprise ne posséde de poste en W2K Pro.

Détrompe toi, je ne connais aucun particulier qui n'a pas XP ou au minimum W2000, alors que je connais très entreprise qui ont encore des postes W98, même si pour la majorité le remplacement est prévu cette année...

Je parlais pas des particuliers puisque c'est pas ma cible.
Quand j'écrivait "plus aucune entreprise ne posséde de poste en W2K Pro" c'était bien sûr ironique

Je ne vois pas pourquoi... Toutes les nouvelles machines dans quelques mois seront vendues avec Vista.

Toutes les entreprises ne renouveleront pas leur parc dans les 2 ans qui viennent. Et, je connais aussi beaucoup d'entreprises et d'administration, qui sont encore en win98 pour une partie du parc.

Moralité dans un an ou deux, il y aura une écrasante majorité de machines sous Vista qui sera en tête (comme XP aujourd'hui) suivi par un grand nombre de stations XP. Toutes ces machines auront .NET ...

on est d'accord : dans au 2 ans.

Quant à .NET 2.0 de ce que tu dis on croirait que c'est plus dur à installer. Il faut le même temps pour installer la V 2 que la V 1.1, donc...

C'est pas plus dur mais il y aura moins de machine en net 2.0 qu'en net 1.1 donc si l'appli est basé sur le framework 2.0, les déploiements en entreprise seront plus gourmand.

Maintenant ce n'est pas être fanatique ou sentimentaliste de considérer ECO comme un framework extrémement puissant n'ayant aucun équivalent dans le monde .net.

Techniquement ECO c'est vraiment bien.
Il reste juste aujourd'hui deux choses qui inquiètent : le manque de doc alors qu'on en est à la V 3... et l'avenir tout simplement de ECO au delà même des IDE Borland.

La doc commence à apparaître et les forums de borland sont une bonne aide. La seule incertitude pour moi et la continuité d'ECO.

Je pense que Delphi.Net va laisser sa place progressivement à C# (pourquoi pas une VCL C#)
Par contre, ce qui distingue BDS des autres outils c'est ECO et rien d'autres.

Je mise sur le fait qu'ECO survivra indépendant de Delphi.
Sous quel forme, seul l'avenir nous le dira ...
Qui sait , peut être qu'un jour ECO aura sa version open-source comme Interbase.

Quand à la VCL, si la tendance vers les interfaces agiles se confirme, je vois mal comment elle pourra s'adapter. Mais là on a encore quelques belles années :-)

[Merlin]

MVC, SOA ne sont certes pas des outils mais pas non plus des modes.
On peut faire la paralèlle avec le client/serveur à une époque.

Oui mais ce n'était pas une mode. Le C/S apportait réellement de vrais bénéfices par rapport àla "gestion de fichier réseau" de type Paradox par exemple. Plus fiable, plus puissant, plus sûr.
Le mode n-tiers remplace le C/S depuis quelques années. Ce n'est pas une mode non plus, c'est une motivation technique bien fondée.
C#, pour revenir au parallèle que tu voulais faire, n'est pas une mode non plus, il s'impose depuis des années avec .NET car il s'agit d'un véritable gain technique sur ce qui se faisait sous Win32.

On peut d'ailleur ici redire que Delphi.net, avec quelques petites réserves, fait partie de ce mouvement et qu'il est possible de bénéficier de tous les avantages de .NET en utilisant Delphi.net. Ce n'est peut être plus le meilleur choix, comme cela fut une évidence sous Win32.

Tu va te faire des amis :-)

je m'en fiche je ne fréquente pas de développeurs VB :-)
Et puis je suis cohérent, j'ai toujours dit que VB était nul, et quand on voit comme le langage a été bricolé sous .NET c'est pire, vraiment n'importe quoi en plus dêtre foutoir et illisible. Pauvres développeurs vb ...

Je parlais pas des particuliers puisque c'est pas ma cible.

ben si, relis ta phrase :-)

on est d'accord : dans au 2 ans.

non .. tu transformes ce que je dis...
un a deux ans pour les plus retardataires.. ça veut dire que .NET c'était hier qu'il fallait s'y préparer et y passer..
De plus, les gros logiciels prennent plusieurs mois, voire un an ou deux, entre les pourpalers et le déploiement... Donc tous les softs qui devront être mis en chantier en 2006 devront être .NET même s'ils sont en fonctions dans un an ou plus...

Tu confonds date à laquelle tout le parc sera majoritairement .net et date à laquelle les développeurs doivent déjà avoir fait leur conversion...

C'est pas plus dur mais il y aura moins de machine en net 2.0 qu'en net 1.1 donc si l'appli est basé sur le framework 2.0, les déploiements en entreprise seront plus gourmand.

Gourmands en quoi ? en place disque ? ... même chez leclerc le moindre PC bas de gamme à 500 euros est fourni avec dd de 160 giga.. c'est pas les 20 mégas du runtime qui vont saturer les disques hein :-)

La doc commence à apparaître et les forums de borland sont une bonne aide. La seule incertitude pour moi et la continuité d'ECO.

tu avoueras quand même que c'est du bricolage d'épicier ça... trois ou quatre ans après sa sortie, la version actuelle, la 3 "commence" à être documentée. ça frôle l'escroquerie pour ceux qui payent cher le produit parce qu'il y a ECO dedans malgré tout...
J'aime bien Borland mais ce sont des champions pour ce genre de chose. C'est pas sérieux d'en être à la troisième version d'un framework et qu'il "commence" à peine à être documenté. Ils ont fait le coup plusieurs fois, notamment avec les WebBroker et l'autre truc après dont je ne me rappelle jamais le nom (WebSnap je crois). Jamais été documenté, génial mais donc inutilisable, et donc... oublié... Toujours les mêmes erreurs. Y'a des types qui méritent d'être virés chez Borland USA, ça me semble évident.

Je pense que Delphi.Net va laisser sa place progressivement à C# (pourquoi pas une VCL C#)
Par contre, ce qui distingue BDS des autres outils c'est ECO et rien d'autres.

on est d'accord sur ce triste constat. Et pour ECO, sans doc, un produit n'existe pas pour moi... ça fait que la différence devient proche de rien du tout. Si, les IDE de MS sont en framework 2, delphi encore en 1.1.

Je mise sur le fait qu'ECO survivra indépendant de Delphi.
Sous quel forme, seul l'avenir nous le dira ...
Qui sait , peut être qu'un jour ECO aura sa version open-source comme Interbase.

Peut être. Car entre nous je vois mal le repreneur (hypothétique pour le moment) des IDE Borland reprendre tous ces gadgets géniaux qui coutent chers à fabriquer et maintenir alors que l'essentiel n'est pas effectué à côté de ça.
Par exemple, au lieu de faire ECO III, au lieu de bricoler Together, au lieu d'intégrer C++builder win32, etc, si toutes les équipes bloquées par ces projets avaient mises au boulot pour que BDS 2006 supporte le framework 2.0 ? Ne crois tu pas que l'avenir de Delphi serait certainement un peu plus clair aujourd'hui ? Moi j'en suis convaincu...
Et je pense qu'un repreneur, s'il ne veut pas mettre à la poubelle ces 100$ de dollar, va devoir faire des coupes sombres dans tous ces zinzins qui ont empeché Borland de gagner vraiment de l'argent avec BDS.

Quand à la VCL, si la tendance vers les interfaces agiles se confirme, je vois mal comment elle pourra s'adapter. Mais là on a encore quelques belles années :-)

Déjà avec .NET elle a pris techniquement un coup de vieux. Par exemple les événements non multicast, la séparation composants db/non db, son système de persistance objet "maison", etc...
Avec XAML ça sera encore plus le grand écart.
La road map prévoyait une adaptation d'ici 2008... c'est loi, XAML sortira avec Vista dans quelques mois...
Je crains que la sitation actuelle (la vente des IDE qui reste dans le vague) et tous ces retards sur un marché extrement dynamique ne coute cher à BDS.
Sauf si un repreneur se fait connaitre vite et qu'il investi beaucoup pour redonner confiance en l'avenir et surtout s'il est crédible... ça fait beaucoup de si.

[dem]

Merlin a écrit:

Y'a des types qui méritent d'être virés chez Borland USA, ça me semble évident.

A ce rythme là , ça va pas tarder....

Sans doc, un produit n'existe pas pour moi...

Bonne réponse ! Vous revenez en deuxième semaine !

Détrompe toi, je ne connais aucun particulier qui n'a pas XP ou au minimum W2000, alors que je connais très entreprise qui ont encore des postes W98, même si pour la majorité le remplacement est prévu cette année...

Je pense que beaucoup ne se rendent même pas compte en ce que cela implique humainement et financièrement de basculer une parc de plusiquers dizaines de serveurs et de pluisieurs centaines de postes d'un système vers un autre. Chez nous, nous sommes encore en W2000 et franchement avec des postes Celeron, WinXP ce serait l'enfer ! Même avec mon Pentium II 466 à la maison, j'ai renoncé à utiliser XP : c'est lent, ça plante, c'est l'enfer ! En repassant à W2000, je travaille enfin !

Il faut savoir que des fournieeur maintenaient encore dernièrement des solutions EDI en Win3.11 pour des corporations qui ne voulaient pas changer leurs solutions informatiques. Après tout, le client est roi ! Surtout que la gronde contre M$ n'est pas prête de s'enrayer vu les nouvelles politiques tarifaires qu'ils veulent faire avaler.

J'aimerais bien savoir ce que peu donner le Framework 2 sur une telle machine en termes de performances.

[Merlin]

A ce rythme là , ça va pas tarder....

c'est dommage ce merdouillage gigantesque autour de la vente des IDE, et cette décision débile de se séparer de ce qui fait la réputation de la boite pour aller sur un marché où ils n'ont pas de référence...
c'est du gâchi.

Bonne réponse ! Vous revenez en deuxième semaine !

youpi ! et qu'est ce qu'on gagne ? :-)

Je pense que beaucoup ne se rendent même pas compte en ce que cela implique humainement et financièrement de basculer une parc de plusiquers dizaines de serveurs et de pluisieurs centaines de postes d'un système vers un autre.

c'est assez lourd en général, il faut l'admettre...

Chez nous, nous sommes encore en W2000 et franchement avec des postes Celeron, WinXP ce serait l'enfer ! Même avec mon Pentium II 466 à la maison, j'ai renoncé à utiliser XP : c'est lent, ça plante, c'est l'enfer ! En repassant à W2000, je travaille enfin !

j'ai un vieux PII juste derrière moi, il est sous XP sans problème. Je dis pas que c'est une flèche... mais ça tourne. En revanche l'update automatique vers le SP2 avait tout planté. Il a fallut 1 heure de bricolage sous console en mode sans échec pour virer la maj SP2 et c'est reparti...
Mais ça marche.

J'aimerais bien savoir ce que peu donner le Framework 2 sur une telle machine en termes de performances.

pour tout dire, le framework 2 définitif est assez rapide. J'ai fait des essais sur le P II, c'est tout à fait raisonnable et comparable à la "vitesse" (ou lenteur) du reste.

[dem]

Faut pas exagérer non plus

un PII pour faire un peu d'internet, du mail, un peu de courrier, ça va !

Par contre, quand j'ai mis à jour mes solutions vidéo d'Adobe qui ne sont compatible qu'avec XP, là on se rend compte à quel poit le SE ralenti par rapport à W2000 sur la même machine ! Et puis il n'y a rien à faire, j'ai des plantages sous XP que je n'ai pas en Win2000 sur la même machine (avec le multi-boot, je fais ce que je veux, sur le SE que je veux).

youpi ! et qu'est ce qu'on gagne ?

Je l'ai déjà dis: un tour gratuit en deuxième semaine... tu vois Merlin, à force d'être sur plusieurs threads en même temps, tu perds la boule

[Merlin]

Je l'ai déjà dis: un tour gratuit en deuxième semaine... tu vois Merlin, à force d'être sur plusieurs threads en même temps, tu perds la boule

je pensais que comme y'avait plusieurs threads y'avait des lots différents.
Déçu je suis ...