¿Por qué hay una gran diferencia en la lectura entre las especificaciones C # y ECMAScript?

Question

He estado estudiando la especificación ECMAScript y han encontrado que es extremadamente difícil de leer y entender. Constantemente tengo que dar marcha atrás para mantener conceptos en mi cabeza. Al leer la especificación C # Soy capaz de estudiar los componentes de la lengua sin estar constantemente en movimiento en todo el documento.

ECMAScript Especificación

C # Especificación

Answer 1

Como soy la única persona que publica regularmente en SO que ha sido miembro tanto del comité de diseño del lenguaje C # y el comité técnico de ECMAScript, es probable que pueda ofrecer algunas ideas.

En primer lugar, gracias por sus amables palabras acerca de la especificación de C #. Hemos trabajado muy duro para mantenerlo legible y es bueno saber que lo hemos conseguido.

En segundo lugar, tenga en cuenta que la especificación de C # no siempre fue así. La especificación de C # 2.0 fue escrito como un addendum para el C # 1.0. Genéricos, iterador bloques y métodos anónimos tenían impactos generalizados en muchos sectores de la especificación. Fue un verdadero dolor de lectura de la especificación 2.0 y tener que saltar entre dos capítulos para entender el algoritmo de resolución real de sobrecarga. Mads hicieron una enorme cantidad de trabajo de edición en C # 3.0 para integrar la primera todas C # 2.0 se transforma en un lugar razonable en la especificación de modo que usted no tendría que saltar por todo el lugar.

En tercer lugar, una gran parte de lo que estás describiendo es el resultado de diferencias tanto en meta y el estilo de los principales arquitectos de las dos especificaciones. Imagine un espectro de "técnico-dad" con papeles sobre la corrección formal por escrito en gran medida en las letras griegas en un extremo, y artículos de revistas para principiantes, por el otro. Diseñamos la especificación de C # a caer en un lugar determinado en ese espectro. Nosotros no queremos que sea un programador tutorial de principiante, pero sí queremos que sea un documento razonable para principiantes programadores de C # para consultar. Anders deseaban específicamente para evitar lo que él llama "el más alto de matemáticas de la especificación".

Se trata de un conjunto razonable de los objetivos dados nuestro público objetivo de la especificación: los programadores profesionales, algunos de los cuales quieren aprender C #, y algunos de los cuales desea buscar con precisión cómo funciona algo. La especificación tiene aspectos tutorial vagas y descripción aspectos semánticos precisos con el fin de servir a esos dos circunscripciones.

Waldemar Horwat, el autor principal de la especificación ECMAScript 3, tuvo lugar diferentes objetivos para la especificación E3 - no peores objetivos, pero con distintos objetivos. El objetivo de la especificación E3 iba a ser mucho más hacia el final de matemáticamente exacta del espectro. Se habrá dado cuenta de cómo prácticamente cada sección de la especificación consiste esencialmente algoritmos de pseudocódigo que describen en prosa en lugar de matemáticas-pesada precisamente lo que el efecto de cada operación está en el sistema.

Se dará cuenta, por ejemplo, que la especificación E3 habla de la diferencia entre los números "matemáticos" y sus representaciones binarias. Un borrador de la especificación E4 incluso fue tan lejos como para señalar que existen problemas de teoría de conjuntos con una definición ingenua de "tipo" como un conjunto de valores si los tipos son también valores. Este tipo de cosas sería completamente fuera de lugar en la especificación C #; No busca tener un fuerte fundamento matemático teórico para asegurar su corrección. Se habrá dado cuenta de que la especificación C # en ninguna parte, incluso define "tipo" - que fue escrito con el supuesto de que los lectores serán pro desarrolladores que (1) ya saben qué tipo son, a efectos prácticos, y (2) no saben ni el cuidado lo que la teoría de conjuntos o la teoría de categorías tiene que decir acerca de la matemática bien fundado de cualquier definición de "tipo".

El objetivo del proceso de ECMAScript fue para múltiples proveedores de idiomas muy similares a reunirse y ponerse de acuerdo sobre una descripción precisa de lo que era en el terreno común entre todas esas implementaciones. La especificación E3 nunca tuvo la intención de ser un tutorial de cualquier tipo, y está dirigido principalmente a la lengua y la herramienta ejecutores , en lugar de lenguaje usuarios .

especificación E4 de Waldemar fue aún más lejos. Si no recuerdo mal, comenzó mediante la especificación de un simple "lenguaje de especificación" muy preciso con una semántica clara. Luego escribió un intérprete para ese idioma en Common Lisp. Luego escribió la especificación E4 en su lenguaje de especificación. El resultado fue que pudo compilar la especificación ECMAScript en sí en un intérprete de trabajo . Esto es exactamente el tipo de "matemáticas superiores" que estamos tratando de evitar en la especificación de C #. Este es un enfoque impresionante a la especificación si desea ser increíblemente precisa y exacta, pero es una forma terrible para escribir un documento que usuarios de la lengua puede aprender.

¿Responde eso a su pregunta?

Answer 2

Usted probablemente está experimentando una diferencia entre la legibilidad de las especificaciones de los dos idiomas porque fueron escritos por diferentes grupos de personas, y discutir los idiomas que emplean diferentes paradigmas de objetos.

