<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">2015-07-17 21:56 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:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div id=":25u" class="" style="overflow:hidden">Si… capisco che è bello conoscere molti linguaggi.<br>
Ma, non per essere pedante, quanto conta il linguaggio nella risoluzione di un problema ?<br></div></blockquote></div><br>Tanto la domanda chiave nel messaggio iniziale e' sempre questa. Quanto conta? Tantissimo.</div><div class="gmail_extra"><br></div><div class="gmail_extra">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.</div><div class="gmail_extra"><br></div><div class="gmail_extra">Questo e' il famoso problema di Blurb (<a href="http://www.paulgraham.com/avg.html">http://www.paulgraham.com/avg.html</a>): se volete leggere poco, leggete solo la sezione chiamata "Blurb Paradox".</div><div class="gmail_extra"><br></div><div class="gmail_extra">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. </div><div class="gmail_extra"><br></div><div class="gmail_extra">Questo problema in Python lo risolvi con importlib, che ti suca la tua classe sulla base di una stringa tipo</div><div class="gmail_extra">"project.authentication.kerberos.Plugin"</div><div class="gmail_extra">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. </div><div class="gmail_extra"><br></div><div class="gmail_extra">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. </div><div class="gmail_extra"><br></div><div class="gmail_extra">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.</div><div class="gmail_extra"><br></div><div class="gmail_extra">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.</div><div class="gmail_extra"><br></div><div class="gmail_extra">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.</div><div class="gmail_extra"><br></div><div class="gmail_extra">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.</div><div class="gmail_extra"><br clear="all"><div><br></div>-- <br><div class="gmail_signature"> .<br>..: -enrico-</div>
</div></div>