Lorsque vous souhaitez donner à l'utilisateur la possibilité d'écrire des plugins pour votre application, vous êtes confronté au choix de la manière de fournir l'API. Sous la coupe, je montrerai pourquoi la pire solution serait d'inventer votre propre langage de programmation et d'analyser les codes source, ainsi que les meubles ici.

PL n'est pas la fonction principale de l'application

Imaginez que nous ouvrions la production de mobilier modulaire. Il y a quelques éléments de base: comptoirs, sous-verres, tables de chevet, etc. Il existe une ligne de production associée à la transformation du bois: machines-outils, scies, vernis, le tout avec les dernières technologies. Mais tout cela doit d'une manière ou d'une autre être maintenu. Nous savons qu'il y a 100 500 entreprises spécialisées dans la fabrication de quincaillerie et boulons, il existe des normes pour les fixations de meubles qui ont été inventées par une communauté de professionnels pour faciliter la vie de leurs clients. Quelle sera la décision à long terme de déployer une ligne supplémentaire pour la production de ses propres boulons, écrous et angles?

Que pouvons-nous gagner?

• De cette façon, nous pouvons marquer notre produit afin que le hamster ressente son "originalité" et porte plus d'argent.
• Peut-être que cela nous permettra de ne pas payer de droits d'auteur pour aucun des boulons ou de résoudre le problème de logistique.
• Nous pouvons entrer sur un nouveau marché pour les boulons et les écrous, en établissant notre propre norme, qui est plus rapide, meilleure et plus élevée.

Mais soyons propres.

• L'illitisme est l'œuvre des vendeurs. Le vendeur fera ou ne fera pas de la marque une Elite avec ou sans nouvelle ligne de production.
• Le droit d'auteur, en règle générale (pas toujours, bien sûr), est moins cher que le développement à partir de zéro. Et en résolvant le problème de la livraison d'un élément en déployant une nouvelle ligne de production, vous ne faites que l'exacerber.
• Si nous voulons essayer un nouveau domaine d'activité pour nous-mêmes, nous n'avons pas besoin de le connecter avec ce dans quoi nous sommes déjà des pros. Il peut sembler plus facile de pousser les boulons avec les meubles, mais si les boulons ne volent pas vers le haut, ils entraîneront les meubles avec eux. Au moins ce qui coûte déjà aux clients.

Revenons à nos moutons: si vous créez un écosystème pour les extensions de votre application, alors vous avez une application . Il fait quelque chose de bien, quelque chose que vous êtes bon.

KSP - Processeur de scripts Kontakt, ou ligne de production de boulons dans le monde audio numérique

Je vais vous raconter une histoire sur une telle langue:

Kontakt est une barboteuse (échantillonneur) de la société autrichienne Native Instruments . Il est actuellement très difficile de trouver un projet à l'aide d'outils virtuels dans lequel il n'est pas utilisé. Au cours des 10 dernières années, Kontakt a occupé la majeure partie du marché des instruments échantillonnés. Le secret est simple: à une époque, Kontakt a proposé deux innovations qui ont révolutionné le développement d'instruments virtuels échantillonnés.

La première innovation était directement liée à sa fonction principale: il manipulait la mémoire très soigneusement (et les échantillons en wav sont le même mangeur, à la fois HDD et RAM). NI a créé un format de compression sans perte avec décodage rapide et a écrit un système de mise en mémoire tampon audio révolutionnaire pour l'époque.

La deuxième innovation était KSP

Avant le contact, il y avait deux façons d'organiser fonctionnellement les échantillons enregistrés dans un instrument contrôlé par MIDI:

• Écrivez votre propre moteur à partir de zéro en C ++, ou dans un autre langage qui peut utiliser le SDK VST de Steinberg (et il existe d'autres formats de plug-in, par exemple, AAX).
• Utilisez un échantillonneur prêt à l'emploi conçu pour les musiciens qui ne sont pas familiers avec la programmation, mais qui ont des sons qui doivent être organisés en une sorte de système. Disons Giga Studio . Mais de tels romperms, en règle générale, étaient fermés, ou pour terminer leur travail, ils nécessitaient pas moins de personnel que le simple développement sous le SDK VST.

Le contact a apprécié ceci et cela: pour un prototypage rapide, il existe une interface graphique pratique qui est compréhensible pour tout musicien qui a lu le manuel, et pour plus de raffinement, il n'y a pas moins un langage de programmation , avec des conditions, des fonctions (à partir de la version 4) et une bibliothèque standard représentant l'API à la plupart des fonctionnalités implémentées via l'interface graphique, ainsi qu'aux paramètres de lecture directe des échantillons. Entre autres choses, à partir de la version 2, il est devenu possible de personnaliser l'interface avec toutes sortes de sifflets et de faux, ce qui a permis de montrer son caractère unique à une échelle presque illimitée. Et le code développeur est caché deux fois: obfuscation et protection contre les changements d' outils .

Compte tenu de la popularité croissante du moteur, ainsi que d'une période impressionnante de développement actif de la barboteuse, Kontakt est aujourd'hui une sorte de fusil d'assaut Kalachnikov dans le monde de l'audio numérique. Il est facile à apprendre, fiable comme un réservoir, a la capacité de dopilka dans des limites raisonnables pour vous-même bien-aimé, et détient un énorme marché pour les utilisateurs satisfaits.

Tout n'est pas si rose

L'inévitable s'est produit: l'innovation sous forme de KSP est devenue un fléau. En essayant de rendre la syntaxe accessible aux mannequins, qui sont des musiciens, au lieu de résoudre l'implémentation de l'API dans le langage humain, Nativs a écrit son propre interprète de leur propre langage, dont l'architecture ne présupposait pas au départ une telle vague orageuse d'imagination des développeurs d'outils, dont nous assistons maintenant. Déjà par la version 3, les autochtones ont perdu tout espoir de suivre l'appétit des utilisateurs et ont simplement commencé à rivaliser avec les nouvelles fonctions de la bibliothèque standard, permettant aux utilisateurs de découvrir par eux-mêmes l'environnement de développement du code.

De plus, même alors, Nils Lieberg KScriptEditor est apparu , bifurqué avec Scintilla , qui a longtemps servi d'IDE principal pour KSP. C'est ridicule à dire, mais quand les indigènes se sont rendu compte que le contact ne pouvait pas faire face à la taille de la source alimentée, ils ont introduit des fonctions dans le langage, sans même prendre la peine de leur passer des arguments. Et un mois plus tard, un taskfunc est apparu dans taskfunc , transmettant des arguments aux fonctions qui ne prennent aucun argument.

Après un certain temps, Niels s'est rendu compte qu'il marchait sur le rake des autochtones: il n'y avait aucun sens à développer son propre IDE. Il a porté le compilateur et implémenté la fonctionnalité IDE sur SublimeText2, et a salué. Pour le moment, les rênes de SublimeKSP sont portées par le développeur, semble-t-il, de Fluffy Audio .

Eh bien, vous comprenez)

Et encore une fois, déjà un générateur de code, qui n'est rien de moins qu'un langage, avec un système d'importations, un analyseur, un compilateur, une syntaxe différente de KSP, mais qui supporte toujours la compatibilité descendante avec lui, pour des raisons inconnues de la science, il s'avère être une terrible montagne de béquilles qui ne peuvent pas être jetées en raison de la compatibilité descendante des projets des développeurs de bibliothèques qui développent leurs moteurs KSP depuis des années.

Supposons que le système d'importation fonctionne globalement par rapport au fichier à partir duquel la compilation est lancée.Par conséquent, pour compiler un module situé dans un sous-dossier, il est nécessaire de changer complètement ses chemins dans les importations, conformément à sa position dans la structure du projet. Et le gars qui le soutient serait heureux de changer cela, mais alors il rompra les projets du même Spitfire Audio longtemps et pour longtemps. Et ce fait à lui seul complique les tests modulaires (ne disons rien sur les unités) en enfer.

