Python vs Lua per motore di scripting incorporato/elaborazione testo

Question

Per un progetto a cui sto lavorando attualmente, sto cercando di incorporare un motore di scripting nel mio codice C++ per consentire una certa estensibilità a valle. L'applicazione richiederà una buona quantità di elaborazione del testo e l'uso di espressioni regolari all'interno di questi script.

So che Lua è generalmente l'industria cara quando si tratta di script incorporati, ma so anche che non supporta le espressioni regolari (almeno out-of-the-box). Questo mi porta ad inclinarmi a Python perché il mio linguaggio si integri, in quanto sembra avere il miglior supporto dietro Lua e offre ancora potenti capacità regex.

Questa è la scelta giusta? Dovrei guardare un'altra lingua? C'è una ragione per dare una seconda occhiata a Lua?

Answer 1

se è necessario in particolare quello che è comunemente noto come 'espressioni regolari' (che non sono regolari a tutti), allora si hanno due scelte:

1. andare con Python. è incluso regexp è abbastanza simile a Perl e sed/grep
2. uso Lua ed una esterna PCRE library

se, d'altra parte, è necessario ogni buon pattern matching, si può stare con Lua e:

1. usa la corrispondenza di modelli inclusa di Lua, che non sono nella tradizione grep ma sono abbastanza capaci. La funzionalità mancante è subpattern alternative (|)
2. utilizzare LPEG, che sono lontano più potente di espressioni regolari, e in genere anche più veloce.

Come potete vedere, sono un grande fan dell'ultimo. Non solo consente di definire schemi molto complessi ma deterministici, è uno strumento grammaticale completo che è possibile utilizzare per creare un parser completo. Se lo desideri, la grammatica può essere descritta in un'unica costante di stringa su più righe, con i tuoi ganci definiti per acquisire dati e costruire le tue strutture.

ho usato per incidere rapidamente un parser JSON, un C call-albero, una libreria xPath, ecc

Answer 2

non dimenticare il grand-papà di tutti loro - tcl

c'è un ++ wrapper di c per Tcl che lo rende incredibilmente facile da incorporare

sto utilizzando in un progetto in corso

in precedente (C#) progetto ho usato lua su python. Nei vecchi progetti C# avevo usato python; Ho scelto lua perché la sintassi è più normale per lo scripter medio (utilizzato per vbscript o javascript). Comunque tornerò a (iron) python per il prossimo progetto C#; lua è troppo oscura

per il C++ sarò sempre usare TCL da ora in poi

EDIT: Il mio nuovo preferito è jint (.net javascriptt interprete) v facile da usare, bella interfaccia. E nessuno può lamentarsi la lingua dato che JS è la lingua fredda nel momento

Answer 3

Python e C++ integrazione è fortemente aiutato con boost.python.Potresti trovarlo molto più comodo se chi ha familiarità con il tuo sorgente C++ sono principalmente quelli che scrivono script.

Anche se gli scripters non hanno familiarità con la tua sorgente particolare, se hanno più familiarità con la sintassi di tipo C (C, C++, ecc.), Dovrebbero trovare Python più facile da usare, forse solo leggermente, Lua isn difficile. I buoni programmatori possono comunque utilizzare una moltitudine di lingue, ma non hai fornito alcuna informazione sul tuo pubblico.

Lua è molto più facile da sandbox di Python, quindi se è necessario limitare ciò che gli script può fare (ad esempio processi aggiuntivi di spawn, leggere i file), che potrebbero escludere Python.

Answer 4

Avendo incorporato Lua in uno dei miei progetti C, suggerirò Lua, poiché è più semplice.

Ma questo dipende da ciò di cui il linguaggio di scripting deve essere capace. Lua è passata al linguaggio di programmazione de-facto dei giochi. Se hai bisogno di funzionalità di scripting avanzate, potresti usare Python, ma se è solo per un facile supporto per lo scripting, prendi Lua. Da quello che ho visto, Lua è più facile da imparare per i newbees, che non sono abituati allo scripting.

Direi che Lua è più leggero, se è necessario disporre di pacchetti esterni, è possibile aggiungerli, ma il punto è che la parte atomica di Lua è molto più piccola di quella di Python.