Quando você deseja dar ao usuário a capacidade de escrever plug-ins para seu aplicativo, você tem a opção de fornecer a API. Abaixo, mostrarei por que a pior solução para isso seria inventar sua própria linguagem de programação e analisar os códigos-fonte, bem como os móveis aqui.

PL não é a principal função do aplicativo

Imagine que abrimos a produção de móveis modulares. Existem alguns elementos básicos: bancadas, bases para copos, mesas de cabeceira, etc. Existe uma linha de produção associada ao processamento de madeira: máquinas-ferramentas, serras, vernizes, todos com a mais recente tecnologia. Mas tudo isso deve ser realizado de alguma maneira. Sabemos que existem 100.500 empresas especializadas na fabricação de ferragens e parafusos, existem alguns padrões para fixadores de móveis que foram inventados por uma comunidade de profissionais para facilitar a vida de seus clientes. Qual será a decisão míope de implantar uma linha adicional para a produção de parafusos, porcas e ângulos próprios?

O que podemos ganhar?

• Dessa forma, podemos marcar nosso produto para que o hamster sinta sua "originalidade" e carregue mais dinheiro.
• Talvez isso nos permita não pagar direitos autorais por nenhum dos parafusos ou resolver o problema de logística.
• Podemos entrar em um novo mercado de parafusos e porcas, estabelecendo nosso próprio padrão, que é mais rápido, melhor e mais alto.

Mas vamos ficar limpos.

• Ilitismo é o trabalho dos vendedores. O vendedor tornará a marca ou não uma Elite com ou sem uma nova linha de produção.
• Os direitos autorais, em regra (nem sempre, é claro), são mais baratos que o desenvolvimento do zero. E resolvendo o problema de fornecer um elemento implantando uma nova linha de produção, você apenas o exacerba.
• Se queremos experimentar um novo campo de atividade, não precisamos conectá-lo ao que já somos profissionais. Pode parecer que é mais fácil empurrar os parafusos com os móveis, mas se eles não voarem, eles arrastarão os móveis junto com eles. Pelo menos o que já custa para os clientes.

Voltando às nossas ovelhas: se você estiver criando um ecossistema para as extensões de seu aplicativo, você terá um aplicativo . Faz algo de bom, algo em que você é bom.

KSP - Kontakt Script Processor, ou linha de produção de parafusos no mundo do áudio digital

Vou contar uma história sobre esse idioma:

Kontakt é um romper (sampler) da empresa austríaca Native Instruments . Atualmente, é muito difícil encontrar um projeto usando ferramentas virtuais nas quais ele não é usado. Nos últimos 10 anos, a Kontakt ocupou a maior parte do mercado de instrumentos amostrados. O segredo é simples: ao mesmo tempo, Kontakt propôs duas inovações que mudaram o caminho do desenvolvimento de instrumentos virtuais de amostra.

A primeira inovação estava diretamente relacionada à sua principal função: tratava a memória com muito cuidado (e as amostras em wav são as mesmas, tanto HDD quanto RAM). A NI criou um formato de compactação sem perdas com decodificação rápida e criou um revolucionário sistema de buffer de áudio para a época.

A segunda inovação foi KSP

Antes do contato, havia duas maneiras de organizar funcionalmente as amostras gravadas em um instrumento controlado por MIDI:

• Escreva seu próprio mecanismo do zero em C ++ ou em outro idioma que possa usar o VST SDK da Steinberg (e existem outros formatos de plug-in, por exemplo, AAX).
• Use um amostrador pronto feito para músicos que não estão familiarizados com a programação, mas que possuem sons que precisam ser organizados em algum tipo de sistema. Digamos Giga Studio . Mas, como regra geral, esses romperms eram fechados ou, para finalizar seu trabalho, eram necessários menos funcionários do que o desenvolvimento vazio no SDK do VST.

O contato agradou tanto a isto como a isso: para prototipagem rápida, existe uma GUI conveniente que é compreensível para qualquer músico que leu o manual, e para aperfeiçoamento adicional, não há menos uma linguagem de programação , com condições, funções (da versão 4) e uma biblioteca padrão representando a API à maioria das funcionalidades implementadas por meio da GUI, bem como aos parâmetros para reproduzir amostras diretamente. Entre outras coisas, a partir da versão 2, tornou-se possível personalizar a interface com todos os tipos de assobios e falsificações, o que permitiu mostrar sua singularidade em uma escala quase ilimitada. E o código do desenvolvedor está oculto duas vezes: ofuscação e proteção contra a troca de ferramentas .

Dada a crescente popularidade do motor, bem como um impressionante período de desenvolvimento ativo do macacão, hoje o Kontakt é uma espécie de rifle de assalto Kalashnikov no mundo do áudio digital. É fácil de aprender, confiável como um tanque, tem a capacidade de dopilka dentro de limites razoáveis ​​para si mesmo amado e possui um mercado enorme para usuários satisfeitos.

Nem tudo é tão róseo

O inevitável aconteceu: a inovação na forma de KSP se tornou um flagelo. Tentando tornar a sintaxe acessível aos manequins, que são músicos, em vez de resolver a implementação da API na linguagem humana, os Nativs escreveram seu próprio intérprete de sua própria linguagem, cuja arquitetura não pressupunha inicialmente um vôo de imaginação tão tempestuoso dos desenvolvedores de ferramentas, que estamos testemunhando agora. Já na versão 3, os nativos perderam a esperança de acompanhar o apetite dos usuários e simplesmente começaram a rebitar as novas funções da biblioteca padrão, permitindo que eles descobrissem o ambiente de desenvolvimento de código por conta própria.

