Discussion :

[davcha]

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
void main(){
  int *p;
  for(p=0;;p++)*p=0;
}

y'a pas que le VB qui permet de faire n'imp :p

[bidou]

S'il n'y avait que ca. Tu le dis toi-même, VB fait moins de choses (et moins bien!) que Delphi. Pourquoi utiliser VB?

Je n'ai pas dis ca. VB fais moins de chose, mais peut les faire tout aussi bien.

Je suis perplexe. Existe-t-il un programmeur confirmé Java, Delphi ou C/C++ qui n'a jamais eu besoin d'aller voir les sources pour comprendre et faire ses propores composants? Je l'ai très souvent fait, et ca permet d'autant plus de voir la puissance et de mieux comprendre le langage en question. C'est bien le minimum pour un développeur qui se respecte de comprendre les rouages de ce qu'il écrit.

Des sources de composant il en existe des milliers en VB. C'est même la plus grosse bibliothèque de code existant. Quand à comprendre ce que tu as véritablement écrit, sauf à aller lire le code généré...

La différence était au minimum de l'ordre de 30% de temps en plus sur VB5, même plutôt 50% et desfois plus.

Sur VB5 même beaucoup plus car VB5 est interprété. Mais VB6 sait générer un code compilé natif.

Non. Le "pro" sait quels sont les utilités et les capacités des différents langages. Ais-je sous-entendu qu'un vrai pro n'utilise pas VB??? Mais non, voyons.

Mais pour connaitre les capacités d'un langage, il faut savoir s'en servir. Et tes connaissances de VB6 sont plus que limitées. C'est normal si tu ne l'utilises pas, mais alors tu te lances dans un débat avec des idées préconcues. Bref le classique Troll.
Ca ne m'inquiètes pas plus que ça, car l'argumentaire anti-VB est toujours le même. Je constate simplement que ceux qui l'ont utilisé à un bon niveau et qui utilisent aussi d'autres langages ne le décrive pas comme ceux qui ne s'en servent pas.

VB n'est pas le plus rapide de tout les RAD. Il est plus rapide pour faire de la bidouille que les autres

Disons alors que jusqu'à présent, je n'en ai jamais rencontré de plus rapide. Et je ne crains pas de comparer mes codes aux tiens pour voir si c'est de la bidouille.

Très bien pour un débutant qui le restera

C'est reparti. Quand va tu comprendre que le fait d'utiliser Delphi ne fais pas de toi un bon developpeur. Ce n'est pas le langage qui fait le professionnel. C'est aussi stupide que de penser qu'on est un bon conducteur parce qu'on a une voiture qui roule vite.

Evidemment, quelqu'un de confirmé peut l'utiliser. Tant pis pour lui.

Ma foi je ne me plains pas

[davcha]

Sur VB5 même beaucoup plus car VB5 est interprété. Mais VB6 sait générer un code compilé natif.

Au fait, c'est vraiment du code natif ? Parce que même si c'est vraiment sans commune mesure avec la vitesse d'execution de VB5, il est tout de même nécessaire d'avoir la dll de vb6, il me semble.

[bidou]

Au fait, c'est vraiment du code natif ? Parce que même si c'est vraiment sans commune mesure avec la vitesse d'execution de VB5, il est tout de même nécessaire d'avoir la dll de vb6, il me semble.

Tout à fait. Dès que tu utilises des feuilles, tu dois avoir la DLL. Mais lorsque tu écris un composant qui fait du calcul, tu fais un composant sans formulaire et tu es alors en code compilé pur.
Malgré tout, d'après mes tests, Delphi est toujours plus rapide que VB même sans l'intervention du runtime.
Mais à mes yeux, VB6 ne se justifie (justifiais car maintenant...) que dans le cas des applications à IHM lourde.
Ou alors pour un simulateur de mongolfière

[davcha]

Ok, c'est bien ce qui me semblait. la dll de vb6 contient les différents conteneurs standards en fait.

Ca pourrait être fun de comparer un hello world console en VB et en C :p lol
Mais peut-on vraiment faire du mode console en VB ? J'avoue ne pas m'être intéressé à cette fonctionnalité potentielle, vu que c'est pas l'intérêt de VB.
Mais bon, pour le fun, ça peut être marrant.

[blbird]

