The most powerfull programming language

Paul Graham, in un post del 2001 che ho riletto recentemente, parla di potenza dei linguaggi di programmazione.
Beating the Average è il titolo del post e l'intero articolo, pur a distanza di anni e pur con i necessari distinguo, è tutt'ora molto interessante ed istruttivo
Vi invito quindi a leggerlo, con un occhio in particolare al "Blub Paradox"

Mi ha divertito e fatto riflettere in particolare una piccola nota finale, che riporto:

All languages are equally powerful in the sense of being Turing equivalent, but that's not the sense of the word programmers care about. (No one wants to program a Turing machine.) The kind of power programmers care about may not be formally definable, but one way to explain it would be to say that it refers to features you could only get in the less powerful language by writing an interpreter for the more powerful language in it. If language A has an operator for removing spaces from strings and language B doesn't, that probably doesn't make A more powerful, because you can probably write a subroutine to do it in B. But if A supports, say, recursion, and B doesn't, that's not likely to be something you can fix by writing library functions.

Beh, mi sembra un criterio interessante ed efficace per misurare la "potenza" di un linguaggio

... ovviamente c'è un prior art: la "Greenspun Tenth Rule"

Che conferma, se ancora ce ne fosse bisogno, che l'intero post è fortemente lisp-biased :-)

Mi propongo (e, se volete, propongo anche a voi) un piccolo "esercizio".
Nel mio linguaggio preferito quali sono le funzionalità per cui è necessario, o sarebbe necessario, un piccolo sotto interprete?

Il primo caso che viene in mente sono i template in C++.
Questa apparentemente piccola funzionalità ha introdotto un intera nuova branca di programmazione in C++: il template metaprogramming.
E questo ha radicalmente cambiato la storia e l'evoluzione del C++.

Per inciso, l'interprete dei template in C++ implementa sostanzialmente un linguaggio funzionale.
Infatti per capirne bene la logica ed entrare nella mentalità consigliano di partire studiando Haskell.
... beh, non siamo finiti poi tanto lontano dalla "decima regola", giusto? ;-)

Virtuosismo ed elementarità

Nel loro sorprendente libro “The 5 Elements of Effective Thinking”  gli autori Burger e Starbird raccontano di quando osservarono Tony Plog, un virtuoso della tromba di fama internazione, condurre una classe di eccellenza per trombettisti. Gli studenti suonavano inizialmente frasi musicali molto complesse, le quali venivano eseguite perfettamente. Ma successivamente agli studenti venne chiesto di suonare note molto semplici e di base.
Quando eseguivano tali note, queste sembravano infantili rispetto alla complessità delle frasi musicali eseguite in precedenza.
Una volta che gli studenti finirono di suonare, l'insegnante suonò le stesse identiche note, ma quando le suonò lui, le note sembravano tutt'altro che infantili.
La differenza era impressionante.
Tony spiego che padroneggiare l'esecuzione di semplici note permette al musicista di suonare pezzi complessi con un maggiore controllo dell'esecuzione.
La lezione era chiara - per costruire il vero virtuosismo uno deve focalizzarsi sul dominare semplici idee elementari.
Mi pare che tutto questo non valga solo per la musica...

ho veramente bisogno del multi-master?

sono appena stati pubblicati i video del'ultimo pycon

e c'è anche quello di Gabriele Bartolini

vorrei concentrarmi su un argomento che emerge nei primi minuti

un partecipante riferisce che avrebbe lasciato Postgres per passare ad un db con multi-master

risposta di Gabriele: "...ma ti serve davvero il multi-master"?

ecco, mi sono fatto la stessa domanda...

a me pare che in effetti il multi-master sia auspicato come panacea di tutti i mali senza rendersi conto che ci sarà un trade off da accettare, sempre e comunque

in fondo il CAP theorem è sempre lì a ricordarcelo: un corollario del CAP theorem è che in caso di partitioning o tieni la consistency o tieni l'availability, non c'è scampo

in proposito vi segnalo questa intervista all'inventore del CAP theorem, Eric Brewer, che ora è un guru di google
https://medium.com/s-c-a-l-e/google-systems-guru-explains-why-containers-are-the-future-of-computing-87922af2cf95

parla di container e di orchestration, ma non solo

interessante, per esempio, questa cosa che dice:

That bothered me for a little while until I eventually realized that was a fundamental tradeoff and that anyone that wants to be highly available in a distributed system has to make some compromises on consistency. It was not at first well received, because it implies that people who build databases can’t promise to be up all the time, even though they do make that promise. And it means if you want to have both you actually have to work pretty hard to even get good compromises.

certo ci sono varie strategie di eventually consistency ... ma non sono per niente banali! hanno ricadute da gestire perfino a livello business

che un ATM mi permetta di prelevare soldi che non mi appartengono o che Amazon mi lasci ordinare beni che non esistono più... beh, è qualcosa che va gestito a vari livelli: dal livello del codice applicativo (logica supplementare per gestire queste situazioni) su su fino ai livelli dirigenziali dell'azienda per capire cosa è accettabile e cosa no

non è uno scherzo, no?

ripetiamo un attimo la domanda... ma ci serve davvero il multi-master?

Notiziario online

Vorrei mettere online un sitarello per uso poco più che personale.
E' una sorta di piccolo CMS molto specializzato.
Alcuni amici dovrebbero poter indicare appuntamenti ed avvisi, poi io (o chi per me) periodicamente, ogni due settimane circa, scarica queste informazioni ed impagina un piccolo "notiziario" cartaceo che verrà stampato in qualche centinaio di copie e distribuito nei dintorni.
Si tratta di un piccolo servizio di utilità per la comunità del luogo.
La prima fase del notiziario, che potremmo chiamare di "raccolta dati", avviene al momento via email: tutti mi spediscono le notizie e poi io impagino un file Libre Office.
Vista la mole relativamente ridotta di notizie, appuntamenti ed avvisi, il tutto potrebbe proseguire tranquillamente secondo la modalità email.
Tuttavia il mio lato "nerd" vorrebbe divertirsi a fare un sitarello dove le persone, chiamiamoli "inviati speciali", dopo debito login, possano caricare le notizie al posto di inviarmele via email.
Il vantaggio è che eventuali correzioni, adeguamenti etc. gli "inviati" le possono fare direttamente sul sito senza bisogno dello scambio di email e contro-email.
Fatta la premessa per l'inquadramento del problema vorrei parlare delle soluzioni tecniche per implementare il "sito del notiziario".
Ma prima di questo serve un ulteriore precisazione.
Va chiarito che, dato che la mia attività di "impaginatore di bollettini" è svolta a livello volontario ed amatoriale, anche la realizzazione di questo sito procederà in modo hobbistico senza scadenze e senza calendari.
Scadenze e calendari ne ho già abbastanza nella mia vita professionale per cui almeno questa cosa avverrà, come si dice, "senza fretta".
Questo significa anche che potrò permettermi di adottare alcune soluzioni tecniche che saranno più o meno un overkill per il problema in oggetto.
Detto questo, veniamo a noi...
Con cosa vogliamo fare il nostro bel super-sito?
Ecco lo stack: ubuntu, nginx, python, django, uwsgi
Per il deploy/provisioning: ansible
Vagrant per il test in locale e, probabilmente, Digital Ocean per il deploy vero e proprio.
Vi interessa come procede la cosa? Allora, arrivederci alla prossima!
Stay tuned!