Discussion :

[bidou]

Je vais rejoindre Maniak sur ce point. Même en étant expérimenté, ecrivez un code assez long sans l'option strict puis activez la. En toute rigueur vous devriez pouvoir dire exactement où ca va sauter avant l'activation. Et pourtant on est parfois surpris du résultat

Moi je ne suis pas spécialement fan des environnements coercitifs, mais je reconnais que j'utilise cette option puisqu'elle est un parfois un bon garde fou contre la bête faute d'attention. D'autant que dans VS2005, on peut régler l'utilisation des late bindings comme un simple warning quand on sait qu'on aura pas le choix.

[Kelpan]

Question subsidiaire : si tu pouvais bosser sur cette appli, mais depuis le début. Est-ce que tu choisirais de te reposer sur le late binding ou est-ce que tu ferais ton possible pour ne pas en avoir besoin ?

Je te dirais que cela dépend du type l'application.
En ce qui nous concerne, notre application doit pouvoir s'adapter aux besoins des clients et pas le client s'adapter à notre application.
Nous sommes dans le milieu de la gestion des ressources humaines et des salaires.
Nous avons une clientèle internationale est notre application doit s'adapter au mode de fonctionnement, de gestion du client et à la legislation du pays.

Pour nous, chaque nouveau client est un nouveau projet, avec ses spécificités à développer ou à adapter, sans que les spécificités des autres clients ne soient modifiées.
C'est pour cela que notre application est complexe.

Pour nous, la late binding (dans certain cas) permet de répondre rapidement aux client sans tout modifier dans l'application.
Donc oui, je pense que je choisirai de développer avec l'option strict à "OFF".
Par contre, je ne dis pas qu'une telle application ne peut être développé sans latebinding, mais cela impliquerai
- De revenir en permanence sur beaucoup de classes de base
- D'avoir le temps de la faire
- Mais aussi, d'engendrer de nouveaux bugs
- Et peut être d'autres problèmes auquel je ne pense pas...

[Herwin78800]

Je code en C# et c'est un vrai bonheur, même si je suis débutant, et je n'entrevois qu'à peine les possibilités de ce langage, et du framework .net en général.
Pour moi c'est C# dans la majorité des cas, et C++ dans des cas précis et restreints.

Mon appli du moment est un lecteur audio, écris en C# avec le framework .Net 2.0. Et ça me convient très bien.

Les seules restrictions sont :
- une certaine lenteur à l'exécution : 60 000 fichiers musicaux indexés dans un fichier xml, c'est lourd. Et le parcours de ce fichier pour afficher la bibliothèque multimedia met un certain temps en C# au démarrage de l'appli.
Un parcours de ce fichier en C, ou C++ serait sans doute plus raisonnable. L'autre solution étant d'utiliser une base de données.

- pour créer les effets visuels (courbe de gauss,...) en rapports avec la musique en cours de lecture, c'est sans doute techniquement possible avec C# et DirectX, mais je n'ai pas trouvé grand chose à ce sujet. C++ me semble donc plus approprié pour cette partie de mon projet

[Thorna]

Pour l'utilisation ludique, amateur et personnelle que j'en fais, Boo est très bien et correspond parfaitement à ce qu'il me faut: on ne se prend pas la tête avec des trucs trop compliqués et c'est un langage pythonesque qui sort un peu des classiques C & Co.

[FRED.G]

De quoi alimenter le débat ?

[FremyCompany]

De quoi alimenter le débat ?

Pas d'accord... on compare du bon code C# avec du mauvais code VB...

Qui, je vous pose la question, fait des boucles FOR avec des Object = Interger ?? Personne !

C'est de la manipulation de l'information...

Qu'on me fasse une comparaison entre late-binding - reflection !
Ca c'est de la vrai comparaison...

Ici on compare late-binding - code typé !
C'est totalement injuste...

[Maniak]

Pas d'accord... on compare du bon code C# avec du mauvais code VB...

J'ai pas vu beaucoup de C# vs VB là-dedans.

Juste des conseils de perfs qui sont tout aussi applicables en C# qu'en VB.

[Xzander]

Le premier langage de prog que j'ai appris est le VB6. J'ai ensuite passé à VB.NET. Après quelques mois, j'ai essayé C# et je ne le regrette pas. Personnellement, je préfère } à End If. Je suis conscient que } n'est pas très instinctif, surtout au début, mais on s'y habitue rapidement. J'adore écrire en code ultra condensé alors C# me sert bien.

[FRED.G]

Moi j'ai commencé sans faire exprès avec VBA, puis comme ça m'a plu, je suis passé à VB.NET. Et là je fais découvrir la prog à mon petit frère avec C# directement.
Car C# est le langage privilégié par la communauté .NET pour les sources et autres tutos.

