Discussion :

[Kelpan]

Désolé, j'ai pas été clair...

Tu dis VB est l'enfer des dll.

Si tu parles de vb6, on peut être d'accord avec toi.
Si tu parles de vb.net, ...

Quoiqu'il en soit, à part quelques irréductibles du vb6, personne ne contredira le fait que .net (que ce soit c# ou vb.net) est mieux que vb6. Il n'y a rien a prouvé de ce côté là !

Enfin pour expliquer mon "Je vois pas le rapport avec c#", tu serais passé à vb.net, ton problème "429, impossible de créer l'objet" aurait tout aussi bien disparu.

vb6 <> vb.net !!
C'est pas c# qui a répondu à ton problème, c'est .net

Désolé, ce genre de commentaire me fera toujours réagir et prouve qu'il n'y a pas beaucoup de monde qui se remet en cause qui vérifie par lui-même ce qu'il entend et vois partout.
J'ai pris le temps de comparer c# et vb.net et ... pour moi ... y en a pas un meilleur que l'autre (malgré ce qu'affirme commercialement microsoft !!).

Je défie quiquonque de faire quelque chose en c# qui soit irréalisable ou moins performant en vb.net et inversemment.

[Dung-Tri]

Désolé, j'ai pas été clair...

Tu dis VB est l'enfer des dll.

Si tu parles de vb6, on peut être d'accord avec toi.
Si tu parles de vb.net, ...

Ne soit pas désolé, c'est moi qui a été imprécis

Je parlais bien de VB6 ou autres variantes comme VBScript, VBA, VB Office....

Je me suis mis au C# pour toucher à plus d'open sources sur le net et pour avoir plus d'opportunités d'emplois. Si il fallait que je me mettent a faire des projets VB.NET, venant d'une culture VB, je pense ne pas avoir trop de difficultés.

Après commercialement microsoft oui. C# selon m$, est le premier language créé avec .NET, pour .NET, puis les autres ont été porté.

La syntaxe C# (voir C en générale) est moins explicit que le VB certe, mais en contre partit plus court. Faire un "int a" a la place de "Dim a As Integer", il n'y a pas photos.
Mais si niveau VB, la fonction With est aussi très interressante et inexistante en C#.

Les 2 languages se vallent au niveau compilation. Après dans la pratique peu de gens font du "pure .NET" en VB.NET. On retrouve souvant l'emploi du namespace Microsoft.VisualBasic, ces fonctions CInt, CStr, Chr(), Asc() qui rendent les developpeur VB plus productif ou pour une compatibilité VB6. Son emploi ne rend pas le programme forcement moins rapide mais cela le rend (par rapport a un projet VB.NET) légèrement plus lourd et reprend certains problèmes qu'on avec en VB6 (pas de gestion UTF32, les insertions à -1 sur les collections).

Pour te reconfirmer au sujet du "DLL Hells" oui avec .NET c'est bien fini!

[tomlev]

Je défie quiquonque de faire quelque chose en c# qui soit irréalisable ou moins performant en vb.net et inversemment.

Aaah, un défi
Voilà 2 exemples :

1. Itérateurs

Code C# :

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

1
2
3
4
5
6
7
8
public IEnumerable<Product> GetActiveProducts()
{
    foreach(Product p in _products)
    {
        if (p.IsActive)
            yield return p;
    }
}

2. Accesseurs d'évènements

Code C# :

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

1
2
3
4
5
6
7
        private HashSet<EventHandler> myEventHandlers = new HashSet<EventHandler>();
 
        public event EventHandler MyEvent
        {
            add { myEventHandlers.Add(value); }
            remove { myEventHandlers.Remove(value); }
        }

Tu vas me dire, on pourrait s'en passer... en général c'est vrai. Pour les itérateurs par exemple, on peut contourner le problème. Par contre pour les accesseurs d'évènements, je ne crois pas que ça existe en VB.NET


EDIT: au temps pour moi, les accesseurs d'évènement existent aussi en VB.NET. Ca doit être nouveau en VB9...

Code VB.NET :

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

1
2
3
4
5
6
7
8
9
10
        Private myEventHandlers As New HashSet( Of EventHandler)
 
        Public Custom Event MyEvent As EventHandler
            AddHandler(ByVal value As EventHandler)
                myEventHandlers.Add(value)
            End AddHandler
            RemoveHandler(ByVal value As EventHandler)
                myEventHandlers.Remove(value)
            End RemoveHandler
        End Event

C'est un peu trop verbeux à mon goût, mais bon...

[Guulh]

Aaah, un défi
Voilà 2 exemples :

1. Itérateurs

Vu l'usage extensif que fait Linq de ce genre de construction, il doit bien y avoir en VB un moyen d'écrire ça, non ? (dit-il en ne connaissant RIEN à VB )

Perso, ce qui me rebute avec VB, c'est la surabondance de mots clés. Je ne ressens pas de besoin impérieux de fermer chaque bloc différemment selon la façon dont je l'ai ouvert. Après, bien sûr, ce n'est qu'une question d'habitude.

D'ailleurs : cette verbosité est peut être un plus pour les gens de langue maternelle anglaise, pour lesquels VB peut ressembler un peu plus à du langage parlé. Mais pour les francophones que nous sommes, quid ?

[LLB]

Perso, ce qui me rebute avec VB, c'est la surabondance de mots clés. Je ne ressens pas de besoin impérieux de fermer chaque bloc différemment selon la façon dont je l'ai ouvert. Après, bien sûr, ce n'est qu'une question d'habitude.

Quand tu as des blocs imbriqués et que tu te retrouves avec des accolades fermantes à la suite, il peut être agréable de savoir laquelle correspond à quoi. Mais quand le code est propre, ce genre de besoin est normalement très rare. Il n'y a pas vraiment de lien avec la langue maternelle, puisque tu es censé comprendre l'anglais (au moins les mots-clés, quoi).

[Guulh]

Il n'y a pas vraiment de lien avec la langue maternelle, puisque tu es censé comprendre l'anglais (au moins les mots-clés, quoi).

Bien sûr, on comprends, mais ce n'est pas natif. Ce que je veut dire, c'est que pour moi, "if", c'est l'instruction conditionnelle ; ce n'est pas le "si" que j'utilise quand je m'exprime. Alors que pour un anglophone, il y a correspondance exacte (et pour cause, tous les mots clés de tous les langages majeurs sont en anglais).
Tous ces byval, byref, endif ne sont que des mots-clé pour nous, alors que ce sont des mots pour les angliches. C'est juste ça que je veux dire.

[spidermario]

Justement, pour certains mots-clés, ça peut ne pas paraître naturel à un anglophone de coller des mots ensembles (exemple : ByVal, ByRef comme tu les as déjà énoncés).

De plus, pour ma part, je ne trouve pas naturel non plus "fin si" ou même "fin de si"

"fin tant que"

[[Nean]]

C# est à mon avis, sinon le langage le plus évolué, en tout cas le plus simple à prendre en main, le plus clair et l'un des plus efficaces.

C'est un avis personnel, mais j'apporte ma contribution au débat...

[benji_dv]

Bonjour,

C# est le langage .NET par excellence (créé pour le Framework.NET), il est donc celui qui permettra le plus de choses, sans pour autant "cacher" les mécanismes (comme le fait VB.NET pour la gestion des évènements par exemple).
De plus, le module C# pour VS.NET est mieux fichu et plus fiable...

Donc à mes yeux... C# !

[prc_600]

Bonjour à tous, j'ai toujours été multilangage: basic, turbopascal, turbo C, turbo prolog (fidèle à à Borland), MASM dés l'achat de mon premier PC! Ensuite VB 3.0, je n'avais pas accroché à Delphi! Et j'ai continuer avec lui jusqu'au VB 6.0!

Faisant de l'électronique, j'ai été très longtemps réfractaire à la POO et ses fameuses boîtes noires! Et je suis devenu réfractaire au C++ car à l'époque, c'était à celui qui faisait le code le plus illisible possible (on aurait dit du LISP, je sais y en a qui vont râler).

La sortie de VB.NET a été une horreur pour moi, la conversion de mon projet VB 6.0 était impossible (le programme de conversion de l'époque voulait me faire changer 85 % du code juste pour des renommages ou des fonctions), j'ai fermé l'appli et j'ai refais le programme en Delphi 5.0.

Maintenant, je suis à fond dans les systèmes embarqués et le reverse engeneering de ceux-ci!

Et j'utilise donc peu les .NET et la plupart des systèmes utilisent le couple C++/gcc + assembleur (MIPS ou autre) mais comme j'en ai un peu marre de devoir chaque fois recoder des algos C++ en Delphi, je me suis dit on va refaire du C++ et dans la foulée je m'intéresse à C#.

Pourquoi pas VB.NET? J'ai été traumatisé!
PS: Y avait déjà l'option explicit! Et je faisais attention à ma casse!

Ensuite? Je vais peut être refaire du VB.NET / Delphi.NET aussi!

Si il est vrai quand se concentrant sur un seul langage, on peut en tirer la quintessence, en n'en pratiquant plusieurs on peut s'élargir l'esprit! Pa exemple, j'ai fait un programme en delphi qui prend du code MIPS sous IDA PRO et le transforme en source C.

Dev C++ n'a t-il pas été écrit en Delphi?

Après avoir lu les 32 pages de posts, je vois la lutte qu'il y a eu entre le bon codeur rigoureux (Maniac) et l'artiste (Freddy), je pense qu'on doit être les deux quelque soit le pinceau qu'on emploie tant qu'on laisse pas des poils de pinceaux dans la couleur!

Bonne journée à tous!

[Maniak]

Après avoir lu les 32 pages de posts, je vois la lutte qu'il y a eu entre le bon codeur rigoureux (Maniac)

Hey ! Mon k ! :)

et l'artiste (Freddy), je pense qu'on doit être les deux quelque soit le pinceau qu'on emploie tant qu'on laisse pas des poils de pinceaux dans la couleur!

Plus aucun souvenir de ce qui se disait à l'époque (j'ai une petite idée cela dit :), et depuis le temps il y a des chances que les arguments aient un peu évolué maintenant.

