Pourquoi est-il une grande différence de lisibilité entre les spécifications C # et ECMAScript?

Question

Je suis en train d'étudier la spécification ECMAScript et ont trouvé qu'il est extrêmement difficile à lire et à comprendre. Je dois constamment revenir en arrière pour maintenir les concepts dans ma tête. Lors de la lecture de la spécification C # Je suis en mesure d'étudier les composants de la langue sans constamment en mouvement autour du document.

ECMAScript Spécifications

C # Spécification

Answer 1

Comme je suis la seule personne qui affiche régulièrement sur le SO qui est membre à la fois du comité de conception du langage C # et le comité technique ECMAScript, je peux offrir probablement quelques idées.

Tout d'abord, merci pour vos bons mots au sujet de la spécification C #. Nous avons travaillé très dur pour le garder lisible et il est bon de savoir que nous avons réussi.

En second lieu, je note que la spécification C # est pas toujours de cette façon. La spécification C # 2.0 a été écrit comme addendum à la spécification C # 1.0. Génériques, iterator blocs et méthodes anonymes ont eu des effets généralisés sur de nombreuses sections de la spécification. Ce fut une vraie douleur à lire la spécification 2.0 et d'avoir à sauter entre deux chapitres pour comprendre l'algorithme de résolution réelle de surcharge. Mads a fait une énorme quantité de travail d'édition en C # 3.0 d'abord intégrer l'ensemble du C # 2.0 se transforme en un endroit raisonnable dans les spécifications afin que vous n'auriez pas à sauter dans tous les sens.

En troisième lieu, une grande partie de ce que vous décrivez est le résultat des différences dans les deux objectifs et le style des principaux architectes des deux spécifications. Imaginez un éventail de « caractère technique » avec des papiers sur la correction formelle écrite en grande partie en lettres grecques à une extrémité, et des articles de magazine pour les débutants de l'autre. Nous concevons la spécification C # pour tomber à un endroit particulier sur ce spectre. Nous ne voulons pas que ce soit un tutoriel programmeur débutant, mais ne veulent que ce soit un document raisonnable pour les programmeurs débutants C # pour consulter. Anders avait expressément pour éviter ce qu'il appelle « les mathématiques plus élevé de la spécification ».

Ceci est un ensemble raisonnable d'objectifs donnés notre public cible pour les spécifications: les programmeurs professionnels, dont certains veulent apprendre C #, et certains d'entre eux veulent regarder précisément comment quelque chose fonctionne. La spécification a des aspects tutoriel vagues et les aspects de la description sémantique précis afin de servir ces deux circonscriptions.

Waldemar Horwat, l'auteur principal de la spécification ECMAScript 3, avait plutôt des objectifs différents pour les spécifications E3 - pas pire buts, mais différents objectifs. L'objectif de la spécification E3 devait être beaucoup plus vers la fin mathématiquement précis du spectre. Vous remarquerez comment pratiquement toutes les sections de la spécification des algorithmes consiste essentiellement pseudocode qui décrivent en prose plutôt de mathématiques lourds précisément ce que l'effet de chaque opération est sur le système.

Vous remarquerez par exemple que les pourparlers de spécification E3 au sujet de la différence entre les chiffres « mathématiques » et leurs représentations binaires. Un projet de la spécification E4 est même allé jusqu'à noter qu'il ya des problèmes avec set-théorétiques une définition naïve du « type » comme un ensemble de valeurs si les types sont aussi des valeurs. Ce genre de chose serait complètement hors de propos dans la spécification C #; il ne cherche pas à avoir une forte mathématique théorique pour fondement assurer l'exactitude. Vous remarquerez que la spécification C # nulle part même définit « type » - il a été écrit avec l'hypothèse que les lecteurs seront pro devs qui (1) savent déjà quels types sont à des fins pratiques, et (2) ne prendra pas ce que la théorie des ensembles ou la théorie des catégories a à dire sur le bien-fondé mathématique de toute définition de « type ».

Le but du processus ECMAScript a été pour plusieurs fournisseurs de langues très similaires à se réunir et se mettre d'accord sur une description précise de ce qui était dans le terrain d'entente entre toutes ces mises en œuvre. La spécification E3 n'a jamais été destiné à être un tutoriel de toute nature, et est principalement destiné à la langue et de l'outil implementors , plutôt que la langue utilisateurs .

spec E4 de Waldemar allé encore plus loin. Si je me souviens bien, il a commencé en spécifiant un très précis, simple « langage spec » avec une sémantique claire. Puis il a écrit un interprète pour cette langue en Common Lisp. Puis il a écrit la spécification E4 dans sa langue spec. Le résultat était qu'il pouvait compiler la spécification elle-même dans un interpréteur ECMAScript travail . C'est exactement le genre de « mathématiques supérieur » que nous essayons d'éviter dans la spécification C #. Ceci est une approche impressionnante à la spécification si vous voulez être incroyablement précis et précis, mais il est un moyen très difficile d'écrire un document les utilisateurs de langue peut apprendre.

Est-ce que cela répond à votre question?

Answer 2

Vous êtes probablement une différence entre la lisibilité des spécifications des deux langues parce qu'ils ont été écrits par différents groupes de personnes et discuter des langues qui emploient des paradigmes d'objets différents.

