Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter
Pourquoi pas, ça peut être interessant de manière générale...
mais comme il s'agit d'un développement professionnel, je suis passé à autre chose depuis et j'ai trouvé une solution moins belle. J'avais pas trois jours à passer sur une c**rie comme ça !
Pour en revenir au choix du langage,
Ne trouvez-vous pas que la donne a sensiblement évolué avec .NET 2.0 et VS 2005 ?
Aprés 2 bonne année de C# je me suis remis récement à faire un petit utilitaire pour oracle en VB.NET. Et coté VB.NET il y a quand même un espace de nom qui est d'une puissance est d'une simplicité d'utilisation déconcertante c'est le fameux my
Fini les dizainnes de lignes de code pour les opération usuelles sur un fichier, récupération des paramètres utilisateurs en un clin d'oeil, etc...
http://webman.developpez.com/articles/vbnet/2005/my/
Difficile de dire comme on l'a dit avec .NET 1.* "VB.NET ou C# c'est juste un histoire de syntaxe". Certes on peut toujours faire les même chose en C# et en VB.NET, certes ce que l'on peut faire avec le "my" on peut le faire en C# (mais avec plus de code).
Mais même l'IDE de microsoft ne se comporte pas de la même manière en vb.net et en C#. Quand on est en VB.NET je regrette par exemple qu'on ai pas toutes les fonctionnalitées de reflexion de l'IDE que l'on a quand on code en C#. Par exemple créer un accesseur sur un membre privé d'une classe :
-C# : 3 clics
-VB.NET : code
Alors que créer un accesseur en VB.NET demande plus de code qu'en C# !
Coté snippets, alors que les snippets VB.NET sont trés nombreux, en C# on a trés peu de snippets (de base avec l'IDE) alors que justement le C# aurrait besoin de plus de snippets pour compenser le my de C#.
Bref on peut toujours faire les même choses en C# et en VB.NET mais suivant le langage et le type d'application on sera plus ou moins productif avec l'un ou l'autre.
Pour tout ce qui est bibliothèques de classe C# me semble plus productif notamment grace aux fontionnalitées avancés de l'IDE en therme de reflexion, mais coté Interface utilisateur VB.NET semble nettement plus productif grace à my et ses multiples snippets.
Franchement sur une application 3 tiers je me demande si le mieux serait pas faire la partie data et métier en c# et la partie UI en VB.NET
Vous savez, tous les gouts sont dans la nature. Souvent on critique certains langages parce qu'on ne les connait pas très bien ou alors parce quelques temps auparavant on s'est fait un bloquage psychologique ou tout simplement parce que c'est une question de gout: je veux dire, on aime ce qu'on utilise et on ne veut pas apprendre autre chose.
Pour ce qui est du C# et du VB (Dot Net) je voudrais faire remarquer qu'il est possible de faire exactement les mêmes choses avant chacun des deux langages, c'est juste la manière qui plus ou moins change. Le plus souvent, le choix est orienté selon le langage dans lequel on se sent plus à l'aise.
Moi, je developpe essentiellement en VB.Net 2005 et je le trouve génial.
Bien que je connaisse le C/C++, le C# ne me tente pas trop. Je reconnais que c'est un bon langage. Mais pour l'instant je prefere rester sur VB. C'est mon choix, je changerais peut être quand j'y trouverai des limites cruciales.
Je pense choisir C#, pour plusieurs raisons :
1. Je développe actuellement en PHP, et la syntaxe m'est donc familière (avec en plus des nano-bases en C++).
2. Je trouve la syntaxe de Visual Basic trop lourde (et si c'est la même pour la version DotNet, alors de même pour Visual Basic.NET).
3. C# est un langage que je pourrai utiliser aussi bien pour développer en C# sous Windows/Mono (encore que, je ne sais pas si le support est correct) qu'en ASP.NET sur Internet. C'est un avantage certain à mes yeux.
Tu sais faire ca en VB .Net aussi, tu sais :-)3. C# est un langage que je pourrai utiliser aussi bien pour développer en C# sous Windows/Mono (encore que, je ne sais pas si le support est correct) qu'en ASP.NET sur Internet. C'est un avantage certain à mes yeux.
je crois que si on utilise mono il vaut mieux se tourner vers C# il me semble que l'équipe de dev de mono se focalise sur .NET 2.0/C# en priorité. C# est un standard public (on peut récupérer les spécif) contrairement à VB.NET ce qui explique ce choix.
Bonjour
je pense que le langage importe peu, c'est la compréhension du framework dotnet qui prime, en ceci que dans une SSII, on peut avoir des projets à développer avec C# ou VB.Net ou avec d'autres langages.
MaheryIsika
Tu veux parler de ce fabuleux point d'accès global à plein d'objets et de ressources qui permet de coupler n'importe quelle partie de l'appli à des données qu'il aurait mieux valu découpler pour ne pas se retrouver avec un gros boxon intenable ?Envoyé par neo.51
C'est vraiment pas le truc qui me manque en C# non. Qu'ils laissent ça dans VB.NET, merci :)
Ça c'est le truc que je pige pas. J'ai vu plusieurs exemples des exploits de My qui permet de simplifier à mort des opérations comme copier/renommer/lire un fichier. Que des opérations qui sont des méthodes statiques sur la classe File.
Ce namespace n'est qu'un wrapper qui rend accessible globalement des choses qui devraient normalement être limitées à certaines parties de l'appli. Non seulement je ne vois pas l'intérêt (si, accélérer le dév de petites applis à la con, comme d'hab), mais je vois surtout les inconvénients vis-à-vis du code final...
Après pour ce qui est du comportement de l'IDE en fonction des langages... j'en suis là :
- IDE C# seul -> vivable.
- IDE C# + ReSharper (+VAssistX) -> miam.
- IDE VB.NET -> "mais pourquoi je suis puni ? j'ai rien fait de mal !"
Manaik, personne ne t'oblige à utiliser my.
Si dans ton esprit ça mélange tout ne l'utilise pas
Mais tu m'enlèveras pas de l'idée que le my permet de réaliser une multitude d'opération usuelles pour un développeur de mannière simplifié.
Quand je vois la mannière dont sont géré les settings en C# alors qu'en vb.net il suffit de faire :
pour récupérer la valeur d'un paramètre.
Code : Sélectionner tout - Visualiser dans une fenêtre à part my.setting.masetting
J'ai beau cherché j'ai pas trouvé l'équivalent avec une simple méthode statique en C#.
Code : Sélectionner tout - Visualiser dans une fenêtre à part
2
Je dis pas que my est la solution a tout problème, mais quand on veut faire quelque chose simplement le recours à my peut faire gagner beaucoup de temps.
Par contre coté IDE c'est comme toi VS 2005 m'aime pas quand je fais du VB, je me demande si c'est pas à cause de choix du profil "développeur C#"
T'en fais pas pour ça :)
(mais hey, mon nom :)
Possible, pour certaines, mais c'est comme beaucoup d'autres simplifications. Ça peut être pratique dans certains cas, mais entre les mains de gens pas particulièrement disciplinés, ça fait encore plus de chances de se retrouver avec des abominations.
(cela dit, c'est peut-être mon environnement actuel qui me pousse autant à me méfier des trucs qui donnent encore plus d'armes aux bidouilleurs en herbe, pour qui le seul objectif est de pondre le plus vite possible un truc qui marchotte vaguement)
(cela dit, je ne suis pas sûr que cette méfiance ne soit pas justifiée de manière générale)
Et ça fait quoi au juste ? :)
(pas trop eu l'occasion de faire grand chose côté applis win, je présume que ça les concerne :)
Ah mais là je ne contredirai rien :) Quand on veut faire quelque chose simplement et rapidement, tous les raccourcis sont bons à prendre (bon, dans certaines limites quand même. rien dans cet univers ne peut justifier de ne pas activer option explicit *et* option strict)
Quand on veut/doit faire quelque chose de propre, béton, bien organisé, avec le moins de couplages possible, un truc qui donne accès à tout et n'importe quoi depuis n'importe où, j'ai une petite appréhension. À tort peut-être, mais jusque-là je n'ai rien vu qui puisse me pousser à voter pour My en tant qu'avantage du langage :)
(dans le même genre, je n'ai encore rien vu non plus qui puisse me faire considérer yield comme un avantage du C#)
(par contre les méthodes anonymes, miam. rien que ça, ça vaut 50 My :)
Le profil c'est juste le layout des fenêtres normalement. C'est pas ça qui va ajouter des fonctionnalités inexistantes côté VB :)
Je voudrai juste rebondir ce temoignage. Si je n' me trompe on peut faire la même chose avec Refactor! qui est gratuit :
http://msdn.microsoft.com/vbasic/dow...ools/refactor/
Celà dis moi j'utilise sytématiquement le snippet pour ça : prop + tab ( aussi bien en VB qu'en C# ) c'est super pratique.
De toute façon c'est une question d'habitude avant tout, les deux langages permettent de coder trés rapidement quand on est habitué ( alors que je trouvais l'intellisens du C# un peu faible en VS2003 ).
A ben oui forcément, tout l'interet du my se trouve dans les applications windows
On a beaucoup moins besoin d'avoir accés aux caractèristiques de la machinne cible sur une applis windows que sur une applis ASP.NET
Je comprend mieux ton point de vue Maniak
Concernant le plugin réfractor c'est une bonne nouvelle mais je ne comprend pas pourquoi ce genre de chose n'est pas intégré de base dans VS 2005.
... un peu comme les snippets C# ...
Vu que je me suis tapper les 24 pages de posts, je vais mettre mon avis.
La synthaxe VB, C# ben c'est une histoire de gout
La rapidité à codé avec une synthaxe ou l'autre euh je suis pas sur que la différence soit énorme. Et normalement on passe plus de temps à trouver le code à tapper qu'à le tapper...
J'ai programmé en C# et VB.Net
Je n'aime pas VB.Net pour ses options strict et explisit désactivé par défaut (tout le monde ne pense pas à les activés quand ils savent qu'elles existent)
L'absence des events dans IDE (on ne voit que les propriétés des controles dans l'environement graphiques) entk en 2003
Les vieux restes de VB6 des methodes qui sortes de nulle part (DateDiff,...)
Il y a plusieur défauts qui sont corrigé avec la version 2005 mais au boulot nous somme toujours sur la 2003
L'absence de surcharge d'opérateurs
Les commentaire XML
part contre le retour du acceder à une fenêtre sans l'instancier
ca me fait pas très POO
J'ai pas nous plus aimé l'obligation de mettre Overridable sur mes fonctions quand j'ai voulu hérité ma classe.(C'est parfois avec le temps qu'on se rencontre qu'on hériterais bien d'une classe et donc si le propriétaire n'y a pas penser ca peut etre génant...)
Je conseillerai aussi le C# car la synthaxe y est presque identique au langage c,c++,java, ...
Donc je pense que quand on doit se tapper des progamme en c , c++,jave + c# cela est assez aiser.
bon maintenant si vous avez des applications en VB 6 aussi a maintenir
Je trouve qu'il y a plus d'exemple en C# qu'en VB.Net donc ca me fait aussi pencher pour lui.
Part contre en VB ne pas devoir recompiler à chaque fois est pratique.
(Pour le Case : euh moi je trouve ca logique que se soit pas identique (heuresement que l'ide remet les majuscules ou alors je n'ose imaginer le nombre d'ortographes d'une même variable)
Qu'ouïs-je ???
Bon je veux bien qu'on trouve des défauts à VB, mais bon, si on ne connais pas le langage, on ferait mieux de ne pas dire des bétises monumentales, qui dénigrent VB...
VB .Net ne gère que les évènements des controles ???
Et AddHandler & RemoveHandler : C'est quoi ???
La surcharge d'opérateurs EST prise en charge par VB .Net 2005
Les commentaires XML AUSSI.
C'est quoi cette histoire de Heritables ?
Ce mot clé, n'existe pas !
L'ide ne remet pas les majuscules, bon sang... En effet, une variable peut s'écrire de 1000 facons différentes, et c'est pas moi qui m'en plaindrai : deux têtes valent mieux qu'une...(Pour le Case : euh moi je trouve ca logique que se soit pas identique (heuresement que l'ide remet les majuscules ou alors je n'ose imaginer le nombre d'ortographes d'une même variable)
Désolé si j'ai pu paraitre agressif, mais il me semblait avoir lu dans les règles des forums que les débutants ne devait pas poster sur les sujets qu'ils ne connaissaient pas. Et dans le choix d'un langage, ca me semble d'autant plus vrai.
Je me suis donc permis de remettre à leur juste place les éléments cités...
Selon moi, pour les versions les plus récentes de logiciels permettant de coder avec les langages qui font le sujet de ce débat, les différences en terme de performance sont minimes.
Par contre, les logiques de programmation sont bien distinctes, je m'en suis aperçu en passant de Vb.Net à C#, la transition s'est faite "dans la douleur".
Je pense que chacun devrait pouvoir choisir ses outils de programmation en fonction de sa logique, et non, comme c'est trop souvent le cas, etre obligé de s'adapter à une méthode de codage imposée.
Ah ? Quoi comme ?
Normalement, si le code VB.NET est bien fait, donc Option Strict+Explicit, pas d'utilisation des fonctions VB6 à deux balles etc, il n'y a aucune raison de ne pas utiliser la même 'logique de programmation'.
Maintenant, si VB.NET a été utilisé comme du VB6 avec un framework de plus, ça peut-être plus douloureux. Mais là c'est autant la faute du langage (pour autoriser ça) que du développeur (pour en avoir profité).
VB.net Vs C#
Je vois beaucoup de messages de gens qui développe en C#
Sur internet aussi la majorité des exemple que je trouve sont plutot développé en C#
y a un réel interêet ou si on à pas été élevé au C++ y en a aucun ?
Perso, je développe en C# parce que je viens du C.
Mais je suis sure que ceux qui developpement en VB.NET viennent principalement de VB6.
Il est vrai qu'il y a quelques différences entre les 2 langages, mais bon quand on est habitué à une syntaxe, pourquoi en changer.
c'est vrai que le passage du C++ au C# est probablement plus facile, que du C++ au VB.NET
Si tu dois choisir un langage prind celui où tu te sents le plus allaise
Dommage que j'ai loupé la discute à l'origine.
J'ai bondi plusieurs fois à la lecture de ce thread.
Je constate, malgré le résultat du sondage, que VB est le langage de .NET
=> C'est Vb qui est le plus utilisé dans l'enseignement, grace au langage qui est plus compréhensible pour un novice (j'ai dis novice Maniak !!)
=> C'est Vb qui est le plus utilisé dans le communauté des développeurs débutant car les développeurs confirmés qui utilisaient les langages comme C++, Java, ne partageait que rarement leurs sources. Un programmeurs autodidacte s'orientait plus vers Vb car les sources étaient plus nombreuses.
(C'est encore le cas aujourd'hui, malgré le fait que l'on constate beaucoup plus de sources en C++, Java, C#, ..., maintenant)
=> A connaissance égale entre C# et VB, Vb s'impose plus facilement pour des développements rapides (types moulinettes, programmes temporaires, ...) grace à son atelier de développement plus sensitive que C#.
(C'est à peu près l'avis que j'ai relevé dans la communauté développeur)
=> C# s'impose pour les grands projets à cause de sa rigueur
En VS2003, je dis : La rigueur vient du développeur.
En VS2005, je pense qu'on peut commencer à réfléchir à savoir dans quel langage on sera le plus à l'aise pour développer.
Pour ma part, nous avons choisi Vb.Net sous VS2003 pour développer un grand projet.
La plupart des développeurs ayant une formation vb, cela semblait logique de passer sous VB.NET
Une 2eme application (plus grande) doit être converti dans un langage .NET.
A priori C#, pour le moment, car les déveleppeurs préssentis sont CSharpistes (ils ont déjà réaliser un projet en C#).
Mais il se peut que ce ne soit pas les développeurs préssentis qui héritent du projet, donc le choix du langage peut être remis en cause.
En ce qui concerne l'avis partagé sur ce thread, je trouve décevant que malgré le résultat du sondage, il n'y a eu que Maniak qui est "essayer" (désolé, c'est l'impression qu'on a) de défendre C# face à une "multitude" (j'exagère, je sais, mais c'est encore l'impression qu'on a) de personnes vantant les mérites de Vb.
(Aller, dis-le, Maniak, t'as truqué le résultat !! :-))
Partager