¿Cuándo sería útil usar un lenguaje de scripting dentro de un programa más grande?

Cuando tienes un comportamiento que no quieres tener que recompilar el programa para poder cambiarlo. Esta es exactamente la razón por la que tantos juegos utilizan Lua como lenguaje de scripting / modding.

Esta técnica se puede utilizar para implementar la lógica central que se puede transportar fácilmente entre diferentes entornos de lenguaje. Por ejemplo, tengo un simulador de calculadora donde toda la lógica de la calculadora interna se implementa en 100% JavaScript. El código de la interfaz de usuario es, por supuesto, diferente para cada plataforma:

• navegador web (JavaScript)
• iOS (Objective-C)
• Windows (C ++ con Qt)
• Mac OS X (C ++ con Qt)
• Java Swing (Java)

Con esta disposición, es mucho más sencillo hacer versiones de mi programa para diferentes entornos operativos, y especialmente para mantenerlos actualizados.

En términos generales, existen dos situaciones en las que aplicaría este patrón:

1. Esto se usa internamente para aprovechar la calidad del lenguaje incorporado.
2. Esto se usa para proporcionar programabilidad externa.

Internamente

• Normalmente, el lenguaje incorporado se interpreta lo que permite cambios para ser hecho y probado rápidamente sin una recompilación.
• El lenguaje incorporado puede ser más expresivo que el lenguaje en el que está escrita su aplicación principal, lo que nuevamente permite un desarrollo más rápido.
• El idioma puede ser más adecuado para algunos domain en particular, en comparación con un lenguaje de propósito general.
• Los usuarios internos utilizan el lenguaje que necesita un lenguaje / entorno de programación "más simple". Los programas cortos son escritos por personas que no son desarrolladores de software que utilizan una sintaxis / API relativamente simple.

Un ejemplo aquí sería el uso de Lua en Adobe Lightroom.

  

Entonces, lo que hacemos con Lua es esencialmente toda la lógica de la aplicación   desde ejecutar la interfaz de usuario hasta administrar lo que realmente hacemos en la base de datos.   Casi cada pieza de código en la aplicación que podría describirse como   Tomar decisiones o implementar funciones está en Lua hasta que te bajas   al procesamiento en bruto, que está en C ++.   ( Entrevista de Mark Hamburg: Adobe Photoshop Lightroom )

Externamente

• Permita que los usuarios extiendan el comportamiento de su aplicación sin requerir herramientas y / o bibliotecas especiales y / o acceso a su código fuente.
• Proporcione a esos usuarios una API bien definida y un entorno de espacio aislado. Esto también se puede hacer en el idioma de la aplicación, pero la incorporación de un intérprete puede facilitarlo.

IBM usó lenguajes de script muy exitosamente en su sistema operativo mainframe VM-CMS . EXEC , EXEC / 2 y más tarde Rexx se utilizaron en todo el sistema, tanto interna como externamente. Las diferentes aplicaciones (p. Ej., XEDIT ) se podían escribir en esos mismos idiomas y las aplicaciones / utilidades internas (p. Ej., Correo electrónico) se escribieron en el lenguaje de scripting y aprovechó la estrecha integración con el sistema operativo y otras herramientas. Los clientes crearon y compartieron muchas herramientas y aplicaciones con script. DEC también proporcionó DCL . Más adelante, Microsoft admitió VBscript como lenguaje de scripting en la mayoría de sus aplicaciones y más recientemente PowerShell (también MS / DOS lotes ). Los shells de Unix también tienen scripting .

La tendencia actual parece estar exponiendo las API de alguna manera y deja la elección del lenguaje de scripting a los usuarios que pueden utilizar diferentes enlaces u otros medios para acceder a la API.

Los ejemplos del mundo real incluirían: -

• La mayoría de los navegadores web que admitan JavaScript incrustado.

• Microsoft Office Suite: Excel Word, etc., todos admiten scripts de VBA incrustados.

• Muchos enrutadores de red incluyen API de script, en una variedad de idiomas TCL, Perl, Lua.

Muchos dispositivos integrados se implementan utilizando un conjunto muy pequeño de funciones básicas de C que se pegan entre sí mediante un lenguaje de scripting como Lua. Así que tiene un conjunto de funciones C pequeñas y rápidas que interactúan con el hardware y la mayoría de la lógica de control en un lenguaje flexible y fácil de modificar.

A veces, las secuencias de comandos están incrustadas en una aplicación porque es un medio para extender la aplicación host a otros desarrolladores. Con el fin de capturar el mayor rango posible de habilidades de lenguaje de programación, el host podría admitir múltiples lenguajes de scripting. Por ejemplo, en la JVM, puede incrustar una gran cantidad de compatible con JSR-223 idiomas , incluidos Python, Ruby, JavaScript, etc.

Otra razón no mencionada anteriormente es que el lenguaje incorporado tiene una o más características destacadas que el lenguaje principal no podría duplicar fácilmente. Un ejemplo de esto sería la funcionalidad Parse o la creación sin esfuerzo de DSL (idioma / dialecto específico del dominio) que se puede encontrar en un idioma como Rebol.

Hay una forma interesante de usar un lenguaje de scripting dentro de una aplicación que aún no ha sido mencionado por los demás.

Si su lenguaje principal tiene un tiempo de ejecución rico y reflexivo, a menudo es útil incorporar un lenguaje simple con REPL en sus aplicaciones, conectarlo a un socket y darle acceso a todo el sistema.