[FremyCompany]

Ce que tu dis est ridicule...
Un code fait en C# est portable sans problème en VB.NET (mais pas nécéssairement inversément car Optional n'existe pas en C#, etc)
==> VB .Net est plus riche et plus simple à comprendre.

Je ne dis pas que les langages en { ... } sont mauvais (je suis fan de programmation JavaScript, par exemple) mais C# permet moins de liberté au developpeur que VB .Net, et surtout du point de vue de l'usage COM...

Je t'en prie, fait moi un beau code qui utilise le WebBrowser en C#... Tu seras vite bloqué car l'API (faite en VB .Net) qui relie COM et .NET est limitée (pas de submit de formulaire, pas accès à la fonction eval de JS, ...), alors qu'en VB .Net je passe par l'Active X non typé et j'ai accès à toutes les possibilités offertes par IE.

On m'a bien fait le coup de yield return xxx; Alors pour clore cette polémique idiote, voici ma réponse :

Code VB :

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

1
2
3
4
5
6
Public Function UsingYield() as List(Of Integer)
   UsingYield = new List(Of Integer)
   For X as Integer = 0 to 10
      UsingYield.Add(X)
   Next
End Function

La deuxième chose est qu'on dit que VB .Net est plus propice à l'erreur, et je suis pas d'accord... Les erreurs faites en VB .Net à cause de sa lacheté ne sont pas causée par les developpeurs VB .Net eux-mêmes, mais par les développeurs qui connaissent C# et qui sont obligés de développés en VB .Net. Ils n'ont alors pas l'habitude de gérer VB comme il faut et font des fautes "de débutant".

[FRED.G]

Ce que tu dis est ridicule...

Oulà, pense à calmer tes ardeurs mon petit. Pas un seul de tes arguments ne contredit mon propos qui n'est que le constat d'un fait et surement pas un jugement de valeur ! Je ne vais pas me répéter, il tient en une seule phrase et tu es hors sujet.

[Maniak]

On m'a bien fait le coup de yield return xxx; Alors pour clore cette polémique idiote, voici ma réponse :
[snip]

Et c'est quoi au juste le rapport en ça et le yield de C# ?

La deuxième chose est qu'on dit que VB .Net est plus propice à l'erreur, et je suis pas d'accord... Les erreurs faites en VB .Net à cause de sa lacheté ne sont pas causée par les developpeurs VB .Net eux-mêmes, mais par les développeurs qui connaissent C# et qui sont obligés de développés en VB .Net. Ils n'ont alors pas l'habitude de gérer VB comme il faut et font des fautes "de débutant".

Bizarrement, les développeurs C# que j'ai vus qui doivent faire du VB.NET font du code bien plus propre/clair/solide que les développeurs VB.NET 'purs'. Tout bonnement parce qu'ils appliquent les règles d'un langage plus 'strict' et évitent du coup les problèmes liés aux fonctions surpuissantes de VB.NET telles que... la conservation de l'héritage de VB6 et... euh... bah c'est tout en fait. Et vu que l'héritage de VB6 est une abomination sans nom dont l'utilisation devrait donner envie de vomir...

Blablabla COM blablabla, oui ok, mais heureusement on peut faire une petite DLL en VB.NET pour faire un wrapper autour de ces appels COM, en exposant ensuite une interface typée bien propre, utilisée par le reste de l'appli en C#. Et c'est bien dommage que MS ne se soit pas fatigué à le faire. D'autant que comme ça on peut s'assurer que les ressources sont bien libérées comme il faut, à un seul endroit, contrairement à ce qui a tendance à être fait par des dévs VB qui éparpillent les appels et créations d'objets COM aux quatres coins de l'appli.

(et hop, le topic repart pour une nouvelle boucle :)

[FremyCompany]

1.

Car C# est le langage privilégié par la communauté .NET pour les sources et autres tutos.

Ma réponse étant

Un code fait en C# est portable sans problème en VB.NET

Je vois pas du tout le hors sujet...

2.
Ben ma fonction fait exactement comme le yield
A chaque itération j'ajoute un élément à une liste "virtuelle" qui est retournée à la fin de la fonction. C'est strictement pareil à un certain

Code C# :

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

1
2
3
4
public IEnumerable<Integer>() {
   Integer x = 0
   for (x=0; x!=11; x++) { yield return x; }
}

