Quando o uso de uma linguagem de script em um programa maior seria útil?

Já ouvi falar de várias situações de pessoas usando, digamos, JavaScript ou Python (ou algo assim), dentro de um programa escrito em C #. Quando seria melhor usar uma linguagem como JavaScript para fazer algo em um programa C #, em vez de fazê-lo em C #?

Quando você tem um comportamento que não deseja recompilar o programa para mudar. É exatamente por isso que muitos jogos usam Lua como uma linguagem de script / modificação.

Essa técnica pode ser usada para implementar a lógica principal, facilmente transportável entre diferentes ambientes de linguagem. Por exemplo, eu tenho um simulador de calculadora em que toda a lógica interna da calculadora é implementada em 100% JavaScript. O código da interface do usuário é obviamente diferente para cada plataforma:

• Navegador da Web (JavaScript)
• iOS (Objective-C)
• Windows (C ++ com Qt)
• Mac OS X (C ++ com Qt)
• Java Swing (Java)

Com esse arranjo, tornar as versões do meu programa para diferentes ambientes operacionais e, especialmente, mantê-las atualizadas, é muito mais simples.

Em termos gerais, existem duas situações em que você aplicaria esse padrão:

1. Isso é usado internamente para alavancar alguma qualidade da linguagem incorporada.
2. Isso é usado para fornecer programabilidade externa.

Internamente

• Normalmente, a linguagem incorporada é interpretada, o que permite que as alterações sejam feitas e testadas rapidamente sem uma recompilação.
• O idioma incorporado pode ser mais expressivo do que o idioma em que seu aplicativo principal está escrito, permitindo novamente um desenvolvimento mais rápido.
• O idioma pode ser mais adequado para um domínio específico em comparação com um idioma de uso geral.
• A linguagem é usada por usuários internos que precisam de uma linguagem / ambiente de programação "mais simples". Programas curtos são escritos por pessoas que não são desenvolvedores de software usando uma sintaxe / API relativamente simples.

Um exemplo aqui seria Lua usada no Adobe Lightroom.

Portanto, o que fazemos com Lua é essencialmente toda a lógica do aplicativo, desde a execução da interface do usuário até o gerenciamento do que realmente fazemos no banco de dados. Praticamente todos os trechos de código no aplicativo que podem ser descritos como tomar decisões ou implementar recursos estão em Lua até você chegar ao processamento bruto, que está em C ++. ( Entrevista com Mark Hamburg: Adobe Photoshop Lightroom )

Externamente

• Permita que os usuários estendam o comportamento do seu aplicativo sem exigir ferramentas e / ou bibliotecas especiais e / ou acesso ao seu código-fonte.
• Forneça a esses usuários uma API bem definida e um ambiente em área restrita. Isso também pode ser feito no idioma do aplicativo, mas a incorporação de um intérprete pode facilitar isso.

A IBM usou linguagens de script com muito êxito em seu sistema operacional de mainframe VM-CMS . EXEC , EXEC / 2 e Rexx posterior foram utilizados em todo o sistema, interna e externamente. Diferentes aplicativos (por exemplo, XEDIT ) eram passíveis de script usando os mesmos idiomas e aplicativos / utilitários internos (por exemplo, email) foram escritos na linguagem de script e alavancaram a forte integração com o sistema operacional e outras ferramentas. Os clientes criaram e compartilharam muitas ferramentas e aplicativos com script. DEC também forneceu DCL . Mais tarde, a Microsoft deu suporte ao VBscript como uma linguagem de script na maioria de seus aplicativos e, mais recentemente, no PowerShell(também arquivos em lote do MS / DOS ). Os shells Unix também têm scripts .

Hoje, a tendência parece expor as APIs de alguma forma e deixar a escolha da linguagem de script para os usuários que podem utilizar diferentes ligações ou outros meios de acessar a API.

Exemplos do mundo real incluem:

• A maioria dos navegadores da Web que suportam JavaScript incorporado.

• O Microsoft Office Suite - Excel Word etc. oferece suporte a scripts VBA incorporados.

• Muitos roteadores de rede incluem APIs de script, em uma variedade de idiomas, TCL, Perl, Lua.

Muitos dispositivos incorporados são implementados usando um conjunto muito pequeno de funções C centrais, que são coladas usando uma linguagem de script como Lua. Portanto, você tem um conjunto de funções C pequenas e rápidas que interagem com o hardware e, a maioria da lógica de controle em um idioma de script flexível e fácil de alterar.

Às vezes, o script é incorporado a um aplicativo porque é um meio de estender o aplicativo host por outros desenvolvedores. Para capturar o maior número possível de habilidades da linguagem de programação, várias linguagens de script podem ser suportadas pelo host. Por exemplo, na JVM, você pode incorporar várias linguagens compatíveis com JSR-223 , incluindo Python, Ruby, JavaScript, etc.

Outro motivo ainda não mencionado é que o idioma incorporado possui um ou mais recursos de destaque que o idioma do host não pôde duplicar facilmente. Um exemplo disso seria a funcionalidade Parse ou a criação sem esforço de DSL (idioma / dialeto específico do domínio), que pode ser encontrada em um idioma como o Rebol.

Há uma maneira interessante de usar uma linguagem de script em um aplicativo que ainda não foi mencionada pelos outros.

Se o idioma do seu host tiver um tempo de execução rico e reflexivo, geralmente é útil incorporar um idioma simples ao REPL em seus aplicativos, conectá-lo a um soquete e dar acesso a todo o sistema.

