Discussion :

[Maniak]

Comme quoi on est pas d'accord.

Pour moi: petit projet = VB.Net, parce que plus rapide pour le développement même si peu adapté à la maintenabilité de longue durée.

Détail. La 'rapidité' de développement en VB.NET est toute relative et dépend beaucoup (essentiellement) du développeur. Pour toi c'est peut-être plus rapide, pour moi c'est plus long (le typage ne me ralentit pas le moins du monde), plus solide et bien plus facile à mettre en place (debugging, tout ça).

Le seul avantage ke j'ai vu au VB.NET juske là, c'est de ne pas avoir besoin de compiler pour voir les erreurs dans la liste des taches :)

Mais là c'est un choix perso. Après, savoir si on est d'accord ou pas dépend de si tu peux concevoir ke VB.NET n'est pas la solution la plus rapide pour tout le monde, ke ça dépend des gens, donc k'on prend ce k'on veut du moment k'on est à l'aise avec et ke ça reste à petite échelle.

Si tu assènes un "VB.NET est plus rapide pour développer pour tout le monde" là non, on ne sera pas d'accord. Ni maintenant, ni jamais :)

[DrQ]

Tout dépend si tu programmes en VB.NET comme en VB6 ou bien si tu fais réellement du .NET.

Dans le cas où tu programmes comme en VB6 alors il est possible que tu ailles un peu (vraiment un peu) plus vite.

[Maniak]

Tout dépend si tu programmes en VB.NET comme en VB6 ou bien si tu fais réellement du .NET.

Dans le cas où tu programmes comme en VB6 alors il est possible que tu ailles un peu (vraiment un peu) plus vite.

Vi, mais là on parle de .NET en principe :)
Et faire des projets soi-disant .NET en programmant comme en VB6... ok c'est peut-être plus rapide (kand on est plus habitué à VB6 k'à .NET), mais c'est pas trop le but :)

Pi bon, une fois habitué à .NET, je doute *vraiment* k'on aille plus vite en VB6. Mais vu ke ce n'est pas du tout la même façon de développer, je ne suis déjà pas sûr k'on puisse comparer.

[cjarnot]

Je ne me rappelle rien ou presque de VB.

Je suis donc parti avec C# ayant des compétences Java et j'ai batir des application Windows sans problèmes.

Je crois que C# est aussi le language le plus complet.

[cmaurice]

Bonjour,

c'est sûr que C# est vraiment un bon langage qui allie les avantages du C++ et du Java. La facilité de programmation du Java (pas de pointeur et de mémoire à gérer par exemple) et les performances du C++ pour une application Windows et non Internet (il faut dire que Java est portable partout mais pour une application, les performances ne sont pas des meilleures). C'est pour cela que j'aime bien développé en C# et j'ai encore énormemment de chos à apprendre mais je ne suis encore qu'étudiant donc ça viendra.

Cyrille

[Moonheart]

Mmm je pense que le but de ce thread est surtout de comparer les deux languages, aussi je me demande si encenser l'un sans le comparer à l'autre est bien pertinent...

Enfin sans vouloir jouer les rabas-joie.

[neo.51]

On le voit dans ce thread, on ne peut pas s'empécher de parler de vb6 ...



Je pense que le problème de VB.NET s'est que le vb souffre de son passé vb6,vba, vbscript qui fait plus pensé à des bidouilleur que les java ou le c++ qui ont une plus grande renomée.

C'est vraiment l'impression que j'ai en lisant les propos de Maniak

En tous cas je pense que le C# et le VB.NET resteront les deux piliers du framework .NET.

[Moonheart]

En tous cas je pense que le C# et le VB.NET resteront les deux piliers du framework .NET.

Jusqu'à Java.Net

[neo.51]

En tous cas je pense que le C# et le VB.NET resteront les deux piliers du framework .NET.

Jusqu'à Java.Net

tu parles de J# ?

[Moonheart]

Nan, je parles de Java.Net

[Maniak]

Je pense que le problème de VB.NET s'est que le vb souffre de son passé vb6,vba, vbscript qui fait plus pensé à des bidouilleur que les java ou le c++ qui ont une plus grande renomée.

C'est vraiment l'impression que j'ai en lisant les propos de Maniak ;)

Bah c'est pas k'il souffre de son passé, c'est k'il en hérite :)
La lourdeur de la syntaxe et le non-typage sont encore là. Et à en croire les arguments ki ont été avancés en faveur de VB.NET, le non-typage est la principale raison de l'utiliser. Hors, vu ke le non-typage n'est utilisable proprement (et encore) ke dans de petits projets, n'ayant aucun riske de devenir gros, ça limite forcément le champ d'action :)

