[Vari]Scripting: se lo conosci lo eviti?

[Tommo]

Salve,
*premetto che nel post critico l'interazione fra linguaggio di scripting e linguaggio di base, e non i linguaggi stessi... lo dico perchè ci capita in mezzo Python e non vorrei scatenare un disastro*

Lo scripting sarebbe la pratica di delegare parte delle funzionalità di un programma scritto a basso livello (ma non sempre) a codice ad alto livello, nella maggior parte dei casi completamente interpretato.
Ora, di questi tempi specie nei videogame sembra andare del tutto per la maggiore, e non si conta chi usa Lua, Python, Squirrel, Ruby o addirittura un linguaggio proprietario, a cui si delegano semplici eventi, alcune cutscenes, o addirittura l'intero gameplay (crysis, CivIV)...
tanto che, passando per questi forum, mi convinsi ad integrare Lua nel progetto del mio gioco...

la domanda semplice, che tutti i "software architect" concreti dovrebbero porsi è: ma ne vale la pena?
A distanza di quasi un anno, la mia risposta tende decisamente verso il NO, avendo fallito nell'obiettivo principale: rendere lo sviluppo più rapido e semplice.

Credo che la maggior parte della gente che si trova a valutare la tecnologia dello scripting si trovi abbagliata da tante features superficiali che venendo da linguaggi arcigni come C++ fanno sembrare tutto un eden felice: typing dinamico, garbage collectors, tables, funzioni anonime, ricompilazione in tempo reale, moddabilità per chiunque abbia un editor di testo
Lo scopo che sta alla base dell'utilizzo di un secondo linguaggio nella propria applicazione sarebbe quindi diminuire la complessità del codice, rimuovendo tutta quella roba che non piace a nessuno come codice usato una sola volta, architetture poco generiche, complessi cast, settaggi hardcoded, catene di if e chi più ne ha più ne metta.

Tuttavia, e parlo per esperienza, questa è una mera illusione; i problemi che si lanciano dalla porta rientrano accompagnati dalla finestra...
infatti a mio parere la complessità che si crede di eliminare viene "wrappata" "dinamicizzata" "moddata" o quant'altro, ma rimane lì, nel nostro programma.
Le il gameplay/i tools/i plugins sono arbitrari, sono regole che qualche parte devono stare scritte... scriptandole si ottengono scripts poco mantenibili come qualsiasi codice low level, con sopra il carico da 11 che ogni singola feature che si vuole usare va esposta:
appoggiandosi a pesanti framework (Boost) o creando un enorme code bloat facendo tutto a mano.
Inoltre il flusso del codice così facendo entra ed esce continuamente da un dominio all'altro creando parecchi problemi, non ultimo la completa indebuggabilità del codice, e i conflitti di thread errori ed eccezioni.
Per non parlare dello spiegare come funziona l'intero attrezzo ad uno che parte da 0.

Quindi nel mio caso, a fronte di alcune centinaia di righe in lua ho dovuto fare enormi sforzi architetturali e non; che si hanno reso più chiare alcune parti, ma che ne hanno definitivamente compromesse altre... spostando e rendendo caotica una complessità che in C++ si sarebbe tradotta nell'implementazione di alcune Factories.

In finale, ecco secondo me "gli svantaggi dello scripting che volevate sapere ma non avete osato chiedere":
*Calo di prestazioni (si, a qualcuno da fastidio )
*Aumento delle dipendenze
*Creazione di un layer di interfaccia che VA configurato e mantenuto, per avere una reale espressività
*I tipi dinamici vanno bene di per se, ma la base potrebbe digerirli male
*Con la permissività degli script si ricorre a soluzioni poco eleganti (variabili globali, etc)
*L'user puo modificare qualcosa, ma anche *tutto*
*O si convive con l'insicurezza o si crea una sandbox (ancora tempo da perdere)
*debug decisamente arduo

A pensarci bene, non vedo perchè risolvere un problema con DUE linguaggi dovrebbe essere più pulito che con uno solo
Lo consiglio solo a chi fa della community un punto vincente E ha 1/2 persone da dedicare del tutto al wrapper.
Io da parte mia, credo che farò un refactor massiccio per liberarmi di questa palla al piede e iniziare a ridurre davvero la complessità

Chissà se a qualcuno interessa abbastanza da arrivare a questa frase

Cosa ne pensate?

[javaboy]

Penso che in un progetto di piccole dimensioni usare un linguaggio di scripting sia controproducente, in un progetto più grosso come potrebbe ad esempio essere un videogioco commerciale penso che sia quasi indispensabile.

