当您想让用户能够为您的应用程序编写插件时，您将面临如何提供API的选择。 在摘要中，我将说明为什么最糟糕的解决方案是发明自己的编程语言并解析源代码以及此处的家具。

PL不是应用程序的主要功能

想象一下，我们开始生产模块化家具。 有一些基本元素：台面，杯垫，床头柜等。 有一条与木材加工相关的生产线：机床，锯子，清漆，全部采用最新技术。 但是，所有这些必须以某种方式结合在一起。 我们知道，有100,500家专门从事五金件和螺栓制造的公司，有一些专业人士发明了一些家具紧固件标准，以使客户的生活更轻松。 要部署一条额外的生产线来生产自己的螺栓，螺母和角钢，将有多么有远见的决定？

我们能赢什么？

• 这样，我们可以为我们的产品打上商标 ，使仓鼠感受到其“原始性”并携带更多的钱。
• 也许这将使我们不必为任何螺栓支付版权，也不会解决物流问题。
• 我们可以进入一个新的螺栓和螺母市场，设定我们自己的标准，该标准更快，更好，更高。

但是，请保持清洁。

• Ilitism是推销员的工作。 无论有没有新的生产线，卖方都会或不会使品牌成为精英品牌。
• 通常，版权（当然并非总是如此）比从头开发便宜。 解决了通过部署新生产线交付一个元素的问题，您只会加剧它。
• 如果我们想为自己尝试一个新的活动领域，则无需将其与我们已有的专业联系起来。 似乎更容易将螺栓与家具一起推，但是如果螺栓不飞起来，它们会将家具与家具一起拖拉。 至少那些已经在客户身上花费的成本。

回到我们的羊：如果您正在为应用程序的扩展创建生态系统，那么您就有一个应用程序 。 它做的很好，您擅长的事情。

KSP-Kontakt脚本处理器，或数字音频世界中的螺栓生产线

我会讲一个有关这种语言的故事：

Kontakt是奥地利公司Native Instruments的吸管（采样器）。 当前使用不使用虚拟工具的项目来查找项目非常困难。 在过去的十年中，Kontakt占领了大部分采样仪器市场。 秘密很简单：一次，Kontakt提出了两项​​创新，从而扭转了采样虚拟仪器开发的道路。

第一项创新与它的主要功能直接相关：它非常仔细地处理内存（wav中的样本是同一台硬盘，包括HDD和RAM）。 NI通过快速解码制作了无损压缩格式，并在当时创造了革命性的音频缓冲系统。

第二项创新是KSP

在联系之前，有两种方法可以将录制的样本功能性地组织到MIDI控制的乐器中：

• 使用C ++或其他可以使用Steinberg的VST SDK的语言（还有其他插件格式，例如AAX）从头开始编写自己的引擎。
• 使用现成的采样器为不熟悉编程但有某种声音需要在某种系统中组织的音乐家制作。 假设Giga Studio 。 但是，通常来说，这样的服装是封闭的，或者要完成他们的工作，与在VST SDK下进行裸开发相比，它们需要的人员不少于。

联系人对此非常满意：为了快速制作原型，有一个方便的GUI，任何阅读过该手册的音乐家都可以理解，并且为了进一步完善，还提供了一种编程语言 ，条件，功能（来自版本4）和代表API的标准库。通过GUI实现的大多数功能，以及直接播放样本的参数。 除其他事项外，从版本2开始，可以使用各种口哨声和假声自定义界面，从而可以在几乎无限的规模上显示其独特性。 而且，开发人员代码被隐藏了两次：混淆和防止更改工具 。

鉴于引擎的日益普及以及爬虫积极发展的令人印象深刻的时期，如今的Kontakt已成为数字音频世界中的卡拉什尼科夫突击步枪。 它易于学习，可靠，可以在自己喜欢的范围内在合理的范围内进行dopilka，并为满意的用户提供广阔的市场。

并非一切都那么红润

不可避免的事情发生了：KSP形式的创新已成为祸害。 Nativs试图让音乐家的傻瓜可以访问该语法，而不是解决人类语言中API的实现，而是编写了自己的语言解释器，该语言的体系结构最初并不以工具开发人员的想象力暴风雨为前提，而我们现在正在目睹。 在第3版中，Natives已经失去了跟上用户胃口的希望，而只是开始铆钉标准库的新功能，从而使用户可以自己确定代码开发环境。

