Piano Nazionale di Ripresa e Resilienza
La versione 2.0 del Recovery Fund, ora PNRR, è pronta [1]. La 1.0 (del precedente Governo) lasciava un po' a desiderare. In questi giorni, quindi, sono in tanti coloro che si sono messi a leggerla, analizzarla, commentarla, ecc. ognuno dal proprio punto di osservazione, l'economista da quello macroeconomico, l'imprenditore da quello di chi cerca nuovi "business" e così via. Uno che vi ha dedicato qualche minuto in più alla lettura è stato un giovane programmatore, Daniele Scacciafratte (qui la sua "lettura veloce" [2]). Io di tempo non ne ho avuto e quindi ho fatto come ai tempi in cui andavo in libreria a scegliere un libro, ne prendevo uno e sceglievo una pagina a caso. Se la frase che mi capitava di leggere era scritta in modo chiaro (e ovviamente non banale), compravo il libro, altrimenti lo riponevo nello scaffale. Torniamo al PNRR, ho applicato la stessa "tecnica", ed è venuto fuori questo: saranno previsti disincentivi per le amministrazioni che non avranno effettuato la migrazione dopo un “periodo di grazia” predefinito. Saranno anche riviste le regole di contabilità che attualmente disincentivano la migrazione (al momento, infatti, la migrazione al cloud comporta di “tradurre” capex in opex). ... Il supporto alle amministrazioni che aderiranno al programma di trasformazione sarà realizzato con “pacchetti” completi che includeranno competenze tecniche e risorse finanziarie. In una logica di vera e propria “migration as a service” si aiuteranno le amministrazioni nella fase di analisi tecnica e di definizione delle priorità ... Le abilità e competenze digitali si fondano su una forte base quantitativa e richiedono una conoscenza dei software per la scrittura, il calcolo e per l’impiego delle applicazioni che oramai contemplano tutti i campi disciplinari, dall’arte alla scienza. Una forte base STEM è propedeutica alla conoscenza più applicativa degli strumenti per il digitale quindi è fondamentale arricchire la scuola primaria e secondaria di corsi a base quantitativa, con relative esemplificazioni sugli strumenti digitali (che gli studenti oggi conoscono bene dal punto di vista dell’impiego come “user”, ma che ignorano nel risvolto di programmazione). --- capex, opex, migration as service, base quantitativa ... Forse all'autore o agli autori, un po' di base "qualitativa" non avrebbe fatto male. Intendiamoci, non che questi termini siano particolarmente difficili da capire, ma è chiaramente un modo di esprimersi da economista ad economista, quando, con un piccolo sforzo aggiuntivo si sarebbe potuto scrivere un documento "leggibile" da tutti. Antonio [1] https://www.governo.it/sites/governo.it/files/PNRR.pdf [2] https://daniele.tech/2021/04/una-lettura-veloce-al-piano-nazionale-di-ripart...
Una mia micro-riflessione sulla missione M4C1.3 Ampliamento delle competenze e potenziamento delle infrastrutture, relativamente all'investimento 3.1: Nuove competenze e nuovi linguaggi https://www.key4biz.it/pnrr-e-trasformazione-digitale-dove-linformatica/3573... Ciao, Enrico Il 26/04/2021 12:52, Antonio Iacono ha scritto:
La versione 2.0 del Recovery Fund, ora PNRR, è pronta [1]. La 1.0 (del precedente Governo) lasciava un po' a desiderare. In questi giorni, quindi, sono in tanti coloro che si sono messi a leggerla, analizzarla, commentarla, ecc. ognuno dal proprio punto di osservazione, l'economista da quello macroeconomico, l'imprenditore da quello di chi cerca nuovi "business" e così via. Uno che vi ha dedicato qualche minuto in più alla lettura è stato un giovane programmatore, Daniele Scacciafratte (qui la sua "lettura veloce" [2]). Io di tempo non ne ho avuto e quindi ho fatto come ai tempi in cui andavo in libreria a scegliere un libro, ne prendevo uno e sceglievo una pagina a caso. Se la frase che mi capitava di leggere era scritta in modo chiaro (e ovviamente non banale), compravo il libro, altrimenti lo riponevo nello scaffale. Torniamo al PNRR, ho applicato la stessa "tecnica", ed è venuto fuori questo:
saranno previsti disincentivi per le amministrazioni che non avranno effettuato la migrazione dopo un “periodo di grazia” predefinito. Saranno anche riviste le regole di contabilità che attualmente disincentivano la migrazione (al momento, infatti, la migrazione al cloud comporta di “tradurre” capex in opex).
...
Il supporto alle amministrazioni che aderiranno al programma di trasformazione sarà realizzato con “pacchetti” completi che includeranno competenze tecniche e risorse finanziarie. In una logica di vera e propria “migration as a service” si aiuteranno le amministrazioni nella fase di analisi tecnica e di definizione delle priorità
...
Le abilità e competenze digitali si fondano su una forte base quantitativa e richiedono una conoscenza dei software per la scrittura, il calcolo e per l’impiego delle applicazioni che oramai contemplano tutti i campi disciplinari, dall’arte alla scienza. Una forte base STEM è propedeutica alla conoscenza più applicativa degli strumenti per il digitale quindi è fondamentale arricchire la scuola primaria e secondaria di corsi a base quantitativa, con relative esemplificazioni sugli strumenti digitali (che gli studenti oggi conoscono bene dal punto di vista dell’impiego come “user”, ma che ignorano nel risvolto di programmazione).
---
capex, opex, migration as service, base quantitativa ...
Forse all'autore o agli autori, un po' di base "qualitativa" non avrebbe fatto male. Intendiamoci, non che questi termini siano particolarmente difficili da capire, ma è chiaramente un modo di esprimersi da economista ad economista, quando, con un piccolo sforzo aggiuntivo si sarebbe potuto scrivere un documento "leggibile" da tutti.
Antonio
[1] https://www.governo.it/sites/governo.it/files/PNRR.pdf [2] https://daniele.tech/2021/04/una-lettura-veloce-al-piano-nazionale-di-ripart... _______________________________________________ nexa mailing list nexa@server-nexa.polito.it https://server-nexa.polito.it/cgi-bin/mailman/listinfo/nexa
-- EN ===================================================================== Prof. Enrico Nardelli Dipartimento di Matematica - Universita' di Roma "Tor Vergata" Via della Ricerca Scientifica snc - 00133 Roma tel: +39 06 7259.4204 fax: +39 06 7259.4699 mobile: +39 335 590.2331 e-mail: nardelli@mat.uniroma2.it home page: http://www.mat.uniroma2.it/~nardelli blog: http://www.ilfattoquotidiano.it/blog/enardelli/ http://link-and-think.blogspot.it/ ===================================================================== --
https://www.key4biz.it/pnrr-e-trasformazione-digitale-dove-linformatica/3573...
Ottima riflessione (come sempre). Ma, visto che siamo in una lista con una buona presenza di "tecnici", vorrei osare un po' di più. Ho estrapolato qualche frase: "sistemi digitali che ingessano il lavoro anziché renderlo più snello (quando non falliscono il loro obiettivo di automazione)" e, tratte da un articolo precedente [1]: "micro e piccole imprese non usano il digitale o lo usano poco non perché – come dice qualcuno – sono pervase dal familismo amorale o non ne hanno capito il potenziale di vantaggio competitivo, ma perché sistemi informatici troppo rigidi costituirebbero la melassa che li ucciderebbe rapidamente" "l'unica informatica buona è quella "personalizzata" che accompagna l'azienda in modo flessibile" Va da se che sono frasi che condivido in pieno ma, proviamo a immaginarci un futuro "ideale" con tanti bravi programmatori. Saranno davvero in grado di produrre "informatica buona" ? Io, come molti altri, ho attraversato diverse fasi di produzione software (è inutile stare qui ad elencare linguaggi e framework) e, devo dire che, tra tutte, la fase LAMP (o LEMP) è stata la più produttiva, oltre che stimolante, visti gli ottimi risultati. Oggi, anzi, da una decina d'anni, se nomini questo acronimo ad un neo-sviluppatore web ti guarda strano. Io non so se questo fuoco concentrico nei confronti del LAMP sia effettivamente dovuto a carenze strutturale "dei quattro" o, viceversa, ci sia il tentativo di vendere soluzioni "chiavi in mano" (vista la complessità dei nuovi framework). Antonio [1] https://link-and-think.blogspot.com/2019/03/trasformazione-digitale-e-svilup...
Caro Antonio non so bene come rispondere perché la tua domanda (a meno che non la fraintenda completamente) entra nel merito dello "sviluppo" del software e di uno specifico approccio (LAMP). Espongo le riflessioni che mi hai suscitato, scusandomi in anticipo se ho male interpretato il tuo stimolo. Io penso che se, prima di tutto nella scuola, sviluppiamo una buona sensibilità all'informatica come "linguaggio per la descrizione di processi che automaticamente e meccanicamente eseguono trasformazione di rappresentazioni", otteniamo due vantaggi Da un lato chi poi sceglierà di fare un altro mestiere capirà che quando si discute di un qualunque sistema di questo ci sono degli elementi da approfondire: CHI ha scelto COSA rappresentare e COSA NO? COSA viene modellato da tali rappresentazioni? COSA viene trascurato? CHI ha scelto COME trasformare? Per apprezzare queste domande devi aver capito la natura "automatica" e "meccanica" dei sistemi informatici. Dall'altro chi sceglie di fare questo mestiere potrà all'università affrontarlo in modo più adeguato e con migliori basi: immagina se dovessimo preparare gli ingegneri a partire dall'università senza che questi abbiano fatto 13 anni di matematica e 8 (almeno) di fisica nella scuola. E all'università, non ritengo che bisogna preparare "programmatori", ma informatici. E non è solo "pedanteria accademica" :-) Se vuoi preparare uno scrittore, non ti basta insegnargli a leggere e scrivere. Deve capire (attraverso lo studio e/o l'esperienza) cosa sono le emozioni e le relazioni, come "funzionano" persone e società. Fuor di metafora, saper programmare benissimo, ma non aver capito il ruolo dei sistemi informatici all'interno del lavoro di organizzazioni di varia complessità produce, in genere, disastri. Esiste infine, come per l'ingegneria tradizionale, tra la scuola e l'università, la funzione intermedia del quadro tecnico. Un esempio, preso dall'ingegneria civile, è quello del geometra, ruolo indispensabile, perché non tutti hanno bisogno di costruire grattacieli, mentre molti devono realizzare "modeste costruzioni civili". Moltissime micro e piccole imprese italiane non hanno necessità di un laureato per le loro esigenze informatiche, gli basterebbe un diplomato, anche qui che sia preparato come un "informatico" in grado di definire un progetto in relazione alle esigenze dell'utente e non semplicemente come un "programmatore" che genera codice. Ciao, Enrico Il 27/04/2021 10:01, Antonio Iacono ha scritto:
https://www.key4biz.it/pnrr-e-trasformazione-digitale-dove-linformatica/3573...
Ottima riflessione (come sempre). Ma, visto che siamo in una lista con una buona presenza di "tecnici", vorrei osare un po' di più.
Ho estrapolato qualche frase: "sistemi digitali che ingessano il lavoro anziché renderlo più snello (quando non falliscono il loro obiettivo di automazione)" e, tratte da un articolo precedente [1]: "micro e piccole imprese non usano il digitale o lo usano poco non perché – come dice qualcuno – sono pervase dal familismo amorale o non ne hanno capito il potenziale di vantaggio competitivo, ma perché sistemi informatici troppo rigidi costituirebbero la melassa che li ucciderebbe rapidamente" "l'unica informatica buona è quella "personalizzata" che accompagna l'azienda in modo flessibile"
Va da se che sono frasi che condivido in pieno ma, proviamo a immaginarci un futuro "ideale" con tanti bravi programmatori. Saranno davvero in grado di produrre "informatica buona" ? Io, come molti altri, ho attraversato diverse fasi di produzione software (è inutile stare qui ad elencare linguaggi e framework) e, devo dire che, tra tutte, la fase LAMP (o LEMP) è stata la più produttiva, oltre che stimolante, visti gli ottimi risultati. Oggi, anzi, da una decina d'anni, se nomini questo acronimo ad un neo-sviluppatore web ti guarda strano. Io non so se questo fuoco concentrico nei confronti del LAMP sia effettivamente dovuto a carenze strutturale "dei quattro" o, viceversa, ci sia il tentativo di vendere soluzioni "chiavi in mano" (vista la complessità dei nuovi framework).
Antonio
[1] https://link-and-think.blogspot.com/2019/03/trasformazione-digitale-e-svilup...
-- EN ===================================================================== Prof. Enrico Nardelli Dipartimento di Matematica - Universita' di Roma "Tor Vergata" Via della Ricerca Scientifica snc - 00133 Roma tel: +39 06 7259.4204 fax: +39 06 7259.4699 mobile: +39 335 590.2331 e-mail: nardelli@mat.uniroma2.it home page: http://www.mat.uniroma2.it/~nardelli blog: http://www.ilfattoquotidiano.it/blog/enardelli/ http://link-and-think.blogspot.it/ ===================================================================== --
Esiste infine, come per l'ingegneria tradizionale, tra la scuola e l'università, la funzione intermedia del quadro tecnico. Un esempio, preso dall'ingegneria civile, è quello del geometra, ruolo indispensabile, perché non tutti hanno bisogno di costruire grattacieli, mentre molti devono realizzare "modeste costruzioni civili". Moltissime micro e piccole imprese italiane non hanno necessità di un laureato per le loro esigenze informatiche, gli basterebbe un diplomato, anche qui che sia preparato come un "informatico" in grado di definire un progetto in relazione alle esigenze dell'utente e non semplicemente come un "programmatore" che genera codice.
L'analogia con l'ingegneria civile mi piace tantissimo :) Il programmatore è il muratore o il carpentiere. L'informatico è l'ingegnere, l'architetto o, per piccoli progetti, il geometra. L'ingegnere non deve "impastare il cemento" ma se qualche volta, nella vita, l'ha fatto, gli tornerà sicuramente utile. L'informatico non deve programmare ma se a volte "si sporca le mani" con il codice, male non fa. Un ipermercato ormai lo si costruisce in un paio di settimane, prefabbricati e via. Ma a nessun ingegnere/geometra/muratore verrebbe in mente di usare i prefabbricati per una "costruzione civile". Nell'informatica attuale (per niente "buona"), purtroppo sì. Antonio
Grazie Antonio solo per chiarire che dal mio punto di vista essere un informatico vuol dire saper programmare. Chi non si è "sporcato le mani" col codice non è un informatico. Punto. Per dirlo con le parole di Donald Knuth «the best computer scientists are thoroughly grounded in basic concepts of how computer actually work; and indeed the essence of computer science is an ability to understand many levels of abstraction simultaneously.» [Keynote Address at the 8th Annual Conference on Innovation and Technology in Computer Science Education (ITiCSE-03)] Ciao, Enrico Il 28/04/2021 10:19, Antonio Iacono ha scritto:
Esiste infine, come per l'ingegneria tradizionale, tra la scuola e l'università, la funzione intermedia del quadro tecnico. Un esempio, preso dall'ingegneria civile, è quello del geometra, ruolo indispensabile, perché non tutti hanno bisogno di costruire grattacieli, mentre molti devono realizzare "modeste costruzioni civili". Moltissime micro e piccole imprese italiane non hanno necessità di un laureato per le loro esigenze informatiche, gli basterebbe un diplomato, anche qui che sia preparato come un "informatico" in grado di definire un progetto in relazione alle esigenze dell'utente e non semplicemente come un "programmatore" che genera codice.
L'analogia con l'ingegneria civile mi piace tantissimo :) Il programmatore è il muratore o il carpentiere. L'informatico è l'ingegnere, l'architetto o, per piccoli progetti, il geometra.
L'ingegnere non deve "impastare il cemento" ma se qualche volta, nella vita, l'ha fatto, gli tornerà sicuramente utile. L'informatico non deve programmare ma se a volte "si sporca le mani" con il codice, male non fa.
Un ipermercato ormai lo si costruisce in un paio di settimane, prefabbricati e via. Ma a nessun ingegnere/geometra/muratore verrebbe in mente di usare i prefabbricati per una "costruzione civile". Nell'informatica attuale (per niente "buona"), purtroppo sì.
Antonio _______________________________________________ nexa mailing list nexa@server-nexa.polito.it https://server-nexa.polito.it/cgi-bin/mailman/listinfo/nexa
-- EN ===================================================================== Prof. Enrico Nardelli Dipartimento di Matematica - Universita' di Roma "Tor Vergata" Via della Ricerca Scientifica snc - 00133 Roma tel: +39 06 7259.4204 fax: +39 06 7259.4699 mobile: +39 335 590.2331 e-mail: nardelli@mat.uniroma2.it home page: http://www.mat.uniroma2.it/~nardelli blog: http://www.ilfattoquotidiano.it/blog/enardelli/ http://link-and-think.blogspot.it/ ===================================================================== --
solo per chiarire che dal mio punto di vista essere un informatico vuol dire saper programmare. Chi non si è "sporcato le mani" col codice non è un informatico. Punto.
Grazie Enrico della tua, non affatto scontata, presa di posizione. Lo dico sulla base di esperienze personali, anche (anzi soprattutto) recenti. Nei periodi emergenziali, quando non hai tempo di scegliere le soluzioni ideali, di architettare, di progettare il sistema "perfetto". Insomma, quando devi "sbracciarti" e mettere mani al codice (spesso di altri) prima che venga giù tutto. E' lì che la padronanza di più linguaggi di programmazione ti "salva". Ma è anche in quei momenti che noti la preparazione di molti ingegneri informatici freschi di laurea. Tratto da una recente tesi: "Il client è composto da pagine web, ogni pagina ha uno scopo differente ed è stata realizzata con due linguaggi che vengono quasi sempre utilizzati in questo ambito, ovvero HTML e CSS. Per rendere più interattive le pagine è stato utilizzato il linguaggio di programmazione JavaScript. Quest’ultimo è stato usato anche per la creazione dei grafici, in collaborazione con il software [proprietario]. Il server è stato realizzato utilizzando la famosa accoppiata Node.js ed Express, in questo modo, è stato possibile utilizzare ancora una volta JavaScript" Ecco, poi vanno in azienda (o nella PA), ti trovano PHP, C, bash, VB ... e vanno in tilt. Antonio
On Wed, 28 Apr 2021 18:18:26 +0200 Antonio Iacono wrote:
Tratto da una recente tesi: "Il client è composto da [...] JavaScript. Il server è [...] ancora una volta JavaScript"
Ecco, poi vanno in azienda (o nella PA), ti trovano PHP, C, bash, VB ... e vanno in tilt.
Guarda Antonio, lo dico per esperienza: può andare molto peggio. Possono diffondere JavaScript in azienda (o peggio nella PA), credendo sinceramente di conoscerlo. Non sanno quello che fanno. E quel che è peggio, non lo sanno i responsabili tecnici che non lo impediscono ed anzi si fanno trascinare dall'hype. Giacomo PS: io programmo (ANCHE e TANTO) in JavaScript da 20 anni. Ma soprattutto lo debuggo. Tanto. TANTO. Ho visto cose che voi umani...
I programmatori di oggi, ma anche gli analisti e su su, sono come i falegnami odierni: sanno solo assemblare ed adattare. Io la chiamo infatti informatica-ikea. Idem per i siti web, ormai la maggioranza sono fatti con wordpress. Col beneplacito degli imprenditori che risparmiano (così credono) ma al committente non lo dicono. Anche se spesso, rifare il codice da zero sarebbe meglio, non occorrerebbe studiare software altrui, spesso mal documentato, che magari è inutilmente pesante per il progetto ... e non parliamo se occorre trovarvi dei bug. Peccato che pochi ne siano capaci. Ci sono i pochi veri informatici che preparano le librerie di base, i framework, le classi, i plugin, e gli altri campano di rendita. Danni del software gratuito (cosiddetto libero). Io faccio tutto, dall'informatico (nel senso di Antonio) giù giù fino al riparatore di tastiere. Utilizzo praticamente tutti i linguaggi presenti a passati, mi sono creato mie piattaforme e librerie e sono indipendente. Quando però partecipavo a progetti di gruppo, rabbirividivo nel vedere dei capi-progetto, laureati in informatica, che tiravano fuori idea balzane, tutto perchè non conoscevano il linguaggio che si era deciso di adottare (e spesso sbagliavano a sceglierlo) e non ne sapevao i limiti e i pregi. Infatti, adesso, o faccio io il capo-progetto (e mi delego parte del codice più il disegno del db) o ne sto fuori. Perciò concordo con Antonio che anche il mega-informatico deve saper programmare, magari non specializzatissimo, ma questo è la base di tutto. Quasi tutti gli allenatori di calcio erano prima dei bravi calciatori. Tralascio poi i rapporti con i "manager" e con i commerciali che sarebbe lunghissimo ... Accenno solo che i vari "framework" spesso sono una palla al piede. Servono per utilizzare manodopera meno skill ed utilizzarla tipo catena-di-montaggio. Poi si lamentano che il server dell'Inps crasha ad ogni nuovo decreto e che confonde gli utenti. Vincenzo. Il 28.04.2021 16:34, Enrico Nardelli ha scritto:
Grazie Antonio
solo per chiarire che dal mio punto di vista essere un informatico vuol dire saper programmare. Chi non si è "sporcato le mani" col codice non è un informatico. Punto.
Per dirlo con le parole di Donald Knuth «the best computer scientists are thoroughly grounded in basic concepts of how computer actually work; and indeed the essence of computer science is an ability to understand many levels of abstraction simultaneously.» [Keynote Address at the 8th Annual Conference on Innovation and Technology in Computer Science Education (ITiCSE-03)]
Ciao, Enrico
Il 28/04/2021 10:19, Antonio Iacono ha scritto:
Esiste infine, come per l'ingegneria tradizionale, tra la scuola e l'università, la funzione intermedia del quadro tecnico. Un esempio, preso dall'ingegneria civile, è quello del geometra, ruolo indispensabile, perché non tutti hanno bisogno di costruire grattacieli, mentre molti devono realizzare "modeste costruzioni civili". Moltissime micro e piccole imprese italiane non hanno necessità di un laureato per le loro esigenze informatiche, gli basterebbe un diplomato, anche qui che sia preparato come un "informatico" in grado di definire un progetto in relazione alle esigenze dell'utente e non semplicemente come un "programmatore" che genera codice.
L'analogia con l'ingegneria civile mi piace tantissimo :) Il programmatore è il muratore o il carpentiere. L'informatico è l'ingegnere, l'architetto o, per piccoli progetti, il geometra.
L'ingegnere non deve "impastare il cemento" ma se qualche volta, nella vita, l'ha fatto, gli tornerà sicuramente utile. L'informatico non deve programmare ma se a volte "si sporca le mani" con il codice, male non fa.
Un ipermercato ormai lo si costruisce in un paio di settimane, prefabbricati e via. Ma a nessun ingegnere/geometra/muratore verrebbe in mente di usare i prefabbricati per una "costruzione civile". Nell'informatica attuale (per niente "buona"), purtroppo sì.
Antonio _______________________________________________ nexa mailing list nexa@server-nexa.polito.it https://server-nexa.polito.it/cgi-bin/mailman/listinfo/nexa
-- EN
===================================================================== Prof. Enrico Nardelli Dipartimento di Matematica - Universita' di Roma "Tor Vergata" Via della Ricerca Scientifica snc - 00133 Roma tel: +39 06 7259.4204 fax: +39 06 7259.4699 mobile: +39 335 590.2331 e-mail: nardelli@mat.uniroma2.it home page: http://www.mat.uniroma2.it/~nardelli blog: http://www.ilfattoquotidiano.it/blog/enardelli/ http://link-and-think.blogspot.it/ =====================================================================
Vorrei spezzare un lancia a favore dei colleghi che insegnano nei corsi di laurea in informatica o ingegneria informatica (formalmente diversi ma spesso abbastanza simili nell'impostazione e nei contenuti). In genere tutti i colleghi sono ben consapevoli dell'importanza di una preparazione anche su aspetti progettuali/pratici. Sono lontani i tempi in cui ci si poteva laureare su una base solo teorica. Però, non dimentichiamo mai che l'università prepara NON a sviluppare software con l'ambiente di oggi ma a farlo con qualunque ambiente, anche quello che useremo fra trent'anni. [Cosa usavamo nel 1990 per sviluppare software?] Quindi non diamo addosso a neolaureati che non conoscono l'ambiente che si sta usando in quel momento in azienda, perché non è quello il problema. Chiarito questo, la tensione tra commerciale e tecnico in azienda è qualcosa che esiste in tutti i settori, ma che nell'informatica è esasperata dalla incorporeità della materia di cui sono fatti i sistemi informatici. Non possiamo farci molto, se non rendere i nostri laureati più sensibili agli aspetti cosiddetti "non funzionali" che alle volte possono essere più rilevanti per il successo di un sistema di quelli funzionali. Infine, una battuta: i falegnami, quelli veri, non vanno da ikea. Gli informatici, quelli veri, non tirano giù una libreria da diecimila linee di codice per fare qualcosa che si può fare con cento. D'altro canto, e chiudo, ignorare l'esistenza delle librerie e iniziare ogni volta aprendo un editor di testo e scrivendo class MyClass { public static void main(String args[]) ... sarebbe altrettanto deleterio. Ed è vero che i framework servono anche a poter usare personale meno preparato ma, d'altro canto, se usati bene rendono il processo di sviluppo più efficiente. Una proposta che ripeto ormai da una decina d'anni è che dovremmo formare gli informatici (a scienze e ad ingegneria) come i medici. Dopo tre anni, iniziare l'attività in corsia a veder curare (prima) e curare (poi) i malati veri, mentre in paralleo si continua ad approfondire lo studio tecnico-specialistico. Ciao, Enrico Il 28/04/2021 21:07, TEV S.r.L. ha scritto:
I programmatori di oggi, ma anche gli analisti e su su, sono come i falegnami odierni: sanno solo assemblare ed adattare. Io la chiamo infatti informatica-ikea. Idem per i siti web, ormai la maggioranza sono fatti con wordpress. Col beneplacito degli imprenditori che risparmiano (così credono) ma al committente non lo dicono. Anche se spesso, rifare il codice da zero sarebbe meglio, non occorrerebbe studiare software altrui, spesso mal documentato, che magari è inutilmente pesante per il progetto ... e non parliamo se occorre trovarvi dei bug. Peccato che pochi ne siano capaci.
Ci sono i pochi veri informatici che preparano le librerie di base, i framework, le classi, i plugin, e gli altri campano di rendita. Danni del software gratuito (cosiddetto libero).
Io faccio tutto, dall'informatico (nel senso di Antonio) giù giù fino al riparatore di tastiere. Utilizzo praticamente tutti i linguaggi presenti a passati, mi sono creato mie piattaforme e librerie e sono indipendente. Quando però partecipavo a progetti di gruppo, rabbirividivo nel vedere dei capi-progetto, laureati in informatica, che tiravano fuori idea balzane, tutto perchè non conoscevano il linguaggio che si era deciso di adottare (e spesso sbagliavano a sceglierlo) e non ne sapevao i limiti e i pregi. Infatti, adesso, o faccio io il capo-progetto (e mi delego parte del codice più il disegno del db) o ne sto fuori. Perciò concordo con Antonio che anche il mega-informatico deve saper programmare, magari non specializzatissimo, ma questo è la base di tutto. Quasi tutti gli allenatori di calcio erano prima dei bravi calciatori.
Tralascio poi i rapporti con i "manager" e con i commerciali che sarebbe lunghissimo ... Accenno solo che i vari "framework" spesso sono una palla al piede. Servono per utilizzare manodopera meno skill ed utilizzarla tipo catena-di-montaggio. Poi si lamentano che il server dell'Inps crasha ad ogni nuovo decreto e che confonde gli utenti.
Vincenzo.
Il 28.04.2021 16:34, Enrico Nardelli ha scritto:
Grazie Antonio
solo per chiarire che dal mio punto di vista essere un informatico vuol dire saper programmare. Chi non si è "sporcato le mani" col codice non è un informatico. Punto.
Per dirlo con le parole di Donald Knuth «the best computer scientists are thoroughly grounded in basic concepts of how computer actually work; and indeed the essence of computer science is an ability to understand many levels of abstraction simultaneously.» [Keynote Address at the 8th Annual Conference on Innovation and Technology in Computer Science Education (ITiCSE-03)]
Ciao, Enrico
Il 28/04/2021 10:19, Antonio Iacono ha scritto:
Esiste infine, come per l'ingegneria tradizionale, tra la scuola e l'università, la funzione intermedia del quadro tecnico. Un esempio, preso dall'ingegneria civile, è quello del geometra, ruolo indispensabile, perché non tutti hanno bisogno di costruire grattacieli, mentre molti devono realizzare "modeste costruzioni civili". Moltissime micro e piccole imprese italiane non hanno necessità di un laureato per le loro esigenze informatiche, gli basterebbe un diplomato, anche qui che sia preparato come un "informatico" in grado di definire un progetto in relazione alle esigenze dell'utente e non semplicemente come un "programmatore" che genera codice.
L'analogia con l'ingegneria civile mi piace tantissimo :) Il programmatore è il muratore o il carpentiere. L'informatico è l'ingegnere, l'architetto o, per piccoli progetti, il geometra.
L'ingegnere non deve "impastare il cemento" ma se qualche volta, nella vita, l'ha fatto, gli tornerà sicuramente utile. L'informatico non deve programmare ma se a volte "si sporca le mani" con il codice, male non fa.
Un ipermercato ormai lo si costruisce in un paio di settimane, prefabbricati e via. Ma a nessun ingegnere/geometra/muratore verrebbe in mente di usare i prefabbricati per una "costruzione civile". Nell'informatica attuale (per niente "buona"), purtroppo sì.
Antonio _______________________________________________ nexa mailing list nexa@server-nexa.polito.it https://server-nexa.polito.it/cgi-bin/mailman/listinfo/nexa
-- EN
===================================================================== Prof. Enrico Nardelli Dipartimento di Matematica - Universita' di Roma "Tor Vergata" Via della Ricerca Scientifica snc - 00133 Roma tel: +39 06 7259.4204 fax: +39 06 7259.4699 mobile: +39 335 590.2331 e-mail: nardelli@mat.uniroma2.it home page: http://www.mat.uniroma2.it/~nardelli blog: http://www.ilfattoquotidiano.it/blog/enardelli/ http://link-and-think.blogspot.it/ =====================================================================
_______________________________________________ nexa mailing list nexa@server-nexa.polito.it https://server-nexa.polito.it/cgi-bin/mailman/listinfo/nexa
-- EN ===================================================================== Prof. Enrico Nardelli Dipartimento di Matematica - Universita' di Roma "Tor Vergata" Via della Ricerca Scientifica snc - 00133 Roma tel: +39 06 7259.4204 fax: +39 06 7259.4699 mobile: +39 335 590.2331 e-mail: nardelli@mat.uniroma2.it home page: http://www.mat.uniroma2.it/~nardelli blog: http://www.ilfattoquotidiano.it/blog/enardelli/ http://link-and-think.blogspot.it/ ===================================================================== --
Però, non dimentichiamo mai che l'università prepara NON a sviluppare software con l'ambiente di oggi ma a farlo con qualunque ambiente, anche quello che useremo fra trent'anni. [Cosa usavamo nel 1990 per sviluppare software?]
Nel 1996 usavo PHP e Bash, stamattina ho usato Bash e PHP (tra l'altro PHP "puro", neanche ad oggetti, perché ho dovuto sistemare il codice di una vecchia applicazione che, come si dice in gergo, il suo "sporco lavoro" lo fa ottimamente) e quasi quasi, per rilassarmi, stasera un po' di C ...
Gli informatici, quelli veri, non tirano giù una libreria da diecimila linee di codice per fare qualcosa che si può fare con cento. E allora sono sfortunato io, perché evidentemente di informatici "veri" negli ultimi dieci anni, non me ne sono capitati molti :(
Ed è vero che i framework servono anche a poter usare personale meno preparato ma, d'altro canto, se usati bene rendono il processo di sviluppo più efficiente.
Perdonami Enrico, a forza di rendere il processo più veloce ed efficiente agli sviluppatori abbiamo reso un inferno la vita dell'utente finale. Nel senso che framework sempre più pesanti hanno rallentato di molto le applicazioni (specie quelle web).
Una proposta che ripeto ormai da una decina d'anni è che dovremmo formare gli informatici (a scienze e ad ingegneria) come i medici. Dopo tre anni, iniziare l'attività in corsia a veder curare (prima) e curare (poi) i malati veri, mentre in parallelo si continua ad approfondire lo studio tecnico-specialistico.
Assolutamente d'accordo. Tornando all'inizio, ok, l'università non deve preparare a sviluppare software, ma converrai che nel momento finale del percorso di studi, la tesi di laurea, spesso il laureando "arricchisce" il proprio elaborato con il "codice". Codice che, volentieri, riflette molto le "mode" del momento. L'Università di Pisa fa un'opera decisamente meritoria, mette online le tesi nell'Archivio digitale delle tesi discusse [1] Ho provato a fare qualche ricerca con delle parole chiave. "machine learning" 178 occorrenze "data mining" 134 occorrenze "java" 128 occorrenze "blockchain" 50 occorrenze "php" 14 occorrenze (tra l'altro quasi tutte tesi di oltre 10 anni fa) PHP è snobbato da SEMPRE nell'ambiente universitario. Come lo era il kernel monolitico ... Ricordi cosa disse Tanenbaum a Torvalds? "Ringrazia di non essere un mio studente. Non avresti ricevuto un gran voto per un lavoro simile". Ancora oggi PHP è il linguaggio in assoluto più usato nel web. Wordpress e Drupal sono ottimi prodotti open source. Il sito governo.it è su Drupal. Milioni di siti sono su Wordpress. Antonio [1] https://etd.adm.unipi.it/ETD-db/ETD-search/search
On Thu, 29 Apr 2021 15:52:18 +0200 Antonio Iacono wrote:
Ricordi cosa disse Tanenbaum a Torvalds? "Ringrazia di non essere un mio studente. Non avresti ricevuto un gran voto per un lavoro simile".
Forse è una fortuna che io non insegni informatica. Ma certamente, in retrospettiva, aveva ragione Tanenbaum. Giacomo
mmm... ci vedo un po' troppo "Not Invented Here syndrome" in questo messaggio ignori anche tutta la tematica COTS (Components Off The Shelf) e la filosofia di UNIX (... small tools and combining them via glueing scripts) è giusto conoscere i linguaggi e i framework e usarli al meglio, ma farsi tutto da soli (from scratch) è proprio lo sbaglio che fanno in molti e che causa danni a volte incalcolabili, gli sviluppatori affetti da hybris fanno da soli, schiantandosi contro solidi muri quando i loro "prodotti" si scoprono inadeguati, non manutenibili, non aggiornabili, non LEGGIBILI last but not least, non posso sorvolare sulla tua affermazione: "Danni del software gratuito (cosiddetto libero)." WTF?!?!?!?! (scusate il francesismo) *plonk* On 28/04/2021 21:07, TEV S.r.L. wrote:
I programmatori di oggi, ma anche gli analisti e su su, ...
-- |_|o|_| Andrea Trentini - http://atrent.it |_|_|o| Dipartimento di Informatica |o|o|o| Università degli Studi di Milano
Ciao. Sono d'accordo con te che il mio sia un caso estremo, ne sono cosciente e sono felice così. (*) Non è una sindrome, ma una scelta consapevole e ragionata, e dettata anche dall'esperienza. Come al solito, il giusto (per la massa) sta nel mezzo. Senza generalizzare, prova a leggere il mio concetto un po' più alla larga. Non trovate che oggi si faccia troppo uso di "software trovato in rete" ("software gretuito", sulla cui qualità stendiamo un velo pietoso) e ci si metta poco di proprio? Vincenzo. PS: (*) Quasi tutti i framework sono nati come iniziative specifiche, e poi sono diventati piattaforme pubbliche. Nell'arco degli anni ho ceduto (gratuitamente) i miei framework nati per utilizzo personale o della mia azienda ad altri. Non sono diventati famosi a livello mondiale, ma hanno aiutato parecchi miei colleghi. Sono stato co-autore del forse primo framework/sistema di sviluppo italiano ed uno dei primi al mondo: "Simple" del Polimi (1975). Il 29.04.2021 08:48, Andrea Trentini ha scritto:
mmm...
ci vedo un po' troppo "Not Invented Here syndrome" in questo messaggio
ignori anche tutta la tematica COTS (Components Off The Shelf) e la filosofia di UNIX (... small tools and combining them via glueing scripts)
è giusto conoscere i linguaggi e i framework e usarli al meglio, ma farsi tutto da soli (from scratch) è proprio lo sbaglio che fanno in molti e che causa danni a volte incalcolabili, gli sviluppatori affetti da hybris fanno da soli, schiantandosi contro solidi muri quando i loro "prodotti" si scoprono inadeguati, non manutenibili, non aggiornabili, non LEGGIBILI
last but not least, non posso sorvolare sulla tua affermazione:
"Danni del software gratuito (cosiddetto libero)."
WTF?!?!?!?! (scusate il francesismo)
*plonk*
On 28/04/2021 21:07, TEV S.r.L. wrote:
I programmatori di oggi, ma anche gli analisti e su su, ...
Provando a "leggere il concetto un po’ più alla larga”: credo che sia collegato a un problema più generale e citato più volte in questa lista, ovvero alla visione del software e in generale del digitale come semplice merce (c.d. “commodity”), e che magari rappresenta anche la soluzione "facile" a problemi complessi (ad es. quelli organizzativi). Visione che, a giudicare dalla recente politica industriale del nostro Paese, sembrerebbe propria della classe dirigente e di una parte della classe industriale. Sempre leggendo da questa mailing list e osservando la realtà, mi sembra che gli sforzi migliori per costruire una cultura digitale più idonea per un Paese moderno vengano dal basso, ed è auspicabile una messa a sistema di quelle energie. Energie che, almeno in ambito digitale, il PNRR sembrerebbe non aver raccolto. A.
Il giorno 29 apr 2021, alle ore 10:15, TEV S.r.L. <info@tev.eu> ha scritto:
Ciao. Sono d'accordo con te che il mio sia un caso estremo, ne sono cosciente e sono felice così. (*) Non è una sindrome, ma una scelta consapevole e ragionata, e dettata anche dall'esperienza. Come al solito, il giusto (per la massa) sta nel mezzo. Senza generalizzare, prova a leggere il mio concetto un po' più alla larga. Non trovate che oggi si faccia troppo uso di "software trovato in rete" ("software gretuito", sulla cui qualità stendiamo un velo pietoso) e ci si metta poco di proprio?
Vincenzo.
PS: (*) Quasi tutti i framework sono nati come iniziative specifiche, e poi sono diventati piattaforme pubbliche. Nell'arco degli anni ho ceduto (gratuitamente) i miei framework nati per utilizzo personale o della mia azienda ad altri. Non sono diventati famosi a livello mondiale, ma hanno aiutato parecchi miei colleghi. Sono stato co-autore del forse primo framework/sistema di sviluppo italiano ed uno dei primi al mondo: "Simple" del Polimi (1975).
Il 29.04.2021 08:48, Andrea Trentini ha scritto:
mmm...
ci vedo un po' troppo "Not Invented Here syndrome" in questo messaggio
ignori anche tutta la tematica COTS (Components Off The Shelf) e la filosofia di UNIX (... small tools and combining them via glueing scripts)
è giusto conoscere i linguaggi e i framework e usarli al meglio, ma farsi tutto da soli (from scratch) è proprio lo sbaglio che fanno in molti e che causa danni a volte incalcolabili, gli sviluppatori affetti da hybris fanno da soli, schiantandosi contro solidi muri quando i loro "prodotti" si scoprono inadeguati, non manutenibili, non aggiornabili, non LEGGIBILI
last but not least, non posso sorvolare sulla tua affermazione:
"Danni del software gratuito (cosiddetto libero)."
WTF?!?!?!?! (scusate il francesismo)
*plonk*
On 28/04/2021 21:07, TEV S.r.L. wrote:
I programmatori di oggi, ma anche gli analisti e su su, ...
nexa mailing list nexa@server-nexa.polito.it https://server-nexa.polito.it/cgi-bin/mailman/listinfo/nexa
Andrea Trentini <andrea.trentini@unimi.it> writes: [...]
gli sviluppatori affetti da hybris fanno da soli
Aggiungo una cosa ovvia ma che vale la pena ribadire a noi stessi di tanto in tanto: NESSUNO si salva da solo. Mai, mai, mai dimenticare cosa scrisse Ken Thompson nel 1984 (o IN 1984?!? :-D ) nelle conclusioni del suo famigerrimo paper [1]: --8<---------------cut here---------------start------------->8--- You can't trust code that you did not totally create yourself. (Especially code from companies that employ people like me.) --8<---------------cut here---------------end--------------->8--- Non c'è bisogno di comprendere il codice C che lui scrive per dimostrare la sua tesi: credetelo sulla parola, è SCIENTIFICAMENTE dimostrata. Evidenzio che è AUTOEVIDENTE che Thompson in quella sua frase non può che essere (auto)ironico, chi fa l'analista o il programmatore lo sa; infatti poi aggiunge una nota per fugare ogni dubbio, che DEVE essere considerata bene altrimenti l'intero paper sarebbe semplicemente /inutile/: --8<---------------cut here---------------start------------->8--- In demonstrating the possibility of this kind of attack, I picked on the C compiler. I could have picked on any program-handling program such as an assembler, a loader, or even hardware microcode. As the level of program gets lower, these bugs will be harder and harder to detect. A well-installed microcode bug will be almost impossible to detec. --8<---------------cut here---------------end--------------->8--- (...mmm, microcode eh... mi ricorda qualcosa) Io SO che NESSUNO sulla faccia della terra, nemmeno il più geniale dei programmatori, è in grado di scriversi (e correggersi) da solo il software che usa: dal microcode della CPU fino all'applicazione utente, passando per compilatori e /librerie/ (anche senza usare "framework", o meglio componendosi da soli il proprio "framework"). Direi quindi che la soluzione di fidarsi solo del codice che ciascuno crea COMPLETAMENTE da se [2] (la "soluzione Thompson") NON è umanamente praticabile; mi sa che ci conviene collaborare. Saluti, Giovanni. [...] [1] «Reflections on Trusting Trust» https://dl.acm.org/doi/pdf/10.1145/358198.358210 [2] ovviamente dicendo agli altri che non possono scriverselo tutto da soli: «fidatevi di me ciecamente perché io so quello che sto facendo» -- Giovanni Biscuolo Noi, incompetenti come siamo, non abbiamo alcun titolo per suggerire alcunché.
Ma che bella deriva che ha preso questa conversazione! :-D On Thu, 29 Apr 2021 08:48:32 +0200 Andrea Trentini wrote:
sviluppatori affetti da hybris fanno da soli
Ciao, mi chiamo Giacomo e qualche volta scrivo software da solo. So che forse posso smettere, ma poi con che faccia guarderò le mie figlie sapendo di non aver neppure provato a evitargli tutto questo? In questi giorni sto prendendo parte ad una lunga discussione sull'uso di ReactJS in ambito finanziario. Io sono contrario (framework instabile, ecosistema pressappochista e mal documentato etc.. etc...) ma a causa di incauti investimenti pregressi in altri settori probabilmente dovremo adottarlo. Il che, di per sé, sarebbe un problema relativo: il team con cui lavoro ha skill così elevati da poter adattare qualsiasi tecnologia alle esigenze dei nostri clienti (grandi gruppi bancari), ma... MA anche se React è un non-framework basato (pressappoco) sul Functional Reactive Programming e che si _presenta_ come estremamente un-opinionated, ci viene detto che il nostro modo di usarlo sarebbe "antitetico alle best practice". Potrei parlare ORE dell'inadeguatezza di queste best practice per codebase di decine di milioni di righe di codice che andranno manutenute per decenni (letteralmente) presso clienti con esigenze di sicurezza e regole di deploy estremamente complesse e che richiederanno innumerevoli evoluzioni. MA mi viene detto che queste best practice vengono adottate con successo da Facebook QUINDI devono andare bene anche per noi. Applicandole alla lettera, ci sono state proposte funzioni da 800 righe di codice (non scherzo!) che mescolano problematiche totalmente ortogonali perché tanto il separation of concern è roba da boomer. Fidati Andrea: talvolta non è hybris riscriversi le cose da soli. E' spirito di sopravvivenza. Perché tanto poi, i problemi in produzione toccherà risolverli a noi. On Thu, 29 Apr 2021 10:22:41 +0200 Giovanni Biscuolo wrote:
--8<---------------cut here---------------start------------->8---
You can't trust code that you did not totally create yourself. (Especially code from companies that employ people like me.)
--8<---------------cut here---------------end--------------->8--- [...] Io SO che NESSUNO sulla faccia della terra, nemmeno il più geniale dei programmatori, è in grado di scriversi (e correggersi) da solo il software che usa
Per citare Stefano Quintarelli: "lo pensi o lo sai?" :-D E' vero: siamo circondati da una enorme quantità di pessimo software. Indipendentemente dalla licenza con cui è distribuito. ;-) Se un software non può essere completamente letto, studiato e compreso in meno di un mese da un singolo essere umano, è "broken beyond repair". Ma questa drammatica situazione non è una condizione necessaria, non è una caratteristica naturale, inevitabile del software. E' solo un problema immanente che fatichiamo ad accettare come tale ed affrontare seriamente. La soluzione è complessa e sfaccettata, passa dall'educazione informatica e dalla riscrittura "from scratch" di tutto lo stack applicativo, a partire dai compilatori (e dai linguaggi), dal sistema operativo e forse anche (come ami sottolineare tu Giovanni) dal microcode e dall'architettura delle CPU. E tutto da buttare. Tutto, purtroppo: https://lkml.org/lkml/2021/4/27/855
mi sa che ci conviene collaborare.
Decisamente! :-D Con tutto il lavoro da fare che c'è, prima partiamo e meglio è! Non dobbiamo scoraggiarci: questo software è stato scritto accumulando una enorme quantità di complessità non necessaria, accidentale o voluta. Può (e deve) essere _semplicemente_ riscritto. Non per hybris, ma per spirito di sopravvivenza. Per lasciare ai nostri figli un mondo cibernetico più vivibile. Giacomo
beh, concordo che IN CERTI CASI possa valere la pena riscrivere cose esistenti: - se sono fatte male - se sono mal documentate - se sono poco supportate da una base utenti/sviluppatori (*) - se non sono licenziate correttamente (i.e. proprietarie) - se non ci sono alternative... really? nel mondo del sw libero è più probabile dover scegliere fra nmila alternative che non doversi "accontentare" di una sola scelta perché la sola (o sòla?) ma in generale vale il pattern "do not reinvent the wheel... badly" e poi in generale chi sono io per sindacare (al punto da dire che va riscritto) che so un gcc, un git, un kernel di linux, un server web (apache/nginx) ... pur ritenendomi un decente sviluppatore (pur se non a tempo pieno) my 2 cents (era un casino che non lo scrivevo!) (*) forse vi riferivate a qualche pezzo di software trovato a caso su github/gitlab scritto da un singolo (vs. una community solida e numerosa), in questo caso sono pienamente d'accordo con voi che l'oggetto vada probabilmente usato solo come ispirazione ;) -- |_|o|_| Andrea Trentini - http://atrent.it |_|_|o| Dipartimento di Informatica |o|o|o| Università degli Studi di Milano
Ah... Andrea! On April 29, 2021 4:19:41 PM UTC, Andrea Trentini <andrea.trentini@unimi.it> wrote:
beh, concordo che IN CERTI CASI possa valere la pena riscrivere cose esistenti: - se sono fatte male - se sono mal documentate - se sono poco supportate da una base utenti/sviluppatori (*) - se non sono licenziate correttamente (i.e. proprietarie) - se non ci sono alternative...
Se solo le cose fossero così semplici! :-) https://security.googleblog.com/2021/03/a-spectre-proof-of-concept-for-spect...
ma in generale vale il pattern "do not reinvent the wheel... badly"
Buona norma, se la ruota che ti serve è disponibile sul mercato. Se no, o ti adatti a ciò che c'è (NIH syndrome) o crei ciò che ti serve. Altrimenti avremmo ruote da carro sui Boing 747 Max.
e poi in generale chi sono io per sindacare (al punto da dire che va riscritto) che so un gcc, un git, un kernel di linux, un server web (apache/nginx) ... pur ritenendomi un decente sviluppatore (pur se non a tempo pieno)
Ma che splendida domanda! :-D La risposta è semplice: il fatto che tu non sia in condizione di "sindacare un GCC o un Linux" è una prova evidente che vadano riscritti. Non avresti alcuna remora, infatti, a sindacare 9front (che non è un kernel, ma un sistema operativo distribuito completo), TinyCC o Netsurf. Dunque chi sei tu per sindacare gli automatismi che ti circondano? Un essere umano capace di farlo. Poi questo diritto di libertà puoi scegliere di non esercitarlo. Non fanno così anche tutti coloro che rinunciano ad usare software libero? Giacomo
(*) forse vi riferivate a qualche pezzo di software trovato a caso su github/gitlab scritto da un singolo (vs. una community solida e numerosa)
No, io facevo riferimento a software open source di Facebook con una vastissima comunità e che come tale risolve problemi di Facebook e di una vastissima comunità. https://it.m.wikipedia.org/wiki/React_(web_framework) Risolve (ma in questo caso sarebbe meglio dire "affronta") problemi molto comuni, come ogni (non-)framework che punti a massimizzare la propria market share. L'errore di molti (troppi) responsabili IT (un po' paraculo) è assumere che "lo usano tutti!" coincida con "risolve tutti i problemi". Poi però tocca ai poveri programmatori/muratori "non laureati" come me risolvere i problemi che queste decisioni causano per anni. Been there, done that.
On 29/04/2021 19:09, Giacomo Tesio wrote:
... Buona norma, se la ruota che ti serve è disponibile sul mercato.
sisi, era nelle mie premesse ;)
Se no, o ti adatti[A] a ciò che c'è (NIH syndrome) o crei[B] ciò che ti serve.
la parentesi va applicata al secondo caso [B], la NIH è la sindrome di chi non si fida per principio di cose fatte da altri (https://en.wikipedia.org/wiki/Not_invented_here) e quindi si scrive tutto in casa (con dispendio enorme di energie e sovente con dubbi risultati)
... La risposta è semplice: il fatto che tu non sia in condizione di "sindacare un GCC o un Linux" è una prova evidente che vadano riscritti.
scusami, non ho svuotato un buffer che avevo in testa troncando il ragionamento, io non posso "sindacare" nel senso che posso criticare quando/quanto voglio tutto quello che voglio (tipo "umarell" da cantiere o politologo da bar), ma per poter pensare di proporre (con speranza di accettazione) anche solo una /patch/ a uno di quei prodotti devo essere credibile, devo saperla presentare, probabilmente dovrò prima farmi un background ed entrare nella community per merito (cfr. libro Hackers di Levy, https://en.wikipedia.org/wiki/Hackers:_Heroes_of_the_Computer_Revolution) ecc.
... Dunque chi sei tu per sindacare gli automatismi che ti circondano? Un essere umano capace di farlo. Poi questo diritto di libertà puoi scegliere di non esercitarlo.
credo ora di essermi spiegato meglio la libertà ce l'ho e me la prendo, spesso, anche pubblicamente, che Stallman o Torvalds mi "caghino" è un altro discorso ;)
Non fanno così anche tutti coloro che rinunciano ad usare software libero?
questa non l'ho capita, ma forse scaturisce dal misunderstanding di cui sopra -- |_|o|_| Andrea Trentini - http://atrent.it |_|_|o| Dipartimento di Informatica |o|o|o| Università degli Studi di Milano
On April 29, 2021 5:27:52 PM UTC, Andrea Trentini <andrea.trentini@unimi.it> wrote:
sisi, era nelle mie premesse ;)
Se no, o ti adatti[A] a ciò che c'è (NIH syndrome) o crei[B] ciò che ti serve.
la parentesi va applicata al secondo caso [B], la NIH è la sindrome di chi non si fida per principio di cose fatte da altri
Hai ragione: scusa(te). Intendevo la sindrome inversa: il rifiuto preconcetto per qualsiasi vera innovazione nata a fronte di esigenze specifiche a vantaggio di soluzioni preconfezionate e ben propagandate. Una situazione che ho visto avvenire più volte ed in diverse aziende in cui ho lavorato. La cosa è triste perché le soluzioni che ho visto (e talvolta creato) precorrevano i tempi di anni. Purtroppo, anche quando era tecnicamente possibile e senzato renderle open source, l'ignoranza del management italiano lo impediva. Persino quando era in procinto di sostituirli con alternative giunte dall'esterno (con costi enormi). Non so se questa sindrome abbia un nome, però.
Dunque chi sei tu per sindacare gli automatismi che ti circondano? Un essere umano capace di farlo. Poi questo diritto di libertà puoi scegliere di non esercitarlo. [...] la libertà ce l'ho e me la prendo, spesso, anche pubblicamente, che Stallman o Torvalds mi "caghino" è un altro discorso ;)
Parlare? Io pensavo ad un'altra forma di espressione: la programmazione di software libero. Quando dico che è tutto da riscrivere, condivido una opinione tecnica professionale. Ma questo semplicemente perché siamo su una mailing list in cui tale parere può essere utile e/o discusso. Ma la libertà di cui parlavo non era quella di critica verbale di Linux o GCC (pur legittima). Pensavo alla critica politica, che come tale, è fattiva e creativa. "Sindacare" GCC o Linux significa creare alternative migliori. Ovvero alternative che una singola persona possa studiare e modificare in un tempo ragionevole, esercitando davvero le libertà garantite dal software libero. Altrimenti queste diventano privilegi elitari. Se tu non puoi sindacare GCC, forkandolo e manutenendolo, esplorando strategie implementative o interfacce diverse, allora GCC non è un software davvero libero per te, quale che sia la licenza. Idem Linux, Firefox, Libre Office etc. Quanto poi al fatto che RMS o Linus ti caghino, giuro che non capisco come dovrebbe essere rilevante. Giacomo
Ciao Giacomo! Giacomo Tesio <giacomo@tesio.it> writes: <joking>
On Thu, 29 Apr 2021 08:48:32 +0200 Andrea Trentini wrote:
sviluppatori affetti da hybris fanno da soli
[...]
In questi giorni sto prendendo parte ad una lunga discussione sull'uso di ReactJS in ambito finanziario.
Già, oggi ci sono un sacco di decisori che sono convinti che le interfacce si possono fare solo in Javascript, possibilmente da far girare nel browser del client :-( Quanti "paradigmi" sono passati sotto i ponti negli ultimi 20 anni?!? :-O ...immagino che tu /non/ stia pensando di scrivere un ReReactJS da solo per farlo meglio ;-) [...]
Potrei parlare ORE dell'inadeguatezza di queste best practice per codebase di decine di milioni di righe di codice che andranno manutenute per decenni (letteralmente) presso clienti con esigenze di sicurezza e regole di deploy estremamente complesse e che richiederanno innumerevoli evoluzioni.
...però coloro che decidono, ai quali hai già spiegato queste cose, non sono d'accordo con te... o non le capiscono? Ti prego /non/ ripondere. :-O
MA mi viene detto che queste best practice vengono adottate con successo da Facebook QUINDI devono andare bene anche per noi.
Perché come per Facebook lo scopo del vostro frontend è quello di esaurire le risorse dei client con una quantità spropositata di cicli di CPU inutili?!? B-) [...]
Fidati Andrea: talvolta non è hybris riscriversi le cose da soli.
Ma perché tu trovi che ci sia carenza di librerie per scrivere frontend, magari *locali*, per la vostra applicazione? Aspetta... mumble mumble: mi stai dicendo non che vogliono che gli utenti non siano "costretti" ad installarsi un client per il vostro backend e quindi deve essere una web app? :-D
E' spirito di sopravvivenza.
Perché tanto poi, i problemi in produzione toccherà risolverli a noi.
Una persona che amo mi dice sempre: "se non li risolvi tu i problemi cosa ci stai a fare?" B-) </joking>
On Thu, 29 Apr 2021 10:22:41 +0200 Giovanni Biscuolo wrote:
--8<---------------cut here---------------start------------->8---
You can't trust code that you did not totally create yourself. (Especially code from companies that employ people like me.)
--8<---------------cut here---------------end--------------->8--- [...] Io SO che NESSUNO sulla faccia della terra, nemmeno il più geniale dei programmatori, è in grado di scriversi (e correggersi) da solo il software che usa
Vedo che hai tolto ad arte esattamente la parte decisamente più importante della mia citazione di Thompson: facciamo che la diamo per scontata? :-P
Per citare Stefano Quintarelli: "lo pensi o lo sai?" :-D
Lo so io e lo sai anche tu :-P ...a meno che tu sia riuscito anche solo a /leggere/ il microcode della tua CPU CISC, che tra l'altro è proprietario (oppure dimmi che hardware usi plz!). Nelle prossime ore (but plz don't hold your breath) tornerò su questo. [...]
Se un software non può essere completamente letto, studiato e compreso in meno di un mese da un singolo essere umano, è "broken beyond repair".
Un software (un programma), ma un sistema è fatto di tantissimo software e nessun essere umano è in grado di gestire (non dico comprendere, con adeguato tempo si può teoricamente fare) tutto il software che compone il proprio sistema: dal microcode della CPU su su fino all'applicazione scritta con ReactJS. BTW non credo che sarei in grado di leggere e comprendere in meno di un mese Emacs... mumble, deve essere irrecuperabile :-O
Ma questa drammatica situazione non è una condizione necessaria, non è una caratteristica naturale, inevitabile del software.
Concordo, non ho mai pensato diversamente ;-) La traccia che da qualche anno amo di più al Fosdem è quella "Minimalistic" (es. https://fosdem.org/2021/schedule/track/declarative_and_minimalistic_computin...) ...e le cose che mi incuriosiscono di più sono esperimenti spinti tipo «code is content-addressed and immutable.» di https://www.unisonweb.org/ (che conosco solo "sulla carta") Tante idee nuove (nuove?) che prima o poi verranno adottate anche "dall'industria"... ah se solo "l'accademia" avesse un po' più di coraggio (e risorse)! [...]
Può (e deve) essere _semplicemente_ riscritto.
Prima o poi gli incentivi che determinano questo stato di cose, non solo nel software, spariranno e allora ci saranno un sacco di fantastiche risorse (eoni di neuroni) da "spendere" anche per questo.
Non per hybris, ma per spirito di sopravvivenza.
Sì ma non da soli, tutto qui. [...] Ciao, Giovanni. -- Giovanni Biscuolo Noi, incompetenti come siamo, non abbiamo alcun titolo per suggerire alcunché.
Scusa Giovanni, sì la parte che ho omesso della citazione pensavo fosse scontata, ma la riporto qui --8<---------------cut here---------------start------------->8--- In demonstrating the possibility of this kind of attack, I picked on the C compiler. I could have picked on any program-handling program such as an assembler, a loader, or even hardware microcode. As the level of program gets lower, these bugs will be harder and harder to detect. A well-installed microcode bug will be almost impossible to detec. --8<---------------cut here---------------end--------------->8---
On Thu, 29 Apr 2021 10:22:41 +0200 Giovanni Biscuolo wrote:
--8<---------------cut here---------------start------------->8---
You can't trust code that you did not totally create yourself. (Especially code from companies that employ people like me.)
--8<---------------cut here---------------end--------------->8--- [...] Io SO che NESSUNO sulla faccia della terra, nemmeno il più geniale dei programmatori, è in grado di scriversi (e correggersi) da solo il software che usa
Per citare Stefano Quintarelli: "lo pensi o lo sai?" :-D
Lo so io e lo sai anche tu :-P
...a meno che tu sia riuscito anche solo a /leggere/ il microcode della tua CPU CISC, che tra l'altro è proprietario
Giovanni, io so che si può fare e come sai ho iniziato a farlo. La strada è lunga per cui non resta che camminare, un passo alla volta. Ma il microcode della mia cpu centra come i cavoli a merenda. La prima generazione di software libero è stata scritta per anni su macchine che eseguivano software proprietario. La seconda verrà scritta su macchine che eseguono complicato software open source. E sarà semplice per permettere A TUTTI di esercitare pienamente le 4 libertà. Ma se nessuno ci prova seriamente, nessuno ci riuscirà mai. Giacomo
On 29/04/2021 15:56, Giacomo Tesio wrote:
... Se un software non può essere completamente letto, studiato e compreso in meno di un mese da un singolo essere umano, è "broken beyond repair".
mi pare un po' draconiano come criterio, diciamo che accetterei l'affermazione se per "software" si intendesse una "funzione/classe" (dandone una definizione più precisa[*], specie dal punto di vista delle dimensioni, che in questo caso contano), per il resto dato che ogni sistema (in senso lato, anche non software) è tipicamente un insieme di sottosistemi tra loro interagenti voler applicare quel principio a qualunque livello è impossibile, pensa se, metaforicamente parlando, lo applicassimo alla medicina: Se un organo non può essere completamente studiato e compreso in meno di un mese da un singolo essere umano, è "broken beyond repair". o all'astronomia: Se un pianeta non può essere completamente studiato e compreso in meno di un mese da un singolo essere umano, è "broken beyond repair". ecc. [*] una Macchina di Turing generica? Ma temo che oltre una certa dimensione (del numero degli stati, dei nastri, ecc.) sia difficile comprenderla senza farla mangiare a qualche tipo di analizzatore... software ;) -- |_|o|_| Andrea Trentini - http://atrent.it |_|_|o| Dipartimento di Informatica |o|o|o| Università degli Studi di Milano
Spero davvero che non annoiamo nessuno, ma... :-D On April 29, 2021 6:31:08 PM UTC, Andrea Trentini <andrea.trentini@unimi.it> wrote:
On 29/04/2021 15:56, Giacomo Tesio wrote:
... Se un software non può essere completamente letto, studiato e compreso in meno di un mese da un singolo essere umano, è "broken beyond repair".
mi pare un po' draconiano come criterio
Così (ap)pare a molti, in effetti. D'altronde quanto software conosci che lo rispetta? Confrontato con il software mainstream cui siamo abituati, appare impossibile. Immagina di stampare Linux (oltre 20 milioni di righe di codice C): carattere 11, circa 30 righe a pagina: fa circa 666 (!!! :-D) risme A4 fronte-retro. Quante opere filosofiche o ricerche scientifiche conosci con tale complessità? Naturalmente per studiarlo non usiamo una lettura lineare e disponiamo di strumenti e tecniche di navigazione del codice che possono tranquillamente dimezzare il tempo necessario. Ci vuole comunque troppo tempo. Chi se lo può permettere? È accettabile? È sostenibile? Secondo me, no. Un mese è già moltissimo. Ma è sufficiente per molti software non-mainstream. Di quelli che fanno una sola cosa molto bene, per intenderci.
diciamo che accetterei l'affermazione se per "software" si intendesse una "funzione/classe"
Uhm... no. Se ci vuole un mese a studiare una funzione, quel software va bruciato e vanno sparse le ceneri ai quattro angoli del pianeta. E a chi la scritto va vietato il contatto diretto con qualsiasi apparecchiatura informatica.
dato che ogni sistema (in senso lato, anche non software) è tipicamente un insieme di sottosistemi tra loro interagenti
A questo proposito per "software" in questo thread non intendo un singolo eseguibile, ma un singolo progetto di sviluppo. Una libreria o un framework sviluppata da una comunità a sé stante, dovrebbe essere studiabile completamente in meno di un mese, così come il codice di una applicazione indipendente che utilizza 12 librerie diverse. Un po' come un teorema può usarne un altro nella propria dimostrazione: sta a te decidere se vuoi andare a rileggere il teorema menzionato, o fidarti. Ma se so che, nel caso, mi basta al mqx un mese per comprenderne la codebase sono più propenso a fidarmi: tu no?
voler applicare quel principio a qualunque livello è impossibile, pensa se, metaforicamente parlando, lo applicassimo alla medicina .. o all'astronomia
Il software è un artefatto umano, non una creazione divina. Come tale è lecito pretendere che abbia alcune caratteristiche fondamentali per garantire la sicurezza e la libertà di una società cibernetica come la nostra. Come pretendiamo che le bottiglie di latte al supermercato non contengano diossina possiamo pretendere che un software richieda un certo tempo massimo per essere studiato, nell'interesse della salute cibernetica di tutti. Giacomo
On 29/04/2021 23:05, Giacomo Tesio wrote:
Spero davvero che non annoiamo nessuno, ma... :-D
spero anche io ;)
On April 29, 2021 6:31:08 PM UTC, Andrea Trentini <andrea.trentini@unimi.it> wrote:
On 29/04/2021 15:56, Giacomo Tesio wrote:
... Se un software non può essere completamente letto, studiato e compreso in meno di un mese da un singolo essere umano, è "broken beyond repair".
mi pare un po' draconiano come criterio
Così (ap)pare a molti, in effetti.
D'altronde quanto software conosci che lo rispetta?
appunto, proprio perché è un criterio sostanzialmente inapplicabile avrebbe senso ribaltarlo, definendo come "atomo programmativo valutabile" quella parte del sistema comprensibile in un mese (anche meno) da una singola persona
Naturalmente per studiarlo non usiamo una lettura lineare e disponiamo di strumenti e tecniche di navigazione del codice che possono tranquillamente dimezzare il tempo necessario.
strumenti software che andrebbero a loro volta studiati e capiti, in un mese ;)
Ci vuole comunque troppo tempo. Chi se lo può permettere?
applicando questo approccio del "mese per comprendere" alla realtà analogica credo si possa capire la sua inapplicabilità
...
diciamo che accetterei l'affermazione se per "software" si intendesse una "funzione/classe"
Uhm... no.
Se ci vuole un mese a studiare una funzione, quel software va bruciato e vanno sparse le ceneri ai quattro angoli del pianeta.
infatti un mese è troppo per un singolo "atomo programmativo", la variabile tempo è da stabilire oppure vedi sopra (ribaltamento della definizione)
... Una libreria o un framework sviluppata da una comunità a sé stante, dovrebbe essere studiabile completamente in meno di un mese, così come il codice di una applicazione indipendente che utilizza 12 librerie diverse.
Un po' come un teorema può usarne un altro nella propria dimostrazione: sta a te decidere se vuoi andare a rileggere il teorema menzionato, o fidarti.
esatto, io propongo di definire un "atomo programmativo" come l'artefatto (funzione/classe/ecc.) comprensibile in un tempo ragionevole (qualche giorno?)
... Il software è un artefatto umano, non una creazione divina.
sono ateo e sbattezzato ;)
... Come pretendiamo che le bottiglie di latte al supermercato non contengano diossina possiamo pretendere che un software richieda un certo tempo massimo per essere studiato, nell'interesse della salute cibernetica di tutti.
concordo, ma (citando un film che adoro) "you have to remember that a worm[bottiglia di latte]... with very few exceptions... is not a human being[kernel di linux]." -- |_|o|_| Andrea Trentini - http://atrent.it |_|_|o| Dipartimento di Informatica |o|o|o| Università degli Studi di Milano
Ciao Andrea,
Il software è un artefatto umano, non una creazione divina.
sono ateo e sbattezzato ;)
Lo sono stato anche io per il 60% della mia vita (ateo). Non vedo come sia rilevante. Che tu faccia derivare l'universo da una fortunatissima coincidenza che ha prodotto casualmente leggi fisiche stabili e tarate esattamente per permettere alle stelle di splendere ed agli uomini di ammirarle, o che tu creda che queste abbiano un Autore, rimane il fatto che i fenomeni di cui parli trascendono la nostra volontà. L'uomo può studiare questi fenomeni, può provare a comprenderne l'evoluzione nel tempo, e persino imparare (in alcuni casi ed entro limiti piuttosto stringenti) ad influenzarla, ma non li ha creati e non può deciderne la struttura o il funzionamento. Non può imporre loro norme di sicurezza (per sé, per la società o l'ecosistema): anche se non ci piace l'idea che il sole esploda fra qualche milione di anni, non possiamo impedirlo. Il software invece lo scriviamo noi e quindi POSSIAMO scriverlo meglio. Insomma "Si può fare!" ;-)
Se un software non può essere completamente letto, studiato e compreso in meno di un mese da un singolo essere umano, è "broken beyond repair".
mi pare un po' draconiano come criterio
Così (ap)pare a molti, in effetti.
D'altronde quanto software conosci che lo rispetta?
appunto, proprio perché è un criterio sostanzialmente inapplicabile
Eppure molti software non-mainstream lo applicano con successo. Ovviamente lo applicano perché non ambiscono al lock-in di vaste user-base da sfruttare economicamente e non hanno alcun interesse nel porre barriere artificiali per mantenere il controllo dello sviluppo o ridurre la probabilità di successo dei fork. Direi dunque che si tratta di un criterio perfettamente applicabile, fuori dall'open source.
avrebbe senso ribaltarlo, definendo come "atomo programmativo valutabile" quella parte del sistema comprensibile in un mese (anche meno) da una singola persona
Sarebbe una definizione inutile. E' un po' come dire che un libro deve essere composto di pagine leggibili entro un mese: ok, potrai valutare una pagina alla volta. E poi? Dire invece che ogni progetto software libero DEVE essere completamente comprensibile entro un mese, significa stabilire un criterio ragionevole a tutela della effettiva praticabilità delle 4 libertà. Se fosse imposto per legge a tutto il software, questo principio farebbe sparire una enorme quantità di problemi della società cibernetica contemporanea, incluso il capitalismo di sorveglianza e i bug di Horizon che hanno distrutto la vita di centinaia di lavoratori delle poste inglesi.
Naturalmente per studiarlo non usiamo una lettura lineare e disponiamo di strumenti e tecniche di navigazione del codice che possono tranquillamente dimezzare il tempo necessario.
strumenti software che andrebbero a loro volta studiati e capiti, in un mese ;)
Naturalmente. Ma non è che ci dobbiamo mettere tutti a leggere gli stessi libri! Nello stesso modo, non è importante che tutti rileggiamo lo stesso software: sarà sufficiente che qualunque software possa essere completamete compreso in un mese. Questa condizione, da sola, incrementerebbe nettamente la qualità del software stesso e la sicurezza cibernetica di tutti coloro che vi interagiscono. Giacomo
On 03/05/2021 11:36, Giacomo Tesio wrote:
Ciao Andrea,
Il software è un artefatto umano, non una creazione divina. sono ateo e sbattezzato ;)
Lo sono stato anche io per il 60% della mia vita (ateo). Non vedo come sia rilevante.
non lo è ;) era solo un riflesso condizionato il mio
... Il software invece lo scriviamo noi e quindi POSSIAMO scriverlo meglio.
certamente! e sono d'accordo che molto software è scritto "male" (criterio in parte soggettivo e in parte oggettivo: anni e anni di SwEng saran pure serviti a qualcosa), ma ridurre tutto al "mese per comprendere" quando esistono le "leggi di composizione" (dei sistemi) è impossibile, se un "atomo programmativo" richiede un TOT per essere compreso, una composizione di "atomi programmativi" richiede...? 1) sempre un TOT (questo mi suona paradossale) 2) la somma dei TOT_i di ogni atomo_i 3) un valore MAGGIORE della 2) se l'interazione fra gli atomi aumenta la complessità a naso propenderei per 3) salvo casi "banali" (tipo le /pipe/ di Unix, ma non sono nemmeno sicuro di quelle) -- |_|o|_| Andrea Trentini - http://atrent.it |_|_|o| Dipartimento di Informatica |o|o|o| Università degli Studi di Milano
On Mon, 03 May 2021 11:57:45 +0200 Andrea Trentini wrote:
ma ridurre tutto al "mese per comprendere" quando esistono le "leggi di composizione" (dei sistemi) è impossibile, se un "atomo programmativo" richiede un TOT per essere compreso, una composizione di "atomi programmativi" richiede...?
un mese, assumendo che i vari componenti (ciascuno dei quali richiede un mese per essere compreso) rappresenti l'elaborazione documentata. Nota però che io ho parlato di software come processo creativo, come artefatto intellettuale collettivo, caratterizzato da una propria evoluzione indipendente, non come specifico eseguibile. Chromium è composto di centinaia di moduli, tutti controllati da Google. Idem Android. Alcuni di questi moduli (ma non tutti) sono effettivamente comprensibili in un mese, ma il software, inteso appunto come processo di sviluppo, non come prodotto (anche perché il prodotto è sempre solo un'istantanea sul processo di sviluppo), è UNO ed è controllato complessivamente da una singola entità. Dunque Chromium non garantisce le 4 libertà se non formalmente. Idem Android. O Linux. O GCC. O Libre Office. O Firefox. O... Mi potresti obiettare che, ad esempio, non si può scrivere un browser che rispetti gli standard moderni in modo che sia comprensibile in un mese. Ed è vero. Infatti quegli standard sono essi stessi "broken beyond repair". Ed è ovvio: quegli standard sono creati da coloro che beneficiano di questa enorme ed ingestibile complessità. Per contro, nel mese per comprendere un software io non includo il tempo necessario a comprendere tutte le sue dipendenze INDIPENDENTI, purché ciascuna di esse, rispetti lo stesso principio. Se sto studiando uno script shell, non andrò necessariamente a studiare il sorgente di ciascuno dei programmi che invoca, delle librerie da cui dipendono etc: è sufficiente che io possa farlo, che siano facilmente "sgamabili" se cercando di minare bitcoin o inviare i miei dati a Google e che siano facilmente sostituibili una volta sgamati. In un mondo in cui ogni software (o ogni azienda, ogni partito, ogni associazione etc) può essere utile, ma DEVE essere trasparente e sostituibile, ogni produttore avrebbe un assoluto interesse a NON provare nemmeno a tradire la fiducia di coloro che lo adottano.
a naso propenderei per 3) salvo casi "banali" (tipo le /pipe/ di Unix, ma non sono nemmeno sicuro di quelle)
Le pipe in Unix non sono banali, sono semplici. Determinano un meccanismo semplice per comporre elaborazioni complesse attraverso software semplici. Da questo punto di vista, file e filesystem in Plan 9 hanno una funzione analoga: grazie al protocollo 9P2000 (estremamente semplice) è possibile comporre elaborazioni molto complesse integrando programmi molto semplici. Confronta X o Wayland con rio, o Emacs/Vim con Acme, e capirai cosa intendo. Entrambi i programmi (rio e acme) richiedono molto meno di un mese per essere letti e compresi (direi circa una settimana). Giacomo
Immagina di stampare Linux (oltre 20 milioni di righe di codice C): carattere 11, circa 30 righe a pagina: fa circa 666 (!!! :-D) risme A4 fronte-retro. Quante opere filosofiche o ricerche scientifiche conosci con tale complessità?
Questa cosa merita di essere approfondita perché, secondo me, può interessare anche i non addetti. Quando un giornalista, un giurista o, comunque, un non informatico, usa la frase "l'algoritmo deve essere noto" (scambiando algoritmo, più di moda, per software) probabilmente non ha idea, o ce l'ha solo parzialmente, della complessità che c'è dietro. Parafrasando il "divide et impera", verrebbe da dire, "confunde et impera". I sistemi operativi di oggi, pur rientrando, forse, tra gli ecosistemi software più complessi, non rappresentano che una piccolissima parte di ciò che c'è dall'altra parte del "filo", nei server. Di Google si parla di DUE MILIARDI di righe di codice [1] e ogni giorno 25000 suoi sviluppatori modificano, a mano o tramite bot, milioni di righe. Caro Giacomo, la battaglia per la semplicità la stiamo perdendo, perché la semplicità porta alla trasparenza e la trasparenza all'onestà (e non intendo solo l'onestà intellettuale). Bisogna coniare un nuovo termine, dopo "free software", dopo "open source", all'acronimo FOSS ("Free and open source software") dobbiamo aggiungere una S, FOSSS ("Free, open and simple source software"), che unisca il FOSS e l'imperativo KISS ( "Keep It Simple, Stupid"). Antonio [1] https://thenextweb.com/news/googles-codebase-spans-2-billion-lines-40-times-...
Buongiorno, Enrico Nardelli <nardelli@mat.uniroma2.it> writes: [...]
Io penso che se, prima di tutto nella scuola, sviluppiamo una buona sensibilità all'informatica come "linguaggio per la descrizione di processi che automaticamente e meccanicamente eseguono trasformazione di rappresentazioni"
solo per capire la semantica di questa fantastica definizione, comprese le sue innumerevoli conseguenze, servirebbe... più informatica. Ops, siamo in un cul de sacc :-D [...]
CHI ha scelto COSA rappresentare e COSA NO? COSA viene modellato da tali rappresentazioni? COSA viene trascurato? CHI ha scelto COME trasformare?
Mi permetto di aggiungere: chi MISURA cosa rappresentare? Come sono gestiti gli STRUMENTI di misura (metrologia)? Sono tenuti in considerazione nel processo RISOLUZIONE e ERRORE di misura? Come viene gestita (e tracciata) la CATENA delle misurazioni/dati/testi (provenance)? Come garantire che la CATENA di trasformazione sia RIPRODUCIBILE? Come INTERPRETARE i dati ottenuti dalle trasformazioni (correlazione vs. causalità)? ...lista probabilmente non esaustiva. [...]
E all'università, non ritengo che bisogna preparare "programmatori", ma informatici. E non è solo "pedanteria accademica" :-)
Ma certo che no: c'è DAVVERO qualcuno che lo pensa?!? :-O [...]
saper programmare benissimo, ma non aver capito il ruolo dei sistemi informatici all'interno del lavoro di organizzazioni di varia complessità produce, in genere, disastri.
Oh sì, è per questo che ai periti tecnici in informatica insegnano (insegnano ancora?) ad essere "ANALISTI programmatori", mica "programmatori": --8<---------------cut here---------------start------------->8--- un analista si preoccupa di analizzare il dominio applicativo e le specifiche dei requisiti per poi produrre i documenti di analisi, utilizzati nelle fasi successive di progettazione e sviluppo del software. --8<---------------cut here---------------end--------------->8--- (https://it.wikipedia.org/wiki/Analista_programmatore) ... e si insegna loro che il ciclo di vita del software inizia con l'analisi, mica col buttarsi a pesce a scrivere codice. Mi permetto, modestamente, di aggiungere alla categoria anche una figura professionale alquanto negletta: l'analista di SISTEMA. (https://en.wikipedia.org/wiki/Systems_analyst); uno sporco lavoro che qualcuno si dovrebbe pur occupare di svolgere in un /sistema/ IT, no? Però, però.... PERÓ tutto questo ha un /costo/ e /qualcuno/ ha deciso, tanto tempo fa, che sono costi inutili, che vanno scaricati in OUTSOURCING, con lavoro gestito da imprese che sanno come si compete sul mercato per abbattere i costi (e massimizzare i profitti, ma questo è un effetto collaterale)... voilà, benvenuti nel 2021! [...]
Moltissime micro e piccole imprese italiane non hanno necessità di un laureato per le loro esigenze informatiche, gli basterebbe un diplomato, anche qui che sia preparato come un "informatico" in grado di definire un progetto in relazione alle esigenze dell'utente e non semplicemente come un "programmatore" che genera codice.
Concordo in pieno la diagnosi (l'analisi) con l'unica differenza (pignoleria?) che la definizione corretta del paziente in cura è "analista sistemista"; tuttavia la prognosi è riservata: il paziente "geometra dell'informatica" inserito nel contesto di cui sopra è in stato vegetativo, non diamo inutili speranze a chi lo conosce. :-( Per avere idea dello stato dei lavoratori nel settore IT (NON dei "geometri dell'informatica" che non esistono) è utile seguire «Tech Workers Coalition Italia» di tanto in tanto: https://twc-italia.org/ [1]; se stanno messi così loro che lavorano per le multinazionali o comunque grandi aziende, immaginatevi gli altri. D'altro canto, fare business nel campo del software (magari software libero) nelle attuali condizioni di mercato è una attività DI NICCHIA, un pertugio oserei dire. Vedremo se le misure contenute nel PNRR miglioreranno le condizioni del mercato e quelle dei lavoratori IT, magari facendo pure uscire i "geometri dell'informatica" dal coma... io NON ci conto. [...] Saluti, Giovanni. [1] e le consorelle internazionali, mica si tratta di un problema prettamente italiano. -- Giovanni Biscuolo Noi, incompetenti come siamo, non abbiamo alcun titolo per suggerire alcunché.
Caro Giovanni grazie per i complimenti della tua precedente mail. Su questa condivido le ulteriori precisazioni alla lista di questioni importanti relative all'informatica che tutti i cittadini dovrebbero essere in grado di comprendere ma per il resto, perdonami, non riesco a capire se c'è qualcosa su cui posso fornire un approfondimento. Ciao, Enrico Il 28/04/2021 12:52, Giovanni Biscuolo ha scritto:
Buongiorno,
Enrico Nardelli <nardelli@mat.uniroma2.it> writes:
[...]
Io penso che se, prima di tutto nella scuola, sviluppiamo una buona sensibilità all'informatica come "linguaggio per la descrizione di processi che automaticamente e meccanicamente eseguono trasformazione di rappresentazioni"
solo per capire la semantica di questa fantastica definizione, comprese le sue innumerevoli conseguenze, servirebbe... più informatica. Ops, siamo in un cul de sacc :-D
[...]
CHI ha scelto COSA rappresentare e COSA NO? COSA viene modellato da tali rappresentazioni? COSA viene trascurato? CHI ha scelto COME trasformare?
Mi permetto di aggiungere: chi MISURA cosa rappresentare? Come sono gestiti gli STRUMENTI di misura (metrologia)? Sono tenuti in considerazione nel processo RISOLUZIONE e ERRORE di misura? Come viene gestita (e tracciata) la CATENA delle misurazioni/dati/testi (provenance)? Come garantire che la CATENA di trasformazione sia RIPRODUCIBILE? Come INTERPRETARE i dati ottenuti dalle trasformazioni (correlazione vs. causalità)?
...lista probabilmente non esaustiva.
[...]
E all'università, non ritengo che bisogna preparare "programmatori", ma informatici. E non è solo "pedanteria accademica" :-)
Ma certo che no: c'è DAVVERO qualcuno che lo pensa?!? :-O
[...]
saper programmare benissimo, ma non aver capito il ruolo dei sistemi informatici all'interno del lavoro di organizzazioni di varia complessità produce, in genere, disastri.
Oh sì, è per questo che ai periti tecnici in informatica insegnano (insegnano ancora?) ad essere "ANALISTI programmatori", mica "programmatori":
--8<---------------cut here---------------start------------->8---
un analista si preoccupa di analizzare il dominio applicativo e le specifiche dei requisiti per poi produrre i documenti di analisi, utilizzati nelle fasi successive di progettazione e sviluppo del software.
--8<---------------cut here---------------end--------------->8--- (https://it.wikipedia.org/wiki/Analista_programmatore)
... e si insegna loro che il ciclo di vita del software inizia con l'analisi, mica col buttarsi a pesce a scrivere codice.
Mi permetto, modestamente, di aggiungere alla categoria anche una figura professionale alquanto negletta: l'analista di SISTEMA. (https://en.wikipedia.org/wiki/Systems_analyst); uno sporco lavoro che qualcuno si dovrebbe pur occupare di svolgere in un /sistema/ IT, no?
Però, però.... PERÓ tutto questo ha un /costo/ e /qualcuno/ ha deciso, tanto tempo fa, che sono costi inutili, che vanno scaricati in OUTSOURCING, con lavoro gestito da imprese che sanno come si compete sul mercato per abbattere i costi (e massimizzare i profitti, ma questo è un effetto collaterale)... voilà, benvenuti nel 2021!
[...]
Moltissime micro e piccole imprese italiane non hanno necessità di un laureato per le loro esigenze informatiche, gli basterebbe un diplomato, anche qui che sia preparato come un "informatico" in grado di definire un progetto in relazione alle esigenze dell'utente e non semplicemente come un "programmatore" che genera codice.
Concordo in pieno la diagnosi (l'analisi) con l'unica differenza (pignoleria?) che la definizione corretta del paziente in cura è "analista sistemista"; tuttavia la prognosi è riservata: il paziente "geometra dell'informatica" inserito nel contesto di cui sopra è in stato vegetativo, non diamo inutili speranze a chi lo conosce. :-(
Per avere idea dello stato dei lavoratori nel settore IT (NON dei "geometri dell'informatica" che non esistono) è utile seguire «Tech Workers Coalition Italia» di tanto in tanto: https://twc-italia.org/ [1]; se stanno messi così loro che lavorano per le multinazionali o comunque grandi aziende, immaginatevi gli altri.
D'altro canto, fare business nel campo del software (magari software libero) nelle attuali condizioni di mercato è una attività DI NICCHIA, un pertugio oserei dire.
Vedremo se le misure contenute nel PNRR miglioreranno le condizioni del mercato e quelle dei lavoratori IT, magari facendo pure uscire i "geometri dell'informatica" dal coma... io NON ci conto.
[...]
Saluti, Giovanni.
[1] e le consorelle internazionali, mica si tratta di un problema prettamente italiano.
_______________________________________________ nexa mailing list nexa@server-nexa.polito.it https://server-nexa.polito.it/cgi-bin/mailman/listinfo/nexa
-- EN ===================================================================== Prof. Enrico Nardelli Dipartimento di Matematica - Universita' di Roma "Tor Vergata" Via della Ricerca Scientifica snc - 00133 Roma tel: +39 06 7259.4204 fax: +39 06 7259.4699 mobile: +39 335 590.2331 e-mail: nardelli@mat.uniroma2.it home page: http://www.mat.uniroma2.it/~nardelli blog: http://www.ilfattoquotidiano.it/blog/enardelli/ http://link-and-think.blogspot.it/ ===================================================================== --
Ciao Enrico, Enrico Nardelli <nardelli@mat.uniroma2.it> writes: [...]
ma per il resto, perdonami, non riesco a capire se c'è qualcosa su cui posso fornire un approfondimento.
mi spiace aver creato confusione, i miei erano semplicemente ulteriori considerazioni in libertà in merito al rapporto tra cultura informatica, scuola, università e mondo del lavoro. Non era una critica a quello che hai scritto o una richiesta di approfondire da parte tua ma, appunto, solo miei contributi nel merito. Ciao, Giovanni. [...] -- Giovanni Biscuolo Noi, incompetenti come siamo, non abbiamo alcun titolo per suggerire alcunché.
Buongiorno Enrico, buongiorno nexiane Enrico Nardelli <nardelli@mat.uniroma2.it> writes:
Una mia micro-riflessione sulla missione M4C1.3 Ampliamento delle competenze e potenziamento delle infrastrutture, relativamente all'investimento 3.1: Nuove competenze e nuovi linguaggi
https://www.key4biz.it/pnrr-e-trasformazione-digitale-dove-linformatica/3573...
Per quel poco che conta (per me moltissimo, anche se solo /simbolicamente/) voglio ringraziare pubblicamente te - e con te tutte le altre persone che hanno portato avanti iniziative analoghe - per gli *incredibili* sforzi che personalmente e professionalmente compi per tentare di far comprendere il messaggio a coloro che - da quello che osservo - sono sordi /semplicemente/ perché non vogliono ascoltare, /qualsiasi/ sia il motivo che li spinge a non ascoltare (che si tratti di carenze culturali dubito). Grazie di cuore a tutte le persone di buona volontà che si sono spese per far entrare un po' di ragione (per "dare senso") nel PNRR introducendo il software libero (o open source) come elemento strategico di RESILIENZA... e l'educazione informatica É software libero :-D I contenuti del PNRR - a mio modesto avviso e dopo una rapida scorsa - sono un po' deludenti e il documento (per essere politicamente _scorrettissimo_) è figlio di vecchie /ideologie/ condite di terminologia /techno-cool/ vuota, senza contenuti realmente nuovi. Per quello io provocatoriamente avrei preferito si parlasse di Next (re)Generation EU. La cosa /estremamente/ positiva di tutto ciò è che le idee sane e ben strutturate sopravviveranno a tutti i futuri fallimenti (prima o poi ci sarà l'ultimo fallimento) e quando finalmente ci sarà qualcuno disposto ad ascoltare (in grado di capire?) /cose/ davvero nuove tutto questo lavoro darà eccellenti frutti: la RIgenerazione delle nostre società. [...] Cordiali saluti, Giovanni. -- Giovanni Biscuolo Noi, incompetenti come siamo, non abbiamo alcun titolo per suggerire alcunché.
Antonio Iacono <antiac@gmail.com> writes:
La versione 2.0 del Recovery Fund, ora PNRR, è pronta [1].
[...]
C'è solo in formato PDF? Almeno in HTML no eh? Microsoft® Word 2010 dovrebbe essere in grado di esportare anche in HTML, no? Comunque: ieri il documento c'era [2] e oggi... errore 404 (pagina non trovata)... è un documento effimero o farà parte dei primi provvedimenti della Transizione Digitale della nuova era? :-D Per fortuna qualche brava persona (grazie anonime persone!) lo ha salvato nella gloriosa Wayback Machine: https://web.archive.org/web/*/https://www.governo.it/sites/governo.it/files/... ...così potremmo sempre fare il (pdf)diff [3] delle varie versioni che circolano visto che il documento NON è ufficialmenre revisionato (eh no, la gestione delle revisioni non è un vezzo da pignoletti). Mi raccomando, se lo vedete ricomparire sul sito ufficiale del governo per favore salvatene una copia nella Wayback Machine attraverso questo link https://web.archive.org/save Saluti, Giovanni [2] Lo dice anche DuckDuckGo https://duckduckgo.com/?q=PNRR+site%3Ahttps%3A%2F%2Fwww.governo.it%2F che lo trova come secondo documento nella ricerca [3] peccato perché il diff dei formati solo testo è così efficace e chiaro... :-( -- Giovanni Biscuolo Noi, incompetenti come siamo, non abbiamo alcun titolo per suggerire alcunché.
Comunque: ieri il documento c'era [2] e oggi... errore 404 (pagina non trovata)... è un documento effimero o farà parte dei primi provvedimenti della Transizione Digitale della nuova era? :-D
Che vuoi, i "ragazzi" giocano. Hanno scoperto questa "cosa" strana che è il web. Qualcuno però dovrebbe spiegare loro che i link, le url, possono anche prendere strade autonome, mica tutti siamo "follower" sui social e cliccatori seriali di ogni novità. Allora, vediamo se cambiano anche questo: https://www.governo.it/it/articolo/pnrr/16718 che ha un riferimento, per il piano, a: https://www.governo.it/sites/governo.it/files/PNRR_0.pdf Antonio
Antonio Iacono <antiac@gmail.com> writes: [...]
Qualcuno però dovrebbe spiegare loro che i link, le url, possono anche prendere strade autonome, mica tutti siamo "follower" sui social e cliccatori seriali di ogni novità.
Non ci posso credere che l'URL di un documento ufficiale del governo italiano sia già vittima di link rot! Cioè non lo hanno _sostituito_ (magari anche scusandosi per l'errore), lo hanno *rinominato*: cos'è la prima best practice di resilienza digitale?!? :-O
Allora, vediamo se cambiano anche questo: https://www.governo.it/it/articolo/pnrr/16718 che ha un riferimento, per il piano, a: https://www.governo.it/sites/governo.it/files/PNRR_0.pdf
Per la miseria, il piano è passato da 337 pagine a 273 in un sol giorno e /senza/ il becco di una spiegazione? Qual'è il documento approvato in consiglio dei ministri? Oh mamma, se questo è l'inizio... E alla Commissione EU che versione daranno? Una modificata da una "manina anonima" a insaputa del CDM e del Parlamento? (come se non fosse già successo). Quando ho detto che sarebbe stato necessario un pdfdiff stavo scherzando ma adesso mi è passato l'umorismo :-O... serve un repo git con i PDF convertiti in testo e la possibilità di effettuare un diff... uff. Per un attimo ho pensato che Antonio avesse "scovato" una bozza che è stata pubblicata per errore /ma/ questo articolo fa un po' di luce sull'accaduto: «Recovery plan, il file sul sito del governo cambiato in corsa prima che parlasse Draghi. Slittano i tempi della riforma della giustizia» di F. Q., 27 APRILE 2021 https://www.ilfattoquotidiano.it/2021/04/27/recovery-plan-il-file-sul-sito-d... --8<---------------cut here---------------start------------->8--- Due ore prima che il premier parlasse alla Camera la versione da 337 pagine pubblicata il 25 aprile è scomparsa e al suo posto ne è stata pubblicata un'altra, 273 pagine con grafici e tabelle più colorati ed elaborati nello stile. Ma a cambiare non è stata solo la forma [...] L’ultima versione è stata creata il 26 aprile, ore 13:35. Ultima modifica alle 14:33: due ore prima che Mario Draghi cominciasse a illustrare il Piano di ripresa e resilienza alla Camera. E’ in quel momento che, sul sito del governo, il file con il testo del documento che ha dentro “il destino del Paese” è stato sostituito, senza darne comunicazione. Quello da 337 pagine pubblicato nel pomeriggio di domenica (ora di creazione 12:29 del 25 aprile) è scomparso e al suo posto ne è stato pubblicato un altro, 273 pagine con grafici e tabelle più colorati ed elaborati nello stile. Non a caso sul sito della Camera ora si legge: “Testo del PNRR (versione aggiornata)”. Ma a cambiare non è stata solo la forma: sono stati fatti ritocchi tutt’altro che banali al capitolo dedicato alla riforma della giustizia. In particolare per quanto riguarda i tempi. [...] --8<---------------cut here---------------end--------------->8--- Non è resiliente nemmeno il piano. Saluti, Giovanni -- Giovanni Biscuolo Noi, incompetenti come siamo, non abbiamo alcun titolo per suggerire alcunché.
Per la miseria, il piano è passato da 337 pagine a 273 in un sol giorno e /senza/ il becco di una spiegazione? Qual'è il documento approvato in consiglio dei ministri? Oh mamma, se questo è l'inizio...
- "Houston, abbiamo un problema" - "Con la congettura di Riemann? Con il secondo teorema di incompletezza di Godel? Diteci ... " - "No ... mmmmmh, con l'addizione" - "Ah, ecco perché volete colmare le "carenze quantitative" degli studenti, avete bisogno di qualcuno che sappia *contare* " Pagina 10. "Se alle sovvenzioni stimate della RRF si somma la prima tranche dei trasferimenti dal REACT-EU (37,5 miliardi su un totale di 47,5 miliardi), il quadro complessivo che emerge è quello riportato nella figura 1.2, in cui le risorse disponibili per i principali Stati membri vengono rapportate al livello del Pil nel 2019." Peccato che nella figura 1.2 il REACT-EU NON è stato aggiunto tanto è vero che la somma delle risorse per Stato è pari a 313 miliardi, cioè le sovvenzioni dell'RRF. Mi sono fermato alla pagina 10, non ho avuto il coraggio di andare avanti. Mah, speriamo nella versione 1.0 (quella di oggi e quella dei giorni scorsi evidentemente sono versioni beta e alfa). Antonio
Antonio Iacono <antiac@gmail.com> writes: [...]
Pagina 10.
"Se alle sovvenzioni stimate della RRF si somma la prima tranche dei trasferimenti dal REACT-EU (37,5 miliardi su un totale di 47,5 miliardi), il quadro complessivo che emerge è quello riportato nella figura 1.2, in cui le risorse disponibili per i principali Stati membri vengono rapportate al livello del Pil nel 2019."
Peccato che nella figura 1.2 il REACT-EU NON è stato aggiunto tanto è vero che la somma delle risorse per Stato è pari a 313 miliardi, cioè le sovvenzioni dell'RRF.
Mi pare di poter confermare, così come /mi pare/ che la didascalia sia chiara: «Figura 1.2: Allocazione risorse del dispositivo per la Ripresa e Resilienza – RRF (miliardi di euro)» Cioè la figura 1.2 rappresenta solo il RRF, senza la prima tranche del REACT-EU. ...è un errore di interpretazione della fonte, mi pare.
Mi sono fermato alla pagina 10, non ho avuto il coraggio di andare avanti.
Credo che ai fini della trasparenza sarebbe opportuno che venisse pubblicato (anche) il formato "sorgente" in MS Word, no? Magari anche con gli oggetti embedded (fogli di calcolo?) utilizzati. Sarebbe una meta-applicazione dei sani principi di trasparenza, ripresa e resilienza enunciati nel piano stesso, o no? Tutti noi abbiamo il diritto di poter verificare in modo trasparente il risultato di tanto lavoro per produrre un piano epocale. [...] Saluti, Giovanni. -- Giovanni Biscuolo Noi, incompetenti come siamo, non abbiamo alcun titolo per suggerire alcunché.
Magari anche con gli oggetti embedded (fogli di calcolo?) utilizzati.
Se ti fidi del mio copia/incolla ti allego il foglio di calcolo con tutti i "numeri" degli investimenti. Antonio p.s. molte "celle" sono vuote anche nell'originale.
Antonio Iacono <antiac@gmail.com> writes:
Magari anche con gli oggetti embedded (fogli di calcolo?) utilizzati.
Se ti fidi del mio copia/incolla ti allego il foglio di calcolo con tutti i "numeri" degli investimenti.
grazie Antonio! Avevo già una mezza idea di trasformare le due (attuali) versioni del PNRR in un formato testuale e "versionabile" (con il PNRR_0 che risulterebbe come la versione modificata del precedente, con tanto di diff ovviamente) e questo tuo lavoro mi "provoca" ulteriormente. Ora la mia mezza idea è quella di usare org-mode di Emacs [1] per (ri)produrre un PNRR... riproducibile, eventuali errori compresi. Ho pochissimo tempo per 'sta cosa ma vedo cosa riesco a mettere assieme nei prossimi giorni
Antonio
p.s. molte "celle" sono vuote anche nell'originale.
Le intepreto come un NIL :-D Grazie! Giovanni. [1] che permette di inglobare anche "fogli di calcolo" e tabelle in formato puro testo, poi convertiti in immagini e tabelle P.S.: chi fosse interessato a questo lavoro e pensa che collaborare è meglio che duplicare gli sforzi mi contatti pure in privato. -- Giovanni Biscuolo Noi, incompetenti come siamo, non abbiamo alcun titolo per suggerire alcunché.
ok grazie. Intanto mando alla lista l'ultima versione del "foglio di calcolo", completo di subtotali e totali On Wed, Apr 28, 2021 at 8:27 AM Giovanni Biscuolo <giovanni@biscuolo.net> wrote:
Antonio Iacono <antiac@gmail.com> writes:
Magari anche con gli oggetti embedded (fogli di calcolo?) utilizzati.
Se ti fidi del mio copia/incolla ti allego il foglio di calcolo con tutti i "numeri" degli investimenti.
grazie Antonio!
Avevo già una mezza idea di trasformare le due (attuali) versioni del PNRR in un formato testuale e "versionabile" (con il PNRR_0 che risulterebbe come la versione modificata del precedente, con tanto di diff ovviamente) e questo tuo lavoro mi "provoca" ulteriormente.
Ora la mia mezza idea è quella di usare org-mode di Emacs [1] per (ri)produrre un PNRR... riproducibile, eventuali errori compresi.
Ho pochissimo tempo per 'sta cosa ma vedo cosa riesco a mettere assieme nei prossimi giorni
Antonio
p.s. molte "celle" sono vuote anche nell'originale.
Le intepreto come un NIL :-D
Grazie! Giovanni.
[1] che permette di inglobare anche "fogli di calcolo" e tabelle in formato puro testo, poi convertiti in immagini e tabelle
P.S.: chi fosse interessato a questo lavoro e pensa che collaborare è meglio che duplicare gli sforzi mi contatti pure in privato.
-- Giovanni Biscuolo
Noi, incompetenti come siamo, non abbiamo alcun titolo per suggerire alcunché.
_______________________________________________ nexa mailing list nexa@server-nexa.polito.it https://server-nexa.polito.it/cgi-bin/mailman/listinfo/nexa
Buongiorno, il metodo di Antonio mi ha intrigato e l'ho adattato... Executive summary: l'intero Next Gen EU e ovviamente il PNRR italiano si fondano sulla /concorrenza/; cosa può andare storto? :-O Antonio Iacono <antiac@gmail.com> writes: [...]
Io di tempo non ne ho avuto e quindi ho fatto come ai tempi in cui andavo in libreria a scegliere un libro, ne prendevo uno e sceglievo una pagina a caso.
Anche io di tempo non ne ho avuto anche se mi piacerebbe tantissimo fare la "spettrografia della Cittadinanza Digitale e Tecnocivismo" di quel piano, ma chissà se e quando ne avrò il tempo, anche in collaborazione coi coautori del libro. In ogni caso il mio istintivo pregiudizio mi dice che difficilmente vi troverei qualcosa di nuovo rispetto al déjà vu degli ultimi 40 anni. Sarò anche qualunquista, pazienza. Però una curiosità me la voglio togliere anche io ed applicare un metodo ispirato al tuo ma non con una pagina a caso, con l'intero documento e lo strumento "ricerca", utilizzando termini per me significativi. Questo lavoro avevo cominciato a farlo ieri in pausa caffè, utilizzando la "vecchia" versione del PNRR di 377 pagine [1], poi l'ho completato ieri sera; /credo/ comunque che la ratio non sia cambiata nella versione PNRR_0.pdf. [1] https://web.archive.org/web/20210425144056/https://www.governo.it/sites/gove... Ecco cosa ho "scoperto": 1. concorrenza: 44 occorrenze C'è un intera sezione "1.4 La promozione della concorrenza" dove viene (di nuovo?) pontificato che sarà la concorrenza (e il mercato) a farci uscire dalla crisi e - udite udite - «contribuire a maggiore giustizia sociale». No comment. Un altro esempio è la sezione «4.3.3 Concorrenza e imprese». Fanno parte di questo insieme di lemmi anche: a. competi (per competizione, competitività, ecc.): 123 occorrenze 2. coperazione: 7 occorrenze Cercate voi stessi il termine e guardate in che modo se ne parla, praticamente «non pervenuta». Fanno parte di questo insieme di lemmi anche: a. collabora (per collaborazione, ecc.): 30 occorrenze 3. impresa: 22 occorrenze La sezione 2.4 include la missione M4C2 dal titolo: «Dalla ricerca all'impresa» dove a un certo punto recita: --8<---------------cut here---------------start------------->8--- misure che si differenziano sia per il grado di eterogeneità dei network tra Università, centri/enti di ricerca e imprese sia per il grado di maturità tecnologica o TRL (Technology Readiness Level). Per tutte le misure sono previste procedure di selezione su base competitiva. --8<---------------cut here---------------end--------------->8--- Troviamo frasi come: --8<---------------cut here---------------start------------->8--- Le iniziative relative al sistema scolastico sono integrate da azioni per rafforzare il collegamento tra ricerca e impresa, ad esempio attraverso il sostegno alla ricerca applicata e agli ecosistemi dell'innovazione. --8<---------------cut here---------------end--------------->8--- Su questa cosa credo non ci sia altro da dire se non che continua la rovina dell'Università che sarà sempre più sottoposta a criteri di valutazione utilitaristici al mercato. 4. open: 8 occorrenze Fanno parte di queso insieme anche questi lemmi: a. floss: zero occorrenze b. software: 6 occorrenze (zero "software libero") c. open data: 1 occorrenza C'è bisogno di aggiungere altro? 5. trasparenza: 14 occorrenze Nessuna sezione dedicata al tema della trasparenza della PA (governo centrale compreso) e in generale dei processi amministrativi e politici, evidentemente non è considerato un problema urgente e che merita un approfondimento *specifico*. Troviamo questo passo: --8<---------------cut here---------------start------------->8--- Al tempo stesso, occorre evitare che alcune norme nate per contrastare la corruzione impongano alle amministrazioni pubbliche e a soggetti privati di rilevanza pubblica oneri e adempimenti troppo pesanti. È il caso delle disposizioni sulla trasparenza che prevedono – tra l’altro – obblighi di pubblicazione di numerosi atti, obblighi non sempre giustificati da effettive esigenze di conoscibilità dei cittadini e assai onerosi per gli uffici, soprattutto degli enti minori. È il caso, inoltre, delle norme che contemplano ben tre tipi di accesso ai documenti e alle informazioni amministrative. Un’unica piattaforma per la trasparenza amministrativa alleggerirà gli obblighi di pubblicazione delle varie amministrazioni su proprie piattaforme; un unico accesso alle informazioni pubbliche è idoneo ad avere evidenti effetti di semplificazione. --8<---------------cut here---------------end--------------->8--- Io lo trovo *molto* ambiguo come testo, come se la trasparenza fosse vissuta come un vero e proprio fastidio da parte del Governo e della PA. Mi sbaglio? Faranno la «piattaforma unica per la trasparenza», come se fino ad oggi non fossero già state provate strade analoghe e sono /miseramente/ fallite. --8<---------------cut here---------------start------------->8--- il PNRR utilizzerà il sistema Informativo “ReGiS” sviluppato dal Ministero dell’economia e delle finanze per supportare i processi di attuazione dei programmi cofinanziati dall’Unione Europea e dei corrispondenti strumenti della programmazione nazionale, assicurando la tracciabilità e trasparenza delle operazioni e l’efficiente scambio elettronico dei dati tra i diversi soggetti coinvolti nella Governance del Piano. --8<---------------cut here---------------end--------------->8--- Quindi hanno istituito «ReGiS»: vedremo quanto sarà utilizzato e aggiornato. 6. cloud: 33 occorrenze Si ribadisce la strategia "cloud first" specificando che: «Le Amministrazioni possono scegliere se migrare verso una nuova infrastruttura cloud nazionale all'avanguardia (“Polo Strategico Nazionale”, PSN) o verso un cloud “pubblico” [9] sicuro» dove [9] significa «Soluzioni cloud commerciali acquistabili sul mercato (certificati, n.d.r.).» Spicca ai mei occhi questo dato: «il 95% dei circa 11mila data center/centri di elaborazione dati distribuiti utilizzati dagli enti pubblici italiani presenta oggi carenze nei requisiti minimi di sicurezza, affidabilità, capacità elaborativa ed efficienza) [20]», dove [20] recita «Analisi AGID» senza nessun riferimento bibliografico, zero. La soluzione, quindi, NON è di sistemare le carenze dei data centre distribuiti ma è quella di /accentrare/. OK, annotato. E anche: «La transizione al cloud favorita da questi primi due investimenti è funzionale anche lo sviluppo di un ecosistema di imprese e startup in grado di integrare e migliorare l’offerta e la qualità di prodotti software per la PA.». Chissà se quato significa "software libero"?!? 7. interoperabilità: 29 occorrenze --8<---------------cut here---------------start------------->8--- Per superare le difficoltà che cittadini e imprese devono affrontare nei rapporti con le amministrazioni centrali e locali, è in corso un lavoro di definizione di standard tecnici comuni di interoperabilità (back-end), in collaborazione con il Ministero per l’Innovazione Digitale --8<---------------cut here---------------end--------------->8--- Esiste una sezione, "Investimento 1.3: Dati e interoperabilità" Si parla di interoperabilità /tra/ PA, non mi pare però che si affronti il tema dell'interoperabilità (e trasparenza) di alcuni importanti servizi pubblici dati in concessione ai privati tipo trasporti locali... io affronterei persino i dati degli esercizi pubblici quali negozi, bar, ristoranti... sto vaneggiando, scusate. In merito alla sanità «Il progetto prevede: (i) la piena integrazione di tutti i documenti sanitari e tipologie di dati, la creazione e implementazione di un archivio centrale, l’interoperabilità e piattaforma di servizi, la progettazione di un’interfaccia utente standardizzata e la definizione dei servizi che il FSE (Fascicolo Sanitario Elettronico, n.d.r.) dovrà fornire;» 8. cultura: 198 occorrenze Buon segno che il termnine compaia tante volte? Buon segno che una sezione si chiami "M1C3: Turismo e cultura 4.0"? 9. dilcis in fundo, blockchain: 1 occorrenza Nella sezione «1.3.9 Riforma "Recovery Procurement Platform" - Digitalizzazione e rafforzamento della capacità amministrativa delle amministrazioni aggiudicatrici» c'è scritto: --8<---------------cut here---------------start------------->8--- Infine, si procederà all’evoluzione del sistema nazionale di eProcurement, attraverso la digitalizzazione end-to-end dei processi di approvvigionamento pubblico. Comprende diversi progetti per l'evoluzione del Sistema Nazionale di eProcurement, tra cui: [...] - "Status chain" per le attività di verifica e audit dei processi di eProcurement attraverso l'uso della tecnologia blockchain. --8<---------------cut here---------------end--------------->8--- A me fa un po' specie che un'amministrazione centrale pensi di puntare su un ledger distribuito decentralizzato (con proof-of-work?!?) per la verifica e audit delle attività degli acquisti pubblici :-D ... ma evidentemente sono io che non capisco. [...] Saluti, Giovanni -- Giovanni Biscuolo Noi, incompetenti come siamo, non abbiamo alcun titolo per suggerire alcunché.
In ogni caso il mio istintivo pregiudizio mi dice che difficilmente vi troverei qualcosa di nuovo rispetto al déjà vu degli ultimi 40 anni. Sarò anche qualunquista, pazienza.
Vogliamo passare ai numeri? Qui il disappunto (almeno il mio) è ancora maggiore. Qualche "voce" di spesa: Al primo posto: "Rete ferroviaria" (TAV ed altro) 24,77 miliardi "Transizione 4.0" 13,97 miliardi, boh, qualcuno prima o poi mi spiegherà questo 4.0 cos'è (AI, robotica industriale ...) "Ecobonus" 15,22 miliardi, e te pareva, ma guardate che chi aveva la "villa palladiana" ormai gli infissi, a forza di ecobonus se l'è rifatti aggratis. a, ma ci sono anche le "note positive". "Finanziamento di progetti presentati da giovani ricercatori", quanto? 0,6, beh, meglio di un pugno in faccia. "Rafforzamento mobilità ciclistica", quanto? 0,6 ... so' soddisfazioni. "Cultura e consapevolezza su temi e sfide ambientali", quanto? Manco i decimali, ci vogliono i centesimali, 0,03 Antonio
participants (7)
-
Andrea Trentini -
Antonio Iacono -
Antonio Vetro' -
Enrico Nardelli -
Giacomo Tesio -
Giovanni Biscuolo -
TEV S.r.L.