¿Un futuro para Dynamic Feature Runtime en el contexto de C#?

Question

Así que C# había evolucionado como un lenguaje de tipado estático y hace un trabajo más que perfecto en mantener el nicho en el desarrollo de la Línea de Aplicaciones de Negocios con .NET Framework.

Ahora, claramente, en el pasado reciente, Microsoft ha comenzado a dar pasos hacia otros paradigmas fundamentales para los cuales C# y .net nunca afirmaron ser la herramienta hasta el pasado reciente.

Uno de ellos es el Ok Divercity lenguaje DLR

- grande, estoy pensando, solo que ahora parece que tengo que cambiar la forma en que estoy pensando cuando escribo mis entidades de negocios con las clases si quiero aprovecha la función ... Lo cual es genial, y todos estoy aprendiendo lo nuevo. Pero antes de hacerlo, tengo algunas preguntas para la respetada comunidad a ese respecto. Ahora, por el bien de la aclaración, estoy más interesado en la aplicación del DLR junto con CLR.

así comenzamos:

1. Para su opinión, es una característica DLR viable que desrves ser mirado desde el punto de vista comercial, el desarrollo de software empresarial? Es decir, ¿realmente necesita c como una característica para continuar haciendo lo que está haciendo o tendría más sentido cambiar a un lenguaje estándar de tipeo dinámico en ese punto?

2. Donde la combinación de código en desarrollo y escritura con CLR y DLR brilla en términos de aplicabilidad comercial? Los ejemplos concretos serían los más valiosos para mí.

3. Beneficios.

Ahora el MSDN dice esto:

Provides Future Benefits of the DLR and .NET Framework Languages implemented by using the DLR can benefit from future DLR and .NET Framework improvements. For example, if the .NET Framework releases a new version that has an improved garbage collector or faster assembly loading time, languages implemented by using the DLR immediately get the same benefit. If the DLR adds optimizations such as better compilation, the performance also improves for all languages implemented by using the DLR.

bien grande, pero ¿cómo exactamente? ¿Y no obtendré lo mismo si solo actualizo mi marco de todos modos? ¿Por qué tengo que escribir en DLR para eso?

1. ¿Se pueden publicar ejemplos de código para mostrar que DLR puede hacer una jon mejor que la C# normal?

2. ¿Vale la pena aprenderlo para ser un ingeniero .net comercializable, o es más o menos una característica isotérica decir simplemente: "Oh, somos mejores que Ruby, pero también podemos hacerlo más"?

3. ¿Cuáles son los gastos generales de combinar esos 2 o simplemente usar el DLR solo en la aplicación. ¿desarrollando?

4. ¿Se puede utilizar DLR con f #?

Saludos.

Answer 1

Puede valer la pena aclarar que el DLR es una API en capas sobre la CLR para bajar la barra para implementar funciones de lenguaje de tipeo dinámico. Puede usarlo de extremo a extremo como lo hacen IronPython, IronRuby, Clojure y otros idiomas para implementar su idioma. Puede usarlo como una comida por pieza como C# o VB para obtener el almacenamiento en caché dinámico del sitio de llamadas (busque el almacenamiento en caché polimórfico en línea para obtener información general sobre los conceptos). Por lo tanto, C# agrega la palabra clave 'dinámica' y utiliza los CallSites, los enlazadores, los objetos dinámicos de DynamicMetaObjects del DLR, etc., para implementar esta característica de idioma.

Sí, el DLR es una característica viable y tiene sentido para C#. C# estaba detrás de VB para interoperabilidad COM, fuentes de datos sin tipo (DB, XML, etc.) y para una sintaxis más ligera detrás de las páginas web (por ejemplo, button.text = "yo"). Cuando amo un idioma, lo encuentro generalmente útil, o he ajustado mi destreza en él, me gusta usar ese lenguaje tanto como sea posible. No quiero tener que improvisar y crear gastos generales de mantenimiento en mi solución mediante el uso de varios idiomas a menos que realmente necesite hacer eso. La 'dinámica' de C# me permite hacer cosas que ya podía hacer en C# de una manera mucho más fácil y sabrosa, y ciertamente significa que no tengo que recurrir a un lenguaje puramente dinámico u opcionalmente explícitamente escrito para escribir código en muchos más situaciones ahora.

El código de desarrollo con el DLR brilla si está intentando agregar funciones de tipo dinámico a un idioma o sistema grande y rico. Como se cita a menudo, "cualquier programa suficientemente complicado ... contiene una implementación ad hoc ... de Lisp". Si encuentra que necesita algún acceso de tipo dinámico a datos u objetos, con algunos cálculos de lo que una operación significa dadas algunas entradas y desea almacenar esa acción para cálculos similares posteriores en esa ubicación en el programa, el DLR lo ayuda a hacer eso a bajo costo Lo que pasa es que es posible que ni siquiera necesite usar el DLR en este nivel, ya que C# le ha presentado el término "dinámico". Sin embargo, es posible que desee implementar IDynamicMetaObjectProvider en algunos objetos que representan sus orígenes de datos para que puedan participar en las operaciones vinculantes que realizan las llamadas de despliegue dinámico de C#. Un ejemplo de esto sería si XmlElement implementó IDMOP para que pudiera escribir algo como: dynamic x = source.GetXmlElement (...); ... x.Clientes [i] .Address.City == "Erie" ...

Los beneficios son un mayor grado de expresividad en el código escrito en contra de los datos u objetos que son inherentemente dinámicos por su naturaleza, en lugar de tener para expresar declaraciones complicadas de tipo intermedio y hacer muchas llamadas a o.GetBlahByName ("whatever").

El párrafo que citó de los documentos DLR trata acerca de las implementaciones de lenguaje compiladas en el DLR. Sí, por supuesto, sus aplicaciones también obtienen los beneficios. El punto era más acerca de cómo, por ejemplo, IronPython avanzó más rápido no solo por el advenimiento del DLR, sino porque el CLR en sí hizo un trabajo que mejoró indirectamente la implementación de IronPython en el DLR.

No se moleste en aprender el DLR a menos que necesite agregar algún acceso dinámico en caché a su idioma o sistema. La mayoría de las personas no codifica en este nivel de complejidad. La mayoría de las personas usa lenguajes y marcos, pocas personas los implementan.

F # podría usar el DLR, pero una idea errónea común es que F # es un lenguaje dinámico. No lo es. Está estrictamente tipado estáticamente, pero no está escrito explícitamente en todos los casos, que es lo que confunde a las personas. Se ve liviano sintácticamente debido al uso intensivo de la inferencia tipográfica y espacios en blanco significativos. Si F # fuera un día para decidir agregar un modelo tipo "dinámico" como lo hizo C#, entonces tendría sentido usar el DLR para facilitar la implementación y para la interoperabilidad con C#, lenguajes dinámicos en .NET, bibliotecas dinámicas y marcos , etc.

Cuenta