Originariamente inviato da javaboy

Penso che in un progetto di piccole dimensioni usare un linguaggio di scripting sia controproducente, in un progetto più grosso come potrebbe ad esempio essere un videogioco commerciale penso che sia quasi indispensabile.

Non è che volevi direi il contrario?

[cdimauro]

Cosa ne penso? Che se per tutti i videogiochi da un po' di anni a questa parte si utilizzano linguaggi di scripting, gli sviluppatori avranno avuto i loro buoni motivi.

Ecco qui tutte le API Python che espone Civilization 4.

Il gioco è interamente "scriptabile".

Altro esempio, Blender.

E' chiaro che si tratta di API e interfaccia (con C++) da mantenere, ma evidentemente ne vale la pena.

Poi, Tommo, hai usato LUA che non è che sia il massimo dell'espressività: è un linguaggio semplice e con pochi costrutti sintattici. E' vero che l'embedding è molto semplice, ma, come si dice dalle mie parti: "poco mi dai e poco ti do".

My 2 cents.

x Sgurbat: javaboy ha detto giusto.

[javaboy]

Originariamente inviato da Sgurbat

Non è che volevi direi il contrario?

No. Ci si sta chiedendo se convenga utilizzare solo c++ oppure c++ in combinazione con un linguaggio di scripting. E secondo me la seconda opzione conviene solo in caso di progetti molto grandi.

[javaboy]

Piuttosto mi chiedo come mai nel campo dei VG Lua vada per la maggiore.
A me sinceramente fa venire l'orticaria!

Pardon, avevo capito male.

[PGI-Bis]

Non vedo alcun problema nell'uso di più linguaggi in uno stesso progetto. Se poi tra questi c'è C++ ben vengano gli ausiliari, ancora meglio se ausiliano C++ fuori dalla finestra.

[fero86]

Originariamente inviato da Tommo

Chissà se a qualcuno interessa abbastanza da arrivare a questa frase

a me interessa moltissimo e mi sono letto tutto fino in fondo
provo a rispondere punto per punto a quelli che secondo te sono aspetti negativi dello scripting. poi per il resto vale quanto detto da cdimauro: evidentemente ne vale la pena

*Calo di prestazioni (si, a qualcuno da fastidio )

oggidi il tipico computer mainstream é carrozzato con tre importanti processori: due CPU e una GPU. quindi diciamo che potresti dedicare una CPU ai calcoli principali del gioco (per es. fisica e IA), l'altra CPU allo scripting e la GPU al rendering. se il gameplay implementato nello scripting non é proprio fulmineo chi se ne frega, basta che sia abbastanza veloce per l'essere umano (e di solito lo é).

*Aumento delle dipendenze

questa secondo me é l'unica vera, ottima, ragione: una dipendenza certe volte puó trasformarsi in un vero dito in posti reconditi. tuttavia non é neanche detto che esista una dipendenza di terze parti: Win32 ad esempio offre una tecnologia di scripting di ottima qualitá, Active Scripting, che poi é la stessa usata da Internet Explorer per esempio. Windows di per se' ha giá due motori di Active Scripting, uno per VBScript e uno per JScript, quindi se programmi in C++ per Windows e vuoi fare scripting sul tuo programma senza avere dipendenze scassacazzo di terze parti puoi adoperare Active Scripting e scriptare in uno di quei linguaggi.

*Creazione di un layer di interfaccia che VA configurato e mantenuto, per avere una reale espressività

secondo me quel layer assomiglia molto alle classi che comunque creeresti se quella parte di logica fosse implementata in codice nativo anziché nello script.

*I tipi dinamici vanno bene di per se, ma la base potrebbe digerirli male

non ho capito...
cos'é la base?

*Con la permissività degli script si ricorre a soluzioni poco eleganti (variabili globali, etc)

vuoi mettere con la permissivitá del C++?
questa motivazione é completamente da scartare.

*L'user puo modificare qualcosa, ma anche *tutto*

dipende dalle API che gli metti a disposizione. eventualmente puoi documentarne solo alcune; avrai da obiettare che tramite reverse engineering si potrebbe accedere anche a quelle non documentate, ma per il reverse engineering devi metterti l'anima in pace: se l'utente é in grado di farlo sarebbe in grado di modificare anche un programma non scriptabile.

*O si convive con l'insicurezza o si crea una sandbox (ancora tempo da perdere)

