Newsgroup: it.comp.giochi.avventure.testuali
Titolo: Intervento di Graham Nelson su Inform 7

Cari amici,
il metafisico Graham Nelson è intervenuto personalmente sul newsgroup
rec.arts.int-fiction in merito agli sviluppi del nuovo Inform 7, che pare ormai
imminente. Ho pensato di rendere un buon servizio traducendo in italiano il suo
messaggio e proponendo qui le parti più interessanti.
PaoloM
-----------------------------------------------------------
Inform 7 non è ancora terminato. Non sarà una semplice estensione di Inform 6, e
si è rivelato molto più complesso di quanto avessi inizialmente pensato. Dopo i
primi diciotto mesi di programmazione sono riuscito ad ottenere una sorta di
sistema di base - uno con il quale fosse possibile produrre vera IF. La build in
questione è stata battezzata 1A01. Ma solo alla 1J34 sono riuscito ad ottenere
qualcosa che fosse possibile mostrare ad altre persone - sebbene fragile e
instabile - ed è servito un altro centinaio di build prima che il sistema fosse
in grado di affrontare un test completo, un lavoro in corso d'opera di Emily
Short. In poche settimane ho ricevuto dieci segnalazioni di bug al giorno da una
sola coppia di tester, il che dovrebbe dare l'idea del perché non sarei riuscito
a gestire una squadra di test più vasta.
A quel punto, arrivati alla build 2C80, abbiamo finalmente iniziato a capire ciò
che stavamo facendo: quali erano i concetti importanti che ci sfuggivano. Al
termine della prima ondata di test siamo tornati al tavolo di progettazione,
perché finalmente sapevamo cosa progettare. Ciò ha portato ad una sostanziale
riscrittura durante l'inverno 2004/5, e alla stesura di una suite di test per
verificare il sistema in modo migliore. (Non vi dico quante ore Emily ci ha
passato, e ciò che ne è ironicamente risultato è che il suo lavoro originale ora
risulta scritto in un linguaggio che non esiste più, quindi in un certo senso
sono responsabile della distruzione di una nuova opera di Emily Short - anche se
spero che un giorno possa essere recuperata. Se precedenti versioni di I7
fossero circolate liberamente, questo destino sarebbe toccato anche ad altri.)
Successivamente ho scritto un documento di ricerca sul lavoro svolto fino a quel
momento, e ho iniziato ad affrontare la mia idea sul fatto che ciò che un
sistema di progettazione IF dovrebbe essere è essenzialmente un problema di
analisi semantica del linguaggio - infatti, mentre la ricerca sulla
programmazione ha ammesso la linguistica sintattica per così tanto tempo da
considerare l'area risolta, ritengo che la semantica è stata spesso
sottovalutata come teoria applicabile al modo in cui le persone potrebbero
utilizzare i computer con maggiore espressività. [...]
I7 è ora alla build 3F40 ed è prossimo al completamento - test, documentazione,
piccoli miglioramenti, curare ciò che è sfuggito, ecc. Molte cose hanno bisogno
di essere sistemate contemporaneamente: il software, su differenti piattaforme,
il sito web, la documentazione, la progettazione, gli esempi (circa 226, i quali
ho passato l'ultima nottata a testare) - una lista più o meno corposa di cose da
fare e da realizzare (Rendere la release per Mac OS X uno Universal Binary, ad
esempio.) Molte di queste cose implicano lo sforzo coordinato di diverse persone
- David Kinder e Andrew Hunter, ad esempio, che hanno dedicato grandi quantità
di tempo al progetto. [...]
Perché blorb? Beh, blorb è stato "ufficialmente riconosciuto" da Inform sin dal
DM4, e penso che molte persone l'abbiano ritenuta una buona idea, ma allo stesso
tempo sembrò una questione accademica - esistevano così pochi blorb da
interpretare. [...] Ho adottato blorb come output di default di I7 per varie
ragioni: (a) se c'è bisogno di una raccoglitore di risorse per IF, è una delle
cose migliori mai progettate; (b) è un formato organizzato e documentato da
qualcuno diverso da me, il che offre varie possibilità di analisi; (c) è
abbastanza flessibile da poter essere utilizzato durante tutto l'arco di vita di
I7, con nuove possibilità offerte da nuove release; (d) fornisce un elemento di
accomunanza tra Z-machine e glulx.
Ma la ragione principale è che vorrei che I7 attirasse nuovi scrittori, gente
che non ha mai provato l'IF, e forse gente che non ha mai neanche giocato.
Vediamo la cosa dal loro punto di vista. Perché un racconto interattivo non
dovrebbe avere una copertina? Perché non dovrebbe essere possibile scrivere
programmi di archiviazione, gallerie web di nuove release, ecc., che facciano
uso di dati bibliografici e immagini di copertina per presentare l'IF come un
mondo vivido, attraente e interessante? Facciamo in modo che l'IF giri anche su
piccoli palmari: non è una scelta esclusiva. Ma rendiamo l'intera esperienza più
ricca e più umana, soprattutto dal punto di vista dei nuovi arrivati.
Graham Nelson

 ricca e più umana, soprattutto dal punto di vista dei nuovi arrivati.
Quoto e riquoto in pieno le ragioni espresse da Graham.
Giovanni

 parte del lavoro preliminare non è perduto.
Resta da vedere come questo discorso si innesti nel nuovo Inform (se si
innesta). E bisognerà anche valutare la questione della localizzazione in
italiano: ho idea che le cose cambieranno parecchio. In meglio, ovviamente.
Almeno spero.... ;-)
PaoloM
--------------------------------
Inviato via 
http://arianna.libero.it/usenet/

