Un po' di storia su come era l'«informatica» scolastica negli anni '90 e perché tutti i programmatori di quel periodo erano autodidatti.
Su cosa insegnavano a programmare i bambini
All'inizio degli anni '90, le scuole di Mosca iniziarono a dotarsi selettivamente di aule informatiche. Negli ambienti venivano subito installate grate alle finestre e una pesante porta rivestita in metallo. Da qualche parte, compariva un insegnante di informatica (che sembrava la persona più importante dopo il preside), il cui compito principale era controllare che nessuno toccasse nulla. Assolutamente nulla. Neanche la porta d'ingresso.
Nelle aule, più comunemente si trovavano i sistemi BK-0010 (nelle sue varie versioni) e BK-0011M.
Foto presa
Ai bambini veniva spiegato il funzionamento di base, oltre a una decina di comandi 'BASIC', in modo che potessero disegnare linee e cerchi sullo schermo. Per le classi inferiori e medie, probabilmente era sufficiente.
Con il salvataggio delle proprie creazioni (programmi) si erano presentati alcuni problemi. Spesso i computer venivano uniti in rete mediante controller a monocolonna con topologia a "bus comune" e velocità di trasmissione di 57600 bps. Di solito c'era un solo lettore, e spesso non funzionava correttamente. A volte funzionava, a volte no, a volte la rete si bloccava, a volte il disco non veniva letto.
All'epoca portavo con me questa creazione da 360 kB.
Le possibilità di riuscire a recuperare il mio programma da essa erano tra il 50 e il 70%.
Tuttavia, il problema principale di tutte queste storie con i computer "BK" erano i continui blocchi.
Questo poteva avvenire in qualsiasi momento, sia durante la digitazione del codice che durante l'esecuzione del programma. Un sistema bloccato significava che 45 minuti di tempo erano stati sprecati, poiché era necessario ricominciare tutto da capo, ma il tempo rimasto per la lezione non era più sufficiente.
Verso il 1993, in alcune scuole e licei apparivano aule normali con macchine 286, e in alcuni posti c'erano anche "tre". Per quanto riguarda i linguaggi di programmazione, c'erano due opzioni: dove finiva il "Basic", iniziava il "Turbo Pascal".
Programmazione in «Turbo Pascal» attraverso l'esempio dei «tank»
In «Pascal», i bambini imparavano a costruire cicli, disegnare varie funzioni e lavorare con gli array. Nella scuola fisico-matematica, dove ho vissuto per un certo periodo, la materia di informatica era insegnata una volta alla settimana. E per due anni è stata una noia mortale. Ovviamente, volevo fare qualcosa di più serio rispetto a stampare i valori di un array o una certa sinusoide.
Tank
Battle City era uno dei giochi più popolari sulle console clone NES (Dendy e altri).
Nel 1996, la popolarità delle console a 8 bit era svanita, giacevano da tempo in un armadio, e mi è sembrato interessante realizzare qualcosa di più grande, coprendo proprio il clone dei «Tank» per PC. Di seguito, parlerò di come all'epoca si doveva arrabbattarsi per creare su «Pascal» qualcosa con grafiche, mouse e suoni.
Si possono disegnare solo bastoncini e cerchi
Iniziamo con la grafica.
Nella versione base, «Pascal» permetteva di disegnare alcune figure, colorare e definire i colori dei punti. Le procedure più avanzate nel modulo Graph, che ci avvicinano agli sprite, sono GetImage e PutImage. Con questi strumenti era possibile catturare un'area dello schermo in una zona di memoria preassegnata e poi utilizzare questo pezzo come un'immagine raster. In altre parole, se desideri riutilizzare ripetutamente elementi o immagini sullo schermo, prima li disegni, li copi in memoria, cancelli lo schermo, disegni il successivo e così via, fino a creare in memoria la libreria necessaria. Poiché tutto avviene rapidamente, l'utente non si accorge di questi trucchi.
Il primo modulo che utilizzava sprite è stato l'editor di mappe.
In esso c'era un campo di gioco contrassegnato. Un click del mouse apriva un menu dove era possibile scegliere una delle quattro opzioni di ostacoli. A proposito del mouse…
Il mouse è già la fine degli anni '90
Le mouse erano ovviamente presenti per tutti, ma fino alla metà degli anni '90 venivano utilizzate solo in Windows 3.11, in pacchetti grafici e in un numero limitato di giochi. In Wolf e Doom si giocava solo con la tastiera. Anche nell'ambiente DOS, il mouse non era particolarmente necessario. Pertanto, in Borland, il modulo per il funzionamento del mouse non era nemmeno incluso nella distribuzione standard. Dovevi cercarlo tra amici che si strizzavano le mani e rispondevano: «E a cosa ti serve?».
Trovare un modulo per interrogare il mouse è solo metà del lavoro. Per poter cliccare sui pulsanti a schermo, dovevano essere disegnati. In effetti, in due varianti (premuto e non premuto). Il pulsante non premuto ha la parte superiore chiara e sotto un'ombra. Al contrario, il pulsante premuto. E bisogna disegnarli tre volte sullo schermo (non premuto, premuto, poi di nuovo non premuto). Inoltre, non dimenticare di impostare delle pause per la visualizzazione e, naturalmente, di nascondere il cursore.
Ad esempio, il codice per la gestione del menu principale appariva in questo modo:
Il suono – solo un altoparlante PC Speaker
Una storia a parte per il suono. All'inizio degli anni '90, i cloni di Sound Blaster si stavano preparando al loro trionfo, e la maggior parte delle applicazioni funzionava solo con il piccolo altoparlante integrato. Il massimo delle sue capacità era la riproduzione simultanea di un solo tono. Ed è proprio quello che permetteva di fare Turbo Pascal. Attraverso la procedura sound era possibile 'emetterei' suoni con diverse frequenze, sufficiente per i rumori di spari e esplosioni, ma non adatto per le colonne sonore musicali, come andava di moda all'epoca. Alla fine è stata trovata una soluzione piuttosto ingegnosa: nel nostro archivio di software è stato scoperto un piccolissimo 'exe', scaricato tempo fa da qualche BBS. Era in grado di compiere miracoli – riprodurre wav non compressi tramite il PC Speaker, e lo faceva dalla riga di comando senza un'interfaccia propria. Tutto ciò che era necessario era chiamarlo tramite la procedura exec di Pascal e assicurarsi che questa costruzione non crollasse.
Alla fine è apparso un bel pezzo musicale sullo schermo, ma è successa una cosa divertente. Nel 1996 avevo un sistema con un Pentium 75, overcloccato a 90. Su di esso tutto funzionava perfettamente. Tuttavia, all'università, dove nel secondo semestre ci hanno messo a studiare Pascal, in aula c'erano dei vecchi "treshki". In accordo con il docente, ho portato quei tank al secondo incontro, per ottenere un giudizio e non doverci più tornare. E così, dopo aver avviato il gioco, dal diffusore è uscito un forte ruggito mescolato a suoni gorgoglianti. Insomma, il DX sul vecchio "treshka" a 33 megahertz non è riuscito a far girare correttamente quel piccolo "executable". Ma per il resto era tutto a posto. Certo, non considerando il ritardo nella risposta della tastiera, che rovinava completamente il gameplay indipendentemente dalle prestazioni del PC.
Ma il problema principale non sta nel "Pascal".
Nella mia opinione, "Tanchiki" rappresenta il massimo che si potesse ottenere da Turbo Pascal senza inserimenti in assembler. Tra i difetti evidenti del prodotto finale ci sono la lentezza nella rilevazione della tastiera e un'animazione grafica poco fluida. A peggiorare la situazione c'era il numero estremamente ridotto di librerie e moduli di terze parti, che si potevano contare sulle dita di una mano.
Ma ciò che mi infastidiva di più era l'approccio nell'istruzione scolastica. All'epoca, ai bambini non venivano spiegati i vantaggi e le opportunità di altri linguaggi. Nelle lezioni si iniziava praticamente subito a parlare di begin, println e if, il che rinchiudeva gli studenti nella parafrasi di base del Pascal. Entrambi questi linguaggi possono essere considerati esclusivamente didattici. Il loro utilizzo "pratico" è un fenomeno raro.
Perché insegnare ai bambini linguaggi di programmazione fittizi rimane un mistero per me. Anche se sono più visivi. Anche se le varianti del «BASIC» vengono utilizzate in alcuni contesti. Tuttavia, se una persona decide di legare il proprio futuro alla programmazione, dovrà imparare da zero altri linguaggi. Allora perché non proporre agli stessi bambini compiti didattici simili, ma su una piattaforma (linguaggio) adeguata, che consenta loro di svilupparsi ulteriormente in autonomia?
A proposito di compiti. A scuola e all'università erano sempre astratti: calcolare questo, costruire una funzione, disegnare qualcosa. Ho studiato in tre scuole diverse, e inoltre abbiamo avuto «Pascal» nel primo anno di università, e mai una volta i docenti hanno proposto un compito applicabile e reale. Per esempio, creare un'agenda o qualcosa di utile. Tutto era artificioso. E quando una persona trascorre mesi a risolvere compiti privi di significato, che poi finiscono nel cestino… Insomma, le persone escono dall'università già bruciate.
A proposito, al terzo anno della stessa università ci hanno inserito nei programmi i "plus". Sembrava un'iniziativa positiva, ma gli studenti erano stanchi, sazi di contenuti superficiali e di "compiti" didattici. L'entusiasmo, come all'inizio, non era più presente.
P.S. Ho cercato su Google quali linguaggi vengono attualmente insegnati nelle scuole durante le lezioni di informatica. Tutto come 25 anni fa: Basic, Pascal. Con qualche sporadica introduzione di Python.
Fonte: habr.com