questo ahimé é vero, infatti prendendo giusto Active Scripting di cui sopra non ho mai capito come fa Internet Explorer ad evitare che uno script di una pagina web crei l'ActiveX del FileSystemObject e si metta a cancellare e sporcare files per ogni dove. posso capire IE7 o successivo in Protected Mode su Vista, ma prima come funzionava?

*debug decisamente arduo

Active Scripting prevede anche gli strumenti necessari al debug dello script. Visual Studio puó essere usato come debugger per Active Scripting, solo che non so se é usabile solo in determinate situazioni (script per pagine web), dovrei investigare la questione (perché comunque interessa anche a me).

[Y3PP4]

Originariamente inviato da Tommo

la domanda semplice, che tutti i "software architect" concreti dovrebbero porsi è: ma ne vale la pena?

Nei videogames i linguaggi di scripting servono eccome. Anzi, sono indispensabili.
Mi spiego.
Creare un engine del gioco è dispendioso. Poterlo usare più volte è invece una cosa d'obbligo per non dover sempre reinventare la ruota.
Modificare ogni volta il sorgente richiede nuovamente fasi di testing e debug - quindi più tempo -. Integrare invece un sistema di configurazione richiede semplicemente la riscrittura del modulo di configurazione e sei sicuro che non ci sono bug nel sorgente - o almeno nuovi bug -.
Certo, se un engine non è sempre adatto a tutti i tipi di gioco e spesso si riscrivono (più o meno interamente), soprattutto quando escono nuove console...

Originariamente inviato da cdimauro

Cosa ne penso? Che se per tutti i videogiochi da un po' di anni a questa parte si utilizzano linguaggi di scripting, gli sviluppatori avranno avuto i loro buoni motivi.

Quoto.

PS. ovvio che implementare un linguaggio di scripting richiede dello sviluppo in più nella fase di creazione, ma il non dover mettere mano al codice, credo sia una buona motivazione.

Originariamente inviato da Tommo

Tuttavia, e parlo per esperienza, questa è una mera illusione; i problemi che si lanciano dalla porta rientrano accompagnati dalla finestra...

Non credo che pensino in questo modo di eliminare problemi, più che altro ridurre i costi di manutenzione del codice. Non doverli modificare è un vantaggio non da poco.

Per non parlare dello spiegare come funziona l'intero attrezzo ad uno che parte da 0.

Questa frase non credo di averla compresa.Se intendi relativamente a una società che sviluppa il proprio engine/tool per lo sviluppo interno, non credo ci siano problemi. Nel senso che comunque non cercano i novellini ma programmatori già dotati delle dovute skill richieste. Da li è solo uno studio dell'architettura, e se mantengono le cose semplici in un paio di giorni il nuovo arrivo inizia già a lavorarci sopra (come un grafico pro che usa 3ds max, se passa a blender un paio di giorni per capirne l'interfaccia e poi il resto è tutta esperienza già fatta...)
Se ti riferisci a prodotti commerciali, beh, idem. I prodotti sono destinati all'enterprise, non ai ragazzi che sviluppano in cantina.

Chissà se a qualcuno interessa abbastanza da arrivare a questa frase

Ciao.

PPS.

Originariamente inviato da cdimauro

"poco mi dai e poco ti do"

Uh! anche dalle mie parti (natali) si dice *-* (ma in dialetto )

[Y3PP4]

Originariamente inviato da javaboy

Piuttosto mi chiedo come mai nel campo dei VG Lua vada per la maggiore.
A me sinceramente fa venire l'orticaria!

Uhm. Bellissima domanda. Nei vari articoli io ho sempre letto che è diventato uno standard nei VG... non saprei però rispondere a questa domanda.

Può darsi che sia per la facilità di embedding.
A chi interessa uno dei tutorial trovati in rete per un semplicissimo esempio: qui

Comunque io a suo tempo usai per imparare Python come linguaggio di configurazione e anche lì è semplicissimo.

[cdimauro]

Originariamente inviato da Y3PP4

Uhm. Bellissima domanda. Nei vari articoli io ho sempre letto che è diventato uno standard nei VG... non saprei però rispondere a questa domanda.

Può darsi che sia per la facilità di embedding.

Il motivo è proprio questo. Essendo un linguaggio/runtime estremamente semplice, LUA è altrettanto semplice da integrare un progetto C/C++ (è stato pensato proprio per questo).

Python richiede molto più "effort" (mi spiace, non mi viene la parola adesso), ma per fortuna esistono librerie come BOOST che rendo l'embbedding (o extending, se sviluppiamo estensioni per Python) estremamente semplice.

