> Il giorno 17/lug/2015, alle ore 23:40, enrico franchi > <enrico.fran...@gmail.com> ha scritto: > > > 2015-07-17 21:56 GMT+01:00 Giovanni Porcari <giovanni.porc...@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 _______________________________________________ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
