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
Discussion :
tu mélanges certaines choses. premièrement le mécanisme d'interpretation peut etre puissant. Tu peux effectuer des choses qu'il serait impossible a faire en compilé. Maintenant effectivement c'est moins rapide que du compilé.Envoyé par addicted_to_MFC
Deuxièment, les applis .NET ne sont pas interprétées mais COMPILE à la volée (JIT)!
OK .tu mélanges certaines choses. premièrement le mécanisme d'interpretation peut etre puissant. Tu peux effectuer des choses qu'il serait impossible a faire en compilé. Maintenant effectivement c'est moins rapide que du compilé.
Deuxièment, les applis .NET ne sont pas interprétées mais COMPILE à la volée (JIT)!
Je serais curieux de lire le meme type de resultats sur - disons - les 1000 sites les plus visites.
Ca donnerait une idee de la part de marche de Apache / MS sur les serveurs les plus solides.
L'idee, c'est que, a mon avis, ce qu'utilise Amazon.com est plus revelateur que ce qu'utilise chezKnotty.com
Si qqun a un pointeur, je prends.
Christophe Ludet
Testez vos connaissances Java - http://knotty.developpez.com
Donner des ailes a votre application (J2EE patterns) - http://knotty.developpez.com/j2ee
The site www.amazon.com is running Stronghold/2.4.2 Apache/1.3.6 C2NetEU/2412 (Unix) on Linux.L'idee, c'est que, a mon avis, ce qu'utilise Amazon.com est plus revelateur que ce qu'utilise chezKnotty.com
A voir ici
Il y à pas que amazon, il y à la majorité des grand sites, et la majorité des grand système d'informations, sous Linux/UNIX, et les salles de marchés, et presque toutes les applications télécom, etc etc....
Plus drole encore, plusieurs routeurs de MS sont sous UNIX....
Je crois que certains d'entre vous ne savent pas par manque d'informations que MS n'à JAMAIS été leader sur les serveurs. JAMAIS.
Historiquement les serveurs sont IBM (grand systèmes), puis cela à dévié sur UNIX et NOVELL et encore IBM, puis maintenant LINUX et encore IBM et UNIX.
Bill voudrais bien, mais voici une information :
C'est une INFORMATION, C'est un FAIT.Microsoft 11866718 31.87 9139785 25.39% -6.48%
PS : On devie totalement du sujet initial. Plutot que de troller pour contester des faits avéré, ce serais beaucoup plus intéréssant de publier des "retours d'informations sur .NET"
ta vu toute les cochoneries généré par les mfc?et tu n'as toujours pas répondu à mes questions. meme à partir du fichier de ressources, les controles sont créés dynamiquement pour les outils Delphi et BCB, tu n'as compris comment ils fonctionnent...oops :
avant la commercialisation et la diffusion de la nouvelle architecture de Visual Studio NET c.a.d. jusqu'à présent , une appli classique véritablement compilée en code natif ,pour afficher les contrôles crées en conception utilise un fichier de ressource , en fait un fichier script comme les fichiers dfm , tpu avec Delphi , Cbuilder , frm avec VB et rc MFC/Win32.
Basiquement avec le SDK win32 un fichier script .rc est compilé en fichier binaire .res lui-même lié avec les fichiers objets .obj issus de la compilation du code source.
Contrairement à la conception dynamique de contrôles , des références ou pointeurs à ces contrôles sont créees au lancement du programme et ces références pointent vers une dll , user.dll je crois .
Pour afficher 3 boutons , le fait d'utiliser un fichier de ressources ou de les créer dynamiquement comme en C#/NET ou Java n'a pas d'importance.
Mais qu'en est-il d'une (i] form [/i] contenant 50 boutons ??
Autre aspect vraiment crétin d'un outil RAD : prenez Visual Basic 6 ou .NET , Delphi ou C++ Builder .
Vous créez une fenêtre vous allez placez un bouton poussoir ou pushbutton .
Regardez tous les événements qui sont rattachés à ce bouton : pas moins de 10 événements...totalement inutiles comme savoir si la souris passe dessus .
En pure win32 ou avec les MFC ( ça y est c'est le conflit diplomatique !) , seulement 2 messages : BN_CLICKED et BN_DOUBLECLICKED
Selon le bon sens , un bouton c'est fait pour être cliqué ou non !
Alors pourquoi rattacher une dizaine d'événements aussi inutiles ?
Un programme Windows est architecturé selon une gestion de messages émis dans une file d'attente.
Vous allez me dire que je raconte n'importe quoi et quelle importance ?
Il y a un an , j'ai travaillé parmi une équipe de développement sur un gros projet client VB6 et serveur As400.
Il y avait 150 forms dans le projet VB ; et chacune contenait pas moins d'une dizaine de EditBox.
Au fur et à mesure du développement du projet , les gens qui développaient le projet se sont aperçus que ces zones de saisie ( EditBox) prenaient énormément de ressources et les ont remplacés ( c'est malin....) par des contrôles statiques ou labels...
Voilà pourquoi avec un outil RAD , on retrouve des imbécilités.
Si vous mettez 10 boutons sur un formulaire avec 10 méthodes chacune , cela fait 100 messages à traiter .
Comment le programme et l'OS traitent-ils tout cela ??
ta vu le code dernière les mfc, des macro a profussion
ta vu les performances avec c++ builder, delphi?
ils ont vraiment pas a rougir devant vc++...
essaye de faire des webservice, bd... vraiment pas donné avec vc++ surtout lorsqu'on débute
deplus rien ne sert de réinventer la roue a chaque fois... c'est pour ça que les composants existe...
si tu veux vraiment quelques chose de pro, regarde qt
ça c'est une librairie de qualité vraiment loin devant mfc
Juste une précision:
En passant par une ressource, on se réserve la possibilité de compiler pour une plate-forme en utilisant son format natif (s'il existe).
Cela génère moins de code.
Cela permet aussi de faire les changements cosmétiques sans recompiler.
C'est (c'était ?) le système du macintosh.
Et si le système ne gère que les ressources ? Comment diable générer un truc statique à partir de code dynamique ?
J'ai toujours considéré l'aspect de l'interface comme une donnée, pas comme une instruction.
Le mieux, comme d'habitude, c'est d'avoir le choix.
.NET donne-t'il le choix ?
Concernant Qt les classes sont sans doute performant mais pas fou chez TrollTech ,gratuit sous Linux mais payant sous Windows...ta vu toute les cochoneries généré par les mfc?
ta vu le code dernière les mfc, des macro a profussion
ta vu les performances avec c++ builder, delphi?
ils ont vraiment pas a rougir devant vc++...
essaye de faire des webservice, bd... vraiment pas donné avec vc++ surtout lorsqu'on débute
deplus rien ne sert de réinventer la roue a chaque fois... c'est pour ça que les composants existe...
si tu veux vraiment quelques chose de pro, regarde qt
ça c'est une librairie de qualité vraiment loin devant mfc
Et sont-elles bcp utilisées en milieu professionnel ?
* les cochonneries générées par les MFC ? c'est vrai c'est pas toujours lisible..il ya bcp de macro . C'est le gros inconvénient de ces classes.
*ta vu les performances avec c++ builder, delphi?
ils ont vraiment pas a rougir devant vc++...
Performances en temps de développement ?? GROSSES FOUTAISES !!
Performances en rapidité d'éxécution ?? Peut-être..
LA VCL est totalement incompléte , bien pour le débutant mais pour faire des applis robustes et complétes elle s'avère incomplète.
J'ai longuement utilisé C++ Builder (version 3 certes , la 5 et 6 ayant sans doute fait des progrés ) , je me suis arraché les cheveux de la tête pour faire une application avec une vue défilante. Quid de la sérialisation des classes alors que c'est déjà tout fait avec les MFC.
Un exemple : avec la classe TCanvas qui hérite de TObject et compagnie , il n'ya pas moyen de centrer le viewport contrairement à une classe CView des MFC; pDC->SetWindowOrg cela n'existe pas avec la VCL . Il faut bricoler comme tjs comme avec Visual Basic
* pour les webservices c'est vrai avec vc++ c'est impossible ( quoique avec VC7 )-> autant utiliser C# et NET.
L'informatique c'est vaste il ya plusieurs domaines d'application , je veux faire un modeleur 3d pour faire un Quake-Like , qu'est-ce que j'ai à foutre des webservices ????
*de plus rien ne sert de réinventer la roue a chaque fois... c'est pour ça que les composants existe...
Les composants c'est bien et s'ils sont incomplets ???
Un exemple : j'ai fait un shareware avec C++Builder : il ya des composants TPicture.
Je le teste sur une machine avec une video en 16 couleurs : impossible de lancer , l'appli, pas un message d'erreur.
Je lance une appli MFC : aucun problème .
Bon c'est sûr avec les MFC il faut tout reécrire.
Mais avec des composants tout fait on n'est pas sûr de tout contrôler.
Juste un petit complément à propos de la rapidité d'exécution de .NET, j'ai écrit un algorithme de traitement de chaine de caractères en pascal avec delphi 6, puis porté ce dernier sous VB .NET : la différence est stupéfiante !!
Le programme écrit en delphi est portable très simplement, et son exécution est 5 à 10 fois plus rapide qu'avec le même programme en VB .NET... j'ai développé plusieurs petites appli avec .NET, et j'en arrive toujours à la même conclusion : C'EST LENT, et DIFFICILEMENT PORTABLE !
Un énorme atout cependant : la doc fournie avec VS .NET est très complète et accessible aux "débutants", et l'interface de développement est tout simplement géniale.
Alex120 a écrit
Je viens de commander Visual Studio .NET après l'avoir dénigré...Le programme écrit en delphi est portable très simplement, et son exécution est 5 à 10 fois plus rapide qu'avec le même programme en VB .NET...
Je sais je suis un imposteur. Bon faut il que j'achète DELPHI alors ??
/mode avocat du Diable on
as-tu-utilisé String ou StringBuilder dans ton algorithme de manip de chaines ?
Parce que String n'est pas fait pour ça, justement
(voir Code optimization demos du dernier .NET show)
Du plus VB.NET donne le code le + lent de tout le runtime .NET, et de très loin: Tous les benchmarks publiés ça et là le montrent.
Dans ces conditions il est aisé de montrer que .NET "çaramecommepaspossible !"
Pour une juste comparaison, utiliser les classes adaptées au maniment des chaines (StringBuilder) avec C# serait + judicieux.
/mode avocat du Diable off
Have a good day !
.NET
En tout cas, lorsque j'ai installé XP sur mon poste, je n'ai pas remis .NET dessus. Par contre, BC et Delphi, oui. Je ne dis pas adieu à .NET car si ses principaux défauts (vitesse lente, gros runtime et portabilite) revenaient à une taille humaine, on pourrait dire que c'est le meilleur des environnements. Pour l'instant, c'est ultra loin d'être le cas et comme j'ai pas envie de passer pour un crétin de guignol j'ai même pas reinstallé le bétail sur ma machine
Faut arrêter les champignons, 120 méga d'install, grosse lenteur et tout rien que pour faire un logo sur un form transparent on est en droit de se demander quel genre de champignons les dev de chez ms mangent!
En fait, on peut se demander qui MS vise avec cette laborieuse distribution ? Vu qu'elle met de coté la grande famille des programmeurs de freeware et cie. En fait, il y'a un volonté marquée de dominer le monde du logiciel et d'empecher le free et le share (grande plaie des éditeurs) d'ailleurs la version beta de sa nouvelle plate forme palladium interdit la distribution de la dite plate forme incluse dans des freewares ou des licence open source - c'est que M$ défend sont steack et veut gagner du $ - rien à taper des utilisateurs et des programmeurs ! le jour ou m$ sera vraiment partout, la recession informatique sera alors de mise et les prix augmenteront de facon fulgurante (ce qui se passe déjà) en renforcant sa position dominante, m$ peut imposer ses prix. Enfin, le débat n'est pas la mais sur .NET
et .NET, en l'état actuel des choses, pour moi c'est un mauvais trip.
Et merci aux fanatiques de m$ de ne pas peindre ce forum de mensonges. Je vous lis déjà assez sur les newsgroups de microsoft en train de tenter de transformer tous les problèmes en avantages. Malgré ces tentatives des MVP et autres "evangelisateurs" de .NET j'ai fait un trait sur cette plate forme et j'ai perdu 15KF dans un abonnement MSDN que je ne suis pas prêt de renouveller.
A bon entendeur, salut !
Je trouve qu'il ne faut pas comparer des choses différentes, Delphi et .NET, c'est pas la même chose et ça sert pas à la même chose.
JE crois qu'il est nettement plus interessant de comparer .Net et Java (et donc les applications internet) (+technologies qui gravitent autour et que je ne maitrise pas tel que J2EE, Corba, etc...).
Et la je pense que .Net à sa place et permet un choix qui ne s'offrait pas vraiment avec isapi.
d'accord, il faut le runtime, mais télécharger ça ou la JVM, c'est presque pareil (et la question ne se pose même pas vu que c'est du côté serveur et que c'est transparent pour le client)
d'accord c'est seulement sur windows, ç'est effectivement une faiblesse, mais des portages sont en cours.
Bonne journée.
Ce que tu vien de dire n'apporte strictement rien au débat, ca déjà été dit 100 fois, ca n'à aucun intéret... .net versus java blablabla, en plus c'est Hors sujet, vu que le débat Java versus .NET c'est dans l'autre sujet de discussion (débat .NET versus Java), sur ce meme forum. Tu n'à rien compris au message précédent, je vais essayer de t'expliquer simplement :
1) Tu te sert de VB6 pour faire des petits frewares à télécharger
2) On t'apprends que VB6 est abandonné et que il n'y aura pas de VB7. Tu sais donc que si tu continue à développer avec VB6 c'est pas bon puisque le produit est mort (pas d'avenir).
3) Tu essaye donc VB.NET et .NET et tu te rend compte que il y à un énorme probleme de déploiement.
4) Tu passe à Delphi et tu te rend compte que :
(a) Delphi est un RAD extraordinaire et très puissant
(b) Ton applis devien plus compacte (de 400 Ko à 1 Mo avec Delphi, au lieu de quelque megs avec VB6, ou énormément plus avec .NET)
(c) Ton applis devien plus rapide (jusqu'à 40 fois plus rapide)
(d) Tu peux proposer la meme appli en téléchargement sous Linux et sous windows
C'est donc avant tout la question de savoir quelle est la solution par rapport à un besoin en particulier.
.NET c'est formidable pour plein de choses (ASPX, etc...), mais pas forcément à court terme pour développer des petites applications façiles à distribuer sur toutes sortes de machines anciennes, bien que effectivement dans le futur toutes les machines (au moins windows) auront la framework DotNet installée.
De par le fait VB.NET c'est pas forcément la solution de remplacement de VB6 pour tous le monde, ca peut etre en effet VB.NET, mais aussi C#, Delphi, Java, etc...
La réponse est : Ca dépends du besoin, et aussi de tes gouts...
ok, autant pour moi. J'ai peut-être confondut le sujet. Je n'y connais rien en VB et c'est vrai que je n'ai donc aucune expérience à partager.
Ton explication était très clair et à bien résumé le débat je pense. Merci
Je n'ai jamais apprecié Delphi. J'aime pas quoi. C'est uniquement viscéral, aucune raison technique mais il y a des trucs comme cela que je n'aime pas (la saucisse de morteau, les capres, la cervelle,
En effet, avec Borland, je ne suis pas obligé d'acheter XP ou 2000 pour programmer (finalement, .NET n'est pas si gratuit que cela) - Je suis certain que mes applications fonctionneront sur plus de plates formes, qu'ils possèderont autant de capacité, si ce n'est plus, que .NET - Je sais que mes programmes tourneront plus vite - Je sais aussi que je pourrait créer des exécutables autonomes ne nécessitant pas de runtime (et de problèmes de déploiements) - Je sais également que, compte tenu de la puissance de ces outils, je pourrais m'ateler à faire à peu prêt n'importe quel type d'application sans craindre que ceux ne se mettent à ramer pour x ou y raison (logiciel graphique, jeux vidéo, contrôle machine outil, systèmes embarqués, communication haute vitesse, temps réel, etc...) parce que .NET est définitivement un système ultra lourd.
Si maintenant, je dois créer des techno clients/serveurs, c'est sans me poser la moindre question que j'utiliserais JAVA car je n'aurais qu'a apprendre un seul langage, je sais qu'en apprenant ce langage j'aurais 250 fois plus de chance de trouver un job un peu partout (unix, linux, windows, Mac, etc) avec la garantie que le modèle de sécurité est fiable, tandis qu'avec C# je me ferme purement et simplement un nombre incroyable de portes, de systèmes d'exploitations; je m'assure aussi de prendre le risque de devenir une vache à lait pour une entreprise qui se soucie guère des utilisateurs et qui rendra mes programmes rapidement incompatibles d'une version à l'autre avec ses patch et autre mise à jours (VB6/VB.NET, J++/J#, C ANSI/VC++)
Maintenant, on peut toujours parler de .NET mais il faut bien avouer qu'il à bien peu d'avantages comparé aux outils existants - il est regrettable que ms ai mis 80% de son budget dev dans .NET sans penser à répondre à l'ensemble des attentes des programmeurs VB - Améliorer le langage, c'est bien mais si c'est pour le rendre super lourd et ultra dépendant d'IE, de XP ou 2000 ça perd de son intérêt.
Pour les afficionados de VB, il ne reste plus qu'a souhaiter qu'avec les 20% de budget qu'il reste peut être, MS fasse quelque chose de concret
Et, je dois rappeler quand même que ces critiques ne sont pas uniquement le fait de ma personne mais d'un nombre très important de programmeurs - il suffit de lire les news un peu partout - et de savoir que le patron de l'empire microsoft à dit : ".NET, ça démarre pas"
Rien d'etonnant, entre les produits difficiles et la politique du flickage total il reste pas grand chose pour séduire.
Je ne souhaite pas spécialiement intervenir dans les débats pour des raisons de neutralité, cependant je souhaite porter à la connaissance des lecteurs une précision importante en ce qui concerne cette affirmation
En ce qui concerne DotNET, Borland Propose Delphi 8 pour DotNet et C#Builder. En ce qui concerne C++ chez Borland, il semble que l'ancienne gamme Borland C++Builder dont la dernière version est C++Builder 6 soit arrétée, et remplacée par un nouvel outil basé sur un code très différent (similaire plutot à JBuilder) : Borland C++Builder X, dont voici le test :
http://c.developpez.com/cbxtest/
Cette première version ne supporte pas la VCL (donc probleme pour l'instant pour reprendre les applications C++Builder 6 /VCL) et d'autre part cette première version n'est pas spécialement destiné à DotNET mais pour l'instant à C++ANSI en Général (multiplateformes/multi-compilateur).
Dans le cadre de ce débat (Dotnet), les solutions offrant une bonne estimation de pérénité sont donc les suivantes :
- Pour DotNET : Principalement VS.NET, ensuite Delphi 8, ensuite C#Builder (par ordre de part de marché)
- Pour C++ pour DotNET : VC++.NET principalement
- Pour C++ ANSI en Général : Borland C++Builder X, Dev C++, etc...
Pas de pérénité pour Borland C++Builder 6.
Ce sont des faits pas des avis
PS : Je précise que bien d'autres langages et outils ont d'excellentes estimations de pérénité hors DotNet (exemples eclipse et jbuilder pour java, etc...)
Ne pas me contacter pour le forum et je ne répondrai à aucune question technique. Pour contacter les différents services du club (publications, partenariats, publicité, ...) : Contacts
15 000 offres d'emploi développeurs et informatique
Bonjour, cela fait bientot 1 an que je vous lis, ceci est pourtant mon premier post.
Je suis actuellement tenu de faire le difficile choix entre Delphi 7 (retour d'experience plus que connu sur le marche) et .Net (encore un "jeune" mais 2 ans de vie tout de meme) pour le developpement de notre nouveau produit.
Je viens de lire ces trois pages de debats, mais constatant les dates (2002) je me demande : qu'en est-il aujourd'hui ?
En effet 2002, .Net venait de naitre, c'etait l'inconnu. Maintenant il doit y avoir plus de retour d'experience.
Je suis issu du monde Java mais je dois reconnaitre que la productivite est encore difficile a atteindre avec ce langage et ces IDE (Eclipse ou WSAD), c'est ce qui fait que je me tourne vers des outils reputes plus productifs.
Delphi 7 me parait assez productif mais je reste septique sur le fait de pourvoir conserver une bonne productivite a partir du moment ou je souhaite faire une architecture du type n-tier.
Quels outils ? Quels erreur a ne pas commetre ?
Autant .net me parait proche de la philosophie J2EE autant j'ai du mal a y voir clair pour Delphi7.
Je n'ai aucune experience dessus, ni moi, ni mes autres collaborateurs.
Donc ma question : Qu'en est-il aujourd'hui, a la lumire de vos experiences ? Vers quoi aller ?
Bonjour,
Aprés 2 ans d'expériences sur dotnet, au niveau web principalement (ASP.NET) le moins que je puisse dire c'est que je ne suis pas déçu
Si ton nouveau produit :
est une applis de gestion (pour client windows)
Je te conseille VS.NET les yeux fermés. Attention, c'est un avis personnel qui n'engage que moi
Comme toi je trouvais java trés bien, le langage, mais je n'ai pas su m'adapter aux IDE... j'ai pas vraiment accroché... fesant du java pour mes études je n'ai jamais su être trés productif avec Jbuilder/éclipse, il y a 4 ans (j'ai pas testé depuis)
Tu parles de delphi 7, donc tu cherches un RAD puissant affin d'augmenter ta productivitée.
donc finalement 2 familles :
Mais je ne pense pas que delphi 7 soit une bonne solution, du moins pas une bonne solution d'attaquer des projet delphi 7 maintenant... tu vas faire des projet delphi 7 que tu voudra migrer en .NET d'ici 2, 3 allez 4 ans max... ça sera possible car delphi 8 migre les projets delphi 7 en delphi 8 for .NET mais quel interet de commencer à faire un projet win32 en pensant déjà à migrer vers .NET
Donc soit tu commences avec delphi 8 soit avec Visual Studio .NET ... aprés là on rentre dans un autre débat dans lequel je ne me risquerais pas ici
je te laisse juger par toi même : http://www.developpez.net/forums/viewtopic.php?t=58595
Merci Neo.51,
En fait le critere principal qui nous preoccupe est la productivite.
Nous avions envisagé Delphi8 mais apres coup nous nous sommes dit que tant qu'a faire du .NET autant utiliser directement l'outils le plus adapté. Le choix est donc Delphi7 ou VS.NET.
Actuellement ma direction cherche des arguments fiables en faveur de l'un ou l'autre. Delphi etant connu et reconnu pour sa productivite et sa fiabilite n'est plus a prouver. .net souffre de son image de jeunesse et de la politique Microsoft qui fait quelques fois reflechir.
La productivite est le facteur majeur car elle conditionne evidement le cout. Si nous ne pouvons nous payer un soft .net alors nous ferons du win32 en Delphi quite a migrer dans 4 ans apres avoir laisser murir les outils et amasser du cash.
Mais cette productivite ne doit pas etre au detriment d'un minimum de struturation technique permettant une maintenance simplifié et des ouvertures au niveau evolutivite.
Mon avis perso est que .NET offrira les meme gain de productivite voir meme peut etre plus (utilisation notamment de OlyMars).
Nous sommes editeur de logiciel mais ce n'est pas un produit sur etagere. Apres la mise en oeuvre nous rentrons dans deux problematique :
1. maintenance et deploiement de la version en place
2. evolution du produit en version superieure
Ce qui me gene avec Delphi c'est que je n'ai pas l'impression qu'on puisse structurer une partie serveur sous forme de tier comme il est assez natif de la faire avec J2EE ou .net. En tout cas si cela est fait, n'est-ce pas alors au detriment de la productivite de l'outils plutot axe Client Lourd/Serveur que multi-tier ? (a ce niveau je n'ai pas assez d'info).
Mais nous manquons de "temoignage" sur l'utilisation de .net. Quelques grande reference seraient peut etre plus convainquante.
Répondre avec citation
Partager