Différences de langages ( C/C++ et VB VB.net )

[quote]Ne vaut-il pas mieux d’abbord s’attaquer au C/C++ et/ou Java avant le C# ?
le plus flagrant, ce sont les similitudes qui existent au niveau de la syntaxe. pour ça pas de problèmes : pas besoin de connaître le père pour manipuler le fils.
au niveau des concepts utilisés, c’est autre chose. c’est sans doutes mieux d’être passé par Java ou ++ pour comprendre un peu la tambouille interne qui est cachée pour l’utilisateur mais bon, d’ici à dire que c’est indispensable…

Je connais bien le Java et je me suis mis au C++, et je retrouve beaucoup de concepts des deux langages dans C#.
normal.  [/quote]

Le truc c’est que je code souvent sur mon powerbook 12" donc je sais pas si il existe déjà un compilateur C# pour les systèmes unix ?
Enfin le C++ / Java restent nécessaires pour moi car c’est un contrainte imposée par mon école. Mais je me demande s’il est bien nécessaire de me tapper toutes les notions complexes du C++ si je peux simplement les ignorer avec C# =/

[quote]Mais je me demande s’il est bien nécessaire de me tapper toutes les notions complexes du C++ si je peux simplement les ignorer avec C# =/[/quote]ce que je vais dire est peut être un peu simpliste mais tout est bon à prendre (en l’occurence à apprendre). même si ça ne sert pas forcement…

Ahlala, je vois bien dans 10 ans des annonces désespérées de recrutement de codeurs C++ voire C, parce que tout le monde aura si bien oublié les problèmes “basiques” (allocation mémoire, etc), totalement gérés par les nouveaux langages… Ce sera beau a voir tiens

Personnellement, je tiens beaucoup à mon savoir sur la tambouille interne des langages, j’aime savoir ce qui se passe au niveau du processeur, parce que généralement ça aide à éviter des problèmes, voire ça permet d’éviter de choisir la méthode la plus ridiculement inefficace juste “parce qu’elle me fait une jolie architecture objet”.

Bref, le C# et le Java c’est bien, mangaizan comme on dit ici, mais je pense que le C et le C++ ont encore de très beaux jours devant eux… surtout quand on voit des ancêtres (cobol, fortran, …) qui résistent toujours, et qui font même mieux que résister : ils se mettent au gout du jour 

Cela dit pour etre un codeur “avance” en C# il faut savoir ce qui se passe et savoir comment fonctionne les allocation/desallocation memoire, quand elles se font, pourquoi, qu’est ce qu’un objet de generation n, etc, etc.

Donc oui c’est plus accessible, au depart, la courbe d’apprentissage est plus facile, mais dire que plus personne connaitra les bases dans 10 ans… faut pas pousser mami

Mais c’'est aussi pour ca, pour que le passage au managed et a .Net ait vraiment un sens, et ne soit pas juste une couche de plus ou on passe plus de temps a boucher les fuites qu’a innover et si on veut vraiment aller au bout des possibilites d’une plate forme, il faut changer aussi la base. La couche est necessaire pour assurer la legacy et la transition mais pour aller jusqu’au bout de la demarche il faut changer l’OS aussi profondement que possible, et c’est un boulot enorme, c’est longhorn qui va faire le premier pas, le plus gros, et blackcomb le poursuivre. Tout ca fait partie d’un meme demarche et constituent les differentes etapes d’un changement qui fera ses preuves ou pas. Pour windows, c’est la pari des 10/15 prochaines annees. Vu la taille du changement on imagine bien que les possibilites d’erreurs sont nombreuses et qu’il pourront pas toutes les eviter…

Donc au final, la connaissance se “perdra” pas, les pros continueront a etre des pros, meme quand ca sera plus simple de faire beaucoup plus de choses que seuls les pros savent faire aujourd’hui pour le commun des mortels, comme d’hab il faudra que les pro aillent plus loin, et ce, sans etre handicape par le cote cryptique d’un langage qu’on pousse dans ses derniers retranchements pour lui faire faire un travail pour lequel il n’est plus adapte. Apres… les fanatiques resteront des fanatiques… ( et c’est dirige vers personne en particulier ici hein … mais vous voyez le genre…).

