[Python] TIOBE vs PYPL

[Dario Bertini]

Premesso che mi sfugge tutto questo interesse per Pascal... se proprio
volessi scrivere qualcosa con un linguaggio di basso livello (leggi:
compilato nativamente e senza GC) ma che al contrario di C non abbia
così tanti undefined behavior, probabilmente mi affiderei ad Ada la
cui ultima versione dello standard risale proprio all'anno scorso

d'altro canto c'è anche TorChat, il cui autore stava cercando di
riscriverlo da Python in Pascal, uno dei motivi principali sarebbe
farlo girare su mobile (ma questo comunque non escluderebbe tutta la
pletora di linguaggi managed che si possono usare)

2013/12/24 Enrico Bianchi <enrico.bianchi at ymail.com>:
> Da quello che vedo, le goroutine permettono una programmazione parallela
> abbastanza semplice rispetto ad altri modelli. Posto che Pascal ha il
> supporto a OpenMP e OpenCL, puoi sempre derivare una classe da TThread e
> avviare il thread con la procedura start. Tra l'altro, ad occhio, il modello
> di parallelizzazione con le goroutines di Go e` di tipo threading, o
> sbaglio?
>

"""Some people, when confronted with a problem, think, "I know, I'll
use threads," and then two they hav erpoblesms."""

non sono la persona più autorevole a riguardo, e per quanto abbia
sentito certe tesi diverse volte, non sono sicuro di dove venga
spiegata meglio, ma cercando su google, direi che questo paper mostra
chiaramente i problemi nell'esporre i thread come strumento principale
per sfruttare il parallelismo:

http://www.eecs.berkeley.edu/Pubs/TechRpts/2006/EECS-2006-1.pdf

ci sono diverse alternative: message passing (Erlang, Akka actors,
Clojure agents, Go channels etc.), reducers ( http://vimeo.com/6624203
), STM...

in particolare, in Go... usare goroutine e limitarsi a comunicare dati
fra di loro con i canali dovrebbe essere l'approccio più idiomatico,
che difatti permette di evitare problemi tipici del gestire
manualmente i thread


-- 
xmpp: berdario at gmail.com
bitmessage: BM-2cTYXfGiSTsnx3righ6aHcJSWe4MV17jDP
gpg fingerprint: 3F8D53518012716C4EEF7DF67B498306B3BF75A0 (used just
for signing commits)