Quando utilizzare un linguaggio di scripting all'interno di un programma più ampio può essere utile?

Quando hai un comportamento a cui non vuoi dover ricompilare il programma per cambiare. Questo è esattamente il motivo per cui così tanti giochi usano Lua come linguaggio di scripting / modding.

Questa tecnica può essere utilizzata per implementare la logica di base facilmente trasportabile tra diversi ambienti linguistici. Ad esempio, ho un simulatore di calcolatrice in cui tutta la logica della calcolatrice interna è implementata in JavaScript al 100%. Il codice dell'interfaccia utente è ovviamente diverso per ogni piattaforma:

• Browser Web (JavaScript)
• iOS (Objective-C)
• Windows (C ++ con Qt)
• Mac OS X (C ++ con Qt)
• Java Swing (Java)

Con questa disposizione, rendere le versioni del mio programma per diversi ambienti operativi, e soprattutto mantenerle aggiornate, è molto più semplice.

Molto ampiamente ci sono due situazioni in cui applicheresti questo modello:

1. Questo è usato internamente per sfruttare alcune qualità del linguaggio incorporato.
2. Questo è usato per fornire programmabilità esterna.

Internamente

• In genere viene interpretata la lingua incorporata che consente le modifiche essere fatto e testato rapidamente senza una ricompilazione.
• Il linguaggio incorporato potrebbe essere più espressivo del linguaggio in cui è scritta la tua applicazione principale, consentendo di nuovo uno sviluppo più rapido.
• La lingua potrebbe essere più adatta per alcuni particolari dominio rispetto a una lingua generica.
• La lingua è utilizzata dagli utenti interni che hanno bisogno di un linguaggio / ambiente di programmazione "più semplice". I programmi brevi sono scritti da persone che non sono sviluppatori di software che utilizzano una sintassi / API relativamente semplice.

Un esempio qui sarebbe Lua utilizzato in 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)

Esternamente

• Permetti agli utenti di estendere il comportamento della tua applicazione senza richiedere strumenti e / o librerie speciali e / o l'accesso al tuo codice sorgente.
• Fornisci a quegli utenti un'API ben definita e un ambiente sandbox. Questo potrebbe anche essere fatto nella lingua dell'applicazione, ma incorporare un interprete può renderlo più facile.

IBM ha utilizzato con successo i linguaggi di scripting nel loro sistema operativo mainframe VM-CMS . EXEC , EXEC / 2 e successivamente Rexx sono stati utilizzati in tutto il sistema sia internamente che esternamente. Diverse applicazioni (ad es. XEDIT ) sono state programmabili con lo stesso linguaggio e sono state scritte applicazioni / utilità interne (ad es. E-mail) il linguaggio di scripting e sfruttato la stretta integrazione con il sistema operativo e altri strumenti. I clienti hanno creato e condiviso molti strumenti e applicazioni con script. DEC ha anche fornito DCL . Successivamente Microsoft ha supportato VBscript come linguaggio di scripting nella maggior parte delle loro applicazioni e più recentemente PowerShell (anche MS / DOS batch file). Le shell Unix hanno scripting .

La tendenza attuale sembra esporre le API in qualche modo e lasciare la scelta del linguaggio di scripting agli utenti che possono utilizzare associazioni diverse o altri mezzi per accedere all'API.

Esempi di mondo reale includeranno: -

• La maggior parte dei browser Web che supporteranno JavaScript incorporato.

• Microsoft Office Suite - Excel Word ecc. supportano tutti gli script VBA incorporati.

• Molti router di rete includono API di script, in una varietà di lingue TCL, Perl, Lua.

Molti dispositivi embedded sono implementati usando un set molto piccolo di funzioni core C che sono incollate insieme usando un linguaggio di scripting come Lua. Quindi disponi di una serie di funzioni C piccole e veloci che interagiscono con l'hardware e, gran parte della logica di controllo in un linguaggio di script flessibile e facile da modificare.

A volte lo scripting è incorporato in un'applicazione perché è un mezzo per estendere l'applicazione host da altri sviluppatori. Al fine di catturare il maggior numero possibile di competenze linguistiche di programmazione, l'host potrebbe supportare più linguaggi di scripting. Ad esempio, sulla JVM, puoi incorporare un'intera muta di compatibile con JSR-223 lingue , inclusi Python, Ruby, JavaScript, ecc.

Un altro motivo non ancora menzionato è che il linguaggio incorporato ha una o più caratteristiche standout che la lingua host non è in grado di duplicare facilmente. Un esempio di questo potrebbe essere la funzionalità Parse o la creazione di un DSL (lingua / dialetto specifico del dominio) senza sforzo che può essere trovata in una lingua come Rebol.

C'è un modo interessante di usare un linguaggio di scripting all'interno di un'applicazione che non è stato ancora menzionato dagli altri.

Se la tua lingua host ha un runtime ricco e riflessivo, è spesso utile incorporare un semplice linguaggio con REPL nelle tue applicazioni, collegarlo a un socket e dargli accesso all'intero sistema.

Può essere usato per un debug interattivo (ed è naturalmente molto più potente del tuo solito debugger), patch hot code, vari scopi di monitoraggio, persino backdoor (se non vuoi fare del bene).

La mia situazione specifica, quando uso un linguaggio di scripting interpretato in un'applicazione principale:

C'è un dispositivo esterno che svolge diverse funzioni. Misure, controllo, letture. È abbastanza "stupido" e richiede un controllo preciso, passo dopo passo, inclusi molti stati di attesa e decisioni ad-hoc sul lato del meccanismo di controllo.

Diverse funzionalità del dispositivo sono richieste in vari punti dell'applicazione principale, in momenti diversi, spesso su richiesta. L'app principale non consente gli stati di attesa in quanto tali, tutto deve essere eseguito con macchine a stati finiti.

Ora chiunque abbia scritto una macchina a stati finiti sa che implementare uno stato di attesa è effettivamente almeno due, spesso tre o quattro stati interni della macchina. Implementare venti wait-state per varie funzioni (e attendere le loro risposte e reagire di conseguenza) del dispositivo esterno sarebbe un'esperienza molto, molto frustrante.

Quindi, ci sono stati di "eseguire una funzione no-wait", "eseguire una funzione di blocco", "eseguire una funzione branching / condizionale / jump" nella macchina a stati finiti, forse sei stati in totale. E ci sono script di controllo che vengono programmati per l'esecuzione, quindi eseguiti dall'interprete che controlla il dispositivo esterno, e i loro risultati posizionati dove sono richiesti.

Riassumendo, l'applicazione: in un RTOS, utilizzando un linguaggio di scripting interpretato internamente può ridurre enormemente la complessità delle attività di esecuzione abbondanti negli stati di attesa (funzioni di blocco).

Dalla mia esperienza, una volta abbiamo sviluppato una grande applicazione che riscrive il codice sorgente di una langue "antica" compatibile con Unicode. Il gioco è stato fatto in C #. Ho finito per scrivere solo il motore (che crea un modello di dati e fornisce i mezzi per fare i passi necessari per il processo di riscrittura) in C # - il "codice colla" per l'esecuzione effettiva delle cose è fatto in IronPython.

Il più grande punto per l'IronPython integrato: supponiamo che tu abbia caricato un modello Big Data (circa un'ora di caricamento). Quindi si desidera, a livello manuale, raccogliere informazioni e cercare le cose. Fare questo con uno script Python da una console interattiva è molto meglio che fare clic sul modello di dati con il debugger (inoltre, è rigiocabile).

Ci sono dei buoni motivi.

• Curva di apprendimento. Praticamente tutti possono imparare e scrivere in javascript.
• Sicurezza. È difficile controllare il contesto di sicurezza del codice di script in C # o Java. Javascript è perfetto per questo. L'autore di script non è mai in grado di accedere al disco o ovunque se non lo consente. Il motore javascript principale è solo una calcolatrice avanzata.
• Qualità. Hai posto un limite molto spinto al codice di scripting. I livelli di "Spaghetti code" sono molto diversi per Javascript o C # / Java. (Che ti impedisce di aprire le porte dell'inferno)
• Tipo di sicurezza. C # / Java sono di tipo sicuro, per lo più non lo preferiscono in un ambiente di scripting. Espressione come "12" + 3 restituisce "123" in javascript, ma C # / Java non viene nemmeno compilato. Gli scrittori di script in genere non hanno nemmeno il "tipo"
• Dinamico. Qualsiasi oggetto può contenere qualsiasi proprietà / metodo e può cambiare tipo nel tempo. Ad esempio, potrei fornire un oggetto C # proxy all'ambiente di scripting che espone i nodi XML come proprietà.
• Produttività. Di solito scrivere script è molto più facile di C # / Java. Nessuna compilazione o "registrazione del plugin" richiesta. È possibile modificare direttamente il contenuto dello script all'interno dell'applicazione con risultati immediati.
• Gestione. L'uso di C # / Java richiede che un SDK sia collegato a plug-in che espone le classi interne al mondo. Questa architettura di plugin richiede la "retrocompatibilità" per le vecchie versioni di SDK. Questa architettura ti obbliga a creare oggetti di dominio "virtuali" che forniscono meccanismi di applicazione interni nel contesto del dominio. È più gestibile / flessibile dell'esposizione a un'API.

Quando? Tra il 1948 e il 2008, le lingue compilate inizialmente richiedevano molto tempo per la compilazione e il collegamento, quindi era normale creare un linguaggio di scripting per consentire la personalizzazione e la configurazione degli utenti. Se si osserva la cronologia di AutoLisp, la risposta è inizialmente fornita da AutoCAD con un linguaggio di scripting al suo interno, ma questa è stata eliminata a favore dell'esposizione di un'interfaccia di script a VBA quindi .net.

Con CLR, l'abilitazione di un programma C # o di un programma Lua in un sistema esistente non è significativamente diversa nei costi di sviluppo e il runtime .net viene fornito con gli strumenti per generare e compilare al volo.

Non è più necessario avere un linguaggio di script all'interno del programma più grande, ma esporre invece il programma più grande alle funzionalità di scripting del runtime.

Negli ambienti che non offrono la generazione e la compilazione in modalità "fly-code" e si ritiene desiderabile offrire un linguaggio di automazione generico piuttosto che uno specifico per il dominio, si otterrà comunque lo scripting Lua o Python. Per gli strumenti che offrono un'interfaccia COM, il linguaggio di scripting sarà C # o VB.net (MS Office, Sparx Enterprise Architect). Quindi avere un linguaggio di scripting per un programma scritto in una lingua che è abbastanza semplice per essere un linguaggio di scripting è inutile.