Newsgroup: it.comp.os.dibattiti
Titolo: [OT] The Next Mainstream Programming Language:

http://www.st.cs.uni-sb.de/edu/seminare/2005/advanced-fp/docs/sweeny.pdf
The Next Mainstream
Programming Language:
A Game Developer's Perspective
Tim Sweeney
Epic Games
Ovvero ciò che gli sviluppatori della Epic Games vorrebbero dal
prossimo linguaggio di programmazione mainstream.
Raffaele

 prossimo linguaggio di programmazione mainstream.
Vediamo:
- quando parla di produttività basterebbe un linguaggio meglio
ingegnerizzato e con qualche costrutto sintattico in più (D?)
- quando parla della modularità in pratica chiede un linguaggio con le
classi aperte, a-la-Ruby
- riguardo alla reliability vorrebbe un compilatore più smart
(basterebbe un linguaggio funzionale con type system "forte" ? Haskell?
Citato da lui stesso...)
- bello il commento nella slide sugli overflow degli interi e il C# "In
the future, can we get integers right? " :D
- quando parla di concorrenza dice quello che io sostengo e cioè che la
concorrenza "shared state" non è il modello più sensato (ma ambienti
come Java e C# purtroppo offrono poche alternative, se non nessuna). Un
modello come quello di Erlang o l'STM di Haskell potrebbe essere la
risposta?
- interessante che tenga in considerazione la garbage collection
- gli farei un monumento per questa frase "The Java/C# "exceptions
everywhere" model should be wholly abandoned " :-)
- sintatticamente sembra più vicino alla famiglia ML :-)
Belle slide, mi domando come mai con il budget di soldi che hanno non se
lo scrivano il linguaggio magari in collaborazione con le altre case di
videogiochi e poi lo "impongano" dall'alto.
-- 
Lawrence - 
http://www.oluyede.org/blog
http://www.neropercaso.it
"Nothing is more dangerous than an idea
if it's the only one you have" - E. A. Chartier

 videogiochi e poi lo "impongano" dall'alto.
Io mi chiedevo come mai con il budget che hanno non facevano meglio le
slides! :)
Comunque, penso che sia perchè non è esattamente il loro mestiere.
Loro usano linguaggi, non li producono. Inoltre, non è detto che
questa loro opinione sia sentita anche da altre software houses.
Quel che è certo è che non è semplice mettere daccordo aziende
concorrenti nello sviluppare uno strumento che porterebbe benefici a
tutti si, ma in misura non necessariamente paritaria. Non è molto
comune questo genere di comportamento (anche se non del tutto assente,
si veda linux, eclipse e progetti simili).
Sarebbe comunque bello che le software house di videogiochi (ma non
solo quelle) collaborassero per avere strumenti comuni ed
all'avanguardia, e basassero la competizione solo sui contenuti (ovvero
tutto ciò che ha a che fare con la "creatività": level design,
storia, meccaniche di gioco, etc.)
Raffaele

 Comunque, penso che sia perchè non è esattamente il loro mestiere.
Certo, in fondo era una provocazione. Cosa dici dei vari punti che ho
elencato?


 elencato?
Vediamo:
- quando parla di produttività basterebbe un linguaggio meglio
ingegnerizzato e con qualche costrutto sintattico in più (D?)
Dipende dai costi in performance. La slide dice "Will gladly sacrifice
10% of our performance
for 10% higher productivity". Non basta che il linguaggio abbia quelle
features: deve anche essere sufficientemente performante. Per dire,
quanto è performante D rispetto al C++?
- quando parla della modularità in pratica chiede un linguaggio con le
classi aperte, a-la-Ruby
Il concetto di "classi aperte" non mi è ancora chiaro, gli ho dato
solo un'occhiata di sfuggita. Mi pare d'aver capito che è possibile
modificare qualsiasi classe, anche quelle del core, giusto?
L'uso delle classi aperte imho cozza però con il punto sulla
'reliability'. Modificare a runtime il comportamento di una classe apre
le porte ad una serie sconfinata di errori runtime.
Quello che mi pare di capire è che vogliono un sistema più efficace
di ereditarietà.
- riguardo alla reliability vorrebbe un compilatore più smart
(basterebbe un linguaggio funzionale con type system "forte" ? Haskell?
Citato da lui stesso...)
Cito: "50% of the bugs in Unreal can be traced to these problems!",
giusto per tenere a mente il punto della situazione: il 50% dei bachi
di unreal era riconducibile ad errori di runtime non individuati dal
compilatore.
Haskell non lo conosco, ma da quel che leggo ciò che vogliono loro è
un linguaggio che permetta
a) un linguaggio che per design impedisca alcune tipologie di errore
b) un linguaggio che fornisca al compilatore informazioni sufficienti
ad individuare bachi legati all'interazione tra classi
c) un copilatore "smart" in grado di individuare bachi che potrebbero
presentarsi a runtime.
- quando parla di concorrenza dice quello che io sostengo e cioè che
la
concorrenza "shared state" non è il modello più sensato (ma ambienti
come Java e C# purtroppo offrono poche alternative, se non nessuna). Un
modello come quello di Erlang o l'STM di Haskell potrebbe essere la
risposta?
passo: sulla concorrenzialità non sono affatto ferrato.
- interessante che tenga in considerazione la garbage collection
Mi sa che pure gli sviluppatori di videogiochi si son rotti le *beeep*
di correre dietro ai malloc ed ai free!!
- gli farei un monumento per questa frase "The Java/C# "exceptions
everywhere" model should be wholly abandoned " :-)
tieni in considerazione anche la frase seguente: "All dereference and
array accesses must be statically verifyable, rather than causing
sequenced exceptions".
Il concetto di individuare un maggior numero di possibili failures a
compile time rende gran parte delle eccezioni per esempio di java del
tutto inutili, rendendo di conseguenza meno significativo il fatto di
avere eccezioni runtime per ogni foglia che si muove.
- sintatticamente sembra più vicino alla famiglia ML :-)
Quanto ad haskell, mi pare che lo escluda come scelta:
"Must not scare away mainstream programmers."
"Haskell family: Quite scary :-)"
Why Haskell is Not My Favorite
Programming Language
§ The syntax is ... scary
§ Lazy evaluation is a costly default
- But eager evaluation is too limiting
- Lenient evaluation would be an interesting default
§ Lists are the syntactically preferred
sequence type
- In the absence of lazy evaluation, arrays seem
preferable
Why Haskell is Not My Favorite
Programming Language
§ Type inference doesn't scale
- To large hierarchies of open-world
modules
- To type system extensions
- To system-wide error propagation
Insomma, non esiste un linguaggio che abbia _tutte_ le feature
richieste. Sarebbe bello che qualcuno magari esterno alla Epic ed alle
altre software houses, magari in collaborazione con i progetti di
videogiochi opensource esistenti, e magari non solo ai giochi, gettasse
il sasso per una collaborazione su larga scala per lo sviluppo di un
nuovo linguaggio che prenda in considerazione il punto di vista di
tutti gli interessati, e porti ad un linguaggio standardizzato, con
un'ampia base di sviluppatori, e che abbia la collaborazione di grandi
nomi come appunto Epic Games, ID software, electronic arts e compagnia
bella.
Ovviamente sperare in uno sforzo congiunto per lo sviluppo di engine e
framework comuni è impensabili, ma se ci si ferma ad un linguaggio di
programmazione mi pare più fattibile. O no?
Raffaele
Raffaele

 programmazione mi pare più fattibile. O no?
Direi di no, la storia dei linguaggi insegna. E` molto più probabile che
possano fare un engine che mette d'accordo tutti (ma che non faranno mai
per ovvi motivi) piuttosto che un linguaggio che metta d'accordo tutti.


 per ovvi motivi) piuttosto che un linguaggio che metta d'accordo tutti.
Beh, potrebbero quantomeno arrivare ad un linguaggio che renda tutti
egualmente scontenti! :)
Raffaele

 trame migliori -.-
Beh li è un problema di tempi e creatività oltre che al mero conio.
Comunque... può darsi


 Comunque... può darsi
Eh, questo idealismo serpeggiante... :)
Raffaele

 presentarsi a runtime.
ada? :-)

 certo come avere un GC sotto.
Ok, ti invito a dimostrare con un esempio quello che hai appena
affermato.
Ciao.
-- 
BSD is for UNIX lovers -- linux is for Windows haters.

 ada? :-)
PL/SQL, deployato su DB Oracle 10g, e non se ne parla più! XD haha!
Raffaele


no no, aspetta.... ci ho messo la faccina, però il posto voleva essere
semiserio. Da quello (poco) che so io ada ha i controlli citati.

 semiserio. Da quello (poco) che so io ada ha i controlli citati.
PL/SQL deriva da ADA, e mi rifiuto di credere che un qualsivoglia game
developer sarebbe felice di programmare i propri giochi in ADA...
"Avere alcune delle feature di ADA" nel linguaggio che usa ci può
stare. Ma _usare_ ADA no...
Raffaele

 
Anche ci si mettessero di impegno, continueremmo ad
avere guerre di religione tra chi considera il nuovo
linguaggio il Santo Graal della Programmazione e chi lo
considera una schifezza, un incubo, il frutto del demonio,
l'Anticristo stesso... anzi, un linguaggio in più, una
guerra di religione in più :-)
Fortuna per me che sono pigro, che, forse per gestire
progetti e programmi "legacy", i laboratori di Robotica
sono rassicurantemente stabili nella scelta dei linguaggi
prediletti, con la stragrande maggioranza che preferisce
C e C++ e pochi "eletti"(? :-) ) che procurano rare gioie
accademiche ai prof. più nel ramo AI approfondendo magari
il Prolog :-D ...non io, sono di una pigrizia vergognosa
e con capacità di concentrazione troppo selettiva e dipendente
dai miei gusti e nei corsi mi hanno dato una prima impressione
di Prolog e Lisp abbastanza spaventosa da farmi scappare a gambe
levate!
C e C++ non li ritengo perfetti, ma almeno mi rassicurano
che lo sforzo per impararli mi viene ripagato da versatilità
e ampie e numerose possibilità d'uso... d'altra parte i linguaggi
in sé come materia di studio non sono più da tempo centrali al mio
indirizzo, ma ormai semplici strumenti...
Alberto
-- 
rimuovere/remove         "Calm yourself!  Man who argue with cow
WLATOPA                      on wall is like plane without wings--
per rispondere/to reply    very soon get nowhere." (Peter Sellers)

 affermato.
Non c'è molto da dimostrare. I GC esistono proprio per permettere al
programmatore di dimenticarsi (o minimizzare) la gestione della memoria.
In Python è cosi, il GC è piuttosto efficiente. Dalla 2.5 hanno anche
introdotto un costrutto per simulare il RAII, in modo tale da potersi
avvantaggiare anche di quell'approccio.
ps. tieni conto che non sto facendo comparazioni. Ho detto che son due
cose differenti.
Se proprio ci tieni dimostrami che il RAII è sempre meglio del GC ma ti
avviso che non mi interessa affatto.


 said:

Se ne parla da molto tempo soprattutto al siggraph, ma per ora le 
accoppiate di linguaggi C, C++, Scripting non battono nessuno. C'era 
chi proponeva anche prolog, haskell, eiffel, ma alla fine nessuno ha 
vinto.
-- 
Sensei <senseiwa@Apple's mail>
Research (n.): a discovery already published by a chinese guy one month
               before you, copying a russian who did it in the 60s.

 vinto.
sed s/battono/'sono battute da'/


 avviso che non mi interessa affatto.
A quanto pare ha fatto un'affermazione senza comprenderne neppure il
Significato ed ora non sei in grado di portare esempi a suo supporto.
Io ti posso sia spiegare a parole che portare esempi sul perché
l'approccio RAII sia meglio del GC, ma se non ti interessa non vedo
perché perdere tempo. Devo dire che ho sempre avuto una buona
considerazione di te, ma quest'ultima tua affermazione la fa diminuire
considerevolmente... 


 indirizzo, ma ormai semplici strumenti...
Capisco.


 considerevolmente... 
Non so che dirti HPL. Anche il mio docente di C++ fa questo genere di
considerazioni sulla superiorità del RAII rispetto al GC. Posso in utta
libertà che preferisco i GC? Se non ti va bene non so che dire.


 
Be' per fare la fortuna di un linguaggio si deve accontentare
anche la maggioranza di utenti che usano i linguaggi (e anche
la matematica, con scorno e orrore dei matematici :-) ) come
un muratore usa la cazzuola :-)


 di confondere le idee?
È che mi sfugge il concetto di inizializzazione in-order o out-of-order.
Probabilmente so di cosa parli ma non uso la stessa terminologia.


 
Allora siamo in due, perché è il poco che ho creduto di
capire dalle slide sulla proposta di nuovo linguaggio
alle pagine 36-37, 55, 66.
Ah, prima usa "initialization", poi "evaluation",
immagino ora, rileggendo, che sottointenda
sospensione della valutazione di un'espressione in
attesa che alcune sue variabili siano inizializzate...
...non so perché, ma ho la sensazione che possa
generare ambiguità e mi sembra, dalle pagine 55 e 66
che lo pensi anche Sweeney.
Oserei però insinuare un dubbio: se per evitare
ambiguità è meglio specificare in quali casi usare
la lazy evaluation, il che implicherà scrivere del
codice apposito, non si farebbe prima a rimettere
in ordine nel codice le inizializzazioni delle
variabili prima del loro uso?


 libertà che preferisco i GC? Se non ti va bene non so che dire.
Per me puoi preferire quello che vuoi, d'altra parte di persone che
preferiscono non essere padrone della propria vita è pieno il mondo...


 preferiscono non essere padrone della propria vita è pieno il mondo...
Per caso dalla tua auto hai rimosso l'ABS in modo da avere il completo
controllo sulla frenata?
Raffaele

 preferiscono non essere padrone della propria vita è pieno il mondo...
Mio dio che analogia del cazzo.


 Mio dio che analogia del cazzo.
Direi che sono stato frainteso, infatti non era un'analogia.


 controllo sulla frenata?
La tua analogia č decisamente sbagliata, per vari motivi.
Prima di tutto č evidente che non sia "meccanicamente" sicuro fare
un'operazione del genere, poi io non ho mai parlato di togliere il GC da
Java, ma di scegliere un linguaggio che prevedesse un approccio diverso;
quindi, al massimo, avresti potuto chiedermi se ho preferito una
macchina senza ABS (ma senza avercelo dalla nascita, non dopo averlo
rimosso) ad una con ABS (ed in effetti la mia risposta sarebbe stata sě,
finche ho potuto ho preferito auto senza ABS).
Ma sarebbe comunque stata ancora sbagliata. Questo perché le persone che 
guidano un'auto e quelle che usano un linguaggio di programmazione hanno 
due approcci completamente diversi (o meglio, salvo il caso di cui
sotto, dovrebbero) al "mezzo".
Quindi, per fare un'analogia piů corretta avresti dovuto chiedermi se un
pilota professionista preferisce un'auto con l'ABS o senza, perň non
avrei saputo risponderti...


 pilota professionista preferisce un'auto con l'ABS o senza
Anzi, neppure così sarebbe stata corretta. La versione più corretta
sarebbe:
un pilota professionista preferisce un'auto con l'ABS o con un sistema
più flessibile, che offre più funzionalità, che può essere, a scelta, 
disattivabile e che è solo un po' più complesso da usare?


 avrei saputo risponderti...
No, questo non è più corretto. Un pilota professionista è un caso
molto particolare, perchè richiede prestazioni estreme. Del tipo che
se preme il freno questo deve frenare SUBITO, e non in maniera
controllata e dilazionata, per dire.
Ma questo è appunto un utilizzo "non-standard" dell'auto.
Allo stesso modo, un programmatore in media non ha necessità di avere
queste prestazioni estreme. Nel caso specifico (si parlava di engine
grafici) certo, ma in una pletora di altre casistiche no.
Per fare un esempio a caso, mi importa poco che su un server web con
10gb di ram la memoria occupata da un oggetto venga liberata
esattamente nel momento in cui io lo dereferenzio. Mi interessa di più
non dovermi preoccupare di implementare il meccanismo che ci sta
dietro.
Tanto per cambiare, qui si applica come sempre il concetto : usa lo
stromento giusto per il lavoro che stai facendo.
Questo non significa non voler essere padroni della propria vita, ma
semplicemente delegare a qualcosa di automatico un aspetto della vita
della quale non interessa poi granchè.
Per fare un altro esempio forse un pò rozzo, io ho la domiciliazione
della bolletta del telefono. Questo non significa che rinuncio ad una
libertà, ma solo che mi libero del fastidio di dover andare di persona
a pagare la bolletta. Poi se viene pagata un giorno prima, od un giorno
dopo, mi è piuttosto indifferente, così come è remota la
possibilità che io finisca le "risorse" (conto in rosso). In compenso
mi evito il rischio di "dimenticarmi una bolletta" (ovvero di
dimenticarmi di liberare la memoria usata da un oggetto).
Raffaele
PS. Scusate la scrittura un pò nervosa mo oggi ho, come diciamo dalle
nostre parti, il cristo girato.
PPS. No, non sono problemi con linguaggi di programmazione, anche se mi
piacerebbe poter leggere i log di sistema di certi individui che mi
vivono attorno...

 Direi che sono stato frainteso, infatti non era un'analogia.
Allora spiegati, ti ascolto.


 dimenticarmi di liberare la memoria usata da un oggetto).
Bene, e per adattare RAII al tuo esempio io ho un sistema che mi paga
qualunque cosa io *debba* pagare (non solo le bollette domiciliabili) in
automatico (sempre che io l'abbia delegato a farlo), ma che mi permette, 
se ne ho la necessità, di pagare personalmente. 


 Allora spiegati, ti ascolto.
Era semplicemente una constatazione: dato che il mondo è pieno di
persone che preferiscono lasciar decidere gli altri sulla loro propria
vita (e, sinceramente, finché ciò non va ad intralciare le mie scelte 
-cosa che purtroppo nella vita spesso non è- sono liberissimi di farlo)
è normale che anche nella programmazione ci sia chi preferisce far
scegliere altri. 
Non intendevo dire, come penso tu abbia capito, che chi in ambito 
informatico preferisce non scegliere è uno che preferisce non scegliere 
della sua vita; sono due cose molto distinte e di importanza estremamente 
diversa.


 diversa.
meno male, comunque spero di non averci letto un'accezione negativa
perché non vedo cosa ci sia di male a scegliere di usare un GC. Non mi
sento "sporco" perché uso un gestore della memoria :-)