3.
Quelle est la différence entre l'héritage en VB .Net et celui en C#...
Je tiens à rappeler que VB .NET comme C# ==> IL; et que l'IL ne gère qu'un seul type d'héritage (ben ca alors, ils ont pas fait une exception pour VB ??? Ben zut un argument de moins pour le C# alors... bof on finira bien par trouver autre chose... Ah oui, les developpeurs VB .Net veulent pas avouer qu'ils sont moins bons que nous et qu'ils comprennent rien à la programmation alors que nous on a tout compris... Franchement, si c'est pas un manque d'ouverture évident ! Tout le monde sait que C# est mieux. D'ailleurs MS developpe en C#... Sources ? Oh ben j'en ai pas... Ah, c'est normal ? Hein ? IL... Mais non, ils développent pas en IL... Oh, ce developpeurs VB .Net... Comprennent pas qu'on peut developper qu'en C#... D'ailleurs on devrait dire à MS qu'il doivent arrêter de dev de VB .Net... Pis de J# aussi... Pis de JScript.Net aussi... Pis aussi du delphi, c'est beacoup trop verbeux et ca fait tout le temps des appels aux API... Pis aussi de...)

EDIT:
Prière de ne pas tenir compte de mon "petit" speech
- Il sert juste à "détendre" l'atmosphère (lol, ca vous a pas fait sourrir de lire ca ?)
- Il ne reflète pas du tout mon avis

[FremyCompany]

Ah encore un truc :
4.
Je me considère comme un developpeur VB .Net pur...
- pur : qui ne résulte d'aucun alliage
- réutiliser du VB 6 dans .Net = alliage != pur

5.
Jamais développé en VB 6

[davcha]

De toute façon, ici il n'est pas question d'avoir fait le choix C# parce que c'est mieux que VB.NET, il est question d'avoir fait le choix C# parce que c'est ce qui est le plus utilisé pour les sources/tutos de la communauté .NET

Alors, n'importe quel code fait en C# est peut-être portable sans problème en VB.NET, mais là n'est pas la question.
Un français qui veut apprendre l'allemand se base sur des traductions allemand/français, pas sur des traductions anglais/allemand.

C'est une question de facilité de compréhension et, donc, de gain de temps.

[Maniak]

2.
Ben ma fonction fait exactement comme le yield
A chaque itération j'ajoute un élément à une liste "virtuelle" qui est retournée à la fin de la fonction. C'est strictement pareil à un certain

Code C# :

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

1
2
3
4
public IEnumerable<Integer>() {
   Integer x = 0
   for (x=0; x!=11; x++) { yield return x; }
}

Moui. Résultat identique, fonctionnement différent. Et vu qu'utiliser yield pour faire une bête boucle est un peu idiot, je vois mal l'intérêt de faire des comparaisons sur une utilisation de ce genre :)

Maintenant... pourquoi pas une itération sur une collection dont les éléments doivent être initialisés à la volée, initialisation qui prend beaucoup de temps ? Si tu n'as pas besoin de parcourir l'ensemble de la collection, avec yield tu n'initialiseras que les éléments parcourus.
Plus tout ce qui nécessite un suivi du stade actuel de l'itération.

Alors bon, je ne suis pas spécialement fan de yield, mais c'est pas une raison pour laisser raconter que ça ne sert qu'à écrire une boucle différemment :)

Inversement, yield n'est pas non plus un gros argument pour proclamer C# supérieur à VB.NET. Les situations où ce mot-clef est utile ne sont quand même pas si nombreuses que ça.

(grmbl grmbl grmbl)

He be ? Tu craques déjà sous la pression ? :)


Ah tiens, j'avais fait trop vite la dernière fois :

Qui, je vous pose la question, fait des boucles FOR avec des Object = Interger ?? Personne !

Oh si, un paquet de gens, c'est bien le problème.

Ici on compare late-binding - code typé !
C'est totalement injuste...

Totalement. C'est aussi ce que se dit Caliméro ainsi que ceux qui ont dû se taper des reprises de projets faits en VB.NET en abusant du late-binding pour cause de fainéantise/incompétence des développeurs, en se demandant "mais bon sang, qui est l'idiot qui a décidé de laisser les gens faire ça avec ce foutu langage ?".

À la base ce n'est pas un problème de langage. C'est un problème de développeur.

[FremyCompany]

À la base ce n'est pas un problème de langage. C'est un problème de développeur.

Ouf tu me rassures là... J'ai cru un instant que tu pensais vraiment que VB .Net c'était mal (lol)

