Cuando desea dar al usuario la capacidad de escribir complementos para su aplicación, se enfrenta a la elección de cómo proporcionar la API. Debajo del corte, mostraré por qué la peor solución para esto sería inventar su propio lenguaje de programación y analizar los códigos fuente, así como también los muebles aquí.

PL no es la función principal de la aplicación

Imagine que abrimos la producción de muebles modulares. Hay algunos elementos básicos: encimeras, posavasos, mesitas de noche, etc. Hay una línea de producción asociada con el procesamiento de madera: máquinas herramienta, sierras, barnices, todo con la última tecnología. Pero todo esto debe de alguna manera mantenerse unido. Sabemos que hay 100,500 empresas que se especializan en la fabricación de hardware y pernos, existen algunos estándares para los sujetadores de muebles que fueron inventados por una comunidad de profesionales para facilitar la vida de sus clientes. ¿Qué tan visionaria será la decisión de desplegar una línea adicional para la producción de tornillos, tuercas y ángulos propios?

¿Qué podemos ganar?

• Así podemos marcar nuestro producto para que el hámster sienta su "originalidad" y lleve más dinero.
• Tal vez esto nos permita no pagar derechos de autor por ninguno de los tornillos, o resolver el problema de logística.
• Podemos ingresar a un nuevo mercado de tornillos y tuercas, estableciendo nuestro propio estándar, que es más rápido, mejor y más alto.

Pero seamos limpios.

• El ilitismo es el trabajo de los vendedores. El vendedor hará o no la marca un Elite con o sin una nueva línea de producción.
• El derecho de autor, por regla general (no siempre, por supuesto), es más barato que el desarrollo desde cero. Y resolviendo el problema de entregar un elemento desplegando una nueva línea de producción, solo lo exacerba.
• Si queremos probar un nuevo campo de actividad para nosotros mismos, no necesitamos conectarlo con lo que ya somos profesionales. Puede parecer que es más fácil empujar los tornillos con los muebles, pero si los tornillos no se elevan, arrastrarán los muebles con ellos. Al menos lo que ya cuesta a los clientes.

Volviendo a nuestras ovejas: si está creando un ecosistema para las extensiones de su aplicación, entonces tiene una aplicación . Hace algo bueno, algo en lo que eres bueno.

KSP - Kontakt Script Processor, o línea de producción de pernos en el mundo del audio digital

Te contaré una historia sobre ese lenguaje:

Kontakt es un mameluco (muestra) de la compañía austriaca Native Instruments . Actualmente es muy difícil encontrar un proyecto utilizando herramientas virtuales en las que no se utiliza. En los últimos 10 años, Kontakt ha ocupado la mayor parte del mercado de instrumentos muestreados. El secreto es simple: en un momento, Kontakt propuso dos innovaciones que dieron la vuelta al desarrollo de instrumentos virtuales muestreados.

La primera innovación estaba directamente relacionada con su función principal: manejaba la memoria con mucho cuidado (y las muestras en wav son las mismas, tanto HDD como RAM). NI creó un formato de compresión sin pérdidas con una decodificación rápida y escribió un revolucionario sistema de almacenamiento en búfer de audio para su época.

La segunda innovación fue KSP

Antes del contacto, había dos formas de organizar funcionalmente las muestras grabadas en un instrumento controlado por MIDI:

• Escriba su propio motor desde cero en C ++ o en otro idioma que pueda usar el SDK VST de Steinberg (y hay otros formatos de complementos, por ejemplo, AAX).
• Utilice una muestra preparada para músicos que no están familiarizados con la programación, pero que tienen sonidos que deben organizarse en algún tipo de sistema. Digamos Giga Studio . Pero tales mamelucos, por regla general, estaban cerrados o para terminar su trabajo, requerían no menos personal que el desarrollo básico bajo el SDK de VST.

El contacto satisfizo tanto esto como aquello: para la creación rápida de prototipos hay una GUI conveniente que es comprensible para cualquier músico que haya leído el manual, y para un mayor refinamiento no hay menos un lenguaje de programación , con condiciones, funciones (de la versión 4) y una biblioteca estándar que representa la API a la mayoría de las funcionalidades implementadas a través de la GUI, así como a los parámetros para reproducir muestras directamente. Entre otras cosas, a partir de la versión 2 se hizo posible personalizar la interfaz con todo tipo de silbatos y falsificaciones, lo que permitió mostrar su singularidad en una escala casi ilimitada. Y el código de desarrollador está oculto a la vista dos veces: ofuscación y protección contra el cambio de herramientas .

Dada la creciente popularidad del motor, así como un período impresionante de desarrollo activo del mameluco, hoy Kontakt es una especie de rifle de asalto Kalashnikov en el mundo del audio digital. Es fácil de aprender, confiable como un tanque, tiene la capacidad de dopilka dentro de límites razonables para usted amado y tiene un gran mercado para usuarios satisfechos.

No todo es tan color de rosa

Lo inevitable sucedió: la innovación en forma de KSP se ha convertido en un flagelo. Tratando de hacer que la sintaxis sea accesible para los tontos, que son músicos, en lugar de resolver la implementación de la API en lenguaje humano, Nativs escribió su propio intérprete de su propio idioma, cuya arquitectura inicialmente no presuponía un tormentoso vuelo de imaginación de los desarrolladores de herramientas, de lo que estamos siendo testigos ahora. Ya en la versión 3, los nativos perdieron la esperanza de mantenerse al día con los apetitos de los usuarios, y simplemente comenzaron a remachar las nuevas funciones de la biblioteca estándar, permitiendo a los usuarios descubrir el entorno de desarrollo de código por su cuenta.