Além disso, mesmo então, o Nils Lieberg KScriptEditor apareceu , bifurcado com o Scintilla , que há muito tempo atua como o principal IDE do KSP. É ridículo dizer, mas quando os nativos perceberam que o contato não podia lidar com o tamanho da fonte alimentada, eles introduziram funções na linguagem sem precisar se preocupar em passar argumentos para eles. E um mês depois, um taskfunc apareceu no taskfunc , passando argumentos para funções que não levam argumentos.

Depois de um tempo, Niels percebeu que estava pisando no caminho dos nativos: não fazia sentido desenvolver um próprio IDE. Ele portou o compilador e implementou a funcionalidade IDE para SublimeText2, e acenou. No momento, as rédeas do SublimeKSP são suportadas pelo desenvolvedor, ao que parece, da Fluffy Audio .

Bem, você entende)

E, novamente, já um gerador de código, que não é menos que uma linguagem, com um sistema de importações, um analisador, um compilador, sintaxe diferente do KSP, mas ainda suportando compatibilidade com ele, por razões desconhecidas pela ciência, acaba sendo uma montanha terrível de muletas que não podem ser jogadas fora devido à compatibilidade com versões anteriores de projetos de desenvolvedores de bibliotecas que desenvolvem seus mecanismos KSP há anos.

Suponha que o sistema de importação funcione globalmente com relação ao arquivo a partir do qual a compilação é iniciada; portanto, para compilar um módulo localizado em uma subpasta, é necessário alterar completamente seus caminhos nas importações, de acordo com sua posição na estrutura do projeto. E o cara que o apoia ficaria feliz em mudar isso, mas depois ele interromperá os projetos do mesmo Spitfire Audio por um longo tempo. E esse fato por si só complica o teste modular (não vamos dizer nada sobre a unidade) para o inferno.

Parece que a solução para o problema é usar links simbólicos, mas em algum lugar em algum lugar não funciona conforme o esperado e os links simbólicos funcionam apenas parcialmente. Esse tipo de problema não é uma coisa. Entre outras coisas, depois de Niels, o desenvolvimento não foi realizado modificando o próprio compilador, que recebe o código já analisado. E, novamente, por razões de compatibilidade com versões anteriores, adicionando plug-ins de sintaxe estendida, cada um dos quais recebe as fontes originalmente cortadas em linhas, as analisa por conta própria e faz modificações.

Dado que a maior parte da lógica do pré-processador se baseia em macros e funções inline, que implantam o código em uma tela enorme que armazena 80% das condições sempre verdadeiras ou sempre falsas (substituindo as constantes pela entrada da condição), que são minimizadas no estágio Ao analisar o AST, o tempo de compilação da fonte "correta" é comparável ao dos projetos With, em linguagem interpretada para manequins.

Dizer que o KSP se tornou uma dor para os desenvolvedores é não dizer nada.

Nem um único contato.

Não posso dar exemplos de outras áreas, mas aqui do escopo do DigitalAudio:

• O Lemur é um aplicativo de escavadeira com um editor de área de trabalho que permite criar rapidamente interfaces bonitas para comunicar pás usando o protocolo OSC . Ele possui seu próprio PL, que pode ser usado em objetos de script especiais espalhados pela árvore do projeto. Não há como criar um compilador como o que foi feito para o KSP.
• Reaper - DAW com um ecossistema desenvolvido para o desenvolvimento de extensões. Como resultado, sempre que possível, dupliquei meu código de linguagem JSFX (ReaScript) como uma API para C ++, lua e Python.
• O HISE é um jovem escritor e construtor de VST \ VSTi que matará o Kontakt do desenvolvedor sueco Christoph Haart mais cedo ou mais tarde. Dentro do próprio editor, ele permite escrever em JavaScript modificado, que é analisado e compilado no binário por objetos C ++. A idéia com seu próprio analisador para introduzir entidades adicionais (por exemplo, registrar variáveis, se traduzi corretamente) funcionou até que os usuários transferissem seu código do editor HISE para seus IDEs favoritos com destaque de sintaxe, análise estática e ferramentas de formatação JsPrettier . Agora, Christophe esboçou alguns arquivos de cabeçalho para compilar bibliotecas estáticas em C ++, que podem ser usadas como módulos no editor. Paralelamente, ele continua a complementar o HISEScript (porque o JavaScript não pode mais ser chamado de) com novas funções, mas sabemos que ...

Conclusão

Escreva seu próprio aplicativo, dedicando-se à sua principal funcionalidade, não perca tempo com analisador, semântica e sintaxe. Isso é interessante enquanto você inicia, mas com uma alta probabilidade levará a um beco sem saída. A linguagem de programação não pode fazer parte do aplicativo: é um tipo de linha de produção separada que requer muito tempo para manter, modificar e dar suporte à comunidade. Por sua vez, se você deseja diminuir o limiar para manequins, largue-o. Um bule de chá real, por via de regra, tem medo de imprimir qualquer coisa e não se incomoda com sua sintaxe simples.

Ao mesmo tempo, para desenvolvedores iniciantes de plug-ins para o seu programa, você pode simplesmente criar um pequeno Guia Rápido , apresentando-os aos conceitos básicos do seu PL escolhido para expandir a funcionalidade e alimentar lentamente sua API, que faz parte do ecossistema desse idioma.

PS Não, escrever seu próprio analisador para um PL pronto também é uma má idéia.

Ficarei feliz com qualquer crítica ao artigo, à primeira panqueca e a todas as coisas.