Il giorno lun, 16/04/2007 alle 14.16 +0200, Premoli, Roberto ha scritto: > Invece, chi come me ha qualche anno sulle spalle, si ricorda bene la fatica > di programmare quando avevi a disposizione 40K (quaranta kylo bite) di ram su > uno ZX spectrum o 38K (trent'otto kilobyte) su un Commodore 64... per avere > la velocita' e/o meno ram occupata , passavi a migliorare il codice fino al > massimo e poi passavi all'assembler. > Quello si che era/e' codice ottimizzato... altrimenti, semplicemente non > funzionava. > Una volta ci si chiedeva: "come faccio a far il soft piu' veloce/piu' piccolo > possibile?" > Oggi ci si chiede: "perche' l'utente si ostina a usare un [EMAIL PROTECTED] > Con quel bidone non ci fai nulla, il mio soft ha requisiti minimi [EMAIL > PROTECTED] 2Gram, compralo o fai ameno del mio soft". > > Mi spiace, ma le nuove generazioni di "scrittori di codice sorgente" NON > sanno programmare, tutto qui.
Fino a qualche anno fa ero d'accordo con te. Ti parlo di tempi in cui i computer andavano da 1 a 8-10 MHz. Il problema e` che le richieste degli utenti sono aumentate e (nel mercato) i tempi di sviluppo si sono ristretti. Sul C64 non avevi multiutenza, rete, interfaccia grafica. Lo schermo era 320x200 a 4 colori (o, con tecniche strane, 16 colori, totale 32.000 bytes). Non c'erano pipeline sul processore da ottimizzare, cache a 2-3 livelli, colli di bottiglia sui bus. Niente multitasking, quindi niente virus, trojan, protezione della memoria, ecc. Se un utente inseriva un dato sbagliato, il programma spesso crashava Oggi un PC medio ha uno schermo 1280x1024 a 16 milioni di colori, 512 Kb solo di grafica da spostare sui vari bus, interrupt dei piu` vari, attacchi che arrivano dappertutto, memoria protetta, software che reagisce in modo quasi intelligente a dati errati, centinaia di software che girano contemporaneamente, ecc. Aggiungici che il mercato vuole ogni settimana qualcosa di nuovo. E in questo mercato metto anche il software per Linux, visto che gli utenti vogliono sempre l'ultima versione che deve fare di piu`. Senza contare gli effetti 3D, anche solo l'automount delle periferiche, le icone sul desktop, l'accesso trasparente a dischi di rete, il ridimensionamento automatico delle finestre, i font anti-alias, le applet sul desktop, i feed che si autoaggiornano via Internet, la correzione ortografica automatica sull'instant messenger, le iconcine animate, le web-application, ecc. ecc. Questo ha portato alla necessita` di due cose: programmazione a oggetti (per riciclare il lavoro e renderlo "stagno") e linguaggi ad alto livello (per evitare di preoccuparsi delle gestione della memoria, fondamentalmente), e quindi ad altri "sprechi" prestazionali (allocazione di spazi preventiva, cicli di clock per la chiamata a funzione con conseguente salvataggio e ripristino dello stack, garbage collector, macchine virtuali e codice intepretato, ecc.) Aggiungici che l'architettura dei PC non e` che sia un bijoux (pochi registri, bus di sistema lenti su cui passa tutto, pochi IRQ, modalita` compatibili dei processori, indirizzamento ormai "stretto" con solo 32 bit). Inoltre non puoi programmare tutto in assembler, perche` le architetture delle CPU sono troppo varie e rischi di perdere un sacco di tempo e di scrivere brutto codice perche` lasci troppo vuote le pipeline, o invalidi troppo la cache, o rendi inline codice troppo grande per la cache L1, magari solo di 10 byte, o invalidi troppo spesso la branch prediction, o usi istruzioni che in un processore sono hardware e in un'altro sollevano eccezioni sulla CPU e vanno emulate in software, ecc. Io non credo che i programmatori oggi non sappiano programmare, anzi, le tecniche di programmazione sono raffinatissime, solo che sono completamente diverse da 15-20 anni fa. Bye. -- Alessandro Pellizzari -- Per REVOCARE l'iscrizione alla lista, inviare un email a [EMAIL PROTECTED] con oggetto "unsubscribe". Per problemi inviare un email in INGLESE a [EMAIL PROTECTED] To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
