Un po' di ciò che era l'informatica scolastica negli anni '90 e perché tutti i programmatori all'epoca erano esclusivamente autodidatti.
Su cosa insegnavano a programmare i bambini
All'inizio degli anni '90, le scuole di Mosca iniziarono a dotarsi selettivamente di aule con computer. Nei locali venivano installate subito griglie alle finestre e porte pesanti rivestite di ferro. Improvvisamente appariva un insegnante di informatica (che sembrava la persona più importante dopo il preside), il cui compito principale era quello di controllare che nessuno toccasse nulla. Assolutamente niente. Nemmeno la porta d'ingresso.
Nelle aule era più comune incontrare sistemi BK-0010 (nelle sue varianti) e BK-0011M.
Foto presa
Ai bambini venivano spiegate le nozioni base, così come una dozzina di comandi 'Basic', per poter disegnare sullo schermo linee e cerchi. Per le classi inferiori e medie, probabilmente questo era sufficiente.
Ci sono stati problemi specifici con il salvataggio delle proprie creazioni (programmi). Più spesso, i computer venivano uniti in rete tramite controller monocanale con una topologia ‘bus comune’ e velocità di trasmissione di 57600 baud. Il disco floppy era di solito uno solo e non funzionava spesso. A volte andava, a volte no, a volte la rete si bloccava, a volte il floppy non veniva letto.
Allora portavo con me questa creazione di 360 kB.
Le possibilità di estrarre di nuovo il mio programma da essa erano del 50-70%.
Tuttavia, il principale problema di tutte queste storie con i computer 'BK' erano i blocchi infiniti.
Questo poteva succedere in qualsiasi momento, sia durante la scrittura del codice che durante l'esecuzione del programma. Un sistema bloccato significava che avevi sprecato 45 minuti di tempo, poiché dovevi rifare tutto da capo, ma il tempo rimanente per la lezione non era mai sufficiente.
Verso il 1993, alcune scuole e licei iniziarono ad avere aule normali con macchine 286, e in alcuni posti c'erano anche 'tre' (386). Per quanto riguarda i linguaggi di programmazione, c'erano due possibilità: dove finiva il 'Basic', cominciava il 'Turbo Pascal'.
Programmazione in 'Turbo Pascal' con l'esempio dei 'tank'
A 'Pascal' i bambini venivano insegnati a costruire cicli, disegnare varie funzioni e lavorare con gli array. Nel liceo scientifico, dove per un po' di tempo 'abitavo', la lezione di informatica era una sola a settimana. E per due anni è stata questa noia. Naturalmente, volevo fare qualcosa di più serio che stampare a schermo i valori di un array o di una certa sinusoide.
Tank
Battle City è stato uno dei giochi più popolari sulle console clone NES (Dendy e altri).
Nel 1996, la popolarità delle 8 bit era già finita, e giacevano da tempo in soffitta, così mi è sembrato interessante, come progetto più grande, realizzare un clone di 'Tank' per PC. Di seguito parlerò di come allora fosse necessario ingegnarsi per sviluppare in 'Pascal' qualcosa con grafica, mouse e suoni.
Puoi disegnare solo bastoncini e cerchi
Iniziamo con la grafica.
Nella versione base, 'Pascal' permetteva di disegnare alcune forme, riempire e definire i colori dei punti. Le procedure più avanzate nel modulo Graph, che ci avvicinano agli sprite, sono GetImage e PutImage. Con questi è possibile catturare in un'area di memoria precedentemente riservata una parte dello schermo e poi utilizzare quel pezzo come immagine raster. In altre parole, se vuoi riutilizzare frequentemente sullo schermo alcuni elementi o immagini, prima li disegni, li copi in memoria, cancelli lo schermo, disegni il successivo e così fino a creare in memoria la libreria necessaria. Poiché tutto avviene rapidamente, l'utente di questi trucchi non se ne accorge.
Il primo modulo in cui sono stati utilizzati gli sprite è l'editor di mappe.
Esso presentava un campo di gioco delineato. Un clic del mouse apriva un menu dove si poteva scegliere una delle quattro opzioni di ostacoli. A proposito del mouse...
Il mouse è già della fine degli anni '90
Ovviamente tutti avevano un mouse, ma fino alla metà degli anni '90 veniva utilizzato solo in Windows 3.11, in pacchetti grafici e in un numero ristretto di giochi. In Wolf e Doom si giocava solo con la tastiera. E, inoltre, nell'ambiente DOS il mouse non era davvero necessario. Pertanto, nel modulo Borland per il lavoro con il mouse non era nemmeno incluso nella fornitura standard. Dovevi cercarlo dai conoscenti che alzavano le spalle dicendo 'e a che ti serve?'
Tuttavia, trovare un modulo per il sondaggio del mouse è solo metà del lavoro. Per fare clic sui pulsanti a schermo con il mouse, dovevano essere disegnati. E in due varianti (premuto e non premuto). Il pulsante non premuto ha una parte superiore chiara e una ombra sotto di esso. Al contrario, quello premuto. E bisognava disegnarli poi tre volte sullo schermo (non premuto, premuto, poi di nuovo non premuto). Inoltre, non dimenticare di impostare ritardi per la visualizzazione e nascondere il cursore.
Ad esempio, l'elaborazione del menu principale nel codice appare così:
Audio – solo un beep del PC Speaker
C'è una storia a parte con l'audio. All'inizio degli anni '90, i cloni della Sound Blaster si stavano appena preparando alla loro vittoria, e la maggior parte delle applicazioni funzionava solo con il diffusore integrato. Il massimo delle sue possibilità era la riproduzione simultanea di un solo tono. E proprio questo era permesso da Turbo Pascal. Tramite la procedura sound era possibile "fare beep" a diverse frequenze, il che era sufficiente per i suoni di spari e esplosioni, ma per un jingle musicale, come andava di moda all'epoca, non era affatto adeguato. Alla fine è stata trovata una soluzione piuttosto ingegnosa: nel proprio archivio di software è stata scoperta una "mini applicazione" scaricata un tempo da qualche BBS. Era capace di fare miracoli: riprodurre file wav non compressi tramite il PC Speaker, e lo faceva dalla riga di comando senza un'interfaccia propria. Tutto ciò che serviva era chiamarlo tramite la procedura exec di Pascal e assicurarsi che questa costruzione non crollasse.
Alla fine è apparso un fantastico pezzo musicale nella schermata di avvio, ma si è verificato un fatto 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 fu introdotto Pascal, in aula c'erano dei "tre in uno" che avevano visto giorni migliori. Su accordo con il docente, ho portato questi tank al secondo incontro, per ottenere il credito e non dover più tornare. E così, dopo il lancio, dal diffusore si è levato un forte ruggito mescolato a suoni gorgoglianti e gutturali. Insomma, il "tre in uno" da 33 MHz non era in grado di gestire correttamente quel "mini applicazione". Ma per il resto andava tutto bene. Ovviamente, a parte l'interrogazione lenta della tastiera, che rovinava l'intero gameplay indipendentemente dalle prestazioni del PC.
Ma il problema principale non è in "Pascal"
Secondo me, "Tanchiki" è il massimo che si poteva ottenere da Turbo Pascal senza l'inserimento di codice assembly. Tra i chiari svantaggi del prodotto finale ci sono il lento interrogare della tastiera e la lenta renderizzazione della grafica. A peggiorare la situazione c'era il numero estremamente limitato di librerie e moduli di terze parti. Si potevano contare sulle dita di una mano.
Ma ciò che mi rattristava di più era l'approccio nell'istruzione scolastica. I bambini all'epoca non venivano informati sui vantaggi e sulle opportunità di altri linguaggi. Nelle lezioni si iniziava subito a parlare di begin, println e if, bloccando gli studenti all'interno della paradigma del Basic-Pascal. Entrambi questi linguaggi possono essere considerati esclusivamente didattici. Il loro utilizzo pratico è un fenomeno raro.
Perché insegnare ai bambini linguaggi falsi è per me un mistero. Possono essere più facili da capire. Le varianti del "Basic" vengono utilizzate in alcune situazioni. Ma, in ogni caso, se una persona decide di legare il proprio futuro alla programmazione, dovrà imparare altri linguaggi da zero. Allora perché non assegnare ai bambini le stesse compiti didattici, ma già su una piattaforma (linguaggio) adeguata, che gli permetta di progredire autonomamente?
A proposito di compiti. A scuola e all'università erano sempre astratti: calcolare qualcosa, costruire una funzione, disegnare qualcosa. Ho studiato in tre scuole diverse, e abbiamo avuto "Pascal" al primo anno di università, e mai una volta i docenti hanno proposto un compito applicativo realistico. Ad esempio, realizzare un'agenda o qualcos'altro di utile. Tutto era artificiale. E quando una persona risolve per mesi compiti vuoti che poi vanno nel cestino... In generale, le persone escono dall'università già esauste.
A proposito, al terzo anno dello stesso ateneo ci hanno messo i "plus" nel programma. Sembrava una cosa buona, ma le persone erano stanche, sazie di linguaggi falsi e di compiti "didattici". Non si vedeva entusiasmo come la prima volta.
P.S. Ho cercato informazioni sui linguaggi attualmente insegnati nelle scuole nelle lezioni di informatica. È tutto come 25 anni fa: Basic, Pascal. Con punte di Python qua e là.
Fonte: habr.com
