Quando sarebbe utile usare un linguaggio di scripting all'interno di un programma più ampio?

Ho sentito parlare di diverse situazioni di persone che usano say, JavaScript o Python (o qualcosa del genere), all'interno di un programma scritto in C #. Quando usare un linguaggio come JavaScript per fare qualcosa in un programma C # sarebbe meglio che farlo in C #?

Quando hai un comportamento che non vuoi ricompilare il programma per cambiare. Questo è esattamente il motivo per cui molti giochi usano Lua come linguaggio di scripting / modding.

Questa tecnica può essere utilizzata per implementare una logica di base facilmente trasportabile tra diversi ambienti linguistici. Ad esempio, ho un simulatore di calcolatrice in cui tutta la logica interna della calcolatrice è 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.

In senso lato ci sono due situazioni in cui applicare questo modello:

1. Questo è usato internamente per sfruttare un po 'di qualità del linguaggio incorporato.
2. Questo è usato per fornire programmabilità esterna.

Internamente

• In genere viene interpretato il linguaggio incorporato che consente di apportare e testare rapidamente le modifiche senza ricompilare.
• Il linguaggio incorporato può essere più espressivo del linguaggio in cui è scritta l'applicazione principale, consentendo di nuovo uno sviluppo più rapido.
• La lingua potrebbe adattarsi meglio a un determinato dominio rispetto a una lingua di uso generale.
• Il linguaggio viene utilizzato dagli utenti interni che necessitano 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 usato in Adobe Lightroom.

Quindi ciò che facciamo con Lua è essenzialmente tutta la logica dell'applicazione dall'esecuzione dell'interfaccia utente alla gestione di ciò che effettivamente facciamo nel database. Praticamente ogni pezzo di codice nell'app che potrebbe essere descritto come prendere decisioni o implementare funzionalità è in Lua fino a quando non si arriva all'elaborazione grezza, che è in C ++. ( Intervista a Mark Hamburg: Adobe Photoshop Lightroom )

Esternamente

• Consenti agli utenti di estendere il comportamento della tua applicazione senza richiedere strumenti speciali e / o librerie e / o accesso al tuo codice sorgente.
• Fornire a quegli utenti un'API ben definita e un ambiente sandbox. Questo potrebbe essere fatto anche nel linguaggio dell'applicazione, ma l'incorporamento di un interprete può semplificarlo.

IBM ha usato con successo i linguaggi di scripting nel proprio sistema operativo mainframe VM-CMS . EXEC , EXEC / 2 e successivi Rexx sono stati utilizzati in tutto il sistema sia internamente che esternamente. Applicazioni diverse (ad es. XEDIT ) erano utilizzabili tramite script con le stesse lingue e le applicazioni / utilità interne (ad es. E-mail) sono state scritte nel linguaggio di scripting e hanno 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 file batch MS / DOS ). Le shell Unix hanno anche degli script .

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

Esempi del mondo reale includono: -

• La maggior parte dei browser Web che supporterà JavaScript incorporato.

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

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

Molti dispositivi integrati vengono implementati utilizzando un set molto piccolo di funzioni C di base che vengono incollate insieme utilizzando un linguaggio di scripting come Lua. Quindi hai una serie di funzioni C piccole e veloci che interagiscono con l'hardware e, la maggior parte della logica di controllo in un linguaggio di scripting 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 acquisire una gamma quanto più ampia possibile di competenze linguistiche di programmazione, l'host può supportare più linguaggi di scripting. Ad esempio, su JVM, è possibile incorporare un'intera serie di linguaggi conformi a JSR-223 , tra cui Python, Ruby, JavaScript, ecc.

Un altro motivo non già menzionato è che la lingua incorporata ha una o più caratteristiche straordinarie che la lingua host non potrebbe facilmente duplicare. Un esempio di questo potrebbe essere la funzionalità Parse o la creazione senza sforzo di DSL (lingua / dialetto specifici del dominio) che può essere trovata in una lingua come Rebol.