Sia chiaro: io già non digerisco il C++ (e concordo con PGI ), e men che meno autentici pachidermi come BOOST, ma gli vanno riconosciuti i giusti meriti.

E senza dubbio utilizzerei Python come linguaggio di scripting: è di gran lunga più "espressivo" (e ben dotato: oltre alla ricca libreria standard, c'è un notevole supporto di terze parti).

Per la velocità (LUA è più veloce), Google ci stà già pensando, per cui mi aspetto grandi cose in futuro.

Originariamente inviato da PGI-Bis

Non vedo alcun problema nell'uso di più linguaggi in uno stesso progetto. Se poi tra questi c'è C++ ben vengano gli ausiliari, ancora meglio se ausiliano C++ fuori dalla finestra.

E' veramente un pessimo linguaggio C++? Non lo conosco.

[cdimauro]

"Se lo conosci, lo eviti. Se lo conosci, non ti uccide"...

Originariamente inviato da cdimauro

"Se lo conosci, lo eviti. Se lo conosci, non ti uccide"...

Curiosità: quali solo i motivi che lo rendono un linguaggio, ad oggi, così poco appetibile?

[Kralizek]

i suoi pro ed i suoi contro coincidono: permettono/costringono lo sviluppatore ad occuparsi di aspetti che altri linguaggi gestiscono automaticamente.

Originariamente inviato da Kralizek

i suoi pro ed i suoi contro coincidono: permettono/costringono lo sviluppatore ad occuparsi di aspetti che altri linguaggi gestiscono automaticamente.

Tipo?

[Kralizek]

Originariamente inviato da Sgurbat

Tipo?

il più citato: gestione della memoria.
- rispetto a .NET e Java, in C++ sai esattamente quando un oggetto viene distrutto
- puoi posizionare una variabile nell'area di memoria che preferisci. In .NET collocare un'istanza di una struct nell'heap ed un'istanza di una classe nello stack è impossibile. Lo stesso in Java.

in genere, quello che scrivi in C++ è quello che viene eseguito. Ad esempio in ogni oggetto java è insita la gestione thread-safe. Questo significa che quando assegni un valore ad un intero

int i;
i = 0;

in realtà stai passando per un costosissimo meccanismo di mutex.

spero di non aver scritto cazzate, soprattutto rispetto al Java, che non mastico da tempo.

[fero86]

Originariamente inviato da Kralizek

in genere, quello che scrivi in C++ è quello che viene eseguito. Ad esempio in ogni oggetto java è insita la gestione thread-safe. Questo significa che quando assegni un valore ad un intero

int i;
i = 0;

in realtà stai passando per un costosissimo meccanismo di mutex.

spero di non aver scritto cazzate, soprattutto rispetto al Java, che non mastico da tempo.

mi sa che le hai scritte

[Y3PP4]

Originariamente inviato da Sgurbat

E' veramente un pessimo linguaggio C++? Non lo conosco.

Io personalmente C++ lo apprezzo. Mi piace molto l'OOP e dovendo scegliere tra C e C++ (ovviamente parlando orientativamente -senza considerare il progetto e tutti gli studi del caso-) preferirei usare C++.
Ovviamente anche in C coi puntatori e con un po' di astuzia si emula l'OOP (occhio, si emula). Se scritto da un buon programmatore il codice diventa comunque riutilizzabile, ma in C++ tutto questo diventa una realtà.

Adesso potremmo star qui a dire perchè ci sono linguaggi da preferire a C++, ma anche questi sono stati scritti in C/C++

Comunque il fatto di dover gestire la memoria è una lama a doppio taglio: è un vantaggio poter decidere come usare la memoria disponibile, ma è altresì vero che devi pensare a tutto te (logicamente). A me questa cosa non dà noia. Certo, se posso fare qualcosa con un linguaggio come Python ben venga, ma da li a dire che C++ fà schifo ne passa...

Originariamente inviato da cdimauro

Il motivo è proprio questo. Essendo un linguaggio/runtime estremamente semplice, LUA è altrettanto semplice da integrare un progetto C/C++ (è stato pensato proprio per questo).

Ah, ecco.

Beh si potendo scegliere anche io userei Python per i motivi che hai citato nel tuo precedente post sul fatto che è un linguaggio più completo.

Comunque riquoto un mio post precedente: nei videogame lo scripting è una necessità data dal non dover modificare il sorgente degli engines per ogni gioco, in questo modo si riduce al minimo la modifica dei sorgenti, si sfruttano i linguaggi di scripting e si migliora la mantenibilità del codice.