Il bello del golang

di Uriel Fanelli

Parlo poco di programmazione non essendo (piu’) uno sviluppatore , ma dal momento che ho deciso di studiare un pochino Go Lang, e che sul lavoro devo gestire gruppi di sviluppatori, (nonche’ il parto delle loro menti) , questo tuffo in un lunguaggio di recente concezione mi permette di trarre alcune conclusioni, o perlomeno alcune sensazioni.

Per prima cosa: sono un seguace di Wirth. Significa che qualsiasi problema della programmazione e’ prima di tutto un problema di cattivi programmatori. Poi, semmai, si va a cercare il difetto nel linguaggio, nel paradigma, eccetera.

In ultima analisi si parla sempre di sistemi che sono Turing-Completi, quindi alla fine si parla di roba che non ha senso definire piu’ o meno potente. Li si puo’ definire piu’ comodi, piu’ adatti allo sviluppo di gruppo, piu’ vicini al linguaggio umano, ma parlare della “potenza” di un linguaggio e’ la tassa per non sapere cosa significhi “Turing-Completo”.

Andiamo al Go Lang. Innanzitutto, perche’ un nuovo linguaggio di programmazione? La risposta e’: perche’ migliorare i programmatori, o assumerne di migliori, costa molto piu’ che costruire un nuovo linguaggio di programmazione. Sebbene sia chiaro che la stragrande mancanza dei problemi siano legati ad una cattiva programmazione, si pensa di risolvere la cosa migliorando il linguaggio.

In particolare, il problema che ossessiona il mondo della programmazione e’ la complessita’ del progetto. La complessita’ del progetto e’ semplicemente il fatto che se occorrono un milione di righe di codice per spiegare alla macchina come comportarsi, allora:

  1. Nessuno puo’ averle in mente tutte => serve una squadra.
  2. Nessuno puo’ capire tutte le interazioni => serve un modello di astrazione
  3. Nessuno puo’ prevedere davvero tutti i possibili problemi => serve un modello sintetico

Il guaio di queste tre cose e’ che alla fine tutte queste cose le si implementa sul linguaggio, tenendosi i programmatori che ci sono. Poiche’ migliorare i programmatori costa, mentre inventare un linguaggio costa meno, il mondo sta saltando da un linguaggio all’altro nel tentativo di colmare le lacune dei programmatori. Allora chi disegna i linguaggi di programmazione cosa fa?

  1. Concepisce sistemi per il lavoro di squadra, cioe’ inclusione, preprocessori, sistemi di sviluppo distribuito, build systems centralizzati, etc.
  2. concepisce sistemi per la modellazione e la rappresentazione del codice, tipo UML &co.
  3. Concepisce sistemi di sintesi: librerie, programmazione ad oggetti, eccetera.

Sembrerebbe una strategia vincente, ma non funzione. La quantita’ di software si e’ moltiplicata quasi esponenzialmente negli ultimi anni, la qualita’ rimane scadente, quando non peggiora. Tutto questo lavoro nel creare il nuovo linguaggio del giorno fallisce regolarmente. Dal almeno 20 anni. Abbiamo ancora sistemi operativi coi virus. Abbiamo ancora eccezioni di null-pointer.

Ma la prova piu’ grande del fallimento e’ la quantita’ immensa di nuovissimissimissimi paradigmi della programmazione, paradigmi del project management, paradigmi dello sviluppo, che si sono sviluppati negli ultimi anni. E che regolarmente vengono rimpiazzati, dopo aver fallito miseramente.

Quello che succede sul mercato del lavoro e’ che molti vogliono fare i programmatori. Si gettano sulla programmazione cercando il linguaggio piu’ semplice da usare. Abbassano il reddito agli altri. Le aziende ci marciano molto (es: Java) sino a quando la gente si rompe di guadagnare poco e si getta sul linguaggio che ricicla il passato ma consente di guadagnare di piu’ (es: da java a scala).

Il guaio e’ che dopo un anno siamo punto a capo. Framework giganteschi, librerie che da sole costituiscono una competenza verticale, complessita’ malgestita e di conseguenza livelli di sicurezza infimi. Cosa e’ successo?

