<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">2015-07-18 6:04 GMT+01:00 Giovanni Porcari <span dir="ltr"><<a href="mailto:giovanni.porcari@softwell.it" target="_blank">giovanni.porcari@softwell.it</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
> Il giorno 17/lug/2015, alle ore 23:40, enrico franchi <<a href="mailto:enrico.franchi@gmail.com">enrico.franchi@gmail.com</a>> ha scritto:<br>
<span class="">><br>
><br>
> 2015-07-17 21:56 GMT+01:00 Giovanni Porcari <<a href="mailto:giovanni.porcari@softwell.it">giovanni.porcari@softwell.it</a>>:<br>
> Si… capisco che è bello conoscere molti linguaggi.<br>
> Ma, non per essere pedante, quanto conta il linguaggio nella risoluzione di un problema ?<br>
><br>
> Tanto la domanda chiave nel messaggio iniziale e' sempre questa. Quanto conta? Tantissimo.<br>
><br>
> 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.<br>
><br>
</span>> Questo e' il famoso problema di Blurb (<a href="http://www.paulgraham.com/avg.html" rel="noreferrer" target="_blank">http://www.paulgraham.com/avg.html</a>): se volete leggere poco, leggete solo la sezione chiamata "Blurb Paradox".<br>
<span class="">><br>
> 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.<br>
><br>
> Questo problema in Python lo risolvi con importlib, che ti suca la tua classe sulla base di una stringa tipo<br>
> "project.authentication.kerberos.Plugin"<br>
> 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.<br>
><br>
> 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.<br>
><br>
> 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.<br>
><br>
> 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.<br>
><br>
> 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.<br>
><br>
> 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.<br>
><br>
<br>
<br>
</span>Certo, quello che dici è giustissimo. Ma se noti le tue argomentazioni<br>
noterai che hai dovuto trovare esempi dove la maggior parte degli sviluppatori<br>
non si trova mai. Intendo dire che riuscirò sempre a trovarti esempi e<br>
situazioni che contraddicano una tesi ma ciò non implica a mio modesto avviso<br>
che questo contraddica la tesi stessa.<br>
<br>
Se lasciamo perdere per qualche momento il genere di problemi di cui parlavi<br>
do ve il terabyte è un bruscolino e il petabyte impera, e guardiamo<br>
a quello che tutti i giorni lo sviluppatore medio che frequenta questa lista<br>
fa, io credo fortemente che avere le idee chiare su come strutturare<br>
il proprio lavoro, saper analizzare i problemi, saper trovare gli algoritmi<br>
giusti conti infinitamente di più rispetto al linguaggio che si usa.<br></blockquote><div><br></div><div>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.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Il che non significa affatto che il linguaggio non sia importante in assoluto<br>
ma che se anche conosci il linguaggio migliore del mondo o ne conosci mille,<br>
se in termini di capacità di risoluzione dei problemi sei una pippa il<br>
linguaggio ti farà fare immani troiate anche se lo conosci perfettamente.<br>
<br>
Questa è la tesi che mi dovresti smontare perchè se lo fai, allora sarà<br>
chiaro a tutti che un buon linguaggio trasforma un fesso in genio :D<br></blockquote><div><br></div><div>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.</div><div><br></div><div>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.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Ti rispondo che no, non lo credo affatto. Stai descrivendo una cosa che ho fatto nel 1989<br>
ovvero un dataset formato da record che venivano sempre aggiunti in modo da poter<br>
ricostruire il dato in un qualsiasi istante. Un database (chiamiamolo così) basato<br>
su una versione di basic dove le variabili erano limitate a una lettera oppure una lettera<br>
seguita da una cifra (da A a Z e da A0 a Z9) e la memoria usabile era se ben ricordo<br>
640 Kb.<br></blockquote><div><br></div><div>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.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Quindi non credo affatto che tu sia pazzo ;). Ma se devo farti un piccolo appunto,<br>
credo che le tue capacità e il tipo di esperienza lavorativa ti portino a pensare<br>
sempre molto in grande e questo, pur facendo di te un grandissimo esperto per<br>
questo tipo di problemi, magari ti fa scordare che la realtà è al 99% molto<br>
più terra terra…<br></blockquote><div><br></div><div>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.</div><div> </div></div><div class="gmail_signature"> .<br>..: -enrico-</div>
</div></div>