Además, incluso entonces apareció Nils Lieberg KScriptEditor , bifurcado con Scintilla , que durante mucho tiempo ha servido como IDE principal para KSP. Es ridículo decirlo, pero cuando los nativos se dieron cuenta de que el contacto no podía hacer frente al tamaño de la fuente alimentada, introdujeron funciones en el idioma, sin siquiera molestarse en pasarles argumentos. Y un mes después apareció un taskfunc en taskfunc , pasando argumentos a funciones que no toman argumentos.

Después de un tiempo, Niels se dio cuenta de que estaba pisando el rastrillo de los Nativos: no tenía sentido desarrollar un IDE propio. Portó el compilador e implementó la funcionalidad IDE a SublimeText2, y saludó. Por el momento, las riendas de SublimeKSP están a cargo del desarrollador, al parecer, de Fluffy Audio .

Bueno, tu entiendes)

Y una vez más, ya es un generador de código, que no es menos que un lenguaje, con un sistema de importaciones, un analizador sintáctico, un compilador, una sintaxis diferente de KSP, pero que aún admite compatibilidad con ella, por razones desconocidas por la ciencia, resulta ser una terrible montaña de muletas que no se pueden tirar. debido a la compatibilidad con versiones anteriores de proyectos de desarrolladores de bibliotecas que han estado desarrollando sus motores KSP durante años.

Supongamos que el sistema de importación funciona globalmente con respecto al archivo desde el que se inicia la compilación, por lo tanto, para compilar un módulo ubicado en una subcarpeta, es necesario cambiar completamente sus rutas en las importaciones, de acuerdo con su posición en la estructura del proyecto. Y el tipo que lo apoya estaría feliz de cambiar esto, pero luego romperá los proyectos del mismo Spitfire Audio por mucho tiempo. Y este hecho por sí solo complica la prueba modular (no digamos nada sobre la unidad) al infierno.

Parece que la solución al problema es usar enlaces simbólicos, pero en algún lugar en algún lugar no funciona como se esperaba, y los enlaces simbólicos funcionan solo parcialmente. Este tipo de problema no es una cosa. Entre otras cosas, después de Niels, el desarrollo no se llevó a cabo modificando el compilador en sí, que recibe el código ya analizado. Y, de nuevo, por razones de compatibilidad con versiones anteriores, al agregar complementos de sintaxis extendida, cada uno de los cuales recibe las fuentes originalmente cortadas en líneas, las analiza por su cuenta y realiza modificaciones.

Dado que la mayoría de la lógica del preprocesador se basa en macros y funciones en línea que implementan el código en un gran lienzo que almacena el 80% de las condiciones siempre verdaderas o siempre falsas (sustituyendo las constantes por la entrada de la condición), que se colapsan en la etapa analizando AST, el tiempo de compilación de la fuente "correcta" es comparable a Con proyectos, esto está en un lenguaje interpretado para dummies.

Decir que KSP se ha convertido en una molestia para los desarrolladores es no decir nada.

Ni un solo contacto.

No puedo dar ejemplos de otras áreas, pero aquí desde el alcance de DigitalAudio:

• Lemur es una aplicación de pala con un editor de escritorio que le permite crear rápidamente interfaces hermosas para comunicar palas utilizando el protocolo OSC . Tiene su propio PL, que se puede usar en objetos de script especiales dispersos por todo el árbol del proyecto. No hay forma de hacer un compilador para él como lo que se hizo para KSP.
• Reaper - DAW con un ecosistema desarrollado de desarrollo de extensión. Como resultado, siempre que sea posible, dupliqué mi código de lenguaje JSFX (ReaScript) como API para C ++, lua y Python.
• HISE es un joven escritor y constructor de VST \ VSTi que matará a Kontakt del desarrollador sueco Christoph Haart tarde o temprano. Dentro del editor en sí, le permite escribir en JavaScript modificado, que los objetos de C ++ analizan y compilan en el binario. La idea con su propio analizador para introducir entidades adicionales (por ejemplo, registrar variables, si las traduje correctamente) funcionó hasta que los usuarios transfirieron su código del editor HISE a sus IDE favoritos con resaltado de sintaxis, análisis estático y herramientas de formato JsPrettier . Ahora Christophe esbozó un par de archivos de encabezado para compilar bibliotecas estáticas en C ++, que luego pueden usarse como módulos en el editor. Paralelamente, continúa complementando HISEScript (porque ya no se puede llamar a JavaScript) con nuevas funciones, pero sabemos que ...

Conclusión

Escriba su propia aplicación, dedicándose a su funcionalidad principal, no pierda tiempo en el analizador, la semántica y la sintaxis. Esto es interesante mientras comienzas, pero con una alta probabilidad conducirá a un callejón sin salida. El lenguaje de programación no puede ser parte de la aplicación: es una especie de línea de producción separada que requiere mucho tiempo para mantener, modificar y apoyar a la comunidad. A su vez, si espera reducir el umbral para tontos, suéltelo. Una tetera real, como regla, tiene miedo de imprimir cualquier cosa, y no se molestará con su sintaxis simple.

Al mismo tiempo, para los desarrolladores principiantes de complementos para su programa, simplemente puede hacer una pequeña Guía de inicio rápido , introduciéndoles los conceptos básicos de su PL elegido para expandir la funcionalidad y alimentarlo lentamente con su API, que es parte del ecosistema de este lenguaje.

PD No, escribir tu propio analizador para un PL listo para usar también es una mala idea.

Estaré encantado de cualquier crítica del artículo, el primer panqueque y todas las cosas.