Riprendiamo le tre assunzioni di prima e vediamo , anziche’ applicarle ai linguaggi, come si applicano ai programmatori. Quando un progetto contiene milioni o anche solo migliaia di righe di codice:

  1. Nessuno puo’ averle in mente tutte => serve una squadra.
  2. Nessuno puo’ capire tutte le interazioni => serve un modello di astrazione
  3. Nessuno puo’ prevedere davvero tutti i possibili problemi => serve un modello sintetico

Allora, che abilita’ specifiche devono avere i programmatori perche’ sia gestibile la complessita’?

  1. Per lavorare in squadra, devono documentare le cose che fanno.
  2. Per usare un modello di astrazione condivisibile, devono stare vicini al linguaggio naturale.
  3. Per poter usare un modello sintetico, devono scrivere meno codice.

Ed e’ qui che si fallisce miseramente.

Andiamo sui punti, per ordine: la documentazione.

Supponiamo che qualcuno sviluppi dentro una squadra e NON documenti quel che scrive. Anzi, oggigiorno diamolo pure per scontato. Ovviamente gli altri dovranno capire come riutilizzare il suo codice. Ma lui risponde che “il codice e’ documentazione”, e vi risponde che chi e’ un buon programmatore puo’ leggere il codice (o il javadoc, o il godoc, o qualsiasi cosa) e capirlo.

La cosa sembra sensata, ma se la estendiamo ad una squadra non lo e’.

Supponiamo che per capire come utilizzare il tuo codice di oggi e fare un paio di test occorra un’ora. E che siamo in una squadra di 8 persone. Abbiamo 8 persone che spendono un’ora per capire ed usare il tuo codice. Il problema non viene nel fatto che hai gettato una giornata uomo. Anche se lo avessi documentato, qualcuno avrebbe dovuto leggere tale documentazione.

Il problema e’ un altro:

  • Hai impattato sui tempi di sviluppo altrui. Non sappiamo di preciso quanto tempo ci mettera’ il tuo collega a capire il tuo codice. Hai inserito una variabile aleatoria nella pianificazione.
  • Hai impattato sulla qualita’. Se documenti il codice e ci metti gli esempi di uso standard, l’uso del codice sara’ sano. Se ci fidiamo della corretta comprensione che una persona diversa ha del tuo codice, ci esponiamo al rischio che lui capisca male. Hai introdotto l’errore umano dove poteva non esserci.
  • Analogamente, hai impattato sulla sicurezza. Il collega che legge il codice andra’ a vedere come usarlo. Non andra’ ad esaminarlo nel dettaglio. Quindi, ci esponiamo al rischio che il collega ne faccia un uso insicuro.

E tutto questo, solo perche’ non hai scritto documentazione che mostri l’uso STANDARD della tua libreria. Se non standard, almeno quello che avevi in mente.

Secondo punto, stare vicini al linguaggio naturale.

A me le “interfacce{}” del golang piacciono un sacco. Vengono subito dopo le emorroidi. Esse sono concepite per rappresentare un processo di astrazione che non esiste in natura. O meglio. Se vostra moglie di dice “prendi il coso che c’e’ dentro il robo, nell’altra stanza”, senza indicare la stanza, il coso e il robo, ha semplicemente fatto quello che in golang si fa con un’interfaccia.

Ma se voi fate quello che si fa in golang con un’interfaccia, deducete che in questo momento vorreste un calzascarpe, andate in corridoio , lo prendete dalla scarpiera, infilate la scarpa e lo portate a vostra moglie. Dal punto di vista del golang avete usato alla perfezione il concetto di interfaccia.

Il guaio e’ che vostra moglie aveva in mente il battibistecche.

Qual’e’ il problema dell’interfaccia di golang?

Il problema e’ che parte dall’idea che:

  1. Programmatore A , che ha l’ idea iA , scriva l’interfaccia.
  2. Programmatore B, che ha l’idea iB , popoli l’interfaccia.
  3. Per un qualche magico motivo, programmatore B sappia che diavolo avesse in mente programmatore A, facendo un uso opportuno dell’interfaccia.

Quanto e’ probabile questa cosa? E’ probabile quanto e’ probabile che vostra moglie vi chieda “prendi il coso che c’e’ nel robo dell’altra stanza” e voi gli portate la cosa giusta.