Ele pode ser usado para uma depuração interativa (e é naturalmente muito mais poderosa que o depurador de costume), patch de código quente, vários propósitos de monitoramento e até backdoors (se você não estiver bom).

Minha situação específica, quando eu uso uma linguagem de script interpretada em um aplicativo principal:

Existe um dispositivo externo que executa várias funções. Medições, controle, leituras. É bastante "burro" e requer controle preciso, passo a passo, incluindo muitos estados de espera e tomada de decisões ad-hoc no lado do mecanismo de controle.

Várias funcionalidades do dispositivo são necessárias em vários pontos da aplicação principal, em momentos diferentes, geralmente sob demanda. O aplicativo principal não permite estados de espera, como tal, tudo deve ser feito com máquinas de estados finitos.

Agora, quem escreveu uma máquina de estados finitos sabe que implementar um estado de espera é efetivamente pelo menos dois, geralmente três ou quatro estados internos da máquina. Implementar vinte estados de espera para várias funções (e aguardar suas respostas e reagir de acordo) do dispositivo externo seria uma experiência muito, muito frustrante.

Portanto, em vez disso, existem estados de "executar uma função sem espera", "executar uma função de bloqueio", "executar uma função de ramificação / condicional / salto" na máquina de estados finitos, talvez seis estados no total. E existem scripts de controle que são agendados para execução e, em seguida, executados pelo intérprete que controla o dispositivo externo e seus resultados são colocados onde são necessários.

Resumindo, o aplicativo: em um RTOS, o uso de uma linguagem de script interpretada interna pode reduzir enormemente a complexidade de executar tarefas abundantes em estados de espera (funções de bloqueio).

Pela minha experiência, uma vez desenvolvemos um grande aplicativo que reescreve o código-fonte de um idioma "antigo" para ser compatível com unicode. O foi feito em c #. Acabei escrevendo apenas o mecanismo (que cria um modelo de dados e fornece meios para executar as etapas necessárias para o processo de reescrita) em C # - o "código de cola" para realmente executar as coisas é feito no IronPython.

O ponto mais importante do IronPython integrado: Vamos supor que você carregou um modelo de big data (aproximadamente uma hora de carregamento). Então você deseja coletar manualmente informações e procurar coisas. Fazer isso com um script Python a partir de um console interativo é muito melhor do que clicar no modelo de dados com o depurador (além disso, é reproduzível).

Existem algumas razões.

• Curva de aprendizado. Praticamente todos podem aprender e escrever em javascript.
• Segurança. É difícil controlar o contexto de segurança do código de script em C # ou Java. Javascript é perfeito para isso. O autor do script nunca poderá acessar o disco ou qualquer lugar se não permitir. O mecanismo JavaScript principal é apenas uma calculadora avançada.
• Qualidade. Você coloca um limite muito grosso ao código de script. Os níveis de "código espaguete" são muito diferentes para Javascript ou C # / Java. (O que impede você de abrir os portões do inferno)
• Digite segurança. C # / Java é um ambiente com segurança de tipo, você geralmente não o prefere em um ambiente de script. Expressões como "12" + 3 fornecem "123" em javascript, mas C # / Java nem compila. Os escritores de scripts geralmente nem mesmo são o "tipo"
• Dinâmico. Qualquer objeto pode conter qualquer propriedade / método e pode alterar seu tipo no tempo. Por exemplo, eu poderia fornecer um objeto C # proxy para o ambiente de script que expõe nós XML como propriedades.
• Produtividade. Geralmente, escrever scripts é muito mais fácil que C # / Java. Nenhuma compilação ou "registro de plug-in" é necessário. Você pode editar diretamente o conteúdo do script no aplicativo com resultados imediatos.
• Gerenciando. O uso de C # / Java requer que um SDK seja vinculado a plug-ins que expõem as classes internas ao mundo. Essa arquitetura de plug-in requer a "compatibilidade com versões anteriores" das versões antigas do SDK. Essa arquitetura obriga a criar objetos de domínio "virtuais" que fornecem mecanismo interno de aplicativo no contexto do domínio. É mais gerenciável / flexível do que expor uma API.

Quando? Entre 1948 e 2008 - as linguagens inicialmente compiladas levaram um tempo significativo para compilar e vincular, por isso era comum criar uma linguagem de script para permitir a personalização e configuração do usuário. Se você observar o histórico do AutoLisp, a resposta será inicialmente fornecida pelo AutoCAD com uma linguagem de script, mas isso foi eliminado em favor da exposição de uma interface programável ao VBA e ao .net.

Com o CLR, ativar um programa C # ou uma chamada de programa Lua em um sistema existente não é significativamente diferente no custo de desenvolvimento, e o tempo de execução .net é fornecido com as ferramentas para gerar e compilar em tempo real.

Você não precisa mais ter uma linguagem de script no programa maior, mas expor o programa maior aos recursos de script do tempo de execução.

Em ambientes que não oferecem geração e compilação de códigos dinamicamente, e é considerado desejável oferecer uma linguagem de automação de uso geral, em vez de uma específica de domínio, você ainda obterá scripts Lua ou Python. Para ferramentas que oferecem uma interface COM, essa linguagem de script será C # ou VB.net (MS Office, Sparx Enterprise Architect). Portanto, é desnecessário ter uma linguagem de script para um programa escrito em uma linguagem que seja suficientemente simples para ser uma linguagem de script.