Il semblerait que la solution au problème soit d'utiliser des liens symboliques, mais quelque part quelque part, cela ne fonctionne pas comme prévu et les liens symboliques ne fonctionnent que partiellement. Ce genre de problème n'est pas une chose. Entre autres choses, après Niels, le développement n'a pas été effectué en modifiant le compilateur lui-même, qui reçoit du code déjà analysé. Et, encore une fois, pour des raisons de compatibilité descendante, en ajoutant des plug-ins de syntaxe étendue, dont chacun reçoit les sources initialement coupées en lignes, les analyse de leur propre chef et apporte des modifications.

Étant donné que la plupart de la logique du préprocesseur repose sur des macros et des fonctions en ligne qui déploient le code sur un immense canevas qui stocke 80% des conditions toujours vraies ou toujours fausses (en substituant les constantes à l'entrée de la condition), qui sont réduites à l'étape en analysant AST, le temps de compilation de la source "correcte" est comparable à celui des projets. Dans un langage interprété pour les nuls.

Dire que KSP est devenu une douleur pour les développeurs, c'est ne rien dire.

Pas un seul contact.

Je ne peux pas donner d'exemples provenant d'autres domaines, mais ici de la portée de DigitalAudio:

• Lemur est une application de pelle avec un éditeur de bureau qui vous permet de créer rapidement de belles interfaces pour communiquer des pelles en utilisant le protocole OSC . Il possède son propre PL, qui peut être utilisé dans des objets de script spéciaux dispersés dans l'arborescence du projet. Il n'y a aucun moyen de faire un compilateur comme cela a été fait pour KSP.
• Reaper - DAW avec un écosystème développé de développement d'extension. Par conséquent, dans la mesure du possible, j'ai dupliqué mon code de langage JSFX (ReaScript) en tant qu'API pour C ++, lua et Python.
• HISE est un jeune écrivain et constructeur VST \ VSTi qui tuera Kontakt du développeur suédois Christoph Haart tôt ou tard. À l'intérieur de l'éditeur lui-même, il vous permet d'écrire en JavaScript modifié, qui est analysé et compilé dans le binaire par des objets C ++. L'idée avec votre propre analyseur pour introduire des entités supplémentaires (par exemple, enregistrer des variables, si j'ai traduit correctement) a fonctionné jusqu'à ce que les utilisateurs transfèrent leur code de l'éditeur HISE vers leurs IDE préférés avec la coloration syntaxique, l'analyse statique et les outils de formatage JsPrettier . Christophe a maintenant esquissé quelques fichiers d'en-tête pour la compilation de bibliothèques statiques en C ++, qui peuvent ensuite être utilisées comme modules dans l'éditeur. En parallèle, il continue de compléter HISEScript (car JavaScript ne peut plus être appelé ainsi) avec de nouvelles fonctions, mais nous savons que ...

Conclusion

Écrivez votre propre application, en vous consacrant à ses principales fonctionnalités, ne perdez pas de temps sur l'analyseur, la sémantique et la syntaxe. C'est intéressant pendant que vous commencez, mais avec une probabilité élevée, cela entraînera une impasse. Le langage de programmation ne peut pas faire partie de l'application: c'est une sorte de ligne de production distincte qui nécessite beaucoup de temps pour maintenir, modifier et soutenir la communauté. À son tour, si vous espérez abaisser le seuil pour les nuls, laissez-le tomber. Une vraie théière, en règle générale, a peur d'imprimer quoi que ce soit et ne se souciera pas de votre syntaxe simple.

Dans le même temps, pour les développeurs de plug-ins débutants pour votre programme, vous pouvez simplement créer un petit QuickStartGuide , leur présenter les concepts de base de votre PL choisi pour étendre les fonctionnalités et lui alimenter lentement votre API, qui fait partie de l'écosystème de ce langage.

PS Non, écrire votre propre analyseur pour un PL prêt à l'emploi est également une mauvaise idée.

Je serai heureux de toute critique de l'article, de la première crêpe et de toutes choses.