E’ vero, succede.

Ne deduciamo quindi che le interfacce del golang siano concepite per programmatori sposati tra loro.

Ne prendo atto: il golang ha i valori della Famiglia. Ok.

L’errore di questa cosa consiste nel disegnare un concetto che e’ troppo lontano dal modo di pensare della mente umana, disegnarlo in modo che non solo venga capito, ma debba anche essere condiviso, e poi ci si aspetti che tutto funzioni. Se anche il singolo individuo puo’ percepire l’astrazione – che non esiste nel linguaggio naturale – , la probabilita’ che l’uso corretto di quell’interfaccia passi da una mente all’altra e’ microscopica.

Non esiste niente di simile alle interfacce nel linguaggio naturale, e quando esiste funziona solo tra coppie sposate. A meno che golang non sia un linguaggio concepito coi valori della famiglia in mente, onestamente se ne faceva anche a meno. Le interfacce andavano bene in ADA95, perche’ restringevano la quantita’ di cose che si potevano fare con un dato. Qui nel golang, esse aumentano enormemente la possibilita’ di fare. E quindi, diminuiscono la probabilita’ che voi facciate la cosa giusta.

Andiamo all’ultimo punto: scrivere meno codice.

Scrivere meno codice e’ essenziale per la buona programmazione.

E’ vero: per avere il certificato A , nella vita normale, devo avere il certificato B, l’attestato C, e poi portarle all’ufficio Z. In Germania ci mettete 5 minuti, ma dovete sapere quale sia l’ufficio esatto ove andare. E’ scritto nel “Manuale della Germania”, che pero’ non e’ in vendita. (La gente crede sia una catena montuosa, viste le dimensioni.).

Allo stesso modo, nei linguaggi di programmazione moderni, per non parlare dei framework moderni, c’e’ il disprezzo totale, inesorabile ed assoluto verso le variabili globali, che riducono enormemente la quantita’ di codice da scrivere. (contemporaneamente i programmatori fanno gara a passare variabili e funzioni usando un puntatore, per mostrare quanto lo hanno grosso. Il fatto che qualsiasi argomento contro una variabile globale possa venire usato contro un puntatore , cioe’ una variabile assoluta, evidentemente non li coglie). Questo si risolve mettendo le variabili dentro dei contenitori locali, e poi scrivendo altro codice per recuperarne il valore ed assegnarlo ad una variabile locale.

Risultato: in fase di troubleshooting, la gente deve fare come l’ispettore Derrick e mettersi ad investigare sul movente del programmatore: come mai qui c’e’ questa roba? Serve solo per recuperare sta cosa da un altro posto? E da quale posto? E quale cosa? Cui prodest? Cave canem?

Queste tre grandi cattive abitudini, che sono

  1. Non documentare librerie e classi.
  2. Non stare vicini al linguaggio naturale.
  3. Scrivere troppo codice.

resistono a tutti i tentativi di produrre un ““mondo del software”” migliore, per una ragione: qualsiasi linguaggio di programmazione puo’ essere abusato. MA specialmente, qualsiasi linguaggio verra’ abusato. Il problema non sta nel linguaggio. Stai nei programmatori.

Sia chiaro, non parlo di vizi dei programmatori moderni. Anzi, quel viziaccio e’ nato spesso dagli accademici, che non pagando i programmatori disegnavano protocolli e software mettendoci dentro unghie incarnite come se piovessero. In questi giorni, per divertimento, sto facendo una specie di server che risponde al protocollo NNTP su localhost e poi usa un altro protocollo per trovare gli altri server e distribuire i messaggi ed i newsgroup. I server si trovano da soli e si scambiano i messaggi. Una specie di usenet senza server dell’ ISP, peer to peer.

Ora, io non sono nemmeno un programmatore full-time, e sto buttando giu’ idee, sinora il mio server crea un cluster DHT/Pastry , e risponde ad alcuni comandi NNTP. Cioe’ non fa ancora nulla. Ma persino costruendo un giocattolo per me stesso, vedo ancora esempi di come, anche in passato, si sia ragionato male.