Cela dit pour ce qui est du combiné rigoureux/artiste, je dirais aussi qu'il faut les deux, mais chacun dans son domaine.

Le côté artiste, c'est pour les idées. Pour trouver les solutions aux problèmes, pour trouver l'inspiration souvent nécessaire. La rigueur, c'est pour coucher ça 'sur le papier'. Pour la rédaction elle-même.

Dans un contexte d'entreprise en particulier, écrire du code 'façon artiste' est une des pires choses qu'on puisse léguer à ceux qui passeront ensuite. C'est là qu'interviennent les conventions de code, règles de nommage etc. Et donc forcément quelque part là-dedans, le choix du langage peut avoir un impact, notamment selon le support des divers outils pouvant servir dans ce domaine.

Appliqué au duel VB.NET vs C#, le support plus que limité de ReSharper et l'absence de StyleCop en VB.NET participent en ce qui me concerne à continuer de faire pencher la balance du côté de C# :)

Je risque d'avoir à refaire du VB.NET prochainement (enfin pas pressé, une petite période de chômage c'est chouette pour prendre sa respiration :), et rien que pour ces deux outils-là, je grince des dents par avance. Je suis devenu très fan de StyleCop depuis son apparition. Faire un audit d'un bon paquet de dizaines de milliers de lignes de code VB.NET, contenant notamment des classes de plus de 8000 lignes... ce serait déjà bien lourd en C#, mais en VB.NET c'est juste une torture. Appliquer les recommandations de l'audit pour essayer d'améliorer la qualité du code... il faut avoir du temps. Et beaucoup, beaucoup de courage.

