Non sto scherzando. golang e’ ancora usato per il 2.5% dei progetti del mondo, quindi di per se’ dovrebbe essere un linguaggio agli albori che discute le sue primitive di base e le sue librerie piu’ usate. Invece, sono gia’ arrivati i programmofoni.
I programmofoni si dividono in diverse categorie. Quando ho scritto su un forum che volevo scrivere un programma che facesse un server NNTP e condividesse i post via P2P, chiedendo se qualcuno conoscesse delle librerie ad hoc, mi hanno proposto cinque o sei librerie, tra NNTP, P2P e UPnP. A parte lo stato pietoso del codice (ho dovuto scaricare una copia mia del software dell’ UpNP e bonificarlo(2) ) , indice di immaturita’, ho pensato subito “ma guarda quanta bella gente servizievole che c’e’ qui”
Invece, poi ho scoperto la verita’.
Tutto quel codice fa schifo. E fa schifo perche’ e’ stato scritto in fretta senza voler raggiungere un obiettivo. Se voi avete un obiettivo, e avete un programma in mente, dovete fare quello. Se invece scrivete delle librerie dht per scrivere delle librerie dht, ma senza uno use-case in mente, scriverete roba di merda.
Ma allora perche’ li scrivono? Scrivono perche’ vogliono diventare programmofoni. Il programmofono e’ uno che scrive codice, ma non programma: il suo scopo e’ di essere pagato per parlare di programmazione.
Scrivono librerie sperando che gli altri le usino. Quando gli altri le usano le loro librerie diventeranno famose, e si faranno pagare per i talk alle convention e per gli articoli sui giornali. Niente idee. Niente bisogni da risolvere.
Uno dei tipi piu’ pericolosi di programmofono e’ chi scrive i framework. Normalmente per scrivere un framework VERO occorre una squadra di esperti, e occorrono anni di analisi dei requisiti.(3) Invece su golang stanno iniziando a piovere framework (identici a quelli che hanno gia’ fallito in Java, btw). E non sono framework scritti da team di esperti di grandi aziende che vogliono intercettare i bisogni dei clienti: sono scritti in pochi mesi da UN individuo , spesso giovanissimo.
Perche’ scrivono framework e non un vero programma? Perche’ manca loro l’idea, o manca il bisogno. Quando ho iniziato a riempire di Raspberry casa mia, ho avuto bisogno di un coso semplice che mi dicesse sul browser in che stato fosse l’ OS. Avevo un bisogno. Quando mi e’ venuto in mente di scrivere un server NNTP che condividesse i post su P2P anziche’ usare il sistema centralzzato attuale, avevo un’idea.
Chi scrive un framework NON ha un’idea. E neanche un bisogno. Si limita a scrivere nella speranza che ALTRI abbiano qualche idea su come usarlo, o che abbianobisogno di usarlo.
Quando scrivono questo codice senza idee ne’ bisogni, cioe’ seza use-case che non siano “esempi” (In pratica, “Hello World”) , cosa fanno per prima cosa? I programmofoni. Cioe’ vanno a dare un talk a qualche convention di go. Se osservate i nuovi “framework” di golang, saranno TUTTI presentati a qualche talk dal loro creatore.
Il quale avra’ vita facile: andra’ li’ e mostrera’ gli esempi. Solo esempi. Non casi reali. Non case study. No: esempi. Ideati da loro medesimi.
Ho qualcosa contro gli esempi? No. Ma gli esempi non hanno quasi nulla a che fare con la realta’. Se per esempio osservate QUALSIASI esempio di Fibonacci, scoprirete che viene usato per spiegare la ricorsione. E funziona BENISSIMO. Per spiegarla, intendo. Ma se prendete un Fibonacci e ci fate una funzione Fibonacci() e gli date un numero lungo 16 bit in ingresso, ci si aspetta che presumiate di calcolare Fibonacci(65535) in maniera ricorsiva. Non vi consiglio proprio di farlo, per il bene del vostro stack. E’ un ottimo esempio, ma mi vengono in mente altri modi iterativi.
Questo e’ il punto degli esempi: servono a capire, ma non necessariamente a fare. Ed e’ per questo che il nostro programmofono va al “talk” a sbrodolare fuffa.
Questa e’ la ragione per la quale tutti mi proponevano librerie dicendo “io! io! usa la mia!”: volevano poter dire “la mia libreria e’ usata”. Per la cronaca, sto implementando un ‘interfaccia NNTP partendo dagli RFC: questa roba che mi offrivano e’ scritta in fretta e furia (4) , per arrivare primi a calcare i “talk”. Siccome gli organizzatori hanno poca gente da chiamare , se fai un framework per golang, ti chiamano di sicuro.
Dopo il “talk” arrivano i giornalisti di informatica-dev e i vari blogger professionali. Che iniziano a parlare dei talk. Il talk di secondo ordine. Allora, innanzitutto occorre che il vostro linguaggio abbia delle parole fiche. Golang e’ idiomatico. Ovunque leggerete che sia idiomatico. Se osserviamo quanto sia usata l’idiomaticita’, scopriamo che se ne fa un uso scadentissimo, e sempre (o quasi) a danno della leggibilita’. Ma parlare di “idiomaticita’” fa fico. Evoca l’umanizzazione. Sembra quasi intelligenza artificiale.
E allora sbrodoliamoci di idiomaticita’.
Questa altra classe di programmofoni, i giornalisti che scrivono di programmazione sulle riviste e sui e’ simile agli animali da talk, nel senso che ne condivide lo scopo esistenziale: vivere di programmazione SENZA programmazione, ovvero parlando di programmazione. La stessa definizione di programmofono.
A quel punto saltano fuori i programmofoni di terzo livello. Quelli che non programmano, ma sono figure tipo “solution designer” (5), o manager “che ti capiscono, perche’ loro un tempo erano tecnici.” Questo tipo di manager, che e’ normalmente appassionato di talk (molti volevano farsi preti per la libidine di poter parlare da un pulpito. La crisi delle vocazioni ha fatto il resto), vede i brillanti talk di questi personaggi , leggono sulle riviste specializzate (perche’ adesso loro sono manager, ma si sentono ancora attirati dalle origini. Il richiamo della foresta, dicono. ) e allora via, l’indomani irrompono in una stanza di programmatori e dicono “ questo framework e’ quello che ci serve”.
Adesso mi chiederete un esempio. Prendero’ cosi’ una stringa casuale di cinque lettere, e vi mostrero’ come diventa , grazie ai programmofoni, un “framework Hello World”.
Prendiamo una stringa di 5 caratteri a casaccio: “Corba”. Si tratta della parola “Cobra” scritta da un dislessico di 6 anni, e non ha significato alcuno, ma come esempio casuale andra’ benissimo. Tanto nessuno lavorerebbe con una cosa che si chiama “Corba”.(6)
Allora, ad un certo punto nasce Corba. Una parola senza alcun significato, ma piace un sacco ai programmofoni di primo livello. I quali scrivono codice a casaccio senza avere use case e senza chiedersi se per caso serva a qualcosa, e decidono che “adesso ci faccio un talk”.
“Corba” ovviamente non serve a nessuno (come potrebbe , una cosa con un nome cosi’ stupido?) , e’ orribilmente RAM-intensive, CPU-intensive, NETWORK-intensive, e chi loha scritto non aveva in mente alcuno use-case. MA aveva degli esempi.
Allora i primi programmofoni di ordine uno si presentano ai talk e fanno vedere che hanno due programmi che girano. Uno scrive “Ciao Mamma”, e sull’altro compare una finestra “Ciao Mamma” . Applausi del pubblico. Delirio. La soluzione di tutti i nostri problemi, dalle emorroidi alla congettura di Poincare’.
Di fronte a tale esibizione di un computer che scrive “ciao mamma” su una finestra e un altro computer che scrive “ciao mamma” sullo schermo, i giornalisti imparano due o tre parole. Diciamo, a casaccio, “serializzazione” e “interoperabilita’ ” e, visto che si siamo, “suocerismo”. Il suocerismo, alla fine, e’ l’unica cosa buona di Corba, ma tutti lo scopriranno dopo. Qualsiasi cosa sia il suocerismo.
Comunque, i programmofoni di secondo ordine hanno nuove parole, e possono scrivere articoli e pagine di blog piene di “serializzazione”, “interoperabilita’” e “suocerismo”. E cominciano a fare esempi. Meta’ di loro sono una scopiazzatura bella e buona delle slide del “talk”. ““Ciao mamma” invade i monitor del mondo.
L’altra meta’ e’ fatta di “guarda come mi diverto” e infine qualcuno cerca di farci qualcosa, sentendosi dire che “Corba non e’ nato per questo”, che “esiste gia’ il TCP/IP per questo” e il resto che gli serve il doppio dei server.
A questo punto, quando “Corba il greco” e’ ormai sulla bocca di tutti, arriva il programmofono di terzo ordine, che legge tutta questa roba, brucia di invidia per il tipo fico del talk, e piomba l’indomani in azienda dicendo che “occorre qualcosa di moderno. Ci serve Corba!”
Questa cosa, che notoriamente non e’ mai successa (che diavolo di porcheria potra’ mai essere una cosa dal nome cosi’ ridicolo? Dai, siamo seri. ) e’ un esempio di come i programmofoni distruggono un ambiente lavorativo.
Oggi come oggi,
- Siamo pieni di framework che funzionano solo sugli esempi di come usarli, e mai nella vita reale.
- Questi framework sono necessari perche’ sono famosi.
- Questi framework sono famosi perche’ tutti ne parlano.
- Quando si cerca di usarli per casi reali si scopre che i loro limiti sono tali e tanti che e’ meglio farsi tutto da soli. E che “gli stessi autori consigliano un’altra libreria”.
Nessuno trova lavoro se non conosce uno di questi framework famosi. Nessuno li utilizza davvero, perche’ il programma reale viene poi splittato su altre 15 librerie. Consigliate dagli stessi autori. Le stesse librerie soffrono il problema, quindi erano nate per fare altro.
Questa merda ha distrutto Java. Ha distrutto Javascript. Python. Perl. Ha distrutto praticamente ogni linguaggio, per una semplice ragione: il programmofono non vuole scrivere programmi. Non ha un problema da risolvere e non ha un’idea. Vuole scrivere codice dicendo che servira’ a chi ha i problemi e le idee. Lui invece fa il talk.
Ma a questo punto arriva in scena il becchino, l’ultima categoria di programmofoni. Quelli che discutono a posteriori di paradigmi.
Voi avete delle scimmie che scrivono software di merda, arriva il programmofono e vi fa un bell’articolo su un giornale: “ma il paradigma OOP ha fallito?”. E via di filosofia.
Ora, dire che “il paradigma OOP ha fallito” non e’ giusto o sbagliato. E’ senza senso.
Stiamo parlando di strumenti. Se Michelangelo prende uno scalpello ci fa il David. Se io prendo uno scalpello, ci spacco delle pietre. Ma non posso dire “ma il paradigma dello scalpello ha fallito”. No. Potrebbe dirlo Michelangelo, e’ vero: se dopo aver scolpito il David con uno scalpello ne prende un altro e gli riesce una ciofeca, allora puo’ dire “questo paradigma di scalpello cinese ha fallito”. Ma puo’ farlo LUI. E DOPO aver scolpito il David.
Allora adesso arriva un mondo che NON ha MAI prodotto niente di simile a “David”. Se escludiamo Donald Knuth e pochi altri, roba del genere non si e’ mai vista. Del resto, Knuth non fa discorsi tipo “ma il paradigma OOP ha fallito?” (7), lui dice che ha sempre pensato a quel modo, e semmai invece di usare un linguaggio specifico preferisce l’ AUTODISCIPLINA nel pensare.
Ma il quarto tipo di programmofono ha quasi vent’anni di fallimenti da commentare, e quindi puo’ facilmente scriverci degli articoli.
In realta’ cosa sia andato storto e’ chiaro:
- Linguaggi vicini alla macchina. Ottimo codice, ma programmatori troppo pagati.
- Linguaggi imperativi classici. Codice ancora decente, ma i programmatori iniziano a essere molti.
- Linguaggi funzionali. Codice “abbastanza buono da metterlo sul mercato”, e i programmatori sono pagati quanto un operaio.
- Linguaggi OOP: codice di merda, e un programmatore indiano costa $20 al giorno.
Ora, anche tornando ai linguaggi funzionali , e tirando fuori roba tipo erlang o ripescando il prolog, il problema del peggioramento del codice e’ chiaro: se qualcuno scrive programmi di merda, non e’ colpa “del paradigma”. Non e’ colpa dello scalpello se io non so fare il David.
La velocita’ con cui nascono e crescono i nuovi linguaggi e’ aumentata mano a mano che il software diventava piu’ scadente: in una specie di legge di Moore al contrario, il codice odierno riesce a sprecare piu’ risorse di quante la legge di Moore riesca a produrre. Il vostro cellulare e’ quello che vent’anni fa vendevo come supercomputer. E alcuni software “ci girano a malapena”. La gente ci simulava galassie, sul vostro quad core con un GB di RAM. E voi fate fatica a farci una app stabile.
E siccome i fallimenti sono sempre di piu’, sempre piu’ velocemente i programmofoni di quarto ordine devono inventarsi “il fallimento del paradigma n-1”. Perche’ si potrebbe seguire l’approccio Wirth e dire “se questo programma fa cagare, licenzia chi lo ha scritto”. Ma ovviamente bisogna salvare la pappa, e allora si dice che “ha fallito il padadigma OOP”.
Adesso arriva l’idiomaticita’. Vedo gia’ codice idiomatico scritto per i talk. Stanno arrivando i programmofoni. Tra qualche anno saremo pieni di codice di merda scritto in golang. Dagli stessi che hanno gia’ fallito in Python, Ruby, PhP, Java e Scala. E anziche’ mandare a casa questi programmatori, sapete cosa scriveranno i giornalisti di informatica?
Che “ha fallito il paradigma idiomatico”. Perche’ la colpa e’ sempre del pennello.
(1) Si, e’ morto. Lo stipendio medio dei programmatori java sta decrescendo ogni giorno, e Scala e’ solo un palliativo. In questo momento Java e’ nello stato di “balena spiaggiata”: prima che scompaia occorreranno mesi, se non anni, di decomposizione. Ma il fatto che la carcassa di Java dara’ da mangiare ancora per anni non significa che sia vivo. Significa che e’ una carcassa molto grande e ci mette molto a decomporsi.
(2) Il cinese che lo ha scritto crede davvero che se un server remoto ti manda qualcosa che non capisci, allora la soluzione migliore sia “panic()”. A me invece sembra carino che i programmi sopravvivano alla propria esecuzione. Cosi l’ho bonificato gestendo degli errori qui e li’.
(3) Altrimenti succede questo: quando usate il framework con gli esempi forniti, siete capaci di scrivere “Helo World”. Ma quando piazzate il framework in un ambiente lavorativo e dovete farci delle cose senza limitarvi a degli esempi, scoprite che il tale framework questo lo fa ma non cosi’, quello lo fa ma non e’ il suo core business, l’altro lo fa ma performa male, e che quell’altra tale cosa sarebbe meglio farla con altre librerie, parola degli stessi sviluppatori del framework. Risultato? Il framework esegue benissimo gli esempi di utilizzo e va bene per le minchiatine.
(4)Il software che sto scrivendo e’ scritto per me stesso, e io non sono un programmatore. Non funziona ancora, e lo mando avanti quando mi diverte programmare. Prima o poi lo commentero’ e lo riordinero’. Per ora sto provando tutte le tecniche do golive, una ad una. E’ un progetto personale e NON pretendo che abbia qualita’, almeno non adesso.
(5) E’ il lato oscuro degli architetti di sistema. Quando ne incontro uno, di solito mi salutano dicendo “Io sono tuo padre”. Io faccio la parte tecnica. Loro fanno il powerpoint. Riunioni di ore nella quale la loro domanda e’ “ma in che dominio e’ questo elemento che chiamiamo “Billing”? Nella zona verde a destra o in quella rosa a sinistra?” E io a spiegare che cosa sia un BSS, sinche’ non mi viene detto “non sono cosi’ tecnico”.
(6) Lo so, lo so. Ma nessuno lo ammettera’ mai. Si vergognano troppo.
(7)http://tex.loria.fr/historique/interviews/knuth-clb1993.html
CLB: What about object-oriented programming? Is it just a current buzzword, or does this approach appeal to you?
Knuth: I’ve always thought of programming in that way, but I haven’t used languages that help enforce the discipline; I’ve always enforced the discipline myself in other languages. Programming languages can now catch you if you make a mistake, and they make it easier for you to hide information from one part of the program to another. In my own programs, with older languages, I wouldn’t use what I wasn’t supposed to use; I would have to discipline myself to follow these rules. I could, so I did. There weren’t programs I couldn’t write… but the new tools do help.