Et là-dessus, je suis catégorike. Kelk'un ki prône le non-typage dans de gros projets, avec évolution, maintenance et tout ce ki s'ensuit, je demande à ce k'il soit pendu par les yeux, là, tout de suite :)

Après au niveau de la syntaxe elle-même, k'elle soit plus lourde est une évidence, k'elle soit plus claire est une kestion de goût (pour moi non par exemple, mais je sais bien ke pour d'autres c'est la syntaxe du C ki semble obscure :), bref c'est plus flou.

Par contre, vu ke j'ai tendance à utiliser des entiers non-signés chake fois ke je n'ai pas besoin de nombres négatifs (c'est un peu fait pour après tout), et vu ke VB.NET est (bêtement) complètement à la masse pour les gérer, poubelle :)

Vraiment, le seul avantage ke je vois à VB.NET, c'est de ne pas avoir à compiler pour voir les erreurs. Ça, j'aimerais beaucoup (beaucoup) l'avoir en C#. Mais mis à part ça... k'est-ce ke VB.NET fait ke le C# ne fait pas, ou k'est-ce k'il fait mieux ou moins lourdement... je sèche :)

Des idées ? :)

[BisonDiligent]

On dirait, à lire l'ensemble des messages qui précèdent, que l'on s'accroche sur deux ou trois points principaux :

1. Qui est le plus rapide? Faux débat! Si la performance est un facteur important, travaillez en C++ et évitez l'OO autant que possible. Si l'on parle de rapidité de rédaction, il faut se rappeler que celà ne joue qu'un rôle tout à fait négligeable dans le cadre plus général du cycle complet d'une application.

2. Le style, la lisibilité, la concision etc. Un vrai débat, car le style peut jouer un rôle important dans le cadre de la lisibilité et donc de la maintenabilité d'une application (ce n'est pas le seul facteur, évidemment ...). A ce que j'en lis, il n'y a pas de vrai progrès en la matière par rapport à VB6 (pour moi, le basic et le pascal sont des exemples de styles conçus pour être facilement lus et compris, le basic original insistant sur la simplicité, le pascal sur la rigueur). La syntaxe du c quant à elle a été conçue pour économiser les lignes de code, en ces temps anciens où l'en encodait encore en faisant des trous dans des petites cartes en carton...; par la suite, cette syntaxe concise a fait le bonheur de la caste universitaire.

3. Le caractère "professionnel" des langages. Les ingénieurs ingénieux n'auront jamais de gêne à utiliser VB pour obtenir une solution rapide vite fait, bien fait (il n'y a pas d'incompatibilité). Le marché étant ce qu'il est pour les informaticiens, Java et C#, cela fait indiscutablement plus "pro". Un tuyau à tous les pros en question : soignez votre orthographe, et votre style "rédactionnel", c'est indiscutablement un des premièrs indices de professionnalisme que l'on peut évaluer.

Bon, dans les mois qui suivent, j'ai justement une mission bien précise à effectuer (mémoire) : comparer la gestion des événements (au sens large) dans les langages OO : de VB6 (eh oui) à C#, en passant par Java et VB.net ...

Souhaitez moi bonne chance ...

[Maniak]

1. Qui est le plus rapide? Faux débat! Si la performance est un facteur important, travaillez en C++ et évitez l'OO autant que possible.

Ça fait longtemps ke l'argument 'performance' entre OO et procédural est devenu bidon, et totalement insignifiant kand on prend en compte tous les avantages de l'OO :)

2. Le style, la lisibilité, la concision etc. Un vrai débat, car le style peut jouer un rôle important dans le cadre de la lisibilité et donc de la maintenabilité d'une application (ce n'est pas le seul facteur, évidemment ...).

Surtout pour les non-développeurs. J'ai notamment comme exemple dans mon voisinage tout proche une grosse appli faite en VB, unikement parce ke des non-développeurs ont besoin d'aller y farfouiller pour changer kks bricoles par-ci par-là et k'ils comprennent bien mieux un langage plus verbeux.

Pour les développeurs, la différence de lisibilité est mineure (voire inversée), alors ke le temps de rédaction prend plus d'importance :)

La syntaxe du c quant à elle a été conçue pour économiser les lignes de code, en ces temps anciens où l'en encodait encore en faisant des trous dans des petites cartes en carton...

Euh, tu ne confondrais pas avec le Cobol là ? :)
C'est surtout lui ki a été fait pour les cartes perforées, avec ses lignes à commencer à une colonne particulière selon leur rôle :)

