[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.
Sans parler de temps réel dur… Je développe des applis dont on doit controler un minimum l’allocation mémoire et le timing et pour cela, c# n’est pas très adapté. Quand au coté Java Killer, j’aime bien MS mais faut quand même rester honnête. Java et MS ça a toujours été une grande histoire d’amour et les deux langages sont tellement proche par certains aspect (pas tous hein attention) que dire que « non non MS ne veut pas contrecarrer le java » avec c# c’est quand même un peu se voiler la face (AMHA)
[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).
Ok
[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.
Alors c’est peut être le cas maintenant, mais à l’époque de lancement de .Net, la portabilité de .Net sur différentes plateformes était un des gros (faux ?) arguments de MS. Sans leur jeter la pierre (après tout c’est leur choix), ils ont déjà été coutumier du fait de par le passer (cf les NT Alpha, PowerPC, les Windows CE…).
Selon moi, l’aspect portabilité (cela me concerne t’il ou non ?) doit être pris en compte lors du choix du langage. Histoire de ne pas se retrouver comme un c… avec du code spécifique à un OS.
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).
J’ai pas de pot, dans le domaine où je bosse (la simulation…) on a besoin de faire de la synchronisation (toujours cette foutue envie de controler le déroulement du programme)… Et il ne s’agit pas toujours de réinventer la roue comme tu le laisse entendre. Faire du multithread sur un bi cpu sans se préoccuper de la synchronisation (ou sans avoir une idée claire de la façon dont elle est réalisée) c’est courrir au suicide logiciel.
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…
Je me suis mal exprimé. Le C# offre quand même des concepts nouveaux par rapport au VB et faire du C# à la VB ce n’est pas vraiment optimal (autant faire du VB .Net). Pour éviter toute querelle, c’est un peu comme faire du C++ à la C. A un moment il faut bien faire la rupture et se plonger à fond dans le langage. Les aspects objets sont suffisamment nouveaux et déroutants (lorsque l’on vient d’un langage plus procédural) pour mettre un bémol au passage direct d’un langage à un autre. Nulle part j’ai écris il me semble que le VB est un langage accessible à des débiles. J’ai connu des débiles qui programmaient (mal) en C/C++. Le danger que je vois sur les langages tels que le VB c’est que ça masque trop les fonctionnements de bases. Certes tous le monde n’a pas nécessairement besoins de connaitre les thread, les files de messages mais cela peut se réveler d’une aide précieuse pour la mise au point des programmes et pourquoi pas faciliter la tache du développeur au final.