[Python] Quanto conta il linguaggio ?

Sab 18 Lug 2015 13:10:31 CEST

2015-07-18 6:04 GMT+01:00 Giovanni Porcari <giovanni.porcari a softwell.it>:

>
> > 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.
>

Secondo me non sono sono stato chiaro. Hai letto petabyte e hai pensato che
io andassi in una certa direzione. Invece io ti stavo solo dicendo che una
certa soluzione apparentemente strana (quella che stavo descrivendo)
sebbene apparentemente complichi molto certi aspetti, in generale
semplifica tantissimo l'architettura, tanto che farla scalare a suddetti
livelli rimane non banale, ma e' incomparabilmente piu' semplice che fare
scalare un sistema basato su update.

>
> 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
>

Ah, beh, ma che tesi e'? Certo che un coglione rimarra' un coglione. Non e'
troppo interessante. Semmai le questioni sono, quanto un linguaggio diverso
insegna un nuovo modo di ragionare ad un programmatore (molto, se il tizio
ha la testa per fare quello che sta facendo, se e' un fesso, e' un fesso) e
quanto piu' potere espressivo (o determinate altre caratteristiche
tecniche) ti permettano di formulare meglio soluzioni a problemi concreti.

In entrambi i casi, io credo che il linguaggio sia molto importante. Odio
ripetermi, ma Graham nel paragrafetto su Blurb la spiega 10 volte meglio di
quello che io sappia fare.

> 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.
>

Certo, non e' nulla di nuovo di per se. Pero' immagina quando qualcuno, su
un problema apparentemente nativamente formulato in termini di update ha
invece detto ad oracle, beh, il vostro cesso non mi interessa: avete speso
tutte le vostre risorse per cercare di fare update funzionante ammodino ma
a me di update non frega nulla: io ho bisogno di un sistema fatto
diversamente (da cui alcuni dei vari NoSQL). Io credo che sarebbe stato
piuttosto interessante vedere la reazione.

> 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…
>

So benissimo che la realta' e' terra terra. Ed e' il motivo per cui tanta
gente alla fine lavora con catorci enarrabili (VB, PHP...), scrive software
penoso ma sperabilmente almeno negli esemplari migliori fa quello che deve
fare etc etc etc. Ma va benissimo: sono consapevole. Questo non toglie che
almeno i piu' promettenti fra quella ciurma potrebbero beneficiare da
qualcosa di meglio. Poi ci si scontra sempre sul fatto che ti costerebbero
di piu' gli sviluppatori, non ci sarabbe l'esperienza per un sacco di
problemi correlati (che so, deploy) che probabilmente in quelle realta'
fare il layer di interoperabilita' li ammazzerebbe e che meta' di quello
che devono fare arriva in pacchetti semi-precostituiti da microsoft. E
quindi, a ognuno il suo.

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