.NET o no .NET, esa es la cuestión

Primero una inconsistencia
O mejor dicho, una supuesta inconsistencia. C# no permite que existan métodos globales, de hecho ni siquiera permite la existencia de variables globales estáticas; A lo más que llega es a permitir miembros estáticos de una clase, sin necesidad de que ésta haya sido instanciada. Personalmente digo: menos mal.

Porque si no, las fichas y las clases deberían tener infinidad de propiedades o métodos compartiendo referencias a otras fichas y otras clases, conformando un maremágnum de elementos cruzados y poseídos entre sí, ofusfcando en gran medida el modelo de objetos.

Pero todo programa (digo ensamblado) ha de tener un punto de entrada, y el C#, violando en cierta manera sus propias reglas, exige la existencia de un elemento global no estático. Ese punto de entrada es main, que debe ser un método miembro estático con una firma concreta.

Técnicamente hablando no estamos violando ninguna regla del C#, pero como es al uso en otros marcos de trabajo, el punto de entrada de la aplicación debería ser una clase heredada de, por poner un ejemplo y sin salirnos mucho de las propias especificaciones del lenguaje, Application.

Que conste que no estoy criticando ni quejándome de esto, pero desde mi punto de vista, que en un lenguaje de programación orientado a objetos tan puro como quiere ser el C#, el punto de entrada de una aplicación sea un método estático global deja un poco que desear.

Y la nueva versión del lenguaje todavía es menos pura (léase LINQ), así que sigo sin entender por qué no permiten ni variables ni métodos globales, máxime cuando la base de LINQ consiste en casi eso (Y en C++/CLI es algo habitual).

Y ahora las consistencias
O mejor dicho, un punto muy fuerte. El último párrafo del capítulo tres del libro The C# Programming Languaje dice (y cito textualmente):

"The ordering of side effects is preserved with respect to volatile reads and writes ($10.4.3). Additionally, the execution environment need not evaluate part of an expression if it can deduce that that expression's value is not used and that not needed side efects are produced (incluiding any caused by calling a method or accessing a volatile field). When program execution is interrupted by an asynchronous event (such as an exexcption thrown by another thread), it is not guaranteed that the observable side effects are visible in the original program order."

La última frase del párrafo es evidente por sí misma, y si quieres garantizarlo, utiliza una sección crítica o un bloqueo. Yo me refiero al tema de los efectos laterales en las evaluaciones de las expresiones. En otros lenguajes una vez que se conoce si la expresión es cierta o falsa, no continúa evaluandose.

Al parecer en C#, si el resto de la expresión contiene o pudiera ocasionar algún efecto lateral, ésta se produciría de igual modo. Esta es una característica muy potente a la que no estamos acostumbrados los programadores de sistemas, aunque aunque sí lo estemos en relación al tema de las variables volátiles. Personalmente pienso que disponer de esta característica requiere que se le dé cierto grado de inteligencia al compilador y al entorno de ejecución; ésta sería una ventaja de lo que yo llamo " entorno interpretado".