C'est reparti. Quand va tu comprendre que le fait d'utiliser Delphi ne fais pas de toi un bon developpeur. Ce n'est pas le langage qui fait le professionnel. C'est aussi stupide que de penser qu'on est un bon conducteur parce qu'on a une voiture qui roule vite.

Mais on s'en fou de savoir si le programmeur est bon ou pas. A niveau de programmation égal, VB (code natif ou pas) est beaucoup moins bon que Delphi.
Et le développement en VB, a niveau de programmeur égal, n'est PAS plus rapide qu'en Delphi.

Faut-il vraiment encore faire une liste?

- langage non typé, peut clair
- pas de programmation objet (ou tentative de faire comme si, mais ca n'en est pas)
- lenteur des executables
- compatibilité multi-plateforme windows difficile : en Delphi, un .EXE tourne de windows 95 à windows XP en passant par Millenium sans aucun soucis et sans avoir à l'installer
- gestion des bases de données basique comparé à Delphi, ou on peut utiliser les alias, champs de BDD virtuels, ou les datasource et dataset sont visuels et très efficaces - ou comment coder une application entière de BDD sans presque aucun code, le tout avec un bind XML efficace pour tout ces composants
- accessibilité facile aux objets COM, aux framework de communication SOAP et WDSL et même communication avec des EJB Java
- gestion graphique pauvre d'une fenêtre, à comparer aux possibilités des panels, et des attributs anchors, align et constraints des composants Delphi (ce n'est qu'un ex.)
- mutli-thread?
- gestion de pointeurs?
- architecture VB orienté windows, à comparer à l'architecture Delphi orientée vers une abstraction du système sur lequel il tourne (windows principalement avec la VCL et CLX), recompilation linux si nécéssaire des programmes.
- pas de code source disponible

Il y aurait bien d'autres choses à passer en revue.

Je donne quelques pistes pour les gros défauts de Delphi :

- Debuguage nul comparé à ce qui se fait actuellement ailleurs (càd VB aussi :p)
- Compostant StringGrid (tableau) trop basique, mieux vaut directement en chercher un autre parmis les centaines de gratuits qui existent

Je n'ai jamais vu aucun interêt à choisir VB plutôt que Delphi. Je reverrais ma copie peut-être pour .Net, qui sait.

[davcha]

pour info : Le multi-thread est possible sous VB. La question avait été posée il y a quelques années sur la mailing list visualbasicfrance.
Par contre sa mise en place, c'est vraiment la croix et la bannière.

[grafikm_fr]

Faut-il vraiment encore faire une liste?

Oui, comme ca on pourra la démonter plus efficacement.

- langage non typé, peut clair

Conneries... Le VB est bien typé (forcement, si t'as pas mis "Option Explicit", ca peut etre dur...

- pas de programmation objet (ou tentative de faire comme si, mais ca n'en est pas)

Perso, j'en ai pas besoin...

- lenteur des executables

Il fait quoi ton EXE? Tu veux programmer Doom? Ne prends pas VB.
Tu veux programmer un bon logiciel de gestion. VB est tout indiqué pour toi...

- compatibilité multi-plateforme windows difficile : en Delphi, un .EXE tourne de windows 95 à windows XP en passant par Millenium sans aucun soucis et sans avoir à l'installer

Quand tu bosses pour une grosse boite, généralement t'as un seul et meme OS partout, ca réduit le pb... En plus, perso j'ai jamais eu de problèmes

- gestion des bases de données basique comparé à Delphi, ou on peut utiliser les alias, champs de BDD virtuels, ou les datasource et dataset sont visuels et très efficaces - ou comment coder une application entière de BDD sans presque aucun code, le tout avec un bind XML efficace pour tout ces composants

VB accède à tous les types de BD vivantes ou mortes, je l'ai meme utilisé pour acceder à des bases ERP sans problèmes... dans 99.9% ca suffit.

- accessibilité facile aux objets COM, aux framework de communication SOAP et WDSL et même communication avec des EJB Java

Tu communiques avec EJB tous les jours toi???

- gestion graphique pauvre d'une fenêtre, à comparer aux possibilités des panels, et des attributs anchors, align et constraints des composants Delphi (ce n'est qu'un ex.)

Et les APIs c'est pour les chiens???

- mutli-thread?

Pour faire quoi?

- gestion de pointeurs?

Ne prononce jamais ce mot devant moi
En plus, ByRef ca existe en VB...

- architecture VB orienté windows, à comparer à l'architecture Delphi orientée vers une abstraction du système sur lequel il tourne (windows principalement avec la VCL et CLX), recompilation linux si nécéssaire des programmes.

Si ton client a Windows, le pb se pose pas, et c le cas la plupart du temps...

- pas de code source disponible

Cf. la remarque de bidou plus haut...

[bidou]

Et le développement en VB, a niveau de programmeur égal, n'est PAS plus rapide qu'en Delphi.

C'est bien la que tu te trompes, il est beaucoup plus rapide. Mais comme tu n'en connais qu'un des deux, forcément ta comparaison n'a pas beaucoup d'intérêt.
Ce n'est pas la peine de nous faire un étalage de ton ignorance de VB car ta liste est un pure délire.

- langage non typé, peut clair

Donc le typage des variables n'existe pas en VB

- pas de programmation objet

Mais on arrive à faire des composants ActiveX, des classes ...

- lenteur des executables

Ben voyons. Fais donc un test de vitesse et revient m'en parler

- gestion des bases de données basique comparé à Delphi

Avec ADO, je te fais la même qu'en Delphi
etc...

Que tu aimes bien Delphi c'est ton droit et à mon avis c'est un très bon langage. Supérieur à VB sur bien des aspects d'ailleurs mais là n'est plus la question.
Mais tes messages sont remplis de débilités hallucinantes.
Tu fais une comparaison entre un langage que tu connais et un que tu ne connais absolument pas. Résultat on dirait une publicité pour de la lessive avec Delphi et la lessive X.
Ou tu veux avoir un débat argumenté, et on peut discuter sérieusement, ou tu poursuis dans ton délire mono-maniaque, mais tu le poursuis sans moi. Car là ca tourne au Troll, et je vais devoir faire le ménage dans le sujet.

Le top quand même

- pas de code source disponible

Quand on sait qu'il y a plus de code VB disponible sur le NET que de code JAVA, ca laisse réveur

[blbird]

Ce n'est pas moi qui ait parlé de développements professionnels en premier, mais effectivement, il n'y a, semble-t-il, pas de quoi le faire quand les réponses aux non-fonctionnalités de VB sont uniquement : "à quoi ca sert? pas besoin".

Ce qui répond à la question du thread, programmer en VB ce n'est pas bien parce que tu ne peux y faire que des choses basiques, qui sont déjà elles-même mieux faites et donnent de meilleurs résultats dans d'autres environnement de développement.

"A quoi ca sert VB? A rien, pas besoin.". Fin de la discussion.

Commentaires :
- concernant les API, pas compris la réponse. J'ai jamais parlé d'API, pas besoin d'API en Delphi pour faire ce que j'ai cité
- je n'ai jamais dit que VB n'accédait pas à des bases de données, j'ai dit que les méthodes d'accès visuelles de Delphi font bien mieux et bien plus simple (tout en étant entièrement codable cela va de soit)
- concernant le code source (le code source de ce QUI EST FOURNIT DE BASE AVEC LE LANGAGE, pas ce qu'on trouve sur le net...), le fait de l'avoir permet d'évoluer dans des méthodes de développement et dans la compréhension de ce qu'on l'ait fait d'un facteur de 1 à 10. Evidemment, pour ca, il faut avoir envie de s'améliorer.
- le test de vitesse c'est quand vous voulez, donnez une petite cible, un petit cahier des charges, aucun problème
- il y a un monde entre permettre de compiler un activex et faire de la POO. Personne des pro VB ici ne réalise l'interêt et la gain de temps ENORME d'un programme objet????

[bidou]

Ce qui répond à la question du thread, programmer en VB ce n'est pas bien parce que tu ne peux y faire que des choses basiques, qui sont déjà elles-même mieux faites et donnent de meilleurs résultats dans d'autres environnement de développement.

"A quoi ca sert VB? A rien, pas besoin.". Fin de la discussion.

Le vrai problème c'est qu'il y une couche opaque entre tes yeux et ton cerveau. Tu peux faire des choses autres que basiques, et elle donne les mêmes résultats. Ca ne sert à rien de nous resservir la même soupe sempiternellement, tu ne connais pas VB 6 et tes affirmations sont vides de sens.

- je n'ai jamais dit que VB n'accédait pas à des bases de données, j'ai dit que les méthodes d'accès visuelles de Delphi font bien mieux et bien plus simple (tout en étant entièrement codable cela va de soit)

Ca c'est la preuve de ce que je viens de dire. Quels sont donc les composant VB d'accès aux données que tu sais manipuler. Car ils sont tout aussi visuel et codable que ceux de delphi, j'ai écrit les cours ADO Delphi et VB de ce site, je pense être bon juge de ce qu'ils font.

- concernant le code source (le code source de ce QUI EST FOURNIT DE BASE AVEC LE LANGAGE, pas ce qu'on trouve sur le net...), le fait de l'avoir permet d'évoluer dans des méthodes de développement et dans la compréhension de ce qu'on l'ait fait d'un facteur de 1 à 10. Evidemment, pour ca, il faut avoir envie de s'améliorer.

Je ne vois pas en quoi le code source fournit de base est plus riche d'enseignement que les autres.

- le test de vitesse c'est quand vous voulez, donnez une petite cible, un petit cahier des charges, aucun problème

n'importe qu'elle application de gestion de base de données fera bien l'affaire

- il y a un monde entre permettre de compiler un activex et faire de la POO. Personne des pro VB ici ne réalise l'interêt et la gain de temps ENORME d'un programme objet????

Ne t'inquiètes pas pour nous va. Mais puisque tu es un tel expert, tu devrais passer plus de temps à aider tes collègues sur les forums techniques plutôt que de me faire perdre le mien avec tes trolls stupides. Car au vu de tes messages, tes extraordinaires qualités de codeur ne m'ont pas encore sauter aux yeux

[blbird]

Ca c'est la preuve de ce que je viens de dire. Quels sont donc les composant VB d'accès aux données que tu sais manipuler. Car ils sont tout aussi visuel et codable que ceux de delphi, j'ai écrit les cours ADO Delphi et VB de ce site, je pense être bon juge de ce qu'ils font.

Existe-t-il une gestion des TField (propriétés et évènements) en VB?

Je ne vois pas en quoi le code source fournit de base est plus riche d'enseignement que les autres.

Elle est sérieuse cette question? L'écrasante majorité des composants VB disponibles sur le net ne serait-elle pas basée sur le code de VB fournit de base? De plus, voir comment ont codés les créateurs des composants du langage permet facilement de voir la qualité des-dits composants. Souvent, des bugs mineurs ont été corrigés par la communauté Delphi avant même qu'ils soient officiels. J'éspère ne pas avoir besoin de faire l'étalage des avantages d'avoir un code source de ce qu'on utilise?

n'importe qu'elle application de gestion de base de données fera bien l'affaire

Sans base de données, pas envie d'installer un Access sur ma machine perso. Pourquoi pas une méthode de tri s'affichant au fur et à mesure de son avancement, ou alors une base de donnée XML?

Ne t'inquiètes pas pour nous va. Mais puisque tu es un tel expert, tu devrais passer plus de temps à aider tes collègues sur les forums techniques plutôt que de me faire perdre le mien avec tes trolls stupides. Car au vu de tes messages, tes extraordinaires qualités de codeur ne m'ont pas encore sauter aux yeux

Je ne me considère pas dans l'obligation de faire mes preuves. Amusant cette manière de vouloir toujours dénigrer les personnes sur les forums. J'ai suffisamment utilisé VB, Delphi, surtout Java ces derniers temps, et bien d'autres pour avoir un jugement significatif.
Et j'aide bien les gens ici, en leur expliquant que VB est un langage qui ne trouve son utilité que dans sa simplicité d'apprentissage, et que, à niveau de connaissance égale, Delphi fait mieux et est beaucoup plus ouvert sur les techno que VB.
Mais évidemment, toutes ces technos ne servent à rien. Amusant que j'utilise des EJB tout les jours, avec des serveurs qui supportent 60 millions de sessions par semaine sur plus de 12000 postes clients en France.

[bidou]

Existe-t-il une gestion des TField (propriétés et évènements) en VB?

oui mais il faut enlever le T
La gestion est un peu différente, mais c'est équivalent

Elle est sérieuse cette question? L'écrasante majorité des composants VB disponibles sur le net ne serait-elle pas basée sur le code de VB fournit de base? De plus, voir comment ont codés les créateurs des composants du langage permet facilement de voir la qualité des-dits composants. Souvent, des bugs mineurs ont été corrigés par la communauté Delphi avant même qu'ils soient officiels. J'éspère ne pas avoir besoin de faire l'étalage des avantages d'avoir un code source de ce qu'on utilise?

On trouve de tout. Et je suis d'accord sur l'intérêt d'avoir le code source. Néanmoins ce n'est pas vital d'avoir le code source de tout les composants.

Sans base de données, pas envie d'installer un Access sur ma machine perso. Pourquoi pas une méthode de tri s'affichant au fur et à mesure de son avancement, ou alors une base de donnée XML?

Fais un effort, comme ca tu pourras voir de tes yeux que pour ce type d'application, il n'y aura pas de différence de vitesse.

Je ne me considère pas dans l'obligation de faire mes preuves. Amusant cette manière de vouloir toujours dénigrer les personnes sur les forums. J'ai suffisamment utilisé VB, Delphi, surtout Java ces derniers temps, et bien d'autres pour avoir un jugement significatif.

Tu n'es pas obligé de faire tes preuve mais on n'est pas obligé de te croire non plus. Et tu connais bien mal VB pour quelqu'un qui l'a suffisamment utilisé

Et j'aide bien les gens ici, en leur expliquant que VB est un langage qui ne trouve son utilité que dans sa simplicité d'apprentissage, et que, à niveau de connaissance égale, Delphi fait mieux et est beaucoup plus ouvert sur les techno que VB.

Ca n'a plus beaucoup d'intérêt puisque l'avenir de Delphi comme de VB c'est .NET
Et je ne suis pas sur que ce style de débat, surtout argumenté comme cela change quoi que ce soit à l'opinion des gens.
Par contre sur les forums techniques, tu seras à coup sur plus utile.

Mais évidemment, toutes ces technos ne servent à rien. Amusant que j'utilise des EJB tout les jours, avec des serveurs qui supportent 60 millions de sessions par semaine sur plus de 12000 postes clients en France.

Tout ca sans savoir lire.
Personne ne t'as dit que ces technos ne servaient à rien. Mais il y a des milliers d'applications qui ne les utilisent pas.

[Barbibulle]

Ca me fait plaisir de voir qu'il existe des choses immuables.

Ataris Vs Amiga
VB vs Delphi ..

Quel beau troll quand même, j'ai l'impression que les VB-istes et Delphistes ont du mal pour garder leur calme quand on compare ces deux languages.

De toute façon ce débat est completement stérile car chacun reste et restera sur ses positions.

Les deux languages sont suffisamments bien et aboutis pour faire des développements pro et c'est tout ce qui compte il me semble.

Si on doit comparer des programmes réalisés dans chacun de ces deux langages on constatera de réèles différences (performance, ergonomie, etc..) mais qui dans 90% des cas sont du a une mauvaise maitrise du langage.
Il vaut mieux être un bon developpeur Delphi qu'un mauvais developpeur VB et inversement.

Pour ma part je suis sur Delphi pour deux raisons :
1- J'ai pas eut le choix, la grande banque dans lequel je travaillai avait fait ce choix pour les développements des applications coté client (à l'époque Delphi 1)
2- J'ai eut une mauvaise expérience avec VB juste avant que je me mette sur Delphi (c'était donc sur un vieux VB, je ne me souviens plus de la version)... Mais bon avec le recul je n'avais jamais eut de formation pro sur VB et je me suis retrouvé parachuté sur ce projet comme développeur VB... Ce qui m'a géné à l'époque c'était mon inexpérience VB et aussi que celui-ci comportait quelques bugs qui m'ont bien pourri l'existance qu'il a fallu contourner. Plus le fait que l'ambiance de travail n'était pas très bonne. Bref quand je suis arrivé sur Delphi tout m a parru bien plus beau. (C'est vrai qu'à l'époque je ne pense pas qu"on puisse comparer ces deux langages tellement Delphi était mieux (mais j'ai peut etre une vision un peu faussée )). Les sources de tous les composants fournis avec Delphi permettaient de corriger soit même les éventuelles bugs, et ça j'ai tout de suite aimer... Car c'est plus facile de corriger un bugs que de devoir expliquer au client non informaticien que si ca bug c'est pas ma faute mais celle de l'environnement de programmation.
La possibilité de faire des DLL, ses propres composants le tout dans le même environnement faisait de Delphi un langage en avance sur VB. Par contre le pilotage OLE automation était plus facile avec VB qu'avec Delphi.

Depuis les deux langages ont bien évoluées, Delphi à perdu l'avance significative qu'il avait. Il y a même eut des versions de Delphi... pas très... comment dire du niveau auquel Borland nous avait habitué (pour faire correcte) Un peu buggué (pour être plus clair). Bref Delphi s'est enrichie ennormément mais j'ai l'impression qu'il a perdu l'avance qu'il avait sur VB (Mais ce n'est pas que VB est devenu excellent, c'est que Delphi a baissé en qualité, je tombe plus souvant sur des bugs (que je peux corriger certe grace aux sources mais qui étaient moins nombreux (innexistant) dans Delphi 1)

La vrai question pour les gros nouveaux projets ou pour un débutant qui veux se former et donc s'investir dans un langage, c'est plus de connaitre l'avenir de ces languages...

Combien de temps VB et Delphi tel qu'on les connaient vont exister encore ?

Delphi 7 sera commercialisé jusqu'en 2005 je crois. L'avenir sera t'il 100% .net les deux mondes vont t'ils cohabiter longtemps ensemble ?
Borland annonce que l'investissement fait pas les développeurs Delphi ne sera pas perdu, car Delphi 8 (la solution .net de Borland) permettra de reprendre les projets précédents, et l'environnement existant et les composants classiques de Delphi (la VCL) fonctionneront sous .NET
Mais est ce que celà ne sera pas au prix d'un ralentissement dues aux multiples couches de l'architecture ?

Qu'en est il de VB ? Les mauvaises langues disent que microsoft n'a pas annoncé de reprise possible des projets VB vers .net. Est ce vrai ?

En considérant ces deux derniers arguments ne vaut il pas mieux faire dans le raisonnable (pour ceux qui débutent) et utiliser directement un langage natif .net ?

[davcha]

Sans compter que .net c'est microsoft, et que certaines personnes n'apprécient pas de travailler avec des outils purement microsoft. Visual Basic jusqu'à 6, c'est un peu différent, car ça reste du Basic, mais .net....

Mais bon, c'est un autre débat :p

[bidou]

La vrai question pour les gros nouveaux projets ou pour un débutant qui veux se former et donc s'investir dans un langage, c'est plus de connaitre l'avenir de ces languages...

Il n'y aura plus d'évolution de VB dans sa version native. Pour quelqu'un qui débute et qui veut utiliser VB, c'est vers VB.NET qu'il faut se diriger.
De toute façon, tout montre que l'avenir s'oriente vers les codes managés.
Le support de VB s'arrètera en 2008

Qu'en est il de VB ? Les mauvaises langues disent que microsoft n'a pas annoncé de reprise possible des projets VB vers .net. Est ce vrai ?

Ce ne sont malheureusement pas des mauvaises langues
L'expérience prouve que le portage (avec l'assistant) est très lourd. A mon avis, il n'est pas rentable de chercher à migrer les gros projets existants.

En considérant ces deux derniers arguments ne vaut il pas mieux faire dans le raisonnable (pour ceux qui débutent) et utiliser directement un langage natif .net ?

Pour ceux qui débutent, je suis entièrement d'accord avec toi.
Mais pour les développements actuels cela peut être un peu plus complexe. Car il faut prendre en ligne de compte le parc existant (machine & système)

A mon avis, la migration va se passer en deux temps. Les sociétés informatiques ou très consommatrices d'informatiques (services) vont migrer assez rapidement. Pour l'industrie cela va être beaucoup plus progressif, et suivre globalement l'évolution naturelle du parc. A terme, je suppose que seul C++ survivra dans les langages natifs, pour des applications qui ont besoin de vitesse et pour lesquelles la portabilité n'a pas d'importance.

Sans compter que .net c'est microsoft, et que certaines personnes n'apprécient pas de travailler avec des outils purement microsoft. Visual Basic jusqu'à 6, c'est un peu différent, car ça reste du Basic, mais .net....

Tu n'as pas tord, mais je pense que c'est un faux problème.
Les trolls, tel que le précédent, même s'ils sont amusant sont profondément réducteurs. S'il existait un langage en tout point supérieur aux autres, il aurait été adopté par l'ensemble de la communauté. Comme tel n'est pas le cas, la diversité des langages existe. Elle est d'ailleurs plutôt utile. L'arrivée de Microsoft dans le monde managé a réveillé SUN, ce qui est plutôt bien pour les développeurs.
Pour un professionnel, la considération de l'éditeur ne devrait pas entrer en ligne de compte. D'abord car le codage n'est que la partie émergée du développement, et que c'est plus sur la conception et la modélisation que repose le développement. N'importe quel développeur expérimenté apprend un langage en six mois.
Ensuite parce que se priver des produits d'un éditeur, c'est se limiter le marché du travail. Dans certain cas ce n'est pas un problème, mais c'est un luxe. Pour quelqu'un qui débute, je ne pense pas qu'avoir une attitude sectaire apporte quoi que ce soit.

[Barbibulle]

Les trolls, tel que le précédent, même s'ils sont amusant sont profondément réducteurs. S'il existait un langage en tout point supérieur aux autres, il aurait été adopté par l'ensemble de la communauté. Comme tel n'est pas le cas, la diversité des langages existe. Elle est d'ailleurs plutôt utile. L'arrivée de Microsoft dans le monde managé a réveillé SUN, ce qui est plutôt bien pour les développeurs.
Pour un professionnel, la considération de l'éditeur ne devrait pas entrer en ligne de compte. D'abord car le codage n'est que la partie émergée du développement, et que c'est plus sur la conception et la modélisation que repose le développement. N'importe quel développeur expérimenté apprend un langage en six mois.
Ensuite parce que se priver des produits d'un éditeur, c'est se limiter le marché du travail. Dans certain cas ce n'est pas un problème, mais c'est un luxe. Pour quelqu'un qui débute, je ne pense pas qu'avoir une attitude sectaire apporte quoi que ce soit.

Tout a fait d'accords, le plus important avant le codage (quel que soit le langage) c'est l'analyse du projet. Une mauvaise analyse donne un mauvais projet... Le développement en lui même ce n'est pas ça le plus difficile (si ça l'est c'est le plus souvant que l'analyse n'est pas assez précise (voir innexistante...)).
Si en effet il y avait un langage supérieur ça se saurait et en effet tout le monde essayerai de l'utiliser.
Je dit bien essayerai car le plus souvant ce n'est pas le développeur qui choisis le langage de programmation. Et ce n'est hélas pas parqu'un produit est très répendu ou très utilisé que c'est le meilleur. Sinon le minitel aurait été présent partout dans le monde, le betamax aurait supplanté la VHS etc...

Bref chaque langage à ses points forts et points faibles le tout est de choisir en fonction de ceux ci celui qui convient le mieux au projet et resources disponnibles.

[davcha]

Tout à fait d'accord également. Je pense qu'on peut répondre clairement au posteur original maintenant.
Il demandait quel était le meilleur langage de programation. La réponse est qu'il n'y en a pas. Et qu'il est plus important de travailler à la conception du projet puis de choisir le langage le plus adapté.

J'ai gagné ? J'ai droit à une image ? :p lol

[Bidouille]

Combien de temps VB et Delphi tel qu'on les connaient vont exister encore ?

Delphi 7 sera commercialisé jusqu'en 2005 je crois. L'avenir sera t'il 100% .net les deux mondes vont t'ils cohabiter longtemps ensemble ?

C'est une bonne question. Encore faut-il que les clients suivent les éditeurs. Lorsque tu vois que des grandes banques utilisent toujours Windows 98 maximum, je ne pense pas que tout sera redéveloppé.
VB et Delphi ont donc encore de beaux jours devant eux. Et donnons nous rendez-vous pour cela en 2006, histoire de faire un état de l'art.

[Keihilin]

C'est une bonne question. Encore faut-il que les clients suivent les éditeurs. Lorsque tu vois que des grandes banques utilisent toujours Windows 98 maximum,

Ha non, c'est pas vrai...

J'ai fait plusieurs missions pour 2 des 5 plus grandes banques privées européennes : environnement XP, nouveaux développements en .net, du Java pour la communication inter-systèmes...
Ca bouge pas mal...Dans l'avenir je vois plutôt une grosse cohabitation .net / Java...