Il primo esempio e’ la stessa definizione del protocollo NNTP nell’ RFC977. Osservate la definizione di “NEWNEWS” e di “NEXT”. Ora, chi facesse un protocollo nell’anno di grazia 1986 – non sto scherzando: 1986 – poteva permettersi tutto tranne che sprecare memoria e codice. Nel senso che erano immensamente costosi. Allocare un puntatore (su cui fare NEXT, che e’ stateful) per ogni utente connesso era costoso. A quell’epoca i KILOBYTE di memoria costavano. E anche i programmatori, nel privato costavano molto.

Stessa cosa con NEWNEWS. Potremmo nominare il fatto che i client avessero ancora meno memoria dei mainframe o dei server, ma rimane il fatto che quel design sembra sensato SOLO SE NON PAGHI I PROGRAMMATORI. Nel 1986, solo l’espansione di quell’ asterisco COSTAVA.Rendere stateful una sessione, che poi oggi e’ banale, all’epoca era pensabile solo su grandi macchine. Che loro, evidentemente, non pagavano.

Quel mindset, cioe’, e’ rimasto sin dal 1986. Immagino che chi ha disegnato quella roba sia passato dal C al C++, poi quando non riusciva piu’ a gestire il codice abbia deciso che Java fosse una ficata, poi quando e’ impazzito di librerie non documentate sia passato a C#, e alla fine sia finito su Python, per divertirsi con l’indentazione, oppure su Scala.

Ma per quanti linguaggi cambino, questi personaggi non potranno mai pensare a roba decente. Non potranno perche’ pensano malissimo.

Il golang me lo dimostra. E’ un linguaggio fantastico, sia chiaro. Ha tolto dalle palle quasi tutti gli elementi fastidiosi della programmazione. Ha tolto moltissime delle cose che seccavano. Cross compilazione in pochi secondi.
Sintassi chiara. Compilazione semplice. Eseguibili senza dipendenze.

Ma nella ricerca di librerie che ho fatto per scrivere il mio programma, mi sono sentito dire che:

  • Vuoi la documentazione? Basta leggere il codice. Il codice e’ documentazione.
  • Se il codice non e’ chiaro, non e’ perche’ ho scritto array di liste di FIFO di interfacce a puntatori di ring. Sei tu che non pensi come Spock sotto LSD.
  • Il fatto che si possa fare la stessa cosa con un terzo del codice testimonia quanto sono fico: posso scrivere tre volte il codice che serve per puro divertimento.

La mia sensazione, cioe’, e’ che su golang stiano cercando di riciclarsi quelli che:

  • hanno fallito in Java.
  • Hanno fallito in Php.
  • Hanno fallito in Python.
  • Hanno fallito in C#/.net
  • Hanno fallito con Javascript/CSS/Jquery

sento odore delle stesse minchiate. Girando per librerie di protocolli, e cercando la documentazione, vedo chiaramente il mindset di tutto cio’ che e’ andato storto nel passato. Roba mal documentata o non documentata e venduta come “libreria”, un modo di programmare lontanissimo dal linguaggio naturale, codice inutile ovunque, scritto solo per dimostrare “mamma, guarda, so usare un’interfaccia{}!”.

Vedo poi arrivare i primi “framework”. La pestilenza del software. Fuori dal mondo enterprise, i framework sono la cosa piu’ stupida ed inutile che esista, e servono solo a creare la persona che sul CV scrive che conosce il tale framework. “Conosce” significa che siccome la documentazione manca e il codice e’ brutto e ridondante, allora lui ci ha sbattuto la testa e per questo tempo speso in trial&errors vuole essere pagato.

Certo, ci sono casi nei quali i framework servono. Ma si tratta di casi che capitano con grandi progetti, nella media basterebbero delle normalissime librerie. Insomma, vedo nubi nere all’orizzonte.

Il motivo per il quale temo per il golang pero’ e’ diverso: si presta troppo bene a programmare da soli. E quando programmi da solo, non ti serve documentare. Hai tutto in mente. Non ti serve usare codice chiaro: tu leggi benissimo la tua calligrafia assirobabilonese. E neanche scrivere poco codice: anzi, sofistichiamo un pochino, che quando torna la mamma glielo faccio vedere prima di aiutarla a portare in casa la spesa.

Golang e’ bellissimo, ma aiuta troppo il programmatore solitario. Ha il merito di essere il piu’ meraviglioso oggetto per hobbysti dopo il Borland Turbo Pascal, ma dall’altro lato, aiuta troppo il programmatore solitario.

Il mio timore e’ di veder piombare nel mondo del lavoro gente che non ha capito una cosa: nell’ IT, devi lavorare con-gli-altri. Il tuo codice verra’ fatto girare da un gruppo di operations. Il tuo codice verra’ osservato dalla security IT. Dovrai implementare sul codice di altri. Gli altri implementeranno sul tuo.

In definitiva, cioe’, il peggior difetto dei programmatori e’ quello di saper lavorare solo sul proprio pc e da soli. Se gia’ il programmatore ha la tendenza a diventare solitario, questa tendenza era attenuata da build tool come maven e altri sistemi che di fatto spingevano gli sviluppatori sulla strada del lavorare con gli altri.

Adesso arriva golang, e vedo che e’ fantasticamente disegnato per consentire ad un programmatore di lavorare da solo. Certo, ha una serie di strumenti magnifici per lo sviluppo di squadra, ma rimane troppo buono per divertirsi da soli.

In pratica, ho paura di sentirmi dire daccapo “ma sul computer dove l’ho provato funziona benissimo”.

Dal mio punto di vista, mi ci sto solo divertendo nel poco tempo libero, ma cercare di immaginare un mondo nel quale si concentreranno tutti quelli che non sanno lavorare con gli altri e hanno tutte le cattive abitudini degli ultimi 20 anni un pochino, onestamente, mi preoccupa.

Spero di sbagliare.

di Uriel Fanelli

PS: questo pezzo e le altre magnifiche elargizioni di saggezza di Uriel sono analizzate su un altro blog degli Untermenschen che curano questo specchio.
PPS: pezzo automagicamente caricato da Fornello!

Annunci

20 pensieri su “Il bello del golang

  1. Questo post è esattamente ciò che Uriel stesso definirebbe la tassa per non aver mai studiato informatica seriamente.
    Non ha capito un cazzo del linguaggio che sta studiando, allora la colpa è sicuramente degli accademici che non hanno senso pratico e dei programmatori che hanno fallito altrove. Aha. Farlocco.

    Mi piace

    • E dire che per gli ultimi 5 anni è rimasto a menarla sui programmatori che imparavano sui linguaggi ad alto livello, perchè non sarebbero stati capaci di scrivere il codice efficiente richiesto dalle telco. Punto anche condivisibile, direi.
      Ma se mi vieni a dire che variabili globali e puntatori condividono gli stessi svantaggi, io credo che pure te di C ne hai visto davvero poco e scritto ancora meno.

      Mi piace

        • Il mio commento vuole proprio evidenziare il fatto di come ciò che scrive sul blog è irrilevante e non necessariamente collegato alla realtà.
          Ha sempre fatto la ramanzina a chi non si è fatto le ossa sul C, ma su questo post ha scritto una cosa che dimostra che lui stesso non si è mai sporcato le mani con i puntatori. Pensa che li considera un virtuosismo fine a sè stesso, afflitto dagli stessi problemi delle variabili globali. Queste ultime sarebbero addirittura vittime di un odio del tutto ingiustificato da parte della comunità scientifica. Aha. Yeah, sure.
          Mi sa che qualcuno non è mai andato oltre a shell e Perl e quando ha dovuto fare i conti con il C i puntatori non li ha capiti tanto bene. Cos’altro dovrei pensare di uno che mi dice che passare dati e funzioni per mezzo di puntatori serve per mostrare di averlo grosso? Sei tu che ce l’hai piccolo Uriel, è solo normale prassi in programmazione C. Sei tu il noob che risolverebbe lo stesso problema con le variabili globali, per la pigrizia di scrivere meno codice (poi debuggalo, e vediamo se cambi idea).
          Quindi può dire di avere esperienza Ada sul blog quanto gli pare, ma non vuol dire che io ci debba credere. Dubito comunque che l’abbia usato per lavoro, Ada, che io sappia, non ha utilizzo fuori dall’ambito mission critical, e questo esclude qualsiasi software che una persona sana di mente gli lascerebbe toccare.
          Sapeva di andare sul sicuro con questo post, perchè non è difficile criticare un linguaggio: spara sul mucchio e qualcosa la prendi. Essendo la progettazione dei linguaggi di programmazione un’arte basata sulla ricerca di un buon compromesso, si finisce sempre per fare delle scelte discutibili. Qualcosa da criticare si trova sempre, è più difficile proporre un’alternativa sensata.
          Ma onestamente pure le sue critiche mi sembrano molto ingenue e tutt’altro che valide: la sua spiegazione su come le interfacce impediscano la collaborazione tra programmatori ha senso solo per lui, forse.

          Mi piace

          • Guarda, esulando dal discorso “programmazione” io da quando ho scoperto nientestronzate e l’ho letto un po’, sono arrivato alla conclusione che qualsiasi fatto Uriel citi come esperienza diretta è irrilevante. Non per altro, eh, ma confrontando le sue storie personali (e qui non ci sono neanche tutte) escono tante di quelle bombe in palese contraddizione tra loro che se le sparassimo a capodanno ci arresterebbero comunque per i rumori molesti.
            E non parlo di teorie o di “aver cambiato idea su questo e quello”. Io parlo di fatti oggettivi. Come essersi occupato per lavoro di una determinata cosa o di un’altra. O esser stati o meno in un determinato posto. Li non è che “basta la logica”. O è successo o non è successo.

            Liked by 1 persona

            • Hai ragione, io volevo semplicemente espandere un punto che avevo già esposto nel precedente commento, quindi sono rimasto sul tecnico.
              Però effettivamente le incongruenze nei suoi racconti e la volubilità delle sue opinioni portano davvero molta confusione al lettore e dunque molti suoi post non lasciano altro che un pesante effetto supercazzola. Da questo punto di vista devo dire che Niente stronzate © è una vera manna dal cielo e ringrazio Raphael e tutti quelli che collaborano a questo fantastico progetto.
              Seguo i blog di Uriel da ormai 4 anni, e nonostante il periodo copra solo una piccola parte dei suoi diari, è un lasso di tempo sufficiente a mettere in difficoltà la mia memoria. Impossibile tenere traccia di tutto ciò che racconta, ogni punto di vista che cambia, etc…
              Da una parte devo dire che la sua mancanza di coerenza rende i post molto più interessanti, il fatto che ad eccezione di alcuni suoi chiodi fissi mischi completamente le carte in tavola anche quando parla di un argomento già trattato rende tutto più divertente, anche se mi porta a doverlo prendere molto meno sul serio.
              Non è un grosso problema per me, che ho sempre letto ogni suo post cum grano salis, alla ricerca di un po’ di divertimento e stimoli intellettuali. A parte il periodo depressivo degli ultimi mesi, Uriel non si può definire certo sterile. La sua continua fuga da quello che chiama pensiero mainstream lo porta a tirar fuori idee anche insolite e ad esporle in maniera altrettanto inusuale. Mi fa divertire.
              Tuttavia ogni tanto ci vuole una maestrina dalla penna rossa che debunki le cazzate che scrive.

              Mi piace

          • Sul fatto che le interfacce impediscano la collaborazione…
            Lui ha descritto una situazione. Assumendo che quanto scritto corrisponda al vero (assunzione forte, direi…) è palese come abbia inquadrato il problema ma non se ne sia accorto: se tu devi lavorare con 2, 3, 4 persone MA NON VI PARLATE non esiste linguaggio che tenga.
            Solo se vivi con il mito delle macchine che sostituiranno tutte le attività inutili e superflue puoi immaginare che le macchine sostituiscano anche la comunicazione. Ok, l’email ha soppiantato la carta, ma i contenuti sono sempre i tuoi.

            E mentre scrivo questo, mi ricordo di aver letto (forum o blog?) qualcuno (forse lui? o comunque lui ci era andato dietro a ruota) che auspicava un generatore automatico di dichiarazioni d’amore. A questo punto mettiamoci anche un generatore di due di picche, un generatore di storie di una sera con trippochiappone trasudanti stracchino 2.0, un automatismo che fuma la sigaretta elettronica dopo che due macchine si sono accoppiate sostituendo l’essere umano in questa faticosa attività fisica.

            Ecco. Le sue previsioni sono tutte sbagliate, perchè non si concludono mai col naturale epilogo “e ci estingueremo per apatia”

            Mi piace

  2. Non parlo quasi mai di programmazione, perchè non sono mai stato uno sviluppatore (serio).

    Adesso sono tutti impallati su questo golang. All’inizio pensavo si parlasse delle alture del golan, ma poi ho capito che è un linguaggio di programmazione.

    Ah, no, scherzo, non è un linguaggios erio perchè fa schifo. E soprattutto fa schifo chi lo usa, infatti il buon programmatore dovrebbe:

    scrivere codice (tempo T) e poi scrivere il manuale di istruzioni, uso, manutenzione, tagliando e revisione del proprio codice (tempo 5xT)
    organizzare una serie di conferenze per spiegare il proprio codice
    scrivere meno codice, così se dimezzi T, dimezzi anche 5xT

    Come spiego tutto questo? Facile. PErchè il mio capo mi ha (di nuovo) fatto una tirata di culo. Perchè?
    Volevo fare un programma che somma due numeri interi minori di 10.
    Per efficientare il resourse management secondo le best work practices della mia company in ottica di synergic team co-working ho preso del codice fatto dal mio compagno di scrivania indiano, sottopagato, pezzente, terrone.
    Risultato:
    – non c’erano le istruzioni. si ok, il codice E’ una catena di istruzioni, ma io voglio le relative istruzioni, e non in linguaggio umanistico interpretabile. Le voglio in linguaggio scientifico/informatico. L’indiano me le ha portate 5 minuti dopo, assomigliavano molto al codice originale, ma nella prima pagina c’era scritto “istruzioni”, ora sono soddisfatto.
    – ho chiesto spiegazioni, mi è stato risposto “Read the fuuuuu… manual!”, ma non sono pagato per leggere. Io sono (stra)pagato per consulenziare.
    – il codice era comunque lunghissimo e visto che il mio tempo costa, non lo ho letto, o avrei creato un 2% di PIL di indebitamento a tutta l’unione europea “high speed” (non quelli a bassa velcoità terroni parassiti fancazzisti ladri e corrotti, come VOI).

    Epilogo: dopo aver usato il codice del collega e aver fatto un test per calcolare 5+4, è successo che:
    5 è stato messo in una variabile globale che coincideva con quella in cui sono allocati i codici di lancio della Russia. Adesso i silos balistici di Volgograd sono vuoti, e la Florida cambierà presto nome in Desertica
    4 è stato messo nell’archivio “LAuree del fornelli”, quindi ad ingegneria, amtematica ed informatic ane devo aggiungere una quarta (pensavo fuffologia).

    Il mio capo si è incazzato a bestia. Mi ha chiamato genocida e causa della 3′ guerra mondiale. Il cielo è attraversato da supposte intercontinentali a testata multilpla, puntate sui culi delle vostre madri.

    Mentre mi sto avviando verso il rifugio antiatomico per i migliori, per la crema della società, per i plurilaureati come me… non riesco a non pensare che in realtà sono solo la mano, l’umile servo di Darwin, che ha ripulito il mondo dagli umanisti.

    Mi faranno una statua in C++.

    Mi piace

  3. Oddio, il codice C++ di Medusa, l’unico programma scritto da Uriel che io conosca, per altro di molto dubbia utilità, era sorprendentemente ben scritto. Comincio però a sospettare che il merito fosse dei suoi collaboratori.

    Mi piace

Rispondi

Effettua il login con uno di questi metodi per inviare il tuo commento:

Logo WordPress.com

Stai commentando usando il tuo account WordPress.com. Chiudi sessione / Modifica )

Foto Twitter

Stai commentando usando il tuo account Twitter. Chiudi sessione / Modifica )

Foto di Facebook

Stai commentando usando il tuo account Facebook. Chiudi sessione / Modifica )

Google+ photo

Stai commentando usando il tuo account Google+. Chiudi sessione / Modifica )

Connessione a %s...