La especificación JavaScript fue escrito por un comité después de que el lenguaje ha evolucionado orgánicamente después de varios años. La especificación de C # fue escrito por un pequeño grupo de ingenieros de la empresa, mientras que el lenguaje fue creciendo de una manera controlada.

C # es programación orientada a objetos de clases centradas y JavaScript es prototipo-céntrica. Es posible que si no está tan familiarizado con uno como lo es con la otra, y luego un poco de material puede ser difícil de entender al principio, sobre todo cuando se entra en detalles de implementación. Eso no necesariamente indica un problema con la claridad y la legibilidad de una especificación.

Answer 3

En relación con los lenguajes convencionales JavaScript es muy extraño. De hecho no hay también muchos lenguajes populares que como JavaScript se basan prototipo. JavaScript es completamente objeto basado, y todos los objetos son esencialmente matrices asociativas con funciones también son objeto de primera clase. Esto no es normalmente lo que se espera de ver desde un lenguaje sin embargo, con la popularidad de Ajax y programación del lado del navegador JavaScript se ha convertido en el idioma de la web. Si bien se podría haber evitado estas especificaciones extraños, creo JavaScript puede conducir a una cierta codificación interesante y creativo. Cierres por ejemplo, son lo que más nuevos desarrolladores se esfuerzan por comprender, pero en mi experiencia, son muy útiles. La semántica de la lengua a veces tontos a los desarrolladores a pensar JavaScript es un sabor de C, pero pronto se dan cuenta de que esto sea no es cierto.

A mí C # es el pináculo de los lenguajes de programación. Es correcto y en línea con las expectativas académicas. Es una pena que la EM es el principal impulsor de este idioma. Al igual que yo estoy seguro de que hay muchos otros que disfrutan de una adecuada implementación de una plataforma con soporte para C # en ninguno sistema basado en Windows (Mono es un paso en la dirección correcta).

Si usted está interesado en aprender JavaScript y no un marco de JavaScript, entonces realmente sugieren que seguir con los libros que tratan directamente JavaScript. Sin embargo, si tiene la intención de empezar y no se preocupan mucho acerca de los pormenores de la sugerencia de libros JavaScript @bwawok es el camino correcto a seguir.

Answer 4

Bueno, usted es la primera persona que conozco de tratar de aprender un lenguaje basado en los documentos ECMA. De todos modos, yo diría que la diferencia se debe principalmente a la habilidad de las personas que escriben las especificaciones. C # es, obviamente, un poco más fácil para especificar (debido a la naturaleza menos dinámico - como ya se ha señalado), pero al final ... ... IIRC JavaScript es el diseño por el comité (muchas personas escribiendo también en la especificación), mientras que C # hecho por Microsoft por una sola persona, al final, tal vez con 1-2 autores lo largo del camino y algunos ayudantes, pero al final se Anders es Hejlsberg (esperanza te sueltan ese derecho). Diseño de comité y tener que votar sobre las cosas a veces puede conducir a menos óptimo "diseño" de un documento.

Así que, al final creo que se trata de la habilidad de las personas que escriben las diferentes especificaciones que uno es más difícil de leer que el otro.

Answer 5

Una de las razones es que la norma se vincula a ECMAScript es en realidad. JavaScript, JScript y ActionScript son todas las implementaciones de ECMAScript, y ECMAScript fue escrito para abarcar las partes comunes de cada uno. Por el contrario, C # fue diseñado principalmente por tres personas (según el estándar ECMA-334) de Microsoft.

Aparte de eso, usted tendría que tomar con la comité que escribió las Normas de ECMAScript.

Answer 6

En pocas palabras, es probablemente porque fueron escritos por diferentes autores. La especificación C # fue escrito por Microsoft que tenía un gran interés en lo que es bueno (por lo que sería aceptada), mientras que la especificación ECMAScript fue escrito por una comisión posterior a la lengua ya estaba en uso.

Answer 7

Bueno, la mejor parte es, C # se ejecuta desde un ordenador a otro los mismos (sí diferencias tal vez de menor importancia en las versiones de .NET, pero cosas por lo general se comportan). Javascript funcionará muy diferente entre Internet Explorer Firefox vs vs cromo.

Por ejemplo, usted tiene una página web con un elemento

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

Y se ejecuta el código JavaScript

document.getElementById("fred")

Internet Explorer le conseguirá el elemento (a pesar de que este es un comportamiento equivocado, no hay ningún elemento con un ID de Fred), pero Firefox le dará un valor nulo.

Lo más probable es que no, esto es debido a cómo crecieron los idiomas. C # 1 fue hecha por la empresa y los desarrolladores se vieron obligados a seguir las normas, o su código no funcionaría. JavaScript se puso en práctica en muchos navegadores diferentes de diferentes maneras, y la gente estaba libre de añadir o eliminar funciones o cambios a su antojo.

En resumen, JavaScript necesita más trabajo para aprender que otras lenguas debido a su historia. Mirada en una buena biblioteca como jQuery para abstraer las diferencias navegador, y usted debe conseguir la caída de ella lo suficientemente rápido. Aprender de un documento es sólo una pequeña parte del aprendizaje de un idioma ... qué algunos de codificación y aprender cómo funciona, y tendrá sentido.