> Quoto e riquoto in pieno le ragioni espresse da Graham.
E come posso non essere d'accordo io?
Spero solo che visto che le ha dette il patriarca servano a smuovere un
po' di polvere...  8)
Perdonate il sarcasmo, ma quando ce vo' ce vo'.
Adesso dovro' aspettare due anni per Inform 8 e aspettare un post che
dice: "Perche' un lavoro di IF non dovrebbe avere una colonna sonora e
un intelligente supporto multimediale? In fondo, possono fare in modo
che la IF sia un mondo vivido, attraente e interessante".
Rob

 po' di polvere...  8)
Forse è perché, a differenza di GN, non ti esprimi in maniera 
sufficientemente autorevole. Prova a eliminare le faccine ;-)

rgrassi wrote: > Adesso dovro' aspettare due anni per Inform 8 e aspettare un post che > dice: "Perche' un lavoro di IF non dovrebbe avere una colonna sonora e > un intelligente supporto multimediale? In fondo, possono fare in modo > che la IF sia un mondo vivido, attraente e interessante". Eh, Rob e' sempre "piu' avanti"... Ma spiegami tre cose (serie le prime due, provocativa l'ultima): a parte  il fatto che tutto questo non dipende da Inform 7, 8 o 9, ma semmai  dalle specifiche del formato blorb (ok, nitpicking, lo so), - Pensi che i filmati rendano davvero una IF piu' vivida, attraente e  interessante? - C'e' altro supporto multimediale che desidereresti e che mi sfugge? - Vedo che ci insisti, ma cosa ti manca ancora per la colonna sonora?  Hai il formato migliore possibile. Vuoi per forza il formato mp3? (che  e' peggiore, proprietario e spero (vanamente, lo so) faccia la stessa  fine del formato gif) Paolo Lucchesi email: plucchesi(at)tin(dot)it 

 che la IF sia un mondo vivido, attraente e interessante".
Eh eh! Si beh, a dire il vero mi pare che Graham si sia limitato a parlare
di copertina.... ;-)


 Hai il formato migliore possibile. Vuoi per forza il formato mp3?
No, mi va bene l'OGG Vorbis e che si faccia manutenzione dei tool
seguendo l'evoluzione tecnologica disponibile.
Non mi va bene che Plotkin debba decidere se questa cosa si fa o no.
Rob

>- C'e' altro supporto multimediale che desidereresti e che mi sfugge?
Io vorrei il flash e quel sistema di rendering 3d che una volta era
abbinato al web.
Chissa' che fine ha fatto? :)

 Paolo Lucchesi email: plucchesi(at)tin(dot)it 

 
Rippo la traduzione di Nelson per dare spazio alle mie opinioni.
Dunque, ci sono molte cose che, nella descrizione di Nelson, fanno
rabbrividire un programmatore.
Primo, capire cosa si sta facendo alla versione Cxx partendo da A01 (senza
specificare quante di quelle due cifre sono state utilizzate prima di
passare alla B) è una roba che fa tremare i polsi a chiunque.
Certo, agli strumenti per scrivere AT non si chiede di essere capolavori di
ingegneria informatica (se così fosse, si userebbe python e non inform),
certo è che capire a quel punto CHE STAI SBAGLIANDO IL DESIGN DI BASE DELLA
VM è una cosa bruttina. E spiega perché glux non è stato scritto da Nelson.
Secondo, il fatto che dopo la CXX si ricevano dieci segnalazioni di bug al
giorno da due tester... su un codice talmente piccolo... per diciotto mesi
(facciamo anche nove, dalla CXX alla Jxx)... uhm... come dire... pare che
nonostante alla CXX si sia capito dove si stava sbagliando, non si sia
stati capaci di sistemare il problema alla base.
Terzo, "complimenti" per la scoperta dell'analisi semantica. Se ci sono
voluti venti anni per capire che 5000 o giù di lì righe per distinguere un
verbo (prima parola) da un oggetto (seconda parola) non sono il massimo
dell'eleganza della programmazione, beh... complimenti davvero. Certo, la
parser.M faceva qualcosa di più, resta il fatto che a chiunque ci abbia
messo le mani il primo pensiero che passava per la testa era "ma perché non
rendere il linguaggio un pelino più efficace così da non dover far fare a
questo macina-caffé le spremute di limone?".
E' notevole che Nelson ci sia arrivato adesso... 
Tornerò sull'argomento in seguito,
Giancarlo Niccolai.

 E' notevole che Nelson ci sia arrivato adesso... 
Forse, come tutti, ha avuto anche dell'altro da fare...
</POLEMICA>
HAPPY INFORMING!!
Giovanni

 </POLEMICA>
</Nessuna polemica ecc ecc..>
Giancarlo Niccolai.

 soprattutto se non critico. Se gli errori non sono critici, si correggono
Prima che mi sia cassato inutilmente e indebitamente questo punto: NON
intendo dire che è stato fatto esattamente questo (una build per ogni
errore); era un eufemismo per sottolineare la frequenza quanto meno
*strana* delle build. Mi auguro che, almeno in questo caso, non mi si
prenda in senso letterale.
GN.

 </Nessuna polemica ecc ecc..>
Idem.
Mi piacerebbe che anche altri entrassero nella discussione dicendo cosa 
ne pensano di tutto.
Giovanni


In particolare la sezione 4 (che descrive le risorse "eseguibili" 
incluse nel Blorb) dice questo:
===========================================================
4: Executable Resource Chunks
There should at most one chunk with usage 'Exec'. If present, its number 
must be zero; its content is a Z-code or Glulx game file, and its chunk 
type is 'ZCOD' or 'GLUL'.
[Other executable formats may be added in the future. Some of them might 
support multiple executable chunks; for example, a VM which supports 
concurrent processes. In such a case, chunk zero should contain the code 
to execute first, or at the top level.]
A resource file which contains an executable chunk contains everything 
needed to run the executable. An interpreter can begin interpreting when 
handed such a resource file; it sees that there is an executable chunk, 
loads it, and runs it.
A resource file which does not contain an executable chunk can only be 
used in tandem with an executable file. The interpreter must be handed 
both the resource file and the executable file in order to begin 
interpreting.
If an interpreter is handed inconsistent arguments -- that is, a 
resource file with no executable chunk, or a resource file with an 
executable chunk plus an executable file -- it should complain 
righteously to the user.
================================================
Ciao,
Giovanni

 
Oh, bene ora mi pare che ci siamo ri-tarati ;-)
Giancarlo

 > ne pensano di tutto.
Penso che per come e' stata impostata la cosa si accentuera' ancora di
piu' la radicalizzazione anti Plotkin/Short e chi ci fara' le spese
sara' Inform (che magari sara' anche un gran bel programma, ma se io
fossi anglosassone non avrei dubbi di andare verso Tads3 che ha un
sviluppo piu' "trasparente").
Rob

Tommaso Percivale ha scritto:

Waaaa, ne ho trovato un altro.
Io ho abbandonato inform per Flash :D

ne pensano di tutto.
Emh, scusate se butto lě un parere molto semplice ed ingenuo. Premesso che
anch'io programmo per professione, comunque quello che mi interessa veramente č
che I7 *funzioni*, che funzioni *bene* e che permetta di scrivere buona IF in
modo piů semplice ed agevole, magari aggiungendo un po' di potenza.
Come programma il prof. Nelson e quali protocolli utilizza per farlo, a me
personalmente interessa poco. Saranno affari suoi, no? ;-)
PaoloM

rgrassi wrote: > Penso che per come e' stata impostata la cosa si accentuera' ancora di > piu' la radicalizzazione anti Plotkin/Short  Bah... IMHO questa radicalizzazione in realta' non esiste o comunque non  e' significativa (ovviamente se togliamo dal conto le varie identita' di  Pudlo, che accentrano su di se). In genere Zarf e Emily (e anche altri) sono piu' stimati per quello che  hanno fatto (tra giochi e altro) che detestati per la loro "elitarieta'"  (che e' in gran parte artificiale). > e chi ci fara' le spese > sara' Inform (che magari sara' anche un gran bel programma, ma se io > fossi anglosassone non avrei dubbi di andare verso Tads3 che ha un > sviluppo piu' "trasparente"). Insomma... Non la vedo troppo questa trasparenza. Anzi, gli standard di  T3 li vedo documentati in modo peggiore. IMHO la gente valutera' se il prodotto vale oppure no. Paolo Lucchesi email: plucchesi(at)tin(dot)it 

 IMHO la gente valutera' se il prodotto vale oppure no.
Infatti. La documentazione è il punto debole di TADS. E consideriamo un 
attimo anche i tempi di sviluppo. Quello di TADS 3 va avanti dal 2001 
quindi da più tempo rispetto a Inform 7 e l'ultima release non è ancora 
matura. All'ultima IF Comp c'è stato un solo gioco in T3, 6 in TADS 2 e 
ben 19 in Inform (di cui due in glulx e gli altri zcode). Sarà anche più 
trasparente lo sviluppo ma poi alla fine la maggior parte della gente 
utilizza Inform. Vorrà dire pure qualcosa, no? Piuttosto mi ha sorpreso 
molto vedere ben 5 giochi in Adrift alla IF COMP, quando gli anni 
precedenti avevamo al massimo un gioco in competizione, fatto con questo 
linguaggio.
Ciao
Giovanni

 linguaggio.
 
Da quel che ho capito dalla strenua difesa del Grassi sembra che Adrift sia 
molto più facile da usare e programmare di Inform (e non ho dubbi in 
merito...), quindi avrà attirato una base più consistente di possibili 
autori. 
Inoltre sembra che abbia una comunità molto attiva (la rivisita bimestrale, 
ad esempio).
Oppure è Roberto Grassi che, essendo evil, ha obbligato con la forza degli 
autori ad usare Adrift... 
-- 
Paolo Vece - 
pv...@mclink.it
 - 
http://www.vece.net

 degli autori ad usare Adrift...
Eheheh... >:)
La comunita' di Adrift e' davvero molto attiva.
UN grande numero di giochi viene scritto con questo applicativo (piu'
di Inform, certamente). Alla IFComp vengono presentati pochi giochi
perche' c'e' una sorta di "timore reverenziale" dovuto al fatto che
presentare giochi scritti con applicativi non "mainstream" e' come
votarsi al massacro. Piano piano pero', ADRIFT si sta ritagliando una
sua nicchia e i pasdaran della IF stanno iniziando a ricredersi.
Io tra l'altro, non lo uso neanche piu' ma non mi dispiacerebbe che
venisse utilizzato in Italia. Se qualcuno avesse bisogno posso dare
supporto.
Rob

 utilizza Inform. Vorrà dire pure qualcosa, no? 
A suo tempo (e quando l'argomento TADS vs INFORM salta fuori) dissi senza
mezzi termini che Inform è il linguaggio perfetto per le AT; aggiungo che
anche le librerie di Inform sono molto più "pratiche" di quelle di tads. A
prima vista, le librerie di tads sembrano più seducenti. Un vero modello
object oriented, una vera gerarchia di oggetti, la scatola deriva dal
contenitore e il tavolo e la sedia derivano dal supporto... tutto molto
bello, in teoria.
In pratica, poter dire che il tuo sclibbits, animale a sei zampe dalla testa
piatta, è anche un supporto, non sarà molto OOP, ma è dannatamente
efficace. 
Un proverbio zen:
l'apprendista non vede la via
il praticante segue la via
il maestro non vede la via.
Con tads non puoi passare oltre il livello di praticante (che conosce la via
di una corretta e pulita programmazione, e la segue). Inform è un
linguaggio per maestri zen (che conoscono la via, ma non ne hanno più
bisogno), e anche gli apprendisti scorgono scintille di luce che offre
Inform.
Solo gli eterni praticanti, sedotti dalla via in se', scelgono tads.
GN.