La spécification JavaScript a été rédigé par un comité après la langue a évolué organique après plusieurs années. La spécification C # a été écrit par un petit groupe d'ingénieurs des entreprises alors que la langue croissait de manière contrôlée.

C # est OOP classe centrée et JavaScript est prototype centrique. Il est possible que si vous n'êtes pas aussi familier avec l'un que vous êtes avec l'autre, puis une matière peut être difficile à comprendre au début, surtout quand il est dans les détails de mise en œuvre. Cela ne signifie pas nécessairement un problème avec la clarté et la lisibilité d'une spécification.

Answer 3

Par rapport aux langues conventionnelles JavaScript est très étrange. En fait, il n'y a pas trop de langues populaires comme le JavaScript sont basées sur des prototypes. JavaScript est un objet entièrement basé, et tous les objets sont essentiellement des tableaux associatifs avec des fonctions étant trop objet de première classe. Ce n'est généralement pas ce que vous attendez de voir d'une langue mais avec la popularité de l'Ajax et la programmation côté navigateur JavaScript est devenu la langue de la bande. Bien que ces spécifications étranges auraient pu être évités, je crois que JavaScript peut conduire à un certain codage intéressant et créatif. Bouclages par exemple sont la chose que la plupart des nouveaux développeurs ont du mal à comprendre, mais dans mon expérience, ils sont très utiles. La sémantique de la langue aux développeurs fois des fous de penser JavaScript est une saveur de C mais bientôt ils se rendent compte que cela n'est pas vrai.

Pour moi C # est le summum des langages de programmation. Il est correct et en ligne avec les attentes académiques. Sa honte un MS est que le principal moteur de cette langue. Comme moi, je suis sûr qu'il ya beaucoup d'autres qui jouirait d'une bonne mise en œuvre d'une plate-forme avec le soutien C # sur aucun système basé sur Windows (Mono est un pas dans la bonne direction).

Si vous êtes désireux d'apprendre JavaScript et non un framework JavaScript, alors je suggère vraiment coller avec des livres qui traitent directement JavaScript. Toutefois, si vous avez l'intention de commencer et ne se soucient pas beaucoup sur les tenants et les aboutissants de la suggestion de JavaScript de livres est la bonne façon de faire.

Answer 4

Eh bien, vous êtes la première personne que je connais d'essayer d'apprendre une langue sur la base des documents ECMA. Quoi qu'il en soit, je dirais que la différence est principalement due à l'habileté des gens qui écrivent les spécifications. C # est évidemment un peu plus facile à préciser (en raison de la nature moins dynamique - comme déjà indiqué), mais à la fin ... ... IIRC JavaScript est conçu par le comité (beaucoup de gens qui écrivent aussi sur la spécification), tandis que C # a été fait par Microsoft par une seule personne à la fin, peut-être avec 1-2 auteurs le long du chemin et des aides, mais à la fin il Anders est Hejlsberg (espoir que j'orthographié ce droit). La conception par le comité et d'avoir à voter sur des choses peut parfois conduire à moins optimale « design » d'un document.

Alors, à la fin, je pense qu'il est de la compétence des gens qui écrivent les différentes spécifications que l'on est plus difficile à lire que l'autre.

Answer 5

Une partie de la raison est que la norme vous liez est en fait ECMAScript. JavaScript, JScript et ActionScript sont toutes les implémentations de ECMAScript et ECMAScript a été écrit pour englober les parties de chaque commune. En revanche, C # a été conçu principalement par trois personnes (selon la norme ECMA-334) chez Microsoft.

En dehors de cela, il vous faudrait le prendre avec le comité qui a rédigé les normes ECMAScript.

Answer 6

Plus simplement, il est probablement parce qu'ils ont été écrits par des auteurs différents. La spécification C # a été écrit par Microsoft qui avait un intérêt à ce que ce bon (pour qu'elle soit acceptée), alors que la spécification ECMAScript a été écrit par un comité après la langue était déjà en cours d'utilisation.

Answer 7

Eh bien la meilleure partie est, C # sera exécuté à partir d'un ordinateur à l'autre les mêmes (oui différences mineures peut-être dans les versions .net, mais des choses se comportera en général). Javascript fonctionnera très différent entre Internet Explorer vs Firefox vs chrome.

Par exemple, vous avez une page Web avec un élément

<input type="text" name="fred" />

Et vous exécutez le JavaScript

document.getElementById("fred")

Internet Explorer vous obtenez l'élément (même si cela est mauvais comportement, il n'y a aucun élément avec un ID de fred), mais Firefox vous donnera une valeur nulle.

Plus que probable, c'est à cause de la façon dont les langues ont grandi. C # a été faite par 1 entreprise et les développeurs ont été contraints de suivre les normes ou leur code ne fonctionnerait pas. JavaScript a été mis en œuvre dans de nombreux navigateurs de différentes manières, et les gens étaient libres d'ajouter ou de supprimer ou les fonctions changent comme ils l'entendent.

En résumé, JavaScript prend plus de travail à apprendre que d'autres langues en raison de l'histoire de ce. Regardez dans une bonne bibliothèque comme JQuery pour abstraire les différences de navigateur, et vous devriez obtenir le coup de lui assez rapidement. L'apprentissage d'un document est seulement une petite partie de l'apprentissage d'une langue ... ne le codage et un certain savoir comment cela fonctionne, et il sera logique.