而且，甚至在那时， Nils Lieberg KScriptEditor出现了 ，并与Scintilla进行了分叉，而Scintilla一直是KSP的主要IDE。 这很荒谬，但是当土著人意识到这种联系无法应付馈送源的大小时，他们甚至在不必担心将参数传递给它们的情况下，就将函数引入了语言。 一个月后，一个taskfunc出现在taskfunc ，将参数传递给不带参数的函数。

一段时间后，尼尔斯意识到自己正在踩着原住民的风头：开发自己的IDE毫无意义。 他将编译器和实现的IDE功能移植到SublimeText2，然后挥手致意。 目前，SublimeKSP的re绳似乎由开发人员从Fluffy Audio承担。

好，你明白了）

再说一次，已经是一种语言生成器，其语言不少于一种语言，具有导入系统，解析器，编译器，与KSP不同的语法，但仍支持向后兼容（出于科学未知的原因），事实证明这是一个可怕的拐杖，无法扔掉由于多年来开发KSP引擎的库开发人员的项目向后兼容。

假设导入系统相对于从其启动编译的文件而言是全局工作的，因此，为了编译位于子文件夹中的一个模块，有必要根据其在项目结构中的位置来完全更改其在导入中的路径。 支持他的家伙很乐意改变这一点，但是他将长期破坏同一个Spitfire Audio的项目。 而且，仅此一个事实就使模块化测试（就单元更不用说了）变得更加复杂。

似乎解决该问题的方法是使用符号链接，但是某个地方的某个地方不能按预期工作，并且符号链接只能部分工作。 这种问题不是一回事。 除其他外，在Niels之后，开发不是通过修改编译器本身来进行的，编译器本身已经接收了已解析的代码。 而且，出于向后兼容性的考虑，通过添加扩展语法的插件，每个插件都接收最初分割成几行的源代码，自行对其进行解析并进行修改。

鉴于大多数预处理器逻辑都依赖于宏和内联函数，这些宏和内联函数将代码部署到一个巨大的画布上，该画布存储80％的始终为true或始终为false的条件（通过将常量替换为条件的输入），这些条件在阶段会折叠起来解析AST时，“正确”源的编译时间与With项目相当，这是针对假人的解释语言。

说KSP已经成为开发人员的痛苦，更不用说了。

没有一个联系人。

我无法提供其他领域的示例，但是这里是DigitalAudio的范围：

• Lemur是带有桌面编辑器的挖土机应用程序，可让您快速创建漂亮的界面，以使用OSC协议与挖土机进行通信。 它具有自己的PL，可用于散布在整个项目树中的特殊脚本对象中。 没有办法像对KSP那样进行编译。
• Reaper - DAW具有扩展的开发生态系统。 结果，我尽可能地将JSFX语言代码（ReaScript）复制为C ++，lua和Python的API。
• HISE是一个年轻的VST \ VSTi作家和构建者 ，迟早会从瑞典开发商Christoph Haart杀死Kontakt。 在编辑器本身内部，它允许您编写经过修改的JavaScript，该JavaScript由C ++对象解析并编译为二进制文件。 拥有自己的解析器以引入其他实体（例如，如果我翻译正确的话，请注册变量）的想法一直有效，直到用户使用语法突出显示，静态分析和JsPrettier格式化工具将其代码从HISE编辑器转移到他们最喜欢的IDE 为止 。 现在，克里斯托夫（Christophe）绘制了几个头文件，用于在C ++中编译静态库，然后可以在编辑器中将其用作模块。 同时，他继续用新功能补充HISEScript（因为无法再调用JavaScript），但我们知道...

结论

编写自己的应用程序，专注于其主要功能，不要浪费时间在解析器，语义和语法上。 开始时这很有趣，但是极有可能导致死胡同。 编程语言不能成为应用程序的一部分：它是一种单独的生产线，需要大量时间来维护，修改和支持社区。 反过来，如果您希望降低虚拟阈值，则将其降低。 通常，真正的茶壶不怕打印任何内容，也不会因您的简单语法而烦恼自己。

同时，对于您的程序的初学者插件开发人员而言，您只需编写一个小型的QuickStartGuide ，将其介绍给您所选PL的基本概念，以扩展功能并缓慢地向您提供API（这是该语言生态系统的一部分）。

PS不，为现成的PL编写自己的解析器也是一个坏主意。

我对这篇文章，第一煎饼和所有事物的任何批评都会感到高兴。