Est-ce que .NET a supprimé la distinction entre les différentes langues?

Question

Nous avons toujours eu des langues qu'il était préférable d'utiliser dans un scénario particulier. Pour un développement rapide du prototype, VB6 était un choix évident. VB6 a été choisi dans des projets qui avaient une interface utilisateur de bureau simple et des exigences d'interaction de base de données standard et non compliquées. Si vous souhaitiez développer un pilote de périphérique à l'aide de routines de bas niveau, vous utilisiez probablement C ou Visual C++. ASP était un choix standard pour le développement d'interfaces web. Chaque langue avait un «domaine» ou une «spécialisation» particulière, parlant grossièrement. Avec .NET framework, toutes les langues sont interopérables et probablement cohérentes. Vous pouvez avoir un projet avec des modules de différentes langues tous ensemble mais tous finalement traités de manière similaire (tous sont compilés en IL). Cela signifie-t-il que la distinction que nous avions auparavant n'existe plus? Cette différenciation n'était pas nécessairement mauvaise plutôt que quelque chose qui était là par conception et non par contrainte. Cela est apparemment quelque peu diminué avec le framework .NET et son traitement des différentes langues.

Answer 1

Les distinctions de langue restent. Cela ne fait pas vraiment de différence si vous compilez un langage vers le code d'assemblage ou MSIL, sauf que le niveau d'abstraction de MSIL est peut-être plus élevé que celui de l'assemblage.

Le gros avantage de .Net bien, ce qui peut avoir inspiré la question est que vous pouvez utiliser le code objet de la langue 1 dans une bibliothèque écrite en langue 2 liée par une application écrite en langue 3.

Il y a longtemps, avant l'électricité et l'auto-mobile, vous ne pouviez pas simplement utiliser les fichiers .obj générés par C dans une application Pascal ou Delphi (et vice versa) sans les encapsuler explicitement dans une DLL (en prenant soin de l'appel méthode et séquence de paramètres et compatibilité des paramètres), ou appel à un autre exécutable.

Answer 2

Les distinctions existent toujours. Par exemple, VB.NET supporte actuellement la liaison tardive d'IDispatch d'une manière plus agréable que C# (à l'exclusion de C# 4.0) et VB.NET a des littéraux XML en ligne avec le code qui en fait un outil pratique pour manipuler XML par rapport aux autres langages .NET. C++ a tendance à ne pas être aussi bien adapté à .NET, même avec la variante C++/CLI, mais il est excellent pour la programmation native (comme toujours) et pour fournir une couche d'interopérabilité entre code managé et non managé.

Chaque langue a des nuances dans sa syntaxe qui facilitent l'expression de certains concepts. Même si tout se résume à IL ce n'est pas différent qu'auparavant quand ils se résument tous à l'assemblage. Vous choisissez la langue avec la syntaxe qui prend le mieux en charge la tâche que vous essayez de faire, quelle que soit la plate-forme qu'elle compile.

Answer 3

Non, il n'a pas les caractéristiques du cadre ne sont pas les mêmes que les caractéristiques du langage. Dire a .Net Supprimé la distinction entre les langues est comme dire que le code de l'Assemblée a supprimé la distinction entre les langues.

Les langages ont encore des caractéristiques différentes, la syntaxe pour certains langages est meilleure pour résoudre certains problèmes, sinon l'ensemble du framework .Net s'homogénéiserait sur une seule langue.

Answer 4

Si quoi que ce soit, je pense qu'il peut avoir Heightened la distinction entre les langues, précisément parce ils sont si interopérables. L'accent étant maintenant sur le langue.Le fait que les mêmes services fondamentaux et les mêmes classes de base soient disponibles signifie que vous pouvez prendre une décision judicieuse concernant le langage en fonction de ce que propose la langue , plutôt que ce que propose le cadre associé au langage. Par exemple, pour travailler avec COM tardif, je pourrais (à contrecœur) choisir VB (ou attendre C# 4.0). Pour un travail financier/de simulation spécifique, je pourrais penser sérieusement à F #. Pour la programmation d'affaires régulière mon choix out-and-out serait C#.

Mais vous pouvez faire ces choix en fonction de la langue appropriée pour différents blocs, et tricoter l'application complétée à partir des différentes DLL dans différentes langues. Auparavant, vous auriez dû vous battre avec une partie du code, car vous avez pour utiliser pour utiliser la langue x pour l'interopérer avec le reste du code.

Answer 5

Je pense que cela dépend vraiment du contexte à partir duquel la question est posée.

Supposons que vous développiez une bibliothèque à utiliser par les clients. Vous marquez cet assembly avec l'attribut CLSCompliant. Cela signifie que le compilateur va vous forcer à utiliser les fonctionnalités garanties par le CLR et ne pourra pas être compilé si vous utilisez une fonctionnalité spécifique au langage.

Lorsqu'une bibliothèque conforme CLS est envisagée, .NET supprime la distinction entre les langues. Chaque langage .NET doit être compatible CLS, vous êtes donc assuré de prendre en charge tous les langages .NET de manière égale. Maintenant, supposons que vous écriviez votre bibliothèque dans VB .NET et que vous décidiez d'utiliser des paramètres facultatifs plutôt qu'une surcharge de méthode. Dans ce cas, .NET met en évidence la distinction entre les langues car les paramètres optionnels ne sont pas compatibles CLS (bien que C# les supporte dans .NET 4.0 apparemment.) Pour quelqu'un utilisant un langage qui ne supporte pas les paramètres optionnels, votre bibliothèque peut être impossible ou au mieux difficile à utiliser. Chaque langue a quelques fonctionnalités qui ne sont pas compatibles avec CLS, lorsque celles-ci sont utilisées, vous allez probablement rendre plus difficile pour les utilisateurs de certains langages .NET de consommer vos bibliothèques. Donc, j'ai l'impression que c'est une question piège. Si vous écrivez du code compatible CLS, il n'y a que des différences de syntaxe entre les langages .NET. Si ce n'est pas le cas, vous pouvez éventuellement écrire des méthodes qui ne peuvent pas être utilisées par certains langages .NET.