Discussion :

[PsychicStorm]

Dans l'absolu, je ne voudrais pas que ce sujet tourne en polémique en disant qu'un logiciel est mieux qu'un autre, etc...

J'ai eu l'idée de ce débat quand j'ai compilé une petite application et quand j'ai vu la taille de l'exécutable que m'a fait delphi V7. Il y avait juste 1 fiche, 3 cadres et moins de 10 boutons en compilant ça me donne un exe de 350Ko ce qui fait beaucoup pour pas grand chose dans la feuille. donc je m'adresse aux spécialistes ici présent pour faire avancer ma problématique : Quel est le meilleur outil de développement RAD en considérant les critères suivants :

• Vitesse d'execution, coeff 2
  Taille de l'exe, coeff 3
  Ergonomie et facilité d'utilisation, coeff 3
  possibilités et puissance du logiciel coeff 4
  portabilité coeff 1

J'ai fait ces critères un peu à la va vite mais elle valent ce qu'elle valent. J'ai essayé de reprérer ce qui me semble important dans ce genre d'outil.
Je sais qu'il y a d'un coté visual XXX et de l'autre les outils borland mais je voudrais avoir des avis sur d'autres outils notemment powerbuilder et les moins connus afin d'avoir une idée des points forts et des faiblesses de chaque outils.

Je rappelle qu'on n'est pas là pour dire delphi c'est le top et VB de la M$@*#.

[Teuchteu]

J'ai juste une question. Dans l'"ergonomie et facilité d'utilisation", tu y inclus entre autre la facilité de comprendre le code, donc une modification plus rapide de ton projet si par la suite il devait être repris par une tierce personne?
Perso je tiendrai compte du langage utilisé avant de choisir l'outil. C'est en partie lui qui va jouer sur la vitesse d'exécution...
Exemple: la différence entre Delphi et C++Builder (tous les 2 Borland) tiens essentiellement des différence entre le C++ et le Pascal objet...

