[Python] Quanto conta il linguaggio ?

Sab 18 Lug 2015 07:04:01 CEST

> Il giorno 17/lug/2015, alle ore 23:40, enrico franchi <enrico.franchi a gmail.com> ha scritto:
> 
> 
> 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.
> 

Certo, quello che dici è giustissimo. Ma se noti le tue argomentazioni
noterai che hai dovuto trovare esempi dove la maggior parte degli sviluppatori
non si trova mai. Intendo dire che riuscirò sempre a trovarti esempi e 
situazioni che contraddicano una tesi ma ciò non implica a mio modesto avviso
che questo contraddica la tesi stessa.

Se lasciamo perdere per qualche momento il genere di problemi di cui parlavi
do ve il terabyte è un bruscolino e il petabyte impera, e guardiamo
a quello che tutti i giorni lo sviluppatore medio che frequenta questa lista
fa, io credo fortemente che avere le idee chiare su come strutturare
il proprio lavoro, saper analizzare i problemi, saper trovare gli algoritmi
giusti conti infinitamente di più rispetto al linguaggio che si usa.

Il che non significa affatto che il linguaggio non sia importante in assoluto
ma che se anche conosci il linguaggio migliore del mondo o ne conosci mille,
se in termini di capacità di risoluzione dei problemi sei una pippa il
linguaggio ti farà fare immani troiate anche se lo conosci perfettamente.

Questa è la tesi che mi dovresti smontare perchè se lo fai, allora sarà
chiaro a tutti che un buon linguaggio trasforma un fesso in genio :D

So benissimo che è colpa mia e che mi sono spiegato male ma il mio 
messaggio verteva sul fatto che un buon paio di sci non fa lo sciatore,
un’ottima motocicletta non fa un Valentino Rossi e via dicendo.

Quando scrivi "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?”

Ti rispondo che no, non lo credo affatto. Stai descrivendo una cosa che ho fatto nel 1989
ovvero un dataset formato da record che venivano sempre aggiunti in modo da poter 
ricostruire il dato in un qualsiasi istante. Un database (chiamiamolo così) basato
su una versione di basic dove le variabili erano limitate a una lettera oppure una lettera
seguita da una cifra (da A a Z e da A0 a Z9) e la memoria usabile era se ben ricordo
640 Kb. 

Ora non avevo certo potuto implementare splendidi algoritmi o consentire al mio cliente
di gestire petabyte ma il succo del problema era : scrivo di seguito delle informazioni
con un riferimento temporale e, a richiesta, ricostruisco la situazione all’istante ’n’.
Però ti posso dire che avendo grossi limiti di memoria disco dovevo anche evitare
le duplicazioni e sostituire tutti i valori inseriti con dei codici numerici in modo
da contenere le dimensioni del dataset. Alla fine il cliente è stato contento
e il sistema è stato operativo fino alla fine degli anni 90.

Quindi non credo affatto che tu sia pazzo ;). Ma se devo farti un piccolo appunto,
credo che le tue capacità e il tipo di esperienza lavorativa ti portino a pensare
sempre molto in grande e questo, pur facendo di te un grandissimo esperto per
questo tipo di problemi, magari ti fa scordare che la realtà è al 99% molto
più terra terra…

Ciao

G