Esiste 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 linguaggio semplice con REPL nelle tue applicazioni, collegarlo a un socket e dargli accesso all'intero sistema.

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

La mia situazione specifica, quando utilizzo un linguaggio di script interpretato in una grande applicazione:

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

Sono necessarie varie funzionalità del dispositivo 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 fatto con macchine a stati finiti.

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

Quindi, invece ci sono stati di "eseguire una funzione no-wait", "eseguire una funzione di blocco", "eseguire una funzione di ramificazione / condizionale / saltare" 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, l'uso di un linguaggio di scripting interpretato interno può ridurre enormemente la complessità dell'esecuzione di compiti abbondanti negli stati di attesa (funzioni di blocco).

Dalla mia esperienza, una volta abbiamo sviluppato una grande applicazione che riscrive il codice sorgente di un "antico" linguaggio per essere compatibile con unicode. L'operazione è stata eseguita in C #. Ho finito per scrivere solo il motore (che crea un modello di dati e fornisce i mezzi per eseguire i passaggi necessari per il processo di riscrittura) in C # - il "codice colla" per eseguire effettivamente le cose è fatto in IronPython.

Il punto più grande per IronPython integrato: supponiamo che tu abbia caricato un modello di big data (tempo di caricamento di circa un'ora). Quindi vuoi raccogliere manualmente le informazioni e cercare le cose. Farlo con uno script Python da una console interattiva è molto meglio che fare clic sul modello di dati con il debugger (inoltre, è riproducibile).

Ci sono un paio di ragioni.

• 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 dello script non potrà mai accedere al disco o da nessuna parte se non lo consente. Il motore javascript di base è solo un calcolatore avanzato.
• Qualità. Hai messo un limite molto spesso al codice di scripting. I livelli di "codice spaghetti" sono molto diversi per Javascript o C # / Java. (Il che ti impedisce di aprire le porte dell'inferno)
• Digitare sicurezza. C # / Java sono un ambiente sicuro, per lo più non lo preferisci in un ambiente di scripting. Espressione come "12" + 3 fornisce "123" in javascript ma C # / Java non verrà nemmeno compilata. Gli autori di script per lo più non fanno nemmeno ciò che è "tipo"
• Dinamico. Qualsiasi oggetto può contenere qualsiasi proprietà / metodo e può cambiare il tipo nel tempo. Ad esempio, potrei fornire un oggetto proxy C # all'ambiente di scripting che espone i nodi XML come proprietà.
• Produttività. Solitamente scrivere script è molto più semplice di C # / Java. Nessuna compilazione o "registrazione plug-in" 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 un collegamento sui plugin che espone le classi interne al mondo. Questa architettura di plug-in richiede la "compatibilità con le versioni precedenti" per le vecchie versioni dell'SDK. Questa architettura ti costringe a creare oggetti di dominio "virtuali" che forniscono un meccanismo interno di applicazione nel contesto del dominio. È più gestibile / flessibile rispetto all'esposizione di un'API.

Quando? Tra il 1948 e il 2008, i linguaggi inizialmente compilati impiegarono molto tempo per compilare e collegare, quindi era normale creare un linguaggio di scripting per consentire la personalizzazione e la configurazione dell'utente. Se osservi la cronologia di AutoLisp, la risposta inizialmente è AutoCAD con un linguaggio di scripting al suo interno, ma questo è stato gradualmente eliminato a favore dell'esposizione di un'interfaccia di script a VBA, quindi .net.

Con CLR, abilitare un programma C # o una chiamata di programma Lua in un sistema esistente non è significativamente diverso 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 scripting all'interno del programma più grande, ma invece esporre il programma più grande alle funzionalità di scripting del runtime.

In ambienti che non offrono la generazione e la compilazione al volo del codice, ed è considerato desiderabile offrire un linguaggio di automazione per scopi generici piuttosto che uno specifico per il dominio, otterrai comunque script 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 è di per sé abbastanza semplice da essere un linguaggio di scripting non è necessario.