PS: Ce message n’engage que me opinion personelle, blablabla, en rien celle de mon employeur blabla. L’avertissement habituel quoi: ce n’est que mon opinion a moi que je l’ai.

Ce message a été édité par GloP le 28/12/2003

[quote][…]parce que tout le monde aura si bien oublié les problèmes “basiques” (allocation mémoire, etc), totalement gérés par les nouveaux langages…
Personnellement, je tiens beaucoup à mon savoir sur la tambouille interne des langages, j’aime savoir ce qui se passe au niveau du processeur, parce que généralement ça aide à éviter des problèmes,[…]
surtout quand on voit des ancêtres (cobol, fortran, …) qui résistent toujours, et qui font même mieux que résister : ils se mettent au gout du jour [/quote]Je développe en base de données et le langage le plus adapté à mes projets est jusqu’à présent Delphi.

Il y aura toujours besoin du C/C++ pour faire du bas niveau et du cobol pour faire des bases de données hierarchiques, et du fortran pour faire de la programmation orienté math de haut niveau. Mais cela deviendra des langages pour des besoins spécifiques.

N’empêche que, pour MES besoins, Delphi (ou C# qui va dans la même direction) est le produit qui me convient le mieux, car pour faire de la base de données ou des IHM, je me contremoque des pointeurs de pointeurs pour déclarer une fonction, ce n’est pas mon problème. Ce qui ne m’empêche pas de jouer avec les pointeurs quand j’en ai besoin et UNIQUEMENT quand j’en ai besoin.

Donc si C# va dans le même sens que Delphi et pas dans le sens de Visual Basic moi je le prends pour mes besoins. L’interêt d’un langage comme C# et Delphi (du même créateur que C#) c’est de simplifier ce qu’on fait tout les jours sans pour autant nous interdire de descendre plus bas, contrairement à Visual Basic où l’on ne peut pas descendre plus bas sans faire de la grosse bidouille et qui nous cache beaucoup trop de choses (sans parler de l’aspect syntaxe).

Mais c’est comme les OS, si C#/Delphi va dans le sens de 80% des besoins, le C restera nécessaire pour le bas niveau, l’assembleur pour le très très bas niveau , et même les langages comme le Visual Basic resteront utiles pour le très haut niveau (macro Excel, macro Business Objects, Crystal Reports) bien que personnellement j’ai vraiment du mal avec la syntaxe trop simple du VB. Comme d’habitude il ne faut pas confondre les besoins du projets avec ses compétences ou ses envies.

Donc le C# est la corde qui manquait à Microsoft entre le C++ et Visual Basic. Il y a bien Delphi mais ce n’était pas du Microsoft. Maintenant est-ce que C#.net va m’apporter quelquechose par rapport à Delphi.net: à vérifier.

PS: notez que j’ai fait exprés de ne pas aborder l’architecture.

Ce message a été édité par phili_b le 28/12/2003

Ce thread mériterait d’être transformé en dossier de la cafzone pour ne
pas perdre toutes les choses intéressantes qui ont été dites.

Pour en revenir à la question d’origine qui porte un peu sur le choix
d’un langage à apprendre, je dirai qu’après avoir bidouillé un temps en
C, il peut être intéressant de passer par du Java avant de faire du
C++. L’intérêt de la chose est que le Java est un langage purement
objet qui force donc à utiliser les concepts de POO même quand on a une
forte envie de revenir à de la programation style C. J’ai vu de très
nombreux élèves apprenant le C++ coller des bouts de C dedans à tout
va, ce qui n’a pas du les aider à vraiment apréhender toutes les
subtilités de la programmation objet.

Maintenant est ce que c’est aussi valable pour le C# ? Je ne sais pas.
Il faudrait que Glop nous dise si on peut s’affranchir des objets en C#
de la même manière qu’en C++.

PS: là je ne parle des avantages du Java que pour ce qui est de l’apprentissage de l’informatique, même si j’aime bien le java dans la vraie vie aussi

Perso je code en C++ (en objet), j’ai suivi une formation C# il y a peu et mon constat est assez brutal:

C# = Java Killer et c’est tout (c’est déjà pas mal).

Pour développer de l’ihm, des services web, utiliser des services web le c# c’est très bien. Pour faire de l’industriel, du performant, du controlable (temps réel plus ou moins contraint) le c# est de part sa conception inadaptée (notamment au niveau mémoire qui est un vrai casse tête car même le pseudo control de la désallocation n’est pas simple et de toute façon pas total).

Par ailleurs je crois savoir qu’un C# v2 est en cours de finalisation… Donc pour l’aspect normalisé (ce que Microsoft souhaite), le langage ne semble pas encore mature (et c’est normal car il est tout réçent).

Je ne pense pas qu’il faille voir le c# comme un c++ killer. Pour le moment les aspect de portabilité du c# (et tout le framework .net) n’est pas très clair. La CLR ne permet pas d’avoir un contrôle suffisamment fin de la gestion mémoire. Enfin certains aspects avancé du c# sont une vraie plaie (multithreading) et demandent autant de taf’ (voir plus) qu’en C++ (et Win32).

Le C++ de par sa portabilité, son aspect plus “bas niveau” que le C# n’est pas prêt de disparaitre.

Pour en revenir au post initial:

Je conseille de passer par le C++ qui offre la contrainte (et l’avantage selon moi) au programmeur d’avoir une bonne vision (comment on alloue, on désalloue, les appels systèmes etc, les aspects objets) puis éventuellement d’évoluer vers du C#. Le passage direct du VB au C# me parait ultra dangereux car c’est un peu comme passer d’une 125cm3 à une 1000cm3 sans avoir passer le permis gros cube (Je suis pas motard pourtant).

Enfin l’IDE. Actuellement on trouve Visual .Net qui permet de faire du vrai C++ (pas du Managed C++). Plus ergonomique que VS6 (et encore les goûts), par contre VS6 est plus mature.

Enfin attention quelques problèmes de compatibilités existent entre du C++ compilé avec VS6 et VS7 (Visual .Net)

[quote]C# = Java Killer et c’est tout (c’est déjà pas mal). Pour développer de l’ihm, des services web, utiliser des services web le c# c’est très bien. Pour faire de l’industriel, du performant, du controlable (temps réel plus ou moins contraint) le c# est de part sa conception inadaptée (notamment au niveau mémoire qui est un vrai casse tête car même le pseudo control de la désallocation n’est pas simple et de toute façon pas total).

Je suis super pas d’accord. Il y a un gouffre en un OS temps reel pour de l’embarque bien dedie et de “l’industriel, du performant, du controlable”. Effectivement c# est pas fait pour faire du vrai temps reel contraint ou de l’embarque. Ca reste des applications bien specifiques. Pour le reste c’est loin d’etre aussi tranche que ca. Sans compter sur le “java killer” c’est pas l’objectif, sauf sur le cote asp.net qui n’est qu’une partie, certes importante du framework. Sur les reste, les concepts fondamentaux, si ils restent proches, ressemblent plus aux concepts de bases communs de smalltalk qu’a une approche de concurence frontalle. .Net et le CLR vont plus loin qu’un simple nouveau langage.

[quote]Par ailleurs je crois savoir qu’un C# v2 est en cours de finalisation… Donc pour l’aspect normalisé (ce que Microsoft souhaite), le langage ne semble pas encore mature (et c’est normal car il est tout réçent).

Encore une fois il faut pas melanger C# et .Net. Le seul ajout a C# v2, c’est la syntaxe des generics, qui ont deja ete normalises dans le MSIL et qui sont ils me semble aussi deja passes pour C#. Donc rien de nouveau sur le plan normalisation du langage. Ces fonctionalites etaient deja prevues des le debut, meme si elles etaient pas presentes dans la v1 du framework (on peut pas tout faire en quelques mois… meme si on sait ou on va pour certains aspects des prochaines versions).

[quote]Pour le moment les aspect de portabilité du c# (et tout le framework .net) n’est pas très clair. La CLR ne permet pas d’avoir un contrôle suffisamment fin de la gestion mémoire. Enfin certains aspects avancé du c# sont une vraie plaie (multithreading) et demandent autant de taf’ (voir plus) qu’en C++ (et Win32).
La portabilite n’est pas un objectif affiche de MS et pas une priorite, meme si une bonne architecture prend en compte ces contraintes. Mono est independant de MS, Rotor qui vient de MS, meme si il a enormement en commun avec le CLR, a ete refait de 0. Donc portable, a mon avis a moi, surement et probablement, mais plus parceque c’est une archi propre et pensee dans un esprit “il faut que ca soit possible”, plus que parceque c’est une volontee affichee par MS.

Apres niveau multi-threading, il va falloir s’expliquer. Les message pump de Win32 ne sont pas, en large majorite thread safe, donc je vois pas en quoi ca a qqch a voir. Ensuite la gestion des threads est la meme, et seul de elements standard de synchronisation et des regles de programmation multi-thread “propre” sont rajoutees par le CLR, donc je comprend pas en quoi c’est “une veritable plaie par rapport au C++”. Ne pas avoir a implementer certains mecanismes de synchronisation est un atout (types de semaphores, signaux, etc), les utiliser pour quelque chose qui n’est pas prevu est un handicap… mais la on se le merite et les justifications pour faire ce genre de bricolages se comptent sur les doigts d’une main et sont bien connus quand on cherche pas a re-inventer la roue, le plus souvent par manque d’experience… (je te vise pas en particulier hein; c’est une generalite).

Je suis pas non plus d’accord sur le passage VB->C# qui est comme de passer de 125 a 1000cc… je peux vous presenter des codeurs VB qui ont des lecons a donner a n’importe quel gourou de l’assembleur ou du C. Ce n’est pas parceque c’est un langage accessible a des debiles qu’il n’y a que des debiles qui l’utilisent… Personellement j’aime pas la syntaxe et certains choix qui sont fait en VB, ca veut pas dire que c’est pas pour ca que VB est pas un langage adapte a d’autres que moi, ou qui sera plus pratique pour eux. Encore une fois, faire de la hierarchie dans les langages avec des raisonements du genre “vb c’est la mobilette du code; et C++ la ducatti” ca n’a aucun sens. On peut parler que dans la plupart des cas pour faire X, langage A est plus adapte que B ou vice versa. Faire des jugements de valeur dans l’absolu c’est pas mal somnifere au final…

En fait je suis plutôt d’accord avec ce que raconte tonton GloP : chaque langage trouve sa “niche écologique” qui lui convient le mieux. Comme je le disais dans mon post précédent, Cobol, Fortran & co existent encore, et se sont adaptés à leurs usages spécifiques qui en sont fait aujourd’hui. Je pense que ce sera pareil pour le C et le C++, ils trouveront leur niche et y resteront pendant encore longtemps.

Parce que bon, je vois beaucoup de personnes parler ici de IHM et autres Web Services de tuerie, mais, si il est vrai que ces applications ont un champs d’application énorme, il ne faut pas pour autant oublier d’autres applications, bien moins connues (parce que en général ça brasse moins d’argent et c’est moins grand public), comme les applications embarquées (bornes SNCF, retrait d’argent, etc.)

Donc encore une fois, comme le dit si bien GloP : ça ne sert à rien de faire des comparaisons frontales entre les langages, étant donné leur champs d’application très différents. Les besoins ne sont pas les mêmes tout simplement.

Mais c’est aussi pour ça que je disais (ironiquement hein, c’était une exagération bien évidemment ) que dans 10 ans il y aura le même phénoméne que pour le Cobol en l’an 2000 Bien sûr ce sera différent, moins “dans l’urgence”, avec une ampleur bien moindre, mais n’empêche

Enfin bref, pour revenir à l’origine du topic : pour choisir son langage, il faut déjà savoir ce que tu veux faire. Ensuite, il suffit de faire un choix dans les quelques langages qui recoupent le domaine en question