C'est qui ce Michael C. Kasten ?Citation:
Envoyé par el_slapper
Version imprimable
C'est qui ce Michael C. Kasten ?Citation:
Envoyé par el_slapper
J'ai programmé depuis plus de 40 ans dans de nombreux langages ( Basic avec mon 1er programme en 1967, Algol,PL1,COBOL,SPL,PASCAL,C et Visual Basic Microsoft et Borland, VC++ 4 à 6 , VB 4 à 6 , VC#, plus quelques autres épisodiques).
Depuis la sortie de Visual Studio 2003, je n'utilise plus que VC# et VB ( plus accessoirement ) versions 2003 à 2010. Je me sens plus à l'aise en VC# ( peut-être à cause des quelques millions de lignes que j'ai écrites en C ) mais je code en VB aussi pour me maintenir eà niveau et aussi parce que je considère que de changer de langage est une sorte de défi qui ajoute un peu de sel au dèveloppement. Il est vrai que je code d'une façon un peu spéciale, puisque, chaque fois que c'est possible, je préfère utiliser les classes .NET. Comme je ne sais jamais si mon code sera lu par un utilisateur VB ou VC#, j'utilise Int32 au lieu de int ou Integer.
Je poste assez souvent sur des forums "concurrents" (MSDN/Technet) et je suis souvent amené à fournir du code en VC#. Si l'utilisateur demande du code en VB, je modifie les syntaxes différentes comme la déclaration des procédures/fonctions, les if, while, static qui devient Shared , mais je peux en 10 minutes modifier 150 lignes de code, les tester et les poster. L'utilisateur est content car il a son code en VB, et je suis content car j'ai pu lui rendre service , alors, pourquoi s'en priver.
Les utilisateurs VB moins professionnels que les partisans de VC#, je ne le pense pas.Je connais des utilisateurs VB ( par exemple Allen White dont le blog était consacré à SMO et qui m'a tant appris sur cette partie très particulière de SQL Server ) près à faire l'effort de produire du bon code en VC# ).Je connais aussi des modérateurs qui se refusent à envisager d'écrire du code VB même pour dépanner un utilisateur à la dérive.
Par contre, les pires VBistes sont ceux qui ont migré de VBA ou VB Script, ils se refusent à recevoir du code en VC# en termes peu agréables.Je leur fournis leur code, mais je râle ( une fois, le créateur du fil a été tellement odieux que j'ai bloqué le fil en empéchant tout nouveau post). Ceux qui ont créé des applications avec ACCESS passent naturellement à VB, mais ils oublient que les syntaxes de VB et VBA sont différentes et plusieurs fois, j'ai posté pour leur expliquer qu'il n'y avait pas un problème avec leur SQL Server mais qu'ils avaient des erreurs de syntaxe ( une compilation erronée ne peut provenir de SQL Server ).
Utiliser VB et VC# au sein d'une même application : par principe, beaucoup de chefs de projet s'y refusent pour cause de difficultés de maintenance. Je crois que c'est un faux problème.Si la gestion du développement est bien faite, il n'y aura de problème surtout si l'on remplace tous les appels spécifiques à un langage ( par exemple pour les I/O ) par des appels à des classes .NET. Bien souvent, le refus provient du fait que le chef de projet connait moins bien .Net que son langage habituel et qu'il ne veut pas passer pour un imbécile.Bien sûr, il faudra toujours avoir un spécialiste VB et un spécialite VC#, mais celà se trouve ( si l'on s'en donne la peine ).
Pour moi, le choix VB/VC# pour un programeur ou un chef de projet n'est pas une question primordiale, il suffit de savoir gérer la situation.
Au fait, en parcourant les blogs du personnel Microsoft, j'ai appris que près des 2/3 du code de SQL Server écrit depuis 2003 l'a été en VC#, le reste en VC++ et VB accessoirement ( près de 90% pour SQL Server Management a été écrit en VC#). Mais ce n'est qu'un cas particulier qui devient amusant quand on sait qu'il était très difficile de trouver du code VC# pour SQL Server 2005, cela a bien changé depuis, peut-être parce que des utilisateurs de la librairie SQL Server ont fourni le code en VC# dans la partie Community Content.
Dans les forums, quand on me demande du code en VB, je le fournis ( ce n'est pas vrai pour VC++ que j'ai completement abandonné en 2003 ), bien que naturellement, ce sera du code VC# que je proposerai en 1er.
Je trouve que l'environement VB de Visual Studio est moins pratique que son correspondant à VC#, voir les extraits de code, l'impossibilité d'avoir un formattage personnel du code. D'ailleurs, il suffit de comparer les options offertes for VC# et VB , il n'y a pas photo ( ne serait-ce qu'en nombre et en utilitité ).
Je ne parlerai des options par défaut pour Strict et Explicit.D'autres personnes l'ont très bien faites. Par contre, c'est le même genre d'erreurs qu'a faite la SQL Server Team avec SQL Server Express avec les options Auto_Close ou UserInstancesEnabled ou RemoteConnectionsDisabled.Celà sent un produit destiné à un public de non-professionnels que l'on veut "ratisser".Et après, dans les forums, on galère pour expliquer gentillement aux posters qu'il faut qu'il change ces options pour qu'ils puissent se connecter.
Au revoir en espérant que les lecteurs de ce message me pardonneront la longueur de mon écrit ( après 8 heures d'anglais, j'avais envie d'écrire en français )
Bonjour Papy
IL me semble que dans ce debat VB.Net -C# c'est plutot biaise parce que les gens ont tendance à oublier l'historique des langages de Microsoft.
En fait VB6 a ete lance par Microsoft pour rentabiliser la technologie COM et il est destine principaement aux developpeurs d'applications c'est le fameux fameux RAD avec COM.
Un exemple simple à l' epoque c'etait la creation rapide de composants ActiveX simples pour une application ou une 20 lignes de code permettait de creer un UserControl ou un Controle Perso.
Par contre le C++ etait plutot destinee aux ecrivains de composants complexes ,au developpement d'application dont l'architecture etait plus complexe ,specialisee ,choses qui necessitent des temps de developpement plus longs.......
Maintenant pour en revenir à VB.Net et C# je pense que la problematique reste la meme .....pour Microsoft...........et pour nous.....
bonne soiree......