Bon, dans les mois qui suivent, j'ai justement une mission bien précise à effectuer (mémoire) : comparer la gestion des événements (au sens large) dans les langages OO : de VB6 (eh oui) à C#, en passant par Java et VB.net ...

Ben déjà, tu gagneras du temps en ne mettant ke C# ou VB.NET dans la comparaison, la gestion des événements est identike :)
Par contre, VB6 langage orienté objet, euh... non ? :)
C'est aussi OO ke du C++ dans lekel les classes ne servent k'à faire des structures un peu moins stupides :)

Souhaitez moi bonne chance ...

Bonne chance Jim :)

[BisonDiligent]

I love VB6 so much ...
Does simple things so simply!
Simple OO features, for 95 % of local application needs.
A people's language, so frustrating for real programmers!

Good to remember : OO was not required at all in order to manage the Apollo XIII crisis ...

Regarding events handling : VB has some powerfull event handling keywords that are native to the langage. So a very simple, straightforward event handling is easy to implement, enough again for 95 % of the usual needs.
Nevertheless, more complicated event handling "à la Java" is possible as well in VB, if required.

IMHO, VB is, simply spoken, THE reference, the starting point of any event handling study.

Best,

[Moonheart]

Ça fait longtemps ke l'argument 'performance' entre OO et procédural est devenu bidon, et totalement insignifiant kand on prend en compte tous les avantages de l'OO

Ca dépends du contexte. Parce qu'il n'y a pas que les IHM dans la vie, il existe aussi des applications avec de GROS besoin de performances, qui ne peuvent tout simplement pas se permettre de gaspiller du temps d'éxécution à la gestion objets, au garbage collector, et autres...

La syntaxe du c quant à elle a été conçue pour économiser les lignes de code, en ces temps anciens où l'en encodait encore en faisant des trous dans des petites cartes en carton...

Euh, tu ne confondrais pas avec le Cobol là ?

J'ai l'impression aussi.

Par contre, VB6 langage orienté objet, euh... non ?

Si si, même si ca reste l'OO du pauvre.

I love VB6 so much ...
Does simple things so simply!
Simple OO features, for 95 % of local application needs.
A people's language, so frustrating for real programmers!

