[Vari]Scripting: se lo conosci lo eviti? [Archivio]

Tommo

29-08-2009, 01:45

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* :Prrr:

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 :sofico:
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 :asd:)
*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 :asd:
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à :D

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

Cosa ne pensate?

javaboy

29-08-2009, 13:02

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.

Sgurbat

29-08-2009, 14:07

cdimauro

29-08-2009, 15:09

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 (http://civilization4.net/files/modding/PythonAPI/) tutte le API Python che espone Civilization 4.

Il gioco è interamente "scriptabile".

Altro esempio, Blender (http://www.blender.org/documentation/245PythonDoc/index.html).

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

29-08-2009, 15:27

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

29-08-2009, 15:30

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

Sgurbat

29-08-2009, 15:48

Pardon, avevo capito male.

PGI-Bis

29-08-2009, 17:23

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

29-08-2009, 19:11

Chissà se a qualcuno interessa abbastanza da arrivare a questa frase :asd: 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 :D

*Calo di prestazioni (si, a qualcuno da fastidio :asd:) 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... :mbe:
cos'é la base?

*Con la permissività degli script si ricorre a soluzioni poco eleganti (variabili globali, etc) vuoi mettere con la permissivitá del C++? :asd:
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

29-08-2009, 22:22

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...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.

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
:D

Ciao.

PPS. "poco mi dai e poco ti do"
Uh! anche dalle mie parti (natali) si dice *-* (ma in dialetto :p)

Y3PP4

29-08-2009, 22:32

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 (http://csl.sublevel3.org/lua/)

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

cdimauro

30-08-2009, 09:29

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 :D), 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 (http://code.google.com/p/unladen-swallow/wiki/ProjectPlan), per cui mi aspetto grandi cose in futuro. :cool:

Sgurbat

30-08-2009, 09:44

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

30-08-2009, 09:58

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

Sgurbat

30-08-2009, 10:10

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

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

Kralizek

30-08-2009, 12:34

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

Sgurbat

30-08-2009, 12:42

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

Tipo?

Kralizek

30-08-2009, 12:49

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

30-08-2009, 13:50

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 :stordita:

Y3PP4

30-08-2009, 14:41

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...
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.

javaboy

30-08-2009, 14:46

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

Si. Il primo problema è la gestione della memoria (che è anche il suo punto di forza d'altra parte): non si contano i bug a cui può portare tra memory leak e double delete. Per poterne uscire vivi si è costretti a usare smart pointers e altri acrocchi che aumentano ulteriormente la complessità.

Non parliamo poi del precompilatore, del sistema di inclusione dei file e degli acrocchi (tipo il PIMPL) utilizzati per ridurre i tempi di compilazione.

La libreria standard fa schifo, incompleta e inutilmente complessa.

Il c++ inoltre dispone di strumenti (funzioni friend, reinterpret_cast, const_cast) che sembrano studiati ad arte per spararsi nei piedi..

PGI-Bis

30-08-2009, 14:46

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

Per me no, a me C++ è sempre piaciuto molto. Ci sono delle ragioni di contorno che non dipendono dal linguaggio ma da qualcosa che ha a che fare coi suoi utenti che terrò per me onde non aprire le porte dell'inferno (con le fiammate che naturalmente conseguirebbero :D).

marco.r

30-08-2009, 14:48

Salve,
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.

Le due caratteristiche di cui parli non sono le uniche che andrebbero valutate.

Lo sviluppo e' piu' rapido e semplice, ma bisogna fattorizzare il costo dell'embedding, che porta via tempo e complica la base. Per massimizzare i vantaggi, bisogna cercare di avere ben chiaro in mente il contesto in cui il linguaggio verra' usato ("configurazione", "interfaccia grafica", ... ), e minimizzare l'interfaccia tra i due linguaggi.

Tieni inoltre presente che un linguaggio di scripting e' utile anche per altri aspetti, come la possibilita' di modificare il comportamento del programma senza bisogno di ricompilare (ottimo per le grandi aziende che hanno gruppi di sviluppatori separati dai designer, oppure per chi vuole facilitare il modding); se a te non servono allora il vantaggio non e' cosi' rilevante.

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 :sofico:
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.

L'embedding non va fatto a caso, interfacciando man mano una funzione che serve, ma pensato un minimo per avere chiare la separazione dei compiti. Fatte le cose come bisogna, diventa anche piu' facile gestire il tutto (il come dipende dal contesto ovviamente).

Per passare ai problemi che elencavi

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

Dipende da come organizzi le cose. Noi abbiamo un software che ha loop di controllo realtime a 1KHz, pero' la parte di alto livello (setup, interazione con l'utente) e' in python, e l'interazione avviene senza problemi o rallentamenti.

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

Una volta che hai definito bene le competenze del linguaggio di scripting, il layer di interfaccia dovrebbe rimanere relativamente stabile nel tempo, *molto* piu' del codice di scripting.

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

Meglio se riesci a fare in modo che la base non debba digerirli affatto, e sia il linguaggio embedded a doverlo fare. La parte di marshalling dovrebbe gestirla il linguaggio embedded in se', o dovresti ricorrere ad un tool che faccia il lavoro per te (boost::python, swig, etc.).

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

Questo non dipende dal fatto che si tratta di uno script.

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

No, lo user dovrebbe poter modificare solo quello che viene deciso. Se puo' modificare tutto allora non e' stata fatta un interfacciamento corretto.

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

Dipende dal linguaggio. Con python fare sandboxing e' altamente difficile, con Lua non dovrebbero esserci problemi (anche se io di lua ne sono poco, sono altri miei colleghi che lo usano regolarmente).

*debug decisamente arduo

In parte. Da un lato la presenza di piu' linguaggi rende il debug classico difficile, se non impossibile. Pero' il linguaggio di scripting permette di costruirsi in un attimo una REPL in cui fare i test in modo veloce. Non si raggiunge l'efficenza che si potrebbe avere con un Common Lisp o uno Smalltalk, pero' direi che e' un gran passo avanti, e molto piu' rapido che non degli unit test (che eventualmente poi deriveranno dalle prove fatte dalla console).

Kralizek

30-08-2009, 14:59

mi sa che le hai scritte :stordita:

ecco lo sapevo che non dovevo uscire dal mio orticello...

mi scrivi la versione corretta? Grassie :D

Tommo

31-08-2009, 00:06

Ecco, scusate se mi sono eclissato ma ho postato prima di andare al mare :asd:

Comunque, sono d'accordo con tutti voi per quanto riguarda in vantaggi di un linguaggio di scripting potente come Python, che avete elencato più o meno efficacemente...

nella discussione però io volevo porre l'accento sul fin troppo sottovalutato aspetto "potenzialità/tempo";
ovvero, facendo l'esempio del mio gioco:
Avere le armi, le fazioni, i livelli interamente in Lua è indubbiamente sciccoso, permette di moddare, crearne un'altro qualsiasi è davvero rapido...
tuttavia molti vantaggi sono più che altro illusori.

*Riuso in più progetti
Al massimo potrei riutilizzarlo in un seguito... il 90% del wrapper sono metodi inerenti ad aspetti estremamente specifici del gameplay... il restante 10% l'ho già messo in una DLL.
In più per esporli in maniera "script friendly" cioè non nel becero wrapping automatico di Boost (usando tabelle, tipi dinamici, comandi più espressivi) ci vuole una cifra di tempo che non verrà affatto ripagato.
E bisogna avere un certo occhio chirurgico per ridurre al minimo le cose "in più" che fa il wrapper (es: una funzione wrapper che usa new: NON va bene).

*Si evita code bloat in C++
Vero, ma da una parte c'è il wrapper, dall'altra lo stesso code bloat negli scripts;
ovvero, se le classi dei vari oggetti di gioco (che potrebbero essere un tool in un altro programma) le avessi direttamente spammate in C++ ben individuate in un Factory Pattern, sono convinto che sarebbe stato più veloce, semplice e potente.
Unico svantaggio? Chi ne vuole aggiungere altre deve linkare la libreria di gioco (non serve nemmeno ricompilare).

Dunque riassumendo, mi sembra che i maggiori vantaggi siano
*Possibilità di inserire contenuti per chi non mantiene il codice
*Gestione maggiormente modulare dei contenuti
*Threading avanzato

Ma, mi sembra che siano punti (in particolare i primi due) che NON possono interessare dei teams così piccoli che questi problemi nemmeno si pongono...
per quanto per teams abbastanza grandi sia una scelta sensata.

E in realtà, mi da l'idea che molti lo usino sentendosi "grandi" ma non conviene nemmeno a loro :sofico:

Certo, i programmi office o di produzione sono una storia diversa...

Y3PP4

31-08-2009, 00:54

Ma, mi sembra che siano punti (in particolare i primi due) che NON possono interessare dei teams così piccoli che questi problemi nemmeno si pongono...
per quanto per teams abbastanza grandi sia una scelta sensata.

Un team può essere grande o piccolo è vero. Ma anche un team piccolo se composto di persone che sanno il loro perchè possono dar vita a medi-grandi progetti, e al di là della dimensione, di ottima qualità.
Non credo che sia possibile generalizzare l'implementazione di un sistema di scripting o meno nel programma, bisogna sempre considerare molti aspetti che vengono solitamente presi in considerazione nello studio dell'applicazione.
Anche se un team è piccolo ma ha intenzione (a maggior ragione per la ridotta dimensione) di realizzare una base quanto più re-implementabile può eventualmente vedere la necessità di utilizzare per questo o quel motivo linguaggi di scripting.
Inoltre uno dei punti di forza dei linguaggi interpretati non è proprio quello di un debug più rapido? (non dovendo ogni volta ricompilare il sorgente eseguibile).

E in realtà, mi da l'idea che molti lo usino sentendosi "grandi" ma non conviene nemmeno a loro :sofico:
LOOOOL :D Veramente simpatica questa frase, ma se un team lo fà per lavoro ed è quantomeno diretto da una persona dotata di buon senso (e comunque di esperienza) riesce a bloccare tutto ciò che non serve realmente, anche se la realizzazione di quel sistema rende il progetto più "pomposo".

Sono ovviamente pronto a chiarire, eventualmente, quanto detto sopra, poichè data l'ora potrei non essere stato chiaro :)

Ciao e buona notte.

PS. Avere tutto ciò che riguarda il gioco in sè scritto in un linguaggio come LUA lo trovo tutt'altro che "sciccoso", sia per motivi prestazionali sia per ordine del codice. Va bene una configurazione o poco più ma tutto quello mi sembra veramente esagerato.

banryu79

31-08-2009, 11:58

ecco lo sapevo che non dovevo uscire dal mio orticello...

mi scrivi la versione corretta? Grassie :D
In Java ogni istanza di tipo reference (quindi non i tipi primitivi, come l'int nel tuo esempio) è dotata di un monitor sotto le chiappe, creato appunto nel momento in cui viene creato un qualsiasi Object, con chiamata a metodo nativo.

E' così (credo, PGI potrà confermare o smentire) perchè serve per avere la caratteristica del multithreading implementata direttamente nel linguaggio.

Kralizek

31-08-2009, 12:24

mi sa che le hai scritte :stordita:

In Java ogni istanza di tipo reference (quindi non i tipi primitivi, come l'int nel tuo esempio) è dotata di un monitor sotto le chiappe, creato appunto nel momento in cui viene creato un qualsiasi Object, con chiamata a metodo nativo.

E' così (credo, PGI potrà confermare o smentire) perchè serve per avere la caratteristica del multithreading implementata direttamente nel linguaggio.

uhm... forse non l'ho reso ma intendenvo quello :P

Tommo

31-08-2009, 12:32

Cmq ecco mi è venuto in mente l'immancabile esempio automobilistico :asd:

Lo scripting è una cosa che non porta alcun vantaggio, anzi, ma è necessario per organizzare teams molto grossi:
se si deve arrivare da qualche parte, 100 persone devono prendere un pullman, 2 possono prendere una spider... inutile dire chi arriva prima :D

Che poi per quanto riguarda il "lo fanno tutti": giochi stupendi come Half Life 2, mario galaxy, metroid, zelda, gli Halo e più o meno tutti i giochi della passata generazione non usano alcun linguaggio di script...
quindi più che chiedermi i motivi di chi lo fa, mi chiederei quelli di chi NON lo fa e riesce ad ottenere gli stessi risultati...
quando giochi come GTA IV, STALKER, Crysis o Civilization ne fanno uso estensivo e sono pachidermi più o meno in tutto.

banryu79

31-08-2009, 13:23

[Off Topic]
uhm... forse non l'ho reso ma intendenvo quello :P
Sì certo, quello che volevo specificare meglio (e che in effetti non ho reso esplicitamente) è che il fatto di avere un monitor collegato ad ogni istanza non significa che ad ogni invocazione di metodo si passi per un meccanismo di mutua esclusione.

Credo che ciò avvenga solo in determinate circostanze, controllate dal programmatore, come, ad esempio, quando si invoca un metodo dichiarato come synchronized.
Cioè non è che di default se io faccio una cosa del genere:

JavaObject o;
o = new JavaObject ;
o.setMethod(aValue);

l'asegnazione o il metodo setMethod inneschi effettivamente il meccanismo di mutex; l'innesco del mutex dovrebbe avvenire solo se quel metodo è stato dichiarato come "synchronized", altrimenti non lo è.
Non ne sono sicuro perchè non l'ho esplicitamente letto da nessuna parte, ma riflettendoci arrivo a queste conclusioni, per questo speravo in una conferma o smentita da parte di qualche esperto.

Invece hai sempre un piccolo overhead di memoria per gli oggetti istanziati, tutti dotati di una qualche sorta di dato/riferimento usato per collegarli al monitor (dubito che tutto il meccanismo di mutex sia istanziato a se stante ogni volta per ogni singolo oggetto). Ignoro però i dettagli di come sia effettivamente implementato.
[/Off Topic]

RaouL_BennetH

31-08-2009, 13:43

ecco lo sapevo che non dovevo uscire dal mio orticello...

mi scrivi la versione corretta? Grassie :D

Credo che fero86 si riferisse più che altro all'ambiente .NET dove 'potresti' comunque utilizzare puntatori e allocare robaccia nello stack mediante l'utilizzo di 'unsafe'

http://msdn.microsoft.com/it-it/library/cx9s2sy4.aspx

http://msdn.microsoft.com/it-it/library/t2yzs44b.aspx

Kralizek

31-08-2009, 13:44

fero86

31-08-2009, 13:55

Credo che fero86 si riferisse più che altro all'ambiente .NET dove 'potresti' comunque utilizzare puntatori e allocare robaccia nello stack mediante l'utilizzo di 'unsafe'

http://msdn.microsoft.com/it-it/library/cx9s2sy4.aspx

http://msdn.microsoft.com/it-it/library/t2yzs44b.aspx a parte che esiste la storia di unsafe in .NET e vabbé, ma non mi pare assolutamente vero quello che ha scritto kralizek: se assegni un banalissimo valore intero non passi per nessun mutex, il codice che ha riportato kralizek non effettua alcuna sincronizzazione; tant'é vero che se quella variabile non la dichiari volatile due thread potrebbero vedere due valori diversi per pochi istanti, a seconda di come il compilatore ha riordinato le istruzioni, che é esattamente lo stesso che succede in C++. se vuoi usare il mutex associato ad un certo oggetto devi usare il costrutto synchronized.

PGI-Bis

31-08-2009, 13:55

[edit]In riferimento al post #31

No no, era proprio sui monitor Java che l'ha sparata grossa :eek:

fero86

31-08-2009, 13:58

No no, era proprio sui monitor Java che l'ha sparata grossa :eek: ecco appunto :D

Kralizek

31-08-2009, 14:19

mi cospargo umilmente la testa di cenere... il mio javese é arruginito (e per questo ringrazio la madonna! :P)

RaouL_BennetH

31-08-2009, 14:49

mi cospargo umilmente la testa di cenere... il mio javese é arruginito (e per questo ringrazio la madonna! :P)

e io la prossima volta farò meglio a stare mutex ... :fagiano:

Sgurbat

31-08-2009, 14:57

e io la prossima volta farò meglio a stare mutex ... :fagiano:

Questa volta è stata una Exception? :stordita:

shinya

31-08-2009, 16:58

e io la prossima volta farò meglio a stare mutex ... :fagiano:
Questa volta è stata una Exception?
La smettiamo di consolidare la mia mancanza di fiducia nell'umanità?!

banryu79

31-08-2009, 17:25

La smettiamo di consolidare la mia mancanza di fiducia nell'umanità?!
Post funnyPost= this.getPostOf("RaouL_BennetH");
Post replyToFunnyPost = this.getPostOf("Sgurbat");
double umanityFaithRate = shinya.computeValueFor(funnyPost, replyToFunnyPost);

try
{
shinya.persistData(umanityFaithRate);
}
catch (ValueTooLowException e)
{
shinya.writeReply();
}
finally
{
shinya.restart();
}
:Perfido: ... :asd:

marco.r

31-08-2009, 18:19

Tommo

31-08-2009, 20:41

Francamente non sono d'accordo... al lavoro abbiamo fatto embedding per un progetto su cui alla fine hanno lavorato 2 persone, e ne e' valsa la pena.
Tu per cosa avevi fatto l'embedding ?

Beh, ho scritto una simpatica classe che gestisce del tutto le interazioni C++ -> Lua...
ma per Lua -> C++ mi è toccato wrappare le funzioni da esporre una per una, non potendo di certo chiamare le funzioni C++ con una stringa.

Non era difficile, questione di pochi secondi... ma bello neppure:asd:

cdimauro

31-08-2009, 21:10

Rieccomi. :)
Curiosità: quali solo i motivi che lo rendono un linguaggio, ad oggi, così poco appetibile?
Ti sono già stati ampiamente esposti. Comunque va bene la battuta, ma bisogna dire che anche il C++ ha motivo di essere utilizzato. Dipende dal tipo di problema che bisogna risolvere.

Nella programmazione non esiste la pietra filosofale, il linguaggio da utilizzare sempre per qualunque cosa.

A parte Python, ovviamente. :O
Per me no, a me C++ è sempre piaciuto molto. Ci sono delle ragioni di contorno che non dipendono dal linguaggio ma da qualcosa che ha a che fare coi suoi utenti che terrò per me onde non aprire le porte dell'inferno (con le fiammate che naturalmente conseguirebbero :D).
Oggi c'è un po' di fresco: fai pure. :fiufiu:
Dipende dal linguaggio. Con python fare sandboxing e' altamente difficile, con Lua non dovrebbero esserci problemi (anche se io di lua ne sono poco, sono altri miei colleghi che lo usano regolarmente).
Se può essere utile: http://wiki.python.org/moin/SandboxedPython
In parte. Da un lato la presenza di piu' linguaggi rende il debug classico difficile, se non impossibile. Pero' il linguaggio di scripting permette di costruirsi in un attimo una REPL in cui fare i test in modo veloce. Non si raggiunge l'efficenza che si potrebbe avere con un Common Lisp o uno Smalltalk, pero' direi che e' un gran passo avanti, e molto piu' rapido che non degli unit test (che eventualmente poi deriveranno dalle prove fatte dalla console).
Per CL va bene (http://shootout.alioth.debian.org/u32q/benchmark.php?test=all&lang=python&lang2=sbcl&box=1), ma con SmallTalk le prestazioni sono simili (http://shootout.alioth.debian.org/u32q/benchmark.php?test=all&lang=python&lang2=vw&box=1).
Dunque riassumendo, mi sembra che i maggiori vantaggi siano
*Possibilità di inserire contenuti per chi non mantiene il codice
*Gestione maggiormente modulare dei contenuti
*Threading avanzato

Ma, mi sembra che siano punti (in particolare i primi due) che NON possono interessare dei teams così piccoli che questi problemi nemmeno si pongono...
Ma anche no (http://addons.miranda-im.org/details.php?action=viewfile&id=2730). Qui (http://forums.miranda-im.org/showthread.php?t=7261) per qualche utile esempio.

E Miranda non è che pulluli di programmatori...
Cmq ecco mi è venuto in mente l'immancabile esempio automobilistico :asd:

Lo scripting è una cosa che non porta alcun vantaggio, anzi, ma è necessario per organizzare teams molto grossi:
se si deve arrivare da qualche parte, 100 persone devono prendere un pullman, 2 possono prendere una spider... inutile dire chi arriva prima :D

Che poi per quanto riguarda il "lo fanno tutti": giochi stupendi come Half Life 2, mario galaxy, metroid, zelda, gli Halo e più o meno tutti i giochi della passata generazione non usano alcun linguaggio di script...
http://en.wikipedia.org/wiki/QuakeC

QuakeC is an interpreted language developed in 1996 by John Carmack of id Software to program parts of the computer game Quake.

:read: :Prrr:
quindi più che chiedermi i motivi di chi lo fa, mi chiederei quelli di chi NON lo fa e riesce ad ottenere gli stessi risultati...
quando giochi come GTA IV, STALKER, Crysis o Civilization ne fanno uso estensivo e sono pachidermi più o meno in tutto.
Leggiti questa (http://www.pycon.it/conference/talks/integrating-and-using-iron-python-in-a-xna-game) presentazione. E mi spiace che il video non sia ancora disponibile, perché avresti visto delle prove al volo dei motivi per cui utilizzare IronPython è una gran comodità per gli sviluppatori.
Francamente non sono d'accordo... al lavoro abbiamo fatto embedding per un progetto su cui alla fine hanno lavorato 2 persone, e ne e' valsa la pena.
Tu per cosa avevi fatto l'embedding ?
Concordo: è una questione di finalità del progetto.

Tommo

31-08-2009, 21:25

Mah;
ho visto i link e sono o roba open source, o sperimentazioni, o cose fatte da Carmack.
E il mio progetto non appartiene a nessuna delle 3 :asd:

Quello che continuo a sostenere, è che se l'estendibilità non è una parte fondamentale del progetto, lo scripting risulta un peso notevole, o comunque un peso che altrimenti non si avrebbe.

Nel progetto citato da marco.r se ne sono occupate 2 persone; sai quanta roba cacciano 2 persone se non lavorano su un wrapper?
Lo scripting diventa quindi conveniente quando i guadagni superano il lavoro prodotto da 2 persone in non so quanto tempo...
e mi sembra una soglia di guadagno decisamente impervia.

E poi si dice che si evita lo "shoot yourself in the foot" tipico del C++; vogliamo invece parlare di dove ci si può sparare combinando C++ con un linguaggio a paradigma diverso? :asd:
C'è un altro post in questo forum dove avevo un crash causato da una funzione C++ lanciata alcune volte contemporaneamente ma sfasata, dove un esecuzione rovinava lo stack dell'altra e faceva crashare la terza. Come dire, stupendo :D

Inoltre non ho ancora capito apparte l'estendibilità cosa mi da IN PIU' un linguaggio di scripting, cioè, quali potenzialità guadagno che in C++ mi sono precluse?

IMHO i linguaggi di scripting in se sono belli, ma molti dovrebbero fare un bel reality check :D
Per esempio Ogre ha tonnellate di plugins, è estendibile ma è scritto tutto in brutto&cattivo C++... anche se ultimamente pare che i plugin li hanno inventati con gli script.
Idem dicasi del Source, che non mi sembra tarpi le ali a nessuno.

PS: se vedi, la maggior parte delle SH che usano e dicono di usare lo scripting fanno parte delle SH "cool", quelle che si fanno pubblicità con i frizzi & i lazzi della loro tecnologia... come ID, Crytek, quellila di STALKER, Epic.
E, sinceramente, seguire gente che salta su qualsiasi carrozzone basta che sia "cutting edge" forse non è ottimo per tutti quanti :D

tomminno

31-08-2009, 23:08

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

Continuo a ritenere che la differenza tra C++ e Java o C# sta soprattutto nella libreria standard.

Uno parte da una base installata e dice: voglio fare operazioni con le date, con un linguaggio managed ho già tutto già fatto, in C++? boh dovrò alambiccarmi il cervello con timeval o SYSTEMTIME, si perchè magari mi servono i millisecondi e la libreria standard manco li contempla.
Devo fare una chiamata web, niente di più semplice con un linguaggio managed, in C++ devi scaricarti una libreria, compilarla, includerla nel progetto, imparare ad usarla (sicuramente a partire da esempi C), farci una classe wrapper sopra e poi se tutto va bene riesci a fare la tua chiamata web.
Ecco la differenza di produttività.
In mezzo a tutto questo il fatto di dovermi gestire la memoria (che poi con shared_ptr non ci pensi più) è il meno.

cdimauro

01-09-2009, 07:22

Mah;
ho visto i link e sono o roba open source, o sperimentazioni, o cose fatte da Carmack.
E il mio progetto non appartiene a nessuna delle 3 :asd:
Questo è un altro discorso, ma io ti ho presentato alcuni progetti (altri li avevo citati prima) di casi di successo dell'utilizzo di linguaggi di "scripting" :rolleyes: all'interno di altri più complessi.
Quello che continuo a sostenere, è che se l'estendibilità non è una parte fondamentale del progetto, lo scripting risulta un peso notevole, o comunque un peso che altrimenti non si avrebbe.

Nel progetto citato da marco.r se ne sono occupate 2 persone; sai quanta roba cacciano 2 persone se non lavorano su un wrapper?
Lo scripting diventa quindi conveniente quando i guadagni superano il lavoro prodotto da 2 persone in non so quanto tempo...
e mi sembra una soglia di guadagno decisamente impervia.
Ma qui nessuno ti sta dicendo che devi per forza integrare un altro linguaggio per il controllo della tua applicazione. Devi essere tu a valutare se è il caso, se la soluzione si prospetta vantaggiosa per ciò che hai intenzione di fare.

Evidentemente per te non va bene, per marco sì. Non ci vedo proprio nulla di male.
E poi si dice che si evita lo "shoot yourself in the foot" tipico del C++; vogliamo invece parlare di dove ci si può sparare combinando C++ con un linguaggio a paradigma diverso? :asd:
Carmack è ancora vivo. :O
C'è un altro post in questo forum dove avevo un crash causato da una funzione C++ lanciata alcune volte contemporaneamente ma sfasata, dove un esecuzione rovinava lo stack dell'altra e faceva crashare la terza. Come dire, stupendo :D
E la colpa era?
Inoltre non ho ancora capito apparte l'estendibilità cosa mi da IN PIU' un linguaggio di scripting, cioè, quali potenzialità guadagno che in C++ mi sono precluse?
La facilità con cui puoi manipolare la tua applicazione.

Lo potresti fare anche in C++ ovviamente, ma dai un'occhiata agli esempi del plugin MirPy e vedi quant'è semplice manipolare Miranda usando Python come linguaggio di scripting.

Con in più il vantaggio non indifferente che non serve imparare un linguaggio complesso com C++, e quindi una maggior facilità di approccio anche da parte di chi è digiuno di programmazione.
IMHO i linguaggi di scripting in se sono belli, ma molti dovrebbero fare un bel reality check :D
Per esempio Ogre ha tonnellate di plugins, è estendibile ma è scritto tutto in brutto&cattivo C++... anche se ultimamente pare che i plugin li hanno inventati con gli script.
Idem dicasi del Source, che non mi sembra tarpi le ali a nessuno.
Prendendo singoli casi ad hoc si può affermare tutto e il contrario di tutto.

Qui l'unico che può valutare se è il caso o meno sei tu, che ci stai lavorando al tuo progetto.

Altri hanno fatto e faranno valutazioni diverse che li porteranno eventualmente a soluzioni diametralmente opposte rispetto alla tua.
PS: se vedi, la maggior parte delle SH che usano e dicono di usare lo scripting fanno parte delle SH "cool", quelle che si fanno pubblicità con i frizzi & i lazzi della loro tecnologia... come ID, Crytek, quellila di STALKER, Epic.
E, sinceramente, seguire gente che salta su qualsiasi carrozzone basta che sia "cutting edge" forse non è ottimo per tutti quanti :D
Non credo che "saltino sul carrozzone" per una questione di moda. Sono professionisti che fanno i loro conti con budget e scadenze dei publisher molto più di chiunque altro, e non credo abbiano tempo e soldi da perdere se decidono di adottare una soluzione (qui sto parlando in generale, non soltanto per i linguaggi di scripting) piuttosto che un'altra.
Continuo a ritenere che la differenza tra C++ e Java o C# sta soprattutto nella libreria standard.

Uno parte da una base installata e dice: voglio fare operazioni con le date, con un linguaggio managed ho già tutto già fatto, in C++? boh dovrò alambiccarmi il cervello con timeval o SYSTEMTIME, si perchè magari mi servono i millisecondi e la libreria standard manco li contempla.
Devo fare una chiamata web, niente di più semplice con un linguaggio managed, in C++ devi scaricarti una libreria, compilarla, includerla nel progetto, imparare ad usarla (sicuramente a partire da esempi C), farci una classe wrapper sopra e poi se tutto va bene riesci a fare la tua chiamata web.
Ecco la differenza di produttività.
In mezzo a tutto questo il fatto di dovermi gestire la memoria (che poi con shared_ptr non ci pensi più) è il meno.
Ma con C# e Java è tutto "naturale" e "trasparente". Certi problemi nemmeno te li poni. Con C++ sì, e i bug che possono saltare fuori sono decisamente più rognosi da scovare e fixare.