Se puede utilizar para una depuración interactiva (y, naturalmente, es mucho más potente que su depurador habitual), parcheo de código en caliente, varios propósitos de monitoreo, incluso puertas traseras (si no está bien).

Mi situación específica, cuando uso un lenguaje de script interpretado en una aplicación principal:

Hay un dispositivo externo que realiza varias funciones. Mediciones, control, lecturas. Es bastante "tonto" en sí mismo y requiere un control preciso, paso a paso, que incluye muchos estados de espera y toma de decisiones ad hoc en el lado del mecanismo de control.

Se requieren varias funcionalidades del dispositivo en varios puntos de la aplicación principal, en diferentes momentos, a menudo bajo demanda. La aplicación principal no permite estados de espera como tales, todo debe hacerse con máquinas de estados finitos.

Ahora, quien haya escrito una máquina de estados finitos sabe que implementar un estado de espera es efectivamente al menos dos, a menudo tres o cuatro estados internos de la máquina. Implementar veinte estados de espera para varias funciones (y esperar sus respuestas y reaccionar en consecuencia) del dispositivo externo sería una experiencia muy, muy frustrante.

Entonces, en cambio, hay estados de "ejecutar una función de no esperar", "ejecutar una función de bloqueo", "ejecutar una función de bifurcación / condicional / salto" en la máquina de estados finitos, quizás seis estados en total. Y hay scripts de control que se programan para su ejecución, que luego son ejecutados por el intérprete que controla el dispositivo externo y sus resultados se colocan donde son necesarios.

En resumen, la aplicación: en un RTOS, el uso de un lenguaje de script interpretado interno puede reducir enormemente la complejidad de realizar tareas abundantes en estados de espera (funciones de bloqueo).

Desde mi experiencia, una vez desarrollamos una gran aplicación que reescribe el código fuente de una lengua "antigua" para que sea compatible con Unicode. El fue hecho en C #. Terminé escribiendo solo el motor (que crea un modelo de datos y proporciona los medios para realizar los pasos necesarios para el proceso de reescritura) en C #: el "código de pegamento" para ejecutar cosas en realidad se realiza en IronPython.

El punto más grande para el IronPython integrado: Supongamos que cargó un modelo de big data (aproximadamente una hora de carga). Entonces quieres, manualmente, recopilar información y buscar cosas. Hacer esto con un script de Python desde una consola interactiva es mucho mejor que hacer clic en el modelo de datos con el depurador (además, es reproducible).

Hay dos razones.

• curva de aprendizaje. Prácticamente todos pueden aprender y escribir en javascript.
• Seguridad. Es difícil controlar el contexto de seguridad del código de script en C # o Java. Javascript es perfecto para eso. El autor de la secuencia de comandos nunca puede acceder al disco ni a ningún otro lugar si no lo permite. El motor de JavaScript principal es solo una calculadora avanzada.
• Calidad. Usted pone un límite muy grueso para el código de secuencias de comandos. Los niveles de "código de espagueti" son muy diferentes para Javascript o C # / Java. (Lo que te impide abrir las puertas del infierno)
• Tipo de seguridad. C # / Java es un entorno seguro para el tipo, en su mayoría no lo prefiere en un entorno de scripting. Expresión como "12" + 3 da "123" en javascript pero C # / Java ni siquiera compilará. En su mayoría, los guionistas ni siquiera son "tipo"
• Dinámico. Cualquier objeto puede contener cualquier propiedad / método y puede cambiar su tipo a tiempo. Por ejemplo, podría proporcionar un objeto C # proxy a un entorno de scripts que exponga los nodos XML como propiedades.
• Productividad. Por lo general, escribir guiones es mucho más fácil que C # / Java. No se requiere compilación o "registro de plugin". Puede editar directamente el contenido del script dentro de la aplicación con resultados inmediatos.
• Gestión. El uso de C # / Java requiere que un SDK esté vinculado a los complementos que expone las clases internas al mundo. Esta arquitectura de complementos requiere la "compatibilidad con versiones anteriores" para las versiones anteriores del SDK. Esta arquitectura le obliga a crear objetos de dominio "virtuales" que proporcionan un mecanismo interno de aplicación en el contexto del dominio. Es más manejable / flexible que exponer una API.

¿Cuándo? Entre 1948 y 2008, los idiomas compilados inicialmente tomaron un tiempo considerable para compilar y vincular, por lo que era un lugar común crear un lenguaje de scripting para permitir la personalización y configuración del usuario. Si nos fijamos en el historial de AutoLisp, la respuesta es inicialmente AutoCAD incluido con un lenguaje de secuencias de comandos dentro de él, pero esto se eliminó gradualmente a favor de exponer una interfaz de secuencias de comandos a VBA y luego .net.

Con CLR, habilitar un programa C # o una llamada al programa Lua en un sistema existente no es significativamente diferente en costo de desarrollo, y el tiempo de ejecución .net se envía con las herramientas para generar y compilar sobre la marcha.

Ya no necesita tener un lenguaje de script dentro de el programa más grande, sino que debe exponer el programa más grande a las funciones de scripting del tiempo de ejecución.

En los entornos que no ofrecen la generación y compilación de códigos al vuelo, y se considera conveniente ofrecer un lenguaje de automatización de propósito general en lugar de uno específico del dominio, todavía obtendrá secuencias de comandos Lua o Python. Para las herramientas que ofrecen una interfaz COM, ese lenguaje de script será C # o VB.net (MS Office, Sparx Enterprise Architect). Por lo tanto, no es necesario tener un lenguaje de scripting para un programa escrito en un lenguaje que sea lo suficientemente simple como para ser un lenguaje de scripting.