En fait, le vrai problème, je penses (à ce que j'en ai compris du moins), est que la majorité des développeurs qui se disent "VB .NET" viennent du VB 6 / VBA et on acquis de mauvaises habitudes de programmation, qui dans des macros MS-Excel passent totalement inapercues, mais qui vont très mal avec le developpement de grosses applications .NET...

Mais dans ce cas, il ne s'agit pas de "pur" développeur .NET, vu qu'ils ont migré depuis une plateforme différente en pensant pouvoir faire pareil de l'une à l'autre....
------------------------------------
De toute facon, je pense personnellement que si un developpeur .NET n'est capable que de développer sur un langage, c'est qu'il a une vision fermée ou partielle de .NET et ne peut l'utiliser correctement. Evidement pour les développeurs C#, c'est moins grave vu que VB .NET n'apporte pas d'avantages réels (exception faite de COM, My, quelques ajouts spécifiques à VB pour X-LINQ, ...) mais pour un developppeur VB, ne pas savoir développer (un minimum au moins) en C#, c'est montrer une certaine incapacité à se structurer et s'emmerder ==> s'ennuyer (passez moi l'expression) à typer un peu ses convertions avec des (Type) partout...

Vous savez le non-typage a vraiment son intérêt coté gain de temps... son utilisation à mauvais escient elle en fait perdre 3x plus... Tout est question de mesure : "La carrence, comme l'excès, est néfaste" ou "Un bon verre de vin par jour est bon pour la santé, 2 tollérables, 3 ennuyants, 4 dévastateurs"

[Maniak]

Ouf tu me rassures là... J'ai cru un instant que tu pensais vraiment que VB .Net c'était mal (lol)

Ben c'est mal. Ça a une syntaxe tellement lourde et inutile que ça en est douloureux à lire.

Maintenant, ça c'est un avis perso totalement subjectif et pas du tout à vocation d'alimenter un quelconque débat :)
(et qui ne m'empêche pas d'avoir aligné pas mal de lignes de code en VB.NET depuis 6 mois, SSIS oblige. j'aime pas, mais il y a un boulot à faire, et aussi nulle que soit la syntaxe du VB.NET, il permet quand même de faire ce boulot :)

Sur un plan plus détaché et orienté développement :

En fait, le vrai problème, je penses (à ce que j'en ai compris du moins), est que la majorité des développeurs qui se disent "VB .NET" viennent du VB 6 / VBA et on acquis de mauvaises habitudes de programmation, qui dans des macros MS-Excel passent totalement inapercues, mais qui vont très mal avec le developpement de grosses applications .NET...

Rien à redire là-desus :)

Mais dans ce cas, il ne s'agit pas de "pur" développeur .NET, vu qu'ils ont migré depuis une plateforme différente en pensant pouvoir faire pareil de l'une à l'autre....

Là je te suis moins. Il n'y a rien de "pur" dans tout ça. Si par "pur" tu veux parler de quelqu'un qui n'a fait que du .NET, ce n'est pas de la pureté, c'est une expérience limitée à une plate-forme (et sans aucune garantie de qualité). Si tu veux parler de quelqu'un qui peut s'adapter à une nouvelle plate-forme quand il en change, c'est juste normal.

mais pour un developppeur VB, ne pas savoir développer (un minimum au moins) en C#, c'est montrer une certaine incapacité à se structurer et s'emmerder ==> s'ennuyer (passez moi l'expression) à typer un peu ses convertions avec des (Type) partout...

Il y a rarement besoin de faire des casts partout (ça indique plutôt un problème de design quelque part), mais sur le principe on est d'accord :)

Vous savez le non-typage a vraiment son intérêt coté gain de temps...

C'est bien là-dessus que tout se joue : "côté gain de temps".
Évidemment que ça fait gagner du temps à court terme. Évidemment que les risques de problèmes sont réduits sur de petits projets. Mais sur quelque chose de 'gros', est-ce que ça vaut vraiment la peine de risquer de perdre 3x plus de temps après-coup (au moment où les pertes de temps augmentent généralement de façon exponentielle) pour en gagner un peu au début ?

(exception faite des langages non-typés de base et qui le gèrent bien. il y en a pas mal, mais VB.NET n'en fait pas partie puisque bâti sur un framework typé et compilé en MSIL tout aussi typé, avec les ambiguités que ça implique au passage d'un mode à l'autre)

"Un bon verre de vin par jour est bon pour la santé, 2 tollérables, 3 ennuyants, 4 dévastateurs"

Un verre de vin par jour est suffisant pour être alcoolique, 4 à intervalles irréguliers peuvent causer bien moins de dégâts :)

Pas évident de trouver des règles qui s'appliquent dans toutes les situations :)

[FRED.G]

Je vois pas du tout le hors sujet...

C'est bien de le reconnaitre !
Mais rassure-toi personne n'aurait pu croire que tu fassses un HS exprès.
Pour le reste davcha a bien répondu.

[Kelpan]

(et hop, le topic repart pour une nouvelle boucle

Oui, avec moins de maturité apparement...

Les développeurs C# sont meilleurs que les développeurs vb.net

Pitié. Merci de nous épargner vos reflexions immatures...
Je pensais que la qualité d'un développeur ne s'appréciait pas selon le language.

De plus, vous donnez vraiment l'impression d'être à des années lumière de la réalité d'un projet. Tout cela manque visiblement d'expérience...