Que peut on programmer avec vb.net

Salut tout le monde, je mets en pratique actuellement mes connaissances en c et c++, or j’ai appris y a peu que vb.net est un POO, étant donné que mes connaissance en basic sont plus étendus que le c et c++, bon ok basic c’est pas la même chose que vb mais bon plus facile à apprendre, donc je souhaite si vb.net vaut le coup pour la programmation software en win 32 et win console comme le c++ ?

Merci d’avance, je précise j’ai déja visual studio.net 2003, et en même existe t’il un autre compilateurs vb ? il me semble que non

En tout cas merci d’avance de vos opinions, conseils et info… :slight_smile:

VB.NET est devenu un vrai langage objet à travers cette version. Facile à apprendre pourquoi pas. Mais je vois que tu cours d’un langage à un autre.

On ne devient pas développeur en connaissant des langages divers. Développer c’est réaliser une réponse informatique à un problème donné.
Le langage ne sert qu’à réaliser cette solution. La plupart des solutions sont d’ailleurs réalisables dans tous les langages.

Pour apprendre à programmer on apprend pas un langage. On apprend à penser, à décomposer un projet en sous-projets en modules enfin en programmes puis inversement (cf intégration cycle en V).

Si tu veux t’amuser apprend l’algo (perso j’utilise les arbres programmatiques qui vont d’ici peut remplacer les organigrammes devenus obsolètes) et met les en application avec un langage. Tiens l’ADA par exemple je me suis bien cassé les dents avec.

Personnelement je code la plupart de mes programmes en vb.net (sauf evidemment s’ils demandent une solution spécifique), donc je peux affirmer qu’il à autant de potentiel que n’importe quel langage .net (par exemple C#). Son inconvenient majeur est de necessiter l’installation préalable du framework sur la machine cible (un peu comme la console java pour les applications… java :stuck_out_tongue: ), ce qui limite pas mal le deploiement. Aussi, si ton application ne demande pas d’interface fenetrée, je te suggere de la laisser en C++. Le reste du temps, vb.net fait gagner un temps précieux :slight_smile:

:smiley: ça je demande à voir :sarcastic:

Cela fait 20 ans que j’entends que l’on va remplacer l’algo
parce que l’algo c’est ceci, c’est cela … :smiley:

… et l’algo est toujours là [:kangol]

Oui, preuve au cours de programmation… On apprend l’algo avec les organigrammes et avec VB.net on met en pratique… Mais attention, on ne regarde pas les composants specifiques du .net… Pour preuve, la pluspart des applis qu’on ecrit, son des command line :slight_smile:

oh que non ! :non:
si tu continu a programmer et pousser plus loin tes connaissances en .NET, un jour où l’autre tu va tomber sur des choses qui vont te bloquer en VB.net et pourtant possible en C# !
Un truc perso qu’il m’ai arrivé, c’est l’appel a une DLL distante par un client riche qui elle meme appel un webservice sécurisé. Les credential cache sont beaucoup plus difficile a manipuler en VB.net qu’en C#, t’es presque obligé de developper 2 methodes qui existent pourtant toute faites en C#.
autre exemple : http://weblogs.asp.net/fbouma/archive/2003/11/12/37199.aspx

mais sinon c’est bien vrai que pour une application toute normale, vb.net, C# ou meme J# n’est qu’une question de préférence et d’habitude.

de plus, C# est certifié ECMA, au contraire de VB.NET :
http://msdn.microsoft.com/net/ecma/

Les arbres programmatiques ne remplaçent pas l’algo c’est juste la nouvelle forme de représentation schématique.
20 ans d’algo pour mes profs et leurs collègues des autres IUT qui ont mis en place ce systeme malheureusement non encore documenté.

L’algo ne disparrait pas du tout mais la doc deviernt complete.

J’ai vu ce que c’était … et on perd le gros avantage de l’algo : celui de la limpidité ; quand on regarde un algo, on pige tout de suite ce qui se passe … avec les arbres programmatiques , il faut chercher, ce n’est pas intuitif.
Ce qui me conduit à dire que cette nouvelle merveille finira comme l’algorythmique en son temps : aux oubliettes :wink:

et en c# on peut utiliser les pointeurs avec du code UNSAFE