Je ne connais que VC++ chez Microsoft et je n'aime pas du tout l'utiliser pour 2 raisons:-je n'aime pas la façon de créer l'interface graphique (mais ça c'est personnel, peut être que d'autres aiment...)
- je n'arrive jamais à comprendre le code généré par l'outil (mais là c'est aussi en partie parce que je ne maitrise pas trop le C++, alors que pour Delphi je comprennais tout)

Pour finir, mon opinion, qui est partagé par toutes les personnes avec qui j'en ai parlé au travail (mais qui ne sont pas de pure informaticien) considère que les produits Borland sont meilleur techniquement que Microsoft, mais que ce sont les produits Microsoft qui sont le + utilisé dans le monde pro (va savoir pourquoi...)
Par exemple pour mon stage, mon maître de stage était d'accord qu'un RAD Borland aurait été plus efficace, mais il avait déjà une licence VC++ (car le compilateur est utilisé par un autre outil...) donc il voulait la rentabiliser...

Pour la taille de ton appli, ça dépend aussi de la taille de ton projet... Pour Delphi je pense que ton exe n'augmentera plus bcp en rajoutant 5 cadres et 8 fiches de plus, car ce qui prends de la place ce sont les librairies de fonctions pour ces composants, et non pas le code du composant...
Sache aussi que des fois l'exe peut etre petit mais accompagné d'un stock d'autres fichier aussi... Je crois aussi que Microsoft utilise les API de windows et non Delphi, donc le code de Delphi est plus portable (vers Linux via Kyllix) que celui des Visual...

Pour les possibilités et puissance du logiciel ça peut dépendre aussi de ce que tu recherche (utilisation de BDD, appli client/Server, ...)

Une dernière chose, le prix ne fait pas partie de tes critières non plus, est-ce vrai où seulement un oubli? Je ne connais pas les prix des outils Microsoft alors je ne peux pas trop comparer...

Et pour les éditeurs moins connu je connais pas trop... Mais je dirai qu'il faut se méfier des plus jeune qui peuvent souvent montrer un manque de maturité...

Je pense (et j'espère) n'avoir pas trop polémiqué...

[Anomaly]

Si la taille de l'exécutable est importante pour toi, alors évite .NET, les exécutables sont pas forcément gros, mais y'a le gros framework de 20 Mo qui va avec. Si la taille des exe delphi te gène (en sachant que la taille initiale est liée à la présence de la VCL, l'exécutable grossira raisonnablement par la suite), tu peux le compacter. UPX est un excellent outil pour ça (et libre, bien entendu), en ligne de commande, mais tes exécutables baisse au moins de moitié, et ceci sans ralentissement

[neo.51]

• Vitesse d'execution, coeff 2
  Taille de l'exe, coeff 3
  Ergonomie et facilité d'utilisation, coeff 3
  possibilités et puissance du logiciel coeff 4
  portabilité coeff 1

je vais reprendre tes critères 1 à 1

Vitesse d'execution, coeff 2

difficile de ce prononcer sans polémiquer. Il n'empèche que cela depend de tes algo, certain s'executeront plus vite en C++, d'autre en C#, d'autre en java... la rapidité d'exécution dépend aussi du SGBD, et suivant le SGBD certain couple sont plus performant que d'autres

Taille de l'exe, coeff 3

Si tu ne doit faire qu'1 déploiement, Bc++ et delphi semble produire les exe les plus petits. Si tu te tourne vers du java ou du .NET tu devras au préalable intaller la JVM ou le framework .NET qui sont assez volumineux. Par contre une fois qu'il sont installé sur le client les .exe doivent être plus petits étant donné qu'il y a déjà une grosse panoplie de librairies stantard installés avec ces frameworks

possibilités et puissance du logiciel coeff 4

Je pense qu'il faut choisir : 1)le langage, 2)L'IDE
Les IDE "haut de gamme" sont de nos jours de vrai petites merveilles.
suivant le langage :
C++ Bc++
java Jbuilder
.NET VS.NET ou C#Builder

portabilité coeff 1

Oublie les produit microsoft

Par contre faire des programmes portables équivaut à un petit sacrifice au niveau des performances.

Je t'invite quand même à lire les différents débats de ce forum pour voir par toi même qu'est ce qui te conviendrait le mieux pâr rapport à tes besoins.


bon courrage

[mat.M]

J'ai eu l'idée de ce débat quand j'ai compilé une petite application et quand j'ai vu la taille de l'exécutable que m'a fait delphi V7. Il y avait juste 1 fiche, 3 cadres et moins de 10 boutons en compilant ça me donne un exe de 350Ko ce qui fait beaucoup pour pas grand chose dans la feuille. donc je m'adresse aux spécialistes ici présent pour faire avancer ma problématique : Quel est le meilleur outil de développement RAD en considérant les critères suivants :

Vitesse d'execution, coeff 2
Taille de l'exe, coeff 3
Ergonomie et facilité d'utilisation, coeff 3
possibilités et puissance du logiciel coeff 4
portabilité coeff 1

Ce n'est pas parce que l'exe "pèse" 350 Ko simplement pour une fenêtre et 2 boutons que le programme va être plus lent que s'il n'était réalisé avec un autre outil..
Il n'est pas évident que le gain en performances avec un autre outil de développement soit significatif.
Avec n'importe quel environnement de développement , tu arriveras grosso modo à la même taille.
Pour ce qui est de l'ergonomie d'utilisation les environnement de développements proposent peu ou prou les mêmes contrôles de base parce qu'ils sont contenus dans cmnctrl.dll , contrôles communs de Windows.
Après il ya des librairies supplémentaires....propres à chaque outil de développement.
Si tu souhaites les performances accrues , alors autant réaliser le projet en C win 32 , mais trop fastidieux !!

Même si un exe compilé avec VB6 peut tourner parfois plus lentement , cela peut paraître négligeable pour un projet Base de données c.ad. info de gestion.
Projet VB6 ou Delphi avec Base de données , ce sera sensiblement la même chose car recours trés important à des requêtes SQL .
Par contre là où Delphi l'emporte largement c'est le cas où l'utilisation de processus ( threads) s'avère nécessaire.

Sinon Delphi est très bien pour développer et réaliser des projets.
Pour ce qui est de la portabilité du code , avec Microsoft ce n'est pas trop le top...

[Barbibulle]

J'ai eu l'idée de ce débat quand j'ai compilé une petite application et quand j'ai vu la taille de l'exécutable que m'a fait delphi V7. Il y avait juste 1 fiche, 3 cadres et moins de 10 boutons en compilant ça me donne un exe de 350Ko ce qui fait beaucoup pour pas grand chose dans la feuille.

Bon déjà je n'ai pas les même conclusions que toi. Si tu regardes QUE le code que tu as ecrit c'est vrai que 350Ko ça parait gros... Ta réaction est du au fait que tu n'as jamais fait de la programmation windows de bas niveau... Sinon tu te rendrai compte de tout ce qu'il y a à faire (en terme de programmation) pour arriver au même résultat... Pour être plus clair, les langages actuels du style de Delphi génère eux même (au travers de leurs librarie) tout le comportement des interfaces windows commun à toute application.

Je peux te dire que Delphi produit des exécutables tres petits.
Par défaut il incorpore à l'exe les librairies utilisées.. Mais contrairement à d'autres uniquement les fonctions utilisées par le programme compilé. C'est pourquoi les exécutables sont si petit (contrairement à ce que tu lui reproches).

Mais si le but du jeu est une diffusion de nombreux EXE via un réseau lent (internet). Tu as la possibilité de faire comme pour la technologie .NET C'est à dire de faire des packages. Cette méthode va séparer la partie librarie de la partie programme. Lors du premier déploiement, il faudra déployer les packages de librairies communes.
Mais une fois ce déploiement fait, tu pourra générer des exe qui n'incluent pas les librairies communes... tes EXE ne feront que quelques Ko.

Le gain de taille se fait sentir uniquement si tu as beaucoup d'EXE a déployer. En effet les packages des librairies communes ne sont pas optmisées par le compilateur cette fois car il ne peux savoir à l'avance quels sont les fonctions qui seront utilisées par les EXE...

[Aurelien.Regat-Barrel]

J'ai pas lu le débat, mais 350 Ko un exe c'est rien. Faut relativiser : une aplli vide fera 350 Ko. Une appli avec 10 fois + de composants fera ... presque pareil.

[Causa Sui]

C++ Bc++
.NET VS.NET ou C#Builder

Je remarque avec amusement que les programmes les plus courrus ne sont jamais ceux de microsoft (pour ne pas metre M$), même pour créer des application destinée à windows ou a la plateforme .NET (limitée a windows?). Il semblerait qu'un bon résumé de tous les psots est vive les IDE Borland (BC++, JBuilder, Delphi) et a mort ceux de MS... Amusant!

portabilité coeff 1

Oublie les produit microsoft

A propos: ne peux-on pas réver (j'en doute) d'une implémentation de la plateforme .NET sous d'autres plateformes (comme pour Java)?

[Bidouille]

Le RAD, c'est cette chose qui permet de générer à partir d'un modèle ou d'une analyse (UML, Merise...) une application complète.

Pour ma part, le RAD est aussi utile qu'un correcteur de grammaire. Sympa pour des petites phrases pas trop compliquées, imbitable pour un texte un peu évolué.

[neo.51]

C++ Bc++
.NET VS.NET ou C#Builder

Je remarque avec amusement que les programmes les plus courrus ne sont jamais ceux de microsoft (pour ne pas metre M$), même pour créer des application destinée à windows ou a la plateforme .NET (limitée a windows?). Il semblerait qu'un bon résumé de tous les psots est vive les IDE Borland (BC++, JBuilder, Delphi) et a mort ceux de MS... Amusant!

Personnellement pour .NET je trouve que Visual Studio est un exellent IDE et j'ai vu plus d''utilisateurs mécontents de C# builder que de VS.NET, si j'ai donné les deux c'est pour ne pas entrer dans le débat VS.NET VS C#builder car c'est hors sujet. Pour ce qui est du C++ Bc++ builder est un rad facile à prendre en main alors que VC++ est un vrai IDE pur de dur assez complexe à prendre en main mais reste un produit trés puissant : ma boite développe un soft d'optimisation de parcours avec des données cartographiques un bon gros progiciel de plus de 350 000 lignes de code, et eux qui maitrisent bien VC++ ont quand même réussit à faire de trés belles choses avec.

portabilité coeff 1

Oublie les produit microsoft

A propos: ne peux-on pas réver (j'en doute) d'une implémentation de la plateforme .NET sous d'autres plateformes (comme pour Java)?

[/quote]

.NET et java sont 2 frameworks différents il existe J# pour .NET : une syntaxe java pour attaquer le frmework .NET, pour ce qui estt de la portabilité, avec VC++ c'est vraiment pas gagné étant donné qu'on attaque les MFC. Par contre pour .NET sous linux, c'est pas une utopie : http://go.mono.org/
L'asp.net tourne déjà sous apache mais ils bloquent un peu pour porter les winforms sous linux. Enfin c'est pas trop dans le sujet du débat. Si tu souhaites intervenir reportons nous aux débats appropriés(voir les post-its dans ce forum)

Pour en revenir au problème de PsychicStorm

Je pense qu'il attaque mal le problème :
Tu as un besoin et des contraintes, à partir de ça tu détermine un langage ou une plateforme.
Je pense que c'est aprés que tu déterminesras les outils qui sont les meilleurs pour le langage ou la plateforme que tu as choisis

[iubito]

avec VB6 il fallait fournir des DLL (vbrunxxx.dll) ... chose que souvent les petits développeurs ki mettent un programme VB sur leur site oublient de faire.
Résultat :
- on n'a pas forcément la bonne dll (trop vieille)
- parfois on ne l'a pas du tout !
=> programme pas portable d'un windows à un autre

donc il faut fournir les dll plus d'1 Mo je crois, joli pour un appli de 15 ko!

Delphi, ton exe est au-to-no-me
Dans ma boîte l'énorme appli Delphi fait 7Mo sans dll !

alors oublie vite le .NET où il faut +20Mo de framework, sans compter les patch windows update pour mettre à jour (y'a eu combien de service pack déjà pour .NET ???)

Portable :
- Java (et encore tout dépend de ce que tu fais avec)
- Delphi (le code est portable sous Kilyx il me semble mais pas testé, et là aussi il y a des bibliothèques à ne pas utiliser, mais l'aide delphi le dit bien)
- peut-être un jour .NET....

[olrt]

avec VB6 il fallait fournir des DLL (vbrunxxx.dll) ... chose que souvent les petits développeurs ki mettent un programme VB sur leur site oublient de faire.

Est-ce que l'outil est là pour pallier aux déficiences des développeurs ?
Ma réponse est non. Un développeur doit être maître de son outil.
En l'occurence, pour livrer une application VB6 il y a une procédure à
suivre et c'est expliqué dans la documentation...

Delphi, ton exe est au-to-no-me
Dans ma boîte l'énorme appli Delphi fait 7Mo sans dll !

Bien.
Donc cela veut dire que si j'ai plusieurs exe Delphi à livrer, alors j'aurai plusieurs fois plusieurs Mo à livrer ?

Dans ce sens l'approche proposée par DOTNET est meilleure.
Il s'agit de livrer le .NET Framework une seule fois, et après on livre
de petits exécutables de taille beaucoup plus réduite...

[neo.51]

Dans ce sens l'approche proposée par DOTNET est meilleure.
Il s'agit de livrer le .NET Framework une seule fois, et après on livre
de petits exécutables de taille beaucoup plus réduite...

l'avantage de ce modèle (qui est le même en java) c'est qu'on a un framework stable et qu'on évite ainsi les problèmes de versionnings de dll.

Ce modèle marche trés bien mais pose un problème :
Si je veux développer une petite applis que je veux mettre en téléchargement sur internet!

je prends un exemple trés bête pour marquer les esprits

Si je veux faire un convertisseur Franc/euros, et le mettre en téléchargement, je vais proposer un exe de quelque ko mais il faudra aussi télécharger un framework de 20Mo pour un converstisseur franc/euros. Et là ça va pas être évident de convaincre l'utilisateur final.

Si je fais une suite logicielle pour une entreprise, avec des mises à jours régulières, des modules d'extensions, etc... Dans ce cas là il vaut mieux s'appuyer sur un framework qu'on va installer 1 fois, mais qui aprés va facilliter les futur déploiements et diminuer les problèmes de versionning.

Tout ça pour dire que le déploiement d'une application est trés différent suivant les cas.

[iubito]

sachant qu'il fo mettre à jour parfois le framework (failles de sécurité...)

[Causa Sui]

Si je veux faire un convertisseur Franc/euros, et le mettre en téléchargement, je vais proposer un exe de quelque ko mais il faudra aussi télécharger un framework de 20Mo pour un converstisseur franc/euros. Et là ça va pas être évident de convaincre l'utilisateur final.

Tout laisse a penser que ce genre de probème va dispraitre dans l'avenir, car microsoft va tout faire pour que chaque utilisateur final ait le framework. Ainsi présque chaqu'un le trouvera soit sur le CD d'un programme, soit déja installé sur son OS (pour les futur version de windows). Finalement même si l'utilisateur ne télécharge pas le framework pour un apli genre convetisseur il se retrouvera quand même avec ce logiciel installé sur sa machine. C'est pourquoi je ne prends pas trop en compte l'objection de la taille du framework dans la liste des défauts de .NET.

[iubito]

justement si il faut la prendre en compte parce que tu as toujours des gens pas doués en informatique qui tournent avec windows 95, qui arrivent à se connecter sur internet, et si dans yahoo ils cherchent le nom d'un logiciel, qu'ils téléchargent, et que ça marche pas parce qu'il faut le framework, ils vont être paumés!

c'est un peu comme le développement web, où on pense que les netscapiens sont passés à la version 7 et bizarrement y'a encore des fac/écoles qui trainent avec la 4.7 !!!
et quand il s'agit d'une école d'informatique, tu es souvent amené à aller sur internet et y'a pleins de pages incompatibles !
c'est pareil pour le .NET!

[olrt]

Ce que dit iubito est extrêmement intéressant et pointe l'un des plus gros défauts de la techno .NET : son incompatibilité totale avec la plate-forme Windows 95.

Comment justifier le fait que le .NET Framework est compatible avec Windows 98 et pas Windows 95, si ce n'est parce que Windows 95 n'est plus supporté par Microsoft ?

C'est cela qui m'énerve le plus dans la politique des produits de MS.
Pour assurer des bénéfices récurrents, une entreprise décide que
tel produit est obsolète et les utilisateurs doivent remplacer leur produit par tel autre non nécessairement meilleur techniquement.

Perso j'ai Windows 95 chez moi et je suis dégoûté de ne pas pouvoir jouer à des jeux récents qui exigent Windows 98 au minimum parce que l'installeur du jeu détecte la version de Windows ou bien parce que MS a décrété que DirectX 8.1 (ou 9 ou je ne sait plus) n'est plus compatible avec Windows 95.

[Causa Sui]

Certes pour l'instant le .NET brouille surment les pistes et rend les chose un peu plus compliquées; cependent l'informetique évolue et MS imposera probalblementle .NET et ainsi dans quelques années plus personne n'utilisera win95 (ce serait comme d'utiliser le 3.1 aujourd'hui ) et beacoup de monde (voir tout le monde) aura une bande passante suffisante pour pouvoir télécharger le 20 (?) Mo du framework en un minimu de temps. Je suppose aussi que tous les developpeurs intelligent qui developpent en .NET diront: pour le framework ddonc vous avec besoin c'est là => www.microsoft.fr/xxx

[neo.51]

A therme tous les produits microsoft seront développée sur le framework .NET c'est à dire que dés que vous installerez un produit microsoft vous installerez le framework .NET, il mes semble que c'est pas le cas pour office 2003(à confirmer) mais si tous les produits microsoftt en arrive à avoir le framework .NET dans leur install le problème de savoir si le framework est présent sur un client qui possède windows sera dans quelques année résolu.

On peu peut-être réver du framework .NET dans les prochains services pack de windows

[iubito]

Certes pour l'instant le .NET brouille surment les pistes et rend les chose un peu plus compliquées; cependent l'informetique évolue et MS imposera probalblementle .NET et ainsi dans quelques années plus personne n'utilisera win95 (ce serait comme d'utiliser le 3.1 aujourd'hui ) et beacoup de monde (voir tout le monde) aura une bande passante suffisante pour pouvoir télécharger le 20 (?) Mo du framework en un minimu de temps. Je suppose aussi que tous les developpeurs intelligent qui developpent en .NET diront: pour le framework ddonc vous avec besoin c'est là => www.microsoft.fr/xxx

Evidemment qu'il sera inclu dans les prochains windows, et évidemment que les développeurs indiqueront l'adresse...
par contre l'ADSL partout c'est utopique, quand on voit qu'à certains endroits il dégroupent, mais qu'à d'autres y'a toujours pas l'ADSL...
en clair ça va bien si dans ta boîte tu connais ton parc c tout du 2K/XP... le .NET pas de pb c'est le pied, mais à distribuer au public....

et je sais bien qu'un jour 2K sera abandonné et je serai obligé de passer à XP mais tant que je peux tenir, et que mes application chéries marchent sur 2K

Aujourd'hui, le 3.1 a quasi disparu parce qu'aussi beaucoup ne l'ont pas connu, les ventes d'ordi ont explosé avec 95 je pense.
J'ai encore le 3.11 sur un très vieil ordi mais je m'en sers jamais, c mon petit frère qui apprend à taper au clavier avec un logiciel sous DOS

et bon je connais des gens qui sont à win95 avec IE3 !!! (mais bon ils doivent pas aller souvent sur internet )