[Python] TIOBE vs PYPL

[enrico franchi]

2013/12/26 Enrico Bianchi <enrico.bianchi a ymail.com>

> On 12/25/2013 04:22 PM, enrico franchi wrote:
>
>  3. Go e' un linguaggio *pensato* per la concorrenza... che lo rende 'un
>> po' diverso' da Pascal. E no, le goroutines sono una bestia molto diversa
>> da un TThread.
>>
>

>  Quindi, la risposta alla mia domanda iniziale e` che Go e` pensato per un
> ambito specifico, mentre (Object) Pascal (ma anche Python, C e un'altra
> serie di linguaggi) sono pensati per un ambito generico. Il che li rende
> due linguaggi di nicchia, sia per diffusione (Delphi e FreePascal sono meno
> diffusi di Python, ad esempio), sia per ambito (L'ambito di Go e` la
> programmazione concorrente). Per il resto del discorso, la risposta si
> riassume in:
>


Guarda che nel 2013 dire che e' "pensato per la concorrenza", vuole dire
che e' progettato per le esigenze specifiche condivise da buona parte dei
progetti software. Cioe' ormai *tutto* e' concorrente: tutte le volte che
vuoi avere a che fare con internet, quello devi fare e' fare tanto I/O
remoto. E qui aiuta. Tutte le volte che vuoi scrivere un servizio
accessibile dalla rete, tutto questo diventa ancora piu' fondamentale.

Il problema della concorrenza e' uno dei piu' sentiti e critici nel mondo
moderno. Tutte le piattaforme sperimentano soluzioni per questo problema.
Perche' nel 2013 e' qualcosa in cui ti imbatti continuamente, piu' volte,
per qualunque cosa.

Quindi e' abbastanza surreale pensare di liquidare "Go e' pensato per un
ambito specifico", nello stesso modo in cui si direbbe "R e' pensato per un
ambito specifico". Semplicemente Go ti mette a disposizione una buona
primitiva, mentre, per dire, Java te ne mette a disposizione una cattiva.

 - Si, (Object) Pascal e` supportato, sia a livello di aziende che ti
> offrono assistenza, sia a livello di
>    sviluppatori che ad oggi ti mettono a disposizione gli strumenti che ti
> permettono di usarlo anche in
>    ambienti mission critical, sia a livello di compilatori disponibili.
>




>  - La "roba moderna" la fai tranquillamente con (Object) Pascal, sia
> perche` sono rilasciate le librerie


Ma sei *sicuro*? Solo per fare una cosa spannometrica... guardiamo GitHub.
Su GitHub ci sono 11 mila e rotti progetti in Go. Per confronto ce ne sono
168 in Pascal.
Non che sia autoritativo, eh, ma e' qualcosa che mi fa sospettare una
leggera differenza in termini di facilita' di trovare i progetti.

Tipo... gli altri 11.000 progetti in Pascal, dove stanno? Tutti sparsi per
la rete?


> , sia
>    perche` puoi  linkare direttamente librerie C. Quindi, se proprio non
> c'e` la libreria che si cerca, il
>    problema lo si aggira facilmente.
>

Cioe' devo passare per il binding in C di una libreria per chiacchierare
con Twitter [sostituisci Twitter con una qualunque web app moderna]? Siamo
sullo stesso pianeta? Cioe', ok mi va anche bene passarci (forse), o meglio
vorrei che qualcun altro ci fosse  passato da tempo; se voglio fare X, mi
piace trovare X-1 fatto.

Mi spiego, mi stai suggerendo di usare Pascal per chiamare librerie in C? E
allora perche' non usare C?
Non e' che Pascal mi dia questa soverchiante astrazione sopra C da
facilitarmi la vita. Viceversa, in Go, chiamare C e' parecchio facile
(imbarazzantemente facile, aggiungo).

Tra l'altro Go e' un linguaggio che ha fatto sua la lezione di cosine come
Python e Ruby. Tante cose che oggi diamo per scontate, in Go le troviamo.
In Pascal, purtroppo, no.


> - Fare programmazione concorrente con (Object) Pascal si puo`, solo che ti
> ritroveresti gli stessi problemi
>   che avresti (e.g.) con C, in quanto sono due linguaggi generici. E
> questo senza considerare Concurrent
>   Pascal
>
>
Veramente stai suggerendo Concurrent Pascal? Cioe' come alternativa a Go tu
stai sostituendo un linguaggio in cui hanno tolto:
1. puntatori
2. la possibilita' di passare funzioni come parametri (eeh?) [quindi in
pratica tutte le higher order functions]
3. il concetto di file?

e che basa il suo modello di concorrenza sul concetto di, udite udite,
*MONITOR* (che nel 1975 magari sembrava una splendida idea, 20 anni di Java
ci hanno insegnato che non lo e')

Aggiungo, questa e' la home page:
http://faculty.cs.wwu.edu/meehan/ProgramExample/CPS/CpsSamps.htm

Parliamo di un linguaggio del 1975 che non ha avuto praticamente impatto
sull'accademia [ovvero 42 citazioni in 38 anni, scherziamo?]. L'impatto
sull'industria e' non pervenuto... l'autore apparentemente ha smesso di
pubblicarci dal 2001.

Cioe', tu vorresti suggerire di deployare un sistema sviluppato in
Concurrent Pascal *sul serio*?
Vorresti paragonare questo a Go? Che scusa, ma quei due o tre progetti di
scala *immensa* visto che se lo usa big G ha dimostrato di saperli reggere.
Non parliamo delle migliaia di progetti di scala grossa o normale che
vengono deployati in Go.



> Infine, dire che le goroutines non sono thread quando praticamente tutto
> il mondo dice che lo sono ma con qualche differenza e` come dire che le
> patate a pasta viola non sono patate


Quello che dovresti chiederti, e' se sai quali sono le differenze. Perche'
queste "piccole" differenze, cambiano completamente il modo in cui
concepisci, strutturi, progetti e scrivi il codice.

Cioe', tipo che quello che fai con l'uno, con l'altro non riesci a fare...
a meno di implementarti a mano quello che il primo ti offre gratis.

Cioe' tecnicamente le goroutine sono threads se e solo se intendi thread
nel senso completamente piu' vago del termine. Se vuoi usare un termine
piu' specifico, assomigliano molto di piu' alle fibre, o se preferisci, ai
processi di Erlang (anche qui... quelli di Erlang li chiamano processi, ma
non e' che siano molto parenti dei processi di un sistema operativo,
sebbene abbiano lo stesso nome).

-- 
.
..: -enrico-
-------------- parte successiva --------------
Un allegato HTML è stato rimosso...
URL: <http://lists.python.it/pipermail/python/attachments/20131226/0ed4bc00/attachment.html>