[Python] Quanto conta il linguaggio ?

[enrico franchi]

2015-07-17 21:56 GMT+01:00 Giovanni Porcari <giovanni.porcari a softwell.it>:

> Si… capisco che è bello conoscere molti linguaggi.
> Ma, non per essere pedante, quanto conta il linguaggio nella risoluzione
> di un problema ?
>

Tanto la domanda chiave nel messaggio iniziale e' sempre questa. Quanto
conta? Tantissimo.

Allora, per intenderci, il linguaggio conta poco se lo usi male o se lo
conosci poco. Per intenderci, se conosci bene Java (per dire) arriverai in
fondo anche ad un progetto in Python. Verosimilmente avrai scritto Java in
Python. Sara' lento come Python, sovra-ingegnerizzato come Java e ti sarai
perso una serie di possibilita' a livello di libreria standard e di
librerie accessorie. Pero', probabilmente, sarai in grado di consegnare.

Questo e' il famoso problema di Blurb (http://www.paulgraham.com/avg.html):
se volete leggere poco, leggete solo la sezione chiamata "Blurb Paradox".

Se il linguaggio lo usi bene, conta tantissimo. Perche' semplicemente certi
linguaggi hanno come costrutti nativi cose che possono essere molto
rilevanti (o meno) per il tuo problema specifico. Che so... facciamo un
esempio concreto per non pontificare. Supponi che la tua applicazione abbia
bisogno di un concetto di plugin. Sempre per semplificare, immaginiamo che
puoi astrarre il tuo plugin come una classe (o come un set di funzioni/API
ben definite) la cui implementazione effettiva viene caricata a runtime
sulla base di un parametro di configurazione.

Questo problema in Python lo risolvi con importlib, che ti suca la tua
classe sulla base di una stringa tipo
"project.authentication.kerberos.Plugin"
ora, e' vero che devi sempre implementarti Plugin, ma e' anche vero che per
il resto tutto il resto te lo da la libreria standard (e il fatto che il
tuo linguaggio e' altamente dinamico). Hai ancora il problema di gestire
gli import path (ovvero il tuo plugin viene separato dalla tua
applicazione, ci vorra' un modo di dire dove sucare i plugin) che potrebbe
essere una seconda stringa (il path) e tre righe di python che rendono
qulla directory visibile a Python. Davvero, hai finito.

Ora, immagina di risolvere la cosa in C++. Intanto devi in qualche modo
astrarre il meccanismo di loading di un .so, poi devi trovare un modo di
gestire i problemi di compatibilita' binaria di C++, poi avrai sempre
problemucci tipo il problema di deallocare/allocare roba sui bordi della
libreria. Il problema e' molto piu' complicato. A seconda di quanto tempo
hai, l'intera feature potrebbe dovere essere soppressa.

Questa per una cosa banale e concreta che tutti masticano. Poi ci sono cose
piu' filosofiche: certi costrutti che semplicemente semplificano la vita
perche' programmi ad un livello piu' alto (o ti danno piu' controllo sul
basso livello). Non tutti i progetti ne hanno bisogno, ma spesso saltano
fuori questo tipo di requirement in modo inaspettato. Ci sono interi
costrutti che ti aprono la mente ad un modo di pensare che semplifica
moltissimo l'architettura e il design.

Poi ci sono limiti intrinseci del linguaggio... per esempio il problema di
Python e' che devi *sempre* spostare a livello di architettura problemi che
vorresti risolvere a livello di design. Ogni qual volta in Python hai un
componente che deve fare sia molto I/O che molta CPU e non puoi isolarlo
completamente (che a sua volta e' una scelta architetturale) devi
introdurre una complicazione achitetturale non indifferente. Devi prendere
code di comunicazione ed esternalizzarle, affrontare il problema di
serializzazione e deserializzazione. La stessa applicazione in Java
potrebbe avere un'architettura simile in termini di macro-componenti, e
tuttavia essere significativamente piu' semplice (si, Redis, per quanto
semplice, e' piu' complicato e piu' costoso di una Bounded Queue e tirare a
mano Celery per spezzare task CPU bound da task I/O bound e' sensibilmente
piu' complicato di avere due thread pool). A volte non importa, a volte e'
un problema.

Ma non solo... certe idee architetturali vengono in modo naturale
dall'avere visto possibilita' a livello di linguaggio che non si
conoscevano. Per esempio... l'idea della lambda architecture, e di lavorare
essenzialmente con un set di dati immutabili, append only e' direttamente
figlio di un modo di programmare che si ha nei linguaggi funzionali, se
puri e' meglio. Se hai visto il mondo funzionale, pensare in termini di
map-reduce e' drammaticamente semplice e l'idea stessa che la mutabilita'
dei database e' il vero problema che rende il CAP theorem uno scoglio
mastodontico viene sempre da li. Non necessariamente in termini che devi
usare un linguaggio funzionale per risolvere il problema (anzi), ma dal
fatto che il tuo cervello si trova a tuo agio in questo mondo.

Supponi che io ti dicessi che il prossimo gestionale non puo' *mai* fare
UPDATE e non puo' fare DELETE come parte delle operazioni normali... come
ti ci trovi? Penseresti che sono pazzo? Forse. E, oggettivamente, avresti
ragione: i gestionali hanno tipicamente un grado di complessita' interna
piuttosto elevata, ma dal punto di vista dello scalare la gestione dei dati
sono relativamente banali (quante volte sei andato sopra una decina di tera
di dati grezzi?). Se dovessi fare un gestionale con una base di dati da 1
petabyte, buona fortuna a fare scalare l'infrastruttura dei dati se vuoi
continuare a supportare UPDATE. Si, certo, di solito i gestionali non fanno
quelle moli di dati.


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