[prc_600]

Merci pour la réponse très instructive ke tu m'as donnée.

Comme dirait un certain Moorcook, l'ordre et le chaos!

Le côté artiste, c'est pour les idées. Pour trouver les solutions aux problèmes, pour trouver l'inspiration souvent nécessaire. La rigueur, c'est pour coucher ça 'sur le papier'. Pour la rédaction elle-même.

C'est effectivement mon avis aussi!

Merci pour tous les outils que tu cites, j'essayerai d'en faire usage, je ne code pas d'énorme projet ça reste toujours en dessous de 100 000 lignes, souvent des simulateurs/émulateurs pour du matériel électronique qui utilise peu les technologies NET et Co!

La rigueur dans le code est aussi ce qui permet pour moi d'avoir des programmes s'éxécutant vite et bien et facilement maintenable.

Mais parfois, la POO est une tueuse de vitesse et cela était l'un des rôles du programmeur de pouvoir éditer le binaire finale et d'y repérer les goulets d'étranglement que certains compilations apporte du C++ vers le binaire, du style les tables de sauts dues aux méthodes avec copie de buffer en buffer mais ce n'est plus possible à faire que pour des applications LIEES quasi définitivement au matériel et impossible à faire quand de nouvelles fonctionnalités ou mise à jour sont constamment demandées par le client/utilisateur et malheureusement on n'a pas souvent le temps de peaufiner à ce point!

