Quando você tem um comportamento que não deseja recompilar o programa para alterar. É exatamente por isso que tantos jogos usam Lua como uma linguagem de script / modding.
Já ouvi falar de várias situações de pessoas usando o say, JavaScript ou Python (ou algo assim) dentro de um programa escrito em C #. Quando seria usar uma linguagem como o JavaScript para fazer algo em um programa c # ser melhor então apenas fazê-lo em c #?
Quando você tem um comportamento que não deseja recompilar o programa para alterar. É exatamente por isso que tantos jogos usam Lua como uma linguagem de script / modding.
Essa técnica pode ser usada para implementar a lógica central que é facilmente transportável entre diferentes ambientes de linguagem. Por exemplo, eu tenho um simulador de calculadora onde toda a lógica interna da calculadora é implementada em 100% JavaScript. O código da interface do usuário é diferente para cada plataforma:
Com esse arranjo, fazer versões do meu programa para diferentes ambientes operacionais e, especialmente, mantê-los atualizados, é muito mais simples.
Em geral, há duas situações em que você aplicaria esse padrão:
Internamente
Um exemplo aqui seria Lua usado no Adobe Lightroom.
So what we do with Lua is essentially all of the application logic from running the UI to managing what we actually do in the database. Pretty much every piece of code in the app that could be described as making decisions or implementing features is in Lua until you get down to the raw processing, which is in C++. (Mark Hamburg Interview: Adobe Photoshop Lightroom)
Externamente
A IBM usou linguagens de script com muito sucesso em seu sistema operacional de mainframe VM-CMS . EXEC , EXEC / 2 e mais tarde Rexx foram utilizados em todo o sistema, tanto interna como externamente. Aplicativos diferentes (por exemplo, XEDIT ) eram programáveis usando essas mesmas linguagens e aplicativos / utilitários internos (por exemplo, e-mail) foram escritos em a linguagem de script e aproveitou a integração com o sistema operacional e outras ferramentas. Os clientes criaram e compartilharam muitas ferramentas e aplicativos com script. O DEC também forneceu DCL . Mais tarde, a Microsoft suportou o VBscript como uma linguagem de script na maioria de seus aplicativos e, mais recentemente, PowerShell (também arquivos MS / DOS batch ). Unix shells tem scripts também.
A tendência hoje parece estar expondo 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 suportará o JavaScript incorporado.
Microsoft Office Suite - o Excel Word etc. suporta scripts VBA incorporados.
Muitos roteadores de rede incluem APIs de script, em uma variedade de linguagens TCL, Perl, Lua.
Muitos dispositivos incorporados são implementados usando um conjunto muito pequeno de funções centrais do C que são coladas juntas usando uma linguagem de script como a Lua. Portanto, você tem um conjunto de funções C pequenas e rápidas que interagem com o hardware e a maior parte da lógica de controle em um idioma de script flexível e fácil de alterar.
Às vezes, o script é incorporado em um aplicativo porque é um meio de estender o aplicativo host por outros desenvolvedores. Para capturar o maior número possível de habilidades em linguagens de programação, várias linguagens de script podem ser suportadas pelo host. Por exemplo, na JVM, você pode incorporar uma enorme quantidade de compatível com JSR-223 idiomas , incluindo Python, Ruby, JavaScript, etc.
Outro motivo ainda não mencionado é que o idioma incorporado possui um ou mais recursos de destaque que a linguagem do host não pôde duplicar facilmente. Um exemplo disso seria a funcionalidade Parse ou DSL sem esforço (linguagem específica de domínio / dialeto) que pode ser encontrada em uma linguagem como a Rebol.
Existe uma maneira interessante de usar uma linguagem de script dentro de uma aplicação que ainda não foi mencionada pelos outros.
Se sua linguagem de host tiver um tempo de execução rico e reflexivo, geralmente é útil incorporar um idioma simples com REPL em seus aplicativos, conectá-lo em um soquete e conceder acesso a todo o sistema.
Ele pode ser usado para uma depuração interativa (e é naturalmente muito mais poderoso do que o seu depurador usual), correção de código quente, vários propósitos de monitoramento, até mesmo backdoors (se você não for bom).
Minha situação específica, quando uso uma linguagem de script interpretada em um aplicativo importante:
Existe um dispositivo externo que executa várias funções. Medições, controle, leituras. É muito "burro" em si e requer um controle preciso, passo a passo, incluindo muitos estados de espera e tomadas de decisão 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, tudo deve ser feito com máquinas de estados finitas.
Agora, quem quer que tenha escrito 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 adequadamente) do dispositivo externo seria uma experiência muito, muito frustrante.
Portanto, existem estados de "executar uma função no-wait", "executar uma função de bloqueio", "executar uma ramificação / condicional / saltar" na máquina de estados finitos, talvez seis estados no total. E há scripts de controle que são agendados para execução, depois executados pelo interpretador que controla o dispositivo externo e seus resultados colocados onde são necessários.
Resumindo, o aplicativo: em um RTOS, usando uma linguagem interna de script interpretada pode reduzir enormemente a complexidade de executar tarefas abundantes em estados de espera (funções de bloqueio).
Da minha experiência, desenvolvemos uma grande aplicação que reescreve o código fonte de uma langue "antiga" 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 reconfiguração) em C # - o "código de cola" para a execução real das tarefas é feito no IronPython.
O maior ponto para o IronPython integrado: suponhamos que você tenha carregado um modelo de big data (cerca de uma hora de carregamento). Então você quer coletar informações e procurar as coisas. Fazer isso com um script Python de um console interativo é muito melhor do que clicar no modelo de dados com o depurador (além disso, é possível reproduzi-lo).
Existem algumas razões.
Quando? Entre 1948 e 2008 - as linguagens compiladas inicialmente levavam um tempo significativo para compilar e vincular, por isso era comum criar uma linguagem de script para permitir a personalização e a configuração do usuário. Se você observar a história do AutoLisp, a resposta é inicialmente que o AutoCAD foi enviado com uma linguagem de script, mas isso foi extinto em favor da exposição de uma interface de script para o VBA e depois para o .net.
Com o CLR, a ativação de um programa C # ou de uma chamada de programa Lua para 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 dinamicamente.
Você não precisa mais ter uma linguagem de script dentro do 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ódigo em tempo real, e é visto como desejável para oferecer uma linguagem de automação de propósito geral em vez de uma linguagem 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, ter uma linguagem de script para um programa escrito em uma linguagem que seja simples o suficiente para ser uma linguagem de script é desnecessária.
Tags scripting