Même pas... Pour moi un "vrai" programmeur est un programmeur qui sait se satisfaire de n'importe quel langage capable de faire ce qui a besoin d'être fait. (Ceci compte aussi la facilité de maintenance quand elle est requise, qui est le point faible de VB6 par rapport à Java et C#)

Par contre, "People's language" tu y vas quand même ultra fort sur la pédale, là... C'est verbeux, oui, mais de la à dire que n'importe qui peux comprendre du code VB6, c'est un peu excessif, ca reste un langage informatique... et donc a priori pas accessible à tous à moins de faire du code simplissime, ce qui est rare.

Good to remember : OO was not required at all in order to manage the Apollo XIII crisis ...

Ca... Dans le genre argument sans queue ni tête...

VB6 non plus n'a pas été requis pour gérer la crise de l'Apollo XIII, alors quel rapport avec le sujet?

N'importe qui peux sortir une phrase du genre: "Simple OO features was not requiered at all in order to manage the 9/11 crisis" mais ca ne fait pas avancer le schimilblick pour autant... d'ailleurs ce n'est même pas un argument: c'est tout un plus une belle phrase capable d'impressionner ceux qui vont pas creuser le sens des mots plus loin que la surface.

Regarding events handling : VB has some powerfull event handling keywords that are native to the langage. So a very simple, straightforward event handling is easy to implement, enough again for 95 % of the usual needs.

VB.Net et C# ont une gestion des évènements à peine plus compliquée mais surtout beaucoup plus souple et maléable... La simple présence des "délégués" les rends 10 fois plus puissants en terme de gestion évènementielle.

Oui, en VB tout court, tu peux gérer 95% des cas (et encore, ca reste à prouver... c'est quoi les sources d'une telle statistique?), mais les languages .Net le font d'une manière tout simplement 10 fois plus performante.
Essaie un peu de coder un évènement nécessitant des délégués sous VB6: tu vas y arriver avec un peu d'huile de coude, mais bonjour l'usine à gaz pour cela!!!!
Je ne parles pas du temps perdu au développement, à l'éxécution et surtout à la maintenance!

IMHO, VB is, simply spoken, THE reference, the starting point of any event handling study.

Au moins tu anonce clairement ton paradigme....

[BisonDiligent]

Vous l'aurez compris, il y avait là un peu de provoc, à différents niveaux.

Quand je dis que VB est la référence en gestion événementielle, je ne dis pas que c'est le meilleur, je dis que c'est un point de comparaison obligé, ne fût-ce que pour des raisons historiques.

Et tu ne me contredis pas, en fait, quand tu dis que le système des délégués est dix foix plus puissant (que VB) et presque aussi simple (que VB).

Quid des 95 %?
Simple : cherche sur le forum ou ailleurs des questions, des problèmes relatifs à "Public Event()", à "Raise Event", à "Public WithEvents" ... et rôle exact de doevents, qui est très mal expliqué dans la doc VB6. Il n'y en a guère et je crois en fait que très peu de programmeurs programment des événements (en dehors des événements des contrôles, bien entendu).

La phrase qui ne veut rien dire à propos du programme Apollo se veut un simple rappel : l'OO à tout casser n'est pas toujours indispensable. Tout le monde insiste sur la réutilisabilité, mais moi je me rappelle que deux des plus beaux crash de l'aérospatiales (Arianne V et je ne sais plus quel robot explorateur martien) se sont soldés par des échecs retentissants, parceque l'on s'était fié à cette notion de réutilisabilité, justement.

A propos, une bonne bibliothèque de fonctions, ce n'est pas réutilisable? On dirait que les méthodes de classe sont une découverte de l'OO?

Mais quid des fonctions mathématiques en tout genre?

Il y a beaucoup d'autres assertion jetées à la figure du public concernant l'OO, qui sont souvent des pétitions de principe, ou des "démonstrations" basées sur un exemple, alors que le contre-exemple existe mais est passé sous silence.

Bon, moi j'essaie d'être pragmatique, et, je me suis sérieusement attaqué à Java, pour éviter de parler sans connaître. Je ne suis pas au bout, loin de là, mais ce que j'en découvre ne me convainct pas toujours.
Il reste beaucoup de confusion, de procédés tortueux, c'est loin d'être "direct".

Bref, j'ai choisi mon mémoire sur un sujet de programmation, qui va me forcer à explorer un domaine bien particulier en .net et en java.

C'est pas de la bonne volonté çà?

[Moonheart]

Tout le monde insiste sur la réutilisabilité, mais moi je me rappelle que deux des plus beaux crash de l'aérospatiales (Arianne V et je ne sais plus quel robot explorateur martien) se sont soldés par des échecs retentissants, parceque l'on s'était fié à cette notion de réutilisabilité, justement.

Ca m'interresse de connaitre tes sources car je n'avais pas entendu la même chose personnellement.
Déjà parce que l'Aerospatiale n'est pas trop une utilisatrice de language OO (trop lent) et ensuite parce qu'il me semble que le crash d'Arianne V était du à un dépassement de capacité binaire ce qui est un problème plus du ressort des langages procéduriers ou assembleurs que des languages OO -qui soulèvent des exceptions dans ces cas-là-)

A propos, une bonne bibliothèque de fonctions, ce n'est pas réutilisable? On dirait que les méthodes de classe sont une découverte de l'OO?

Ce qu'apporte les méthodes de classe, ce n'est pas tellement l'avantage de la réutilisabilité (comme tu dis, une bibliothèque de fonction le fait aussi) mais plutot le concept de "boite noire" et d'héritage/dérivation, à mon avis.

Il y a beaucoup d'autres assertion jetées à la figure du public concernant l'OO, qui sont souvent des pétitions de principe, ou des "démonstrations" basées sur un exemple, alors que le contre-exemple existe mais est passé sous silence.

Comme toutes les propagandent publicitaires.

[BisonDiligent]

Bon, Arianne V => Le principe en cause : la réutilisabilté.
Pour ce que j'en ai lu, au moins une partie du logiciel qui fonctionnait bien sur Arianne IV a été transférée dans le système Arianne V sans être suffisemment testé dans son nouvel environnement (D'accord, c'est plus un défaut politique qu'un défaut logiciel)

Mars : une erreur d'emploi d'unité => ré-utilisation d'une partie de logiciel calculant en unités ango-saxonnes dans un logiciel plus moderne (je suppose) calculant en SI. Là encore, insuffisance de test et de simulation.

Bref, la ré-utilisabilité, ce n'est pas gratuit.

Une interface "boîte noire" est séduisante. Mais elle se présente à l'utilisateur sans spécifier réellement ce quelle fait : on ne connaît que la signature des méthodes, mais on ne connaît rien des spécifications réelles. Alors, si on ne fait pas un test sérieux ...

Bien. Je sais que l'OO apporte quelque chose, qu'une classe bien conçue, c'est chouette à utiliser.

Mais je pense que celà a un prix, et que dans certains cas, la programmation "procédurale" reste non seulement plus efficace, mais aussi plus naturelle. Et j'ai l'impression que le courant de pensée actuel présente l'OO une technologie de programation incontournable, une véritable panacée. On fait de l'OO pour faire de l'OO.

Ceci dit, je crois que l'on a bien divergé par rapport au sujet de cette discussion. Je m'en excuse, je ne suis qu'un "semi-professionnel".

Merci à tous, en tous cas pour les avis éclairés qui sont publiés sur ce forum.

[Maniak]

Bon, Arianne V => Le principe en cause : la réutilisabilté.
Pour ce que j'en ai lu, au moins une partie du logiciel qui fonctionnait bien sur Arianne IV a été transférée dans le système Arianne V sans être suffisemment testé dans son nouvel environnement (D'accord, c'est plus un défaut politique qu'un défaut logiciel)

Mars : une erreur d'emploi d'unité => ré-utilisation d'une partie de logiciel calculant en unités ango-saxonnes dans un logiciel plus moderne (je suppose) calculant en SI. Là encore, insuffisance de test et de simulation.

Bref, la ré-utilisabilité, ce n'est pas gratuit.

Euh oui, en koi la POO est en cause là-dedans au juste ?
Reprendre des modules et les coller ailleurs, ça se fait aussi en procédural, depuis longtemps, avec les mêmes implications.

Tu peux appliker le même raisonnement à tout et n'importe koi hein, ça ne veut strictement rien dire :)

À kand un "la canicule de l'été dernier, c'était la faute à la POO" ? :)

Pi bon, je doute ke ki ke ce soit ici soit en position de commenter ce ki se passe dans l'aérospatiale. C'est "un peu" plus pointu ke l'essentiel des projets ke le commun des développeurs fait à longueur de temps. Des erreurs ki n'auraient aucune importance en entreprise peuvent causer de gros dégâts en l'air.

Alors les critiker parce k'ils n'ont pas bien testé (ouh les feignasses) alors k'on n'a pas la moindre idée de ce ke ça demande, c'est un peu facile.

Mais je pense que celà a un prix, et que dans certains cas, la programmation "procédurale" reste non seulement plus efficace, mais aussi plus naturelle. Et j'ai l'impression que le courant de pensée actuel présente l'OO une technologie de programation incontournable, une véritable panacée. On fait de l'OO pour faire de l'OO.

Et je pense ke tu as tort. Tu ne parles ke du côté "réutilisation" (et encore), k'on peut très bien reproduire en procédural (ou plutôt, ki existait déjà en procédural avant ke la POO existe).
Les principaux avantages de la POO se situent en dehors du contexte "pissage de code". Va faire de la maintenance sur kks millions de lignes de code procédural. Va :)

[Moonheart]

Bon, Arianne V => Le principe en cause : la réutilisabilté.
Pour ce que j'en ai lu, au moins une partie du logiciel qui fonctionnait bien sur Arianne IV a été transférée dans le système Arianne V sans être suffisemment testé dans son nouvel environnement (D'accord, c'est plus un défaut politique qu'un défaut logiciel)

D'où l'interet du langage objet qui "encapsule" les méthodes avec leurs données: ainsi pas de problèmes du au fait qu'on emploie une méthode dans un environnement non-adapté... La méthode apporte son propre environnement (virtuel) avec elle.

Une interface "boîte noire" est séduisante. Mais elle se présente à l'utilisateur sans spécifier réellement ce quelle fait : on ne connaît que la signature des méthodes, mais on ne connaît rien des spécifications réelles. Alors, si on ne fait pas un test sérieux ...

Ce que tu présentes là, c'est une boite noire mal développée.
Une boite noire correctement développée s'accompagne TOUJOURS d'une documentation expliquant ce que chacune de ses interfaces fait... La seule chose d'une boite noire qui est censée être ignorée de son utilisateur en informatique, ce n'est pas ce qu'elle fait, mais comment elle le fait.

Et j'ai l'impression que le courant de pensée actuel présente l'OO une technologie de programation incontournable, une véritable panacée. On fait de l'OO pour faire de l'OO.

Propagande de ceux qui vendent de l'OO, ni plus ni moins.
L'OO c'est génial, mais c'est génial uniquement dans le contexte pour lequel l'OO a été créé... L'OO ne replacera jamais avantageusement un langage concu pour un domaine qui n'a pas été visé par l'OO au départ.
Par exemple, le C a été fait pour la programation système, l'OO non... donc l'OO n'a aucune raison ni avantage à être employé en programation système.