Mais ici, je sort du cadre NET!

[calagan99]

Pour ma part, j'ai tout juste deux années d'expérience professionnelle, exclusivement sur du DotNet.
J'ai passé ma première année sur du VB.Net et la seconde sur de C#.

Aujourd'hui, je reste sur C# et je ne ferais pas demi-tour sauf si une opportunité vraiment intéressante m'était proposée.

Néanmoins, j'ai commencé le dotnet (et la programmation) avec VB.Net et j'ai vraiment apprécié ce côté verbeux que beaucoup de personnes décrient. Alors que je débutais, l'abondance de mots-clés, la gestion simpliste des évènements (dans VS, dans l'aspx d'une page, clic sur la DDL des contôles, clic la DDL des évènements liés et hop on retrouve son évènement côté .vb), les structures conditionnelles, le côté laxiste du langage m'ont aidé.
Plus dure a été la chute lorsque je suis passé à C#...
J'y est découvert beaucoup plus de rigueur, une gestion des évènements sans raccourcis, etc. Je m'y suis finalement vite fait car je connaissais le framework et n'avait qu'à apprendre la syntaxe du langage, mais je pense que j'aurais autrement plus galéré si j'avais débuté par du C#.

Je ne regrette pas mon choix et j'apprécie aujourd'hui beaucoup plus de développer en C# mais je ne dénigre pas VB car pour ma part il m'a vraiment été utile.

[MORJANE]

Ma formation est basée sur le vb.net, mais au cours de mes expériences j'ai pu travailler avec Java(Le langage le plus performant dans le monde) et maintenant je travaille avec C#, mais je trouve qu'il n'est pas assez fort que Vb.net, la seule chose qui oblige les développeur à le choisir c'est par ce qu'il rassemeble un peu à c++, java.... mais Vb.net reste plus riche en bibliothèques ainsi que sa facilité de syntaxe...

[tomlev]

maintenant je travaille avec C#, mais je trouve qu'il n'est pas assez fort que Vb.net

Ah ? j'aurais dit le contraire... les 2 langages sont quasiment équivalents au niveau de leurs fonctionnalités, mais C# a quelques trucs sympas en plus (itérateurs, expressions lambda multi-instructions, propriétés automatiques (ajoutées à VB2010 mais un peu moins souples qu'en C#), etc...). VB semble avoir certaines fonctionnalités en plus, mais la plupart ne sont pas vraiment liées au langage : elles sont fournies par les assistants de Visual Studio qui génèrent du code pour tout ce qui est My.Application, My.Resources, etc...

la seule chose qui oblige les développeur à le choisir c'est par ce qu'il rassemeble un peu à c++, java

Je pense qu'il y a des raisons autrement plus profondes que la ressemblance avec d'autres langages... D'ailleurs, même chez MS ils font presque tout en C# plutôt qu'en VB.NET

mais Vb.net reste plus riche en bibliothèques

C'est les mêmes bibliothèques qu'en C# ou n'importe quel autre langage .NET... Même celles qui s'appellent "VisualBasic.QuelqueChose", on peut tout à fait les utiliser à partir de C# ou d'un autre langage. Donc non, c'est pas plus riche.

ainsi que sa facilité de syntaxe...

Mouais... si tu veux, mais c'est très subjectif : personnellement je trouve la syntaxe de VB.NET absolument atroce... y a beaucoup trop de mots .
D'ailleurs c'est pas vraiment plus facile, c'est surtout moins strict et donc plus dangereux : VB.NET te fournit le pistolet pour te tirer dans le pied

[Morad ISSOULGHANE]

CSharp it