italian developers: GOTO affan...
Per capire bene la situazione dei programmatori o sedicenti tali italiani, forse è bene vedere la storia dell'informatica italiana osservando il proprio microcosmo passato davanti al pc. Ci fu un periodo a metà degli anni 90 dove comparvero i computer in casa degli italiani. E piccoli programmatori nel mondo crescevano, tranne che in Italia. Mentre il mondo sfornava prodotti a livello di diskeditor, editor grafici, utilities, videogiochi, audio editing, in altre parole tutto lo scibile umano in materia di computer, in Italia spiccavano prodotti di eccellenza, ad esempio, senza ricordare esattamente i titoli:
WinToto1x2
WinEnalotto
WinRicette
WinContoFamiglia
e poi il colpo di grazia: il primo WinFattura, che ha tracciato la rotta di tutti i software italiani da quel momento in poi; tutti a fare gestionali.
Questo Winfattura è fondamentalmente un database con milioni di record e alla sera partono programmi che aggiornano, modificano, leggono questi record. Si fermano il mattino seguente. Ho avuto occasione di visionarne diversi e tutti presentavano la stessa problematica: erano scritti e basta. Nel senso erano scritti secondo standard. Il ciclo è For Next. Punto. Nessuno si è mai posto il problema di ottimizzare un ciclo. Quando parlo di ottimizzazione intendo applicare regole basi che dovrebbero insegnare i docenti o che un autodidatta dovrebbe comunque conoscere. Per esempio quelle procedure che durano 8 ore, ne potrebbero durare 3 solo applicando quanto segue, in formato testo qui.
Penso che il livello dei programmatori italiani sia veramente indecente. O meglio, il livello della massa critica di programmatori. Per fortuna esistono realtà completamente opposte, come ad esempio http://victorythegame.com/ ,un capolavoro tutto italiano.
Ecco, io il mondo dei programmatori italiani lo vedo così:
i Javatori sono quel tipo di programmatori che tanto che cazzo me ne frega, ci pensa il garbage collector. Non dimentichiamo che nel 1992 la massima espressione italiana nel mondo dei videogiochi era Dylan Dog. Nel 1992 esisteva Wolfestein 3D e Alone in the dark.
Mi sono sforzato per anni di convincermi che non fosse così, poi ho trovato la risposta proprio in mezzo al codice. Intendo proprio in mezzo al codice, come commento. La questione 'usi Goto --> sei un bad programmer'. Ecco cosa pensano quelli che a metà degli anni 90 invece di scrivere WinLotto, scrivevano Disk editor:
Questa procedure fa parte della unit JvInterpreterParser delle JediLibrary. E si, è proprio così, è un parser e deve essere veloce. Chi in Italia nello schema sopra ha mai dovuto scrivere un parser nella sua vita? O un interpreter? Visto che parliamo di Italia, parliamo di numeri romani e contate i 'goto'.
Anche questa procedure fa parte delle JediLibrary i cui developer non sono proprio gli ultimi arrivati. Erano quelli dei DiskEditor. Forse quello che una volta era l'impiegato delle poste, ora è il programmatore medio: fa le cose con sufficienza. E quello che una volta studiava legge perchè la mamma lo voleva avvocato o medico, oggi ha studiato informatica. E poi vedi le password non criptate nei databases.





Il GOTO è una merda. Lo è perché spezza completamente il flusso di lettura del codice e lo rende complicato e difficile da gestire. E tutto quello che fai col GOTO può essere facilmente rimpiazzato da un loop condizionale.
RispondiEliminaPuò essere utile per uscire da una serie di loop condizionali innestati ma a quel punto mi porrei il problema del perché ho una serie di loop innestati: sicuramente c'è un pessimo design architetturale.
Può aver senso a bassissimo livello, ma come ultima risorsa. Non l'ho nemmeno mai visto in un game engine.
Il bravo programmatore non è quello che ottimizza fino al midollo, ma quello che pensa a quali sono i trade off e gli strumenti giusti per quello che è il compito che il software andrà ad eseguire.
Un loop di un game engine dovrà essere eseguito in 1/60 di secondo perché è necessario. Un batch di una banca può girare per 8 ore perché non mi interessa che giri in 3, mi interessa che la serie di scritture contabili da 1.500.000 euro l'una vadano a buon fine. Mi interessa che il codice sia prima di tutto leggibile, non performante. Perché se ci mette "sole" 3 ore ad essere eseguito ma un programmatore ci deve mettere 3 giorni a capire dove sta il bug quando ne hai solo 2 a disposizione per trovarlo e correggerlo - pena multoni da milioni di euro o agenzia delle entrate che ti fa il culo - delle performance te ne importa un fico secco.