[Python] Js vs QT - was [graphql] interessante alternativa/evoluzione rispetto al REST

[enrico franchi]

2015-10-01 16:22 GMT+01:00 Luca Bacchi <bacchilu a gmail.com>:

> Lavorando molto sul frontend di applicazioni web lavoro in JavaScript
> ormai da anni e sinceramente ne apprezzo alcune caratteristiche.
>
> Il suo modello ad oggetti va capito. Prototype-based è molto diverso da
> Class-based di Python, questo lo sappiamo tutti. Piuttosto che cercare di
> emulare l'ereditarietà classica (nel senso di Class-based, con o senza
> librerie di terze parti) l'approccio corretto è capire come si progetta a
> oggetti in JavaScript (module pattern, closures, ...). Ma anche questa è
> una cosa ovvia che sanno tutti.
>

E non ho nessun problema con questo.


>
> Supporta nativamente molti costrutti della programmazione funzionale:
> closures, First order functions. E questo lo fa anche Python, ma in
> JavaScript si è più portati a utilizzare queste cose, non chiedetemi il
> perchè ma a me pare così: non ho forse mai scritto delle closure in Python;
> in JavaScript praticamente non faccio altro.
>

 nemmeno con questo. Detto questo, in Python uso spesso costrutti
funzionali. Alcuni costrutti di Python sono molto legati a questo. Per
esempio quando si scrive un decoratore spesso e volentieri si usano
closures (e quando non si usano, si usa una classe in modo molto vicino ad
una chiusura -- ma d'altra parte la relazione fra OOP e closures e' roba
ben nota).


> Il modello single-threaded... Non so che dire. Alla fine ci sono le
> Promises, non c'è bisogno di impazzire, è un ambiente single-thread,
> funziona in quel modo... Non fa poi così schifo.
>

Non e' questione di fare schifo o meno. E' un problema di espressivita': ci
sono una serie di problemi che semplicemente non si mappano bene sul
modello single-threaded *dentro* l'applicazione e bisogna necessariamente
spostarli a livello di architettura. Che per carita', si fa... ma non e'
certo ideale.

Nota, io non sono un amante dei thread "alla Java", ma siccome il codice
CPU bound e' piuttosto analogo a codice bloccante e il modello di
Javascript (e di Python) ti aiuta solo con il codice I/O bound -- che rendi
non bloccante --, ma non fa nulla per le cose CPU bound, non liquiderei il
problema.

>
> La community? Non si può ignorare che al momento è la più vasta in
> circolazione. E dovrebbe essere uno degli argomenti più forti, direi.
>

Si, ma i numeri contano poco. Conta la qualita'. Altrimenti si finisce
nell'argomento del milione di mosche e compagnia cantante.
Per me una grossa community di persone non necessariamente skillate e' un
motivo per stare alla larga. Nota, non sto sostenendo che la community di
Javascript sia fatta da persone non skillate: sto solo dicendo che la sola
dimensione della community non e' per me un buon motivo (anzi, potrebbe
essere un motivo a sfavore).

Quando Python era un linguaggio di nicchia, il Python paradox era davvero
qualcosa. Ecco... quelle sono le community che mi interessano.


>
> Anche i Big investono molto su JavaScript e anche questo non va ignorato.
> Non conosco la storia, ma posso immaginare che se Nodejs è nato è
> soprattutto perchè V8 di Google aveva evidentemente raggiunto livelli tali
> di performance che potesse essere interessante utilizzarlo anche al di
> fuori del browser.
>

Certo. E i Big investono tanto anche su Java e .Net. Potenzialmente anche
su PHP, da un certo punto di vista. Ma ancora una volta, non mi interessa.

Se hai un grosso monte di escrementi e hai abbastanza fondi probabilmente
riesci a costruire una casa che sta in piedi. Questo non vuole dire che
trovi particolarmente interessante vivere in una casa fatta di escrementi.


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