Come posso affrontare l'atteggiamento di programmazione cult-cult?

Ho alcuni studenti di informatica in un corso di programmazione introduttiva obbligatoria che vedono un linguaggio di programmazione come un insieme di incantesimi magici, che devono essere lanciati per ottenere un effetto (invece di vederlo come un mezzo flessibile per esprimere la loro idea di soluzione) .

Tendono a copiare e incollare il codice da precedenti incarichi simili senza considerare l'essenza del problema.

Esistono esercizi o analogie per rendere questi studenti più sicuri di poter comprendere e comprendere la struttura e il significato di ogni codice che scrivono?

Potresti presentare loro una serie di esercizi, ognuno basato sul precedente aggiungendo qualche elemento aggiuntivo o attorcigliato al problema, o indagando il problema da una prospettiva diversa, che rivela una debolezza della soluzione precedente, che richiede un approccio nuovo e diverso . Ciò li costringe a pensare, analizzare, modificare e sperimentare ogni soluzione, anziché semplicemente incollare un pezzo di codice già pronto.

Un'altra possibilità - sebbene non strettamente un compito di programmazione - è di chiedere loro di stimare varie cose. Ad esempio, quanta acqua scorre attraverso il delta del Mississippi al secondo? Tali domande non hanno una risposta prestabilita, soprattutto perché è necessario formulare alcune ipotesi per arrivare a un (intervallo di) valori convincenti. E - sebbene le risposte a molte di queste "classiche" possano davvero essere cercate su Google - puoi facilmente inventarne di nuove che non sono (ancora) trovate da nessuna parte sulla rete.

Esempi di entrambi questi tipi di esercizi possono essere trovati, ad esempio, in Perle di programmazione di Jon Bentley. Anche il programmatore pragmatico ha alcune buone sfide.

Un terzo tipo di compito sarebbe quello di presentare loro un pezzo di codice con (uno o più) bug, che devono trovare e correggere. Questo li costringe di nuovo a usare le loro capacità analitiche e la ragione di come il programma sta effettivamente funzionando.

Aggiornare

Feedback da un commento di Billy ONeal:

Il problema con la "serie di esercizi" è che gli studenti che hanno un problema con un esercizio precedente sono completamente fregati per gli esercizi rimanenti.

Hai ragione, anche se ritengo che ciò riguardi più il problema generale di stabilire la difficoltà del corso al giusto livello / raggruppare insieme studenti di livello simile. Inoltre, si possono organizzare gli studenti in gruppi più piccoli dove sono tenuti a discutere e discutere sui problemi e sulle soluzioni e risolverli insieme. Se qualcuno non lo capisce, gli altri possono aiutare (questa configurazione migliorerebbe anche le capacità di lavoro di squadra). E se qualcuno cerca di essere pigro e lascia che gli altri facciano tutto il lavoro, viene sicuramente notato dall'insegnante (che dovrebbe camminare, supervisionare e tutorare gli studenti, non giocare a WoW sul suo laptop in un angolo ;-)

E si può anche regolare gli esercizi per accogliere studenti con diversi livelli di abilità. I principianti possono andare più lentamente, quelli più esperti più velocemente.

Stai combattendo l'atto di bilanciamento degli studenti sul loro bisogno di prendersi cura della tua materia e sul loro bisogno di ottenere voti positivi . Molti studenti ritengono che:

(Get it Wrong || Experiment) == (Grado fallito && tempo sprecato)

Non appena uno studente sente che il proprio tempo o grado è a rischio, anche per una materia interessante, smette di imparare e passa direttamente a "Non mi interessa, basta dare all'insegnante la risposta giusta". I tuoi studenti stanno cercando di tagliare gli angoli (o almeno così pensano) pensando il meno possibile al problema e semplicemente risolvendolo copiando e incollando.

Ecco i miei suggerimenti su come gestirlo:

1. Usa il metodo Bob Ross: prova loro che è possibile e più veloce ricominciare da capo rispetto a copiare e incollare. Crea nuovi programmi davanti ai loro occhi durante le lezioni - mostra loro davvero che programmare può essere come dipingere un'immagine.
2. Fornire incarichi che richiedono creatività . Ad esempio, chiedi a ogni studente di creare le proprie strutture di dati (quali sono gli oggetti necessari per creare uno zoo, un negozio di animali, una città, un college, ecc.) Su carta da utilizzare durante il corso. Il compito n. 2 può convertire tali strutture in classi o oggetti, ecc. Fondamentalmente, attirali a pensare in modo astratto: ricompensali per essere creativi e poi ricompensali per aver trasformato la loro creatività in un programma per computer.
3. Utilizzare il minor numero possibile di sintassi. Cose come la creazione di classi e la sintassi del linguaggio sono così prevalenti nell'introduzione della programmazione che spesso induce in errore gli studenti a pensare che tutta la programmazione stia solo sapendo dove mettere le parentesi graffe - non si rendono conto che ciò che è nel mezzo del riccio le parentesi graffe è dove scorre la creatività . Scegli una lingua semplice e fornisci file di esempio (come un file di classe vuoto) per gli studenti che vogliono ancora copiare e incollare qualcosa. Man mano che il corso avanza, puoi gradualmente diventare più severo riguardo alla sintassi e agli incarichi compilabili.

Diverse cose che mi vengono in mente:

• Dai loro incarichi in cui devono effettivamente spiegare il codice scritto da qualcun altro. La comprensione del codice precedente o, più specificamente, la sua mancanza è sia la causa principale che il pericolo della programmazione di culto del carico. Chiedi loro di usare i commenti, riga per riga, se necessario, per spiegare il tuo programma in un inglese semplice (o in qualunque linguaggio umano tu usi).

• Solo dopo aver spiegato il codice, chiedi loro di modificarlo per apportare una certa modifica. Ad esempio, se hai assegnato loro una funzione di ordinamento in ordine decrescente, chiedi loro di renderlo in ordine crescente. O qualcosa di più impegnativo. Ma assicurati che sia qualcosa che richiede la comprensione del codice dato.

• Se lo desideri, puoi inserire alcune uova di Pasqua nel codice. Una linea o due che non fa nulla di utile o addirittura correlato al problema. Dai loro un indizio che tali linee esistono e concedi punti extra a coloro che le rimuovono.

• Allora e solo allora puoi dare loro un compito di scrivere un pezzo di codice da solo. A questo punto dovrebbero avere una comprensione molto migliore di cosa sia realmente il codice. Potrebbero persino trovare un po 'più facile farlo da soli.

L'idea di base è che la programmazione non è solo scrivere codice, ma anche leggerlo. Anche la lettura del codice dovrebbe essere insegnata.

Guardalo in un altro modo. Questo fenomeno cult-cargo è il palcoscenico per principianti del modello di acquisizione di abilità di Dreyfus . Ecco come impariamo. Quando ho imparato a programmare per la prima volta, tutto ciò che stavo facendo era digitare pagine di codice dal retro di Compute! rivista. La ripetizione è la chiave. I bambini imparano a parlare copiando i suoni che sentono i loro genitori fare. Tutto ciò che impariamo è attraverso l'imitazione. Non ci resta che insegnare come passare dall'imitazione alla padronanza.

Il problema che hai è che i tuoi studenti non ripetono nulla, lo stanno copiando da Internet. C'è qualche vantaggio in questo, ma i guadagni sono minimi. L'atto di scrivere il codice è ciò che mi ha portato a capire. Ho iniziato a vedere i modelli in ciò che stavo scrivendo e ho capito cosa stavo facendo.

Un'opzione è strutturare il tuo laboratorio come un dojo di codice. Chiedi agli studenti a turno di accoppiarsi tra loro sullo stesso problema. Scegli un problema che richiede circa 10-15 minuti per essere risolto. Ripeti questo problema su alcuni laboratori e introduce una nuova svolta al problema man mano che aumenta la competenza della classe. Forse avvii il laboratorio facendo in modo che gli studenti ti osservino mentre programmano la soluzione e che la ripetano. Cambio di coppie con ogni iterazione.

Per i tuoi test hai un codice kata in cui ogni studente affronta i problemi del semestre di fronte al resto della classe. Concentrati non solo sulla correttezza ma sulla forma e sulla creatività. Penso che ciò fornirebbe una comprensione più profonda di come programmare che dare incarichi da portare a casa.

Ho insegnato lezioni introduttive in passato e, come ricordo, guardando indietro ora:

Alcuni studenti pensano che la programmazione sia così per diversi motivi. Ricordo che una volta un bravo ragazzo ha adorato molto ciò che ho fatto:

Credendo che non si trattasse di un problema isolato, ma altri studenti della stessa classe potrebbero avere un comportamento simile o avvicinarsi al problema e non esprimerlo, mi sono sempre rivolto alla classe.

1. È stato impiegato del tempo per spiegare alcune cose come il determinismo, il che significava per loro che nello stesso ambiente con gli stessi dati e codice, avrebbero gli stessi risultati (dissipare la "casualità"),

2. Poiché la risoluzione dei problemi dipende dalle azioni dello studente e non da altro, l'attenzione dovrebbe essere nel risolvere il problema e nel non trovare l'incantesimo giusto,

3. Si trovano in un ambiente educativo, quindi i problemi sono creati per offrire un'esperienza di apprendimento, il risultato è imparare a programmare (o in alcuni casi come le lezioni per gli amministratori di sistema, come funzionano i programmi, che è diverso) e non a dammi una soluzione. ("World non ha bisogno di un'altra calcolatrice, è un esercizio"), quindi i loro problemi potrebbero essere risolti con i materiali disponibili (esempio: note fornite),

4. Penso che sia nel codice completo: "Anche se copi e incolli, il codice è tuo". Se qualcuno lo facesse, non dovrebbe essere in stile cargo. Ogni riga doveva essere spiegata a me (individualmente) o ad un altro studente (stesso) o alla classe.

I tuoi studenti hanno iniziato al "livello di astrazione" corretto all'inizio del corso? Ad esempio un compito che li introduce alle principali strutture di programmazione come loop e condizionali senza scrivere una sola riga di codice?

Quando ho iniziato la programmazione, il nostro primo incarico era chiamato " Rick the Robot ". Avevamo un pezzo di carta con una mappa aerea di una città con punti interessanti, come banche, negozi di alimentari, ecc ... Avevamo un tizio chiamato "Rick" e avevamo azioni come "fai un passo", "guarda a sinistra", 'guarda bene', 'attraversa la strada' e potremmo usare cose come 'ripeti' e 'se qualcosa, allora fai qualcosa'. (Questo non è al 100%, dato che non sono riuscito a trovare questo incarico) L'idea era che Rick potesse usare solo ciò che gli era stato dato e che doveva raggiungere diversi luoghi sulla mappa.

Questo è stato un esercizio divertente e qualcosa che ti ha fatto conoscere le basi (che a volte sono le più difficili da comprendere per i nuovi arrivati). Non esiste una buona risposta a questo problema (è un gioco) e non ci sono soluzioni da copiare e incollare. Qualcosa del genere potrebbe anche permetterti di giocare un po 'di più con la loro creatività senza intimidirli con il codice.

Infine, l'idea è di iniziare con l' astratto e passare al concreto . Non possono copiare gli abstract di incolla. Devono capirlo per risolvere un problema.

Quello che stai chiedendo loro di fare è dimostrare l'analisi e la sintesi nel dominio cognitivo della tassonomia di Bloom , dove attualmente stanno solo dimostrando l'applicazione.

Sfortunatamente, è una specie di situazione "conduci il cavallo nell'acqua". L'analisi e la sintesi sono anche molto difficili da fare quando si è ancora alle prese con la comprensione. Senza la comprensione in atto, le attività di analisi e sintesi fungeranno più da erbacce che da attività di apprendimento.

La mia opinione personale è che va bene non aspettarsi altro che un'applicazione nell'introduzione alle lezioni di programmazione. Questa è la prima volta che gli studenti sono stati esposti a questi concetti, quindi è come insegnare ai bambini a leggere prima di chiedere loro di scrivere un saggio. Queste abilità di ordine superiore seguiranno nelle loro classi successive.

Hai pensato di fornire loro un po 'di codice per cominciare? Qualunque sia la semplice impalcatura di cui ha bisogno il compito, come una funzione principale vuota (non so quale lingua stai usando). Qualcosa che compila e gira e non fa nulla. Quindi possono iniziare ad aggiungere il loro codice con un certo grado di sicurezza che almeno parte di esso funziona.

Questo è in realtà abbastanza comune nel "mondo reale"; molti IDE e altri strumenti creano progetti vuoti con librerie / modelli / file di configurazione tipici già presenti.

Qualsiasi tipo di mentalità di culto del carico (compresi gli stessi culti del carico ) deriva dalla mancanza di una comprensione fondamentale della tecnologia in questione.

La programmazione di culto delle merci non dovrebbe essere considerata un'abitudine problematica, ma piuttosto un sintomo della confusione di fondo che il programmatore sta affrontando.

Ancora più importante, il presupposto che la mancanza di comprensione da parte dello studente sia semplicemente l'espansione della sua mancanza di fiducia è fondamentalmente fuorviato e non affronta il problema di fondo.

Invece, lo stile di programmazione copia-incolla dello studente dovrebbe essere una bandiera rossa che ti dice che questo studente è sopraffatto dalla complessità di ciò che dovrebbe fare.

Sta istintivamente usando il lavoro passato come impalcatura su cui costruire il suo progetto attuale, cercando di comporre una soluzione usando problemi precedentemente risolti come elementi costitutivi. Lo facciamo tutti fino a un certo punto, ma la maggior parte di noi lo fa utilizzando le conoscenze acquisite dal lavoro passato come elementi costitutivi. Questo studente utilizza invece il lavoro stesso, il che significa che non capisce veramente i blocchi con cui sta lavorando. Ha decomposto il lavoro per quanto consentito dalla sua comprensione e tratta grandi blocchi di codice come unità atomiche perché non capisce come funzionano . Sa solo cosa fanno.

Cambia la tua idea di progetti!

Nel mondo della programmazione, raramente in realtà creiamo nuovi progetti per ogni soluzione che si presenta. Il più delle volte modifichiamo quelli vecchi.

Cambia la tua idea di un progetto da una soluzione per ciascun incarico a una soluzione per l'intero semestre. Ogni incarico si basa sull'assegnazione precedente.

Esempio

Progetto: costruire un sistema di ascensore

• Assegnazione 1: stampa il piano attuale
• Assegnazione 2: creare le strutture dati per una classe di ascensore e stampare il pavimento in base all'ascensore
• Assegnazione 3: creare il codice che "sposta l'ascensore", stampando il pavimento. Accetta input da tastiera (> inserisci piano:)
• Assegnazione 4: gestire più ascensori

Il punto è che si basa sull'assegnazione precedente invece di riciclare le vecchie assegnazioni per una nuova attività.

Prendi in considerazione l'uso di un linguaggio di livello molto alto che richiede un minimo di codice del boilerplate.

Per me, è spesso il codice di caldaia in grandi strutture o linguaggi verbosi che sembrano incantesimi magici e ostacolano la comprensione.

Mi è stato insegnato personalmente ML nel mio corso introduttivo di programmazione CS. Per molti anni, Lisp è stato insegnato come introduzione alla programmazione al MIT. Entrambe sono scelte eccellenti. Alcuni dei vantaggi che hanno sono

• Interprete interattivo. Molto importante, in quanto ciò consente l'esplorazione.
• Molto succinta. Nessuna caldaia. Permette agli studenti di concentrarsi sulle idee che stanno cercando di esprimere.
• Relativamente oscuro e alieno (almeno rispetto a Java, C o altri linguaggi tradizionali con cui gli studenti potrebbero già avere una certa esperienza). Sì, lo elenco come un professionista. Livella il campo di gioco per gli studenti, poiché probabilmente nessuno avrà precedenti esperienze. E rende meno probabile che saranno in grado di copiare e incollare soluzioni sul Web da compiti a casa.

Ho fatto qualche ricerca sui problemi dei programmatori alle prime armi negli anni '80. Sulla base della mia esperienza con programmatori alle prime armi oggi, non è cambiato molto. I principianti non hanno un utile modello mentale di ciò che fanno realmente i computer. Ricorrono a incantesimi magici perché la macchina stessa è magica.

La programmazione richiede la suddivisione di compiti naturalmente semplici in passaggi innaturalmente piccoli. Dato che i novizi non affrontano una granularità così fine nella vita quotidiana, è difficile per loro capire quali dovrebbero essere i piccoli passi, specialmente quando non è chiaro quali piccoli passi siano resi disponibili dalla macchina. Ma anche se riescono a capirlo, vengono quindi confrontati con la sintassi accentuata e la semantica limitata di un linguaggio di programmazione (un linguaggio innaturale mascherato da quasi-naturale) che controlla la macchina del mistero con il controllo remoto.

Poiché non sono in grado di stabilire una connessione tra una soluzione logica al problema e la funzionalità della macchina, si concentrano sulla soddisfazione delle esigenze del linguaggio. Il primo obiettivo è scrivere qualcosa - qualsiasi cosa - che si compili. Il secondo è modificare quel programma - qualunque cosa faccia effettivamente - per evitare che si blocchi. Quindi, se hanno il tempo, l'energia e l'interesse, provano a ottenere il programma per produrre risultati che assomiglino a ciò che il problema richiede. Lungo la strada, possono accidentalmente produrre codice ben scritto.

Con ogni probabilità, i novizi che imparano a programmare hanno successo perché hanno inferito un utile modello mentale del computer, non perché ne sono stati intenzionalmente forniti uno e lo hanno interiorizzato.

Potresti porre loro domande su pezzi di codice che richiedono risposte scritte? Tipo "Cosa sta facendo questo codice?" "Perché il programmatore l'ha risolto in questo modo?" "Esiste un modo migliore?", Ecc.?

Ciò li indurrà a pensare al problema, che è qualcosa che possono fare senza nemmeno toccare il codice.

• Sfidali a creare le soluzioni più brevi possibili al problema.
• Ricompensa le soluzioni più concise con un incentivo.
• Crea esercizi che ruotano interamente attorno al codice di refactoring
• Chiedi agli studenti di scambiare incarichi e di simularli per efficienza e pulizia del codice e di utilizzare alcuni dei meno efficienti come esempi, su un proiettore a soffitto.

Simile all'idea di JoelFans è che facciano eseguire i compiti iniziali su carta usando uno pseudo codice (lingua) che crei. Puoi aggiungere le strutture come meglio credi e non si preoccupano della scatola magica.

Presumo che per "culto delle merci", intendi dire che stanno inserendo elementi che ritengono necessari, ma in realtà non fanno assolutamente nulla per risolvere il problema.

In tal caso, puoi sempre aggiungere un certo fattore alla valutazione basata sulla concisione: lasciare codice superfluo o ridondante nel tuo programma richiede problemi in futuro, in quanto potrebbe interrompersi o semplicemente renderlo più difficile da mantenere.

Sarebbero stati giudicati allo stesso modo in un esercizio di scrittura in una lezione di inglese - nessuno vuole cose che vanno in una tangente a caso o che in genere è sconclusionato senza arrivare al punto.

Quando prendevo un corso di assemblaggio, l'insegnante ci diceva per ogni esercizio se voleva che scrivessimo il codice per velocità, dimensioni o utilizzo della memoria, e segnava se non ti avvicinavi all'ottimizzazione di ciò che chiedeva per.

...

Se stanno copiando e incollando il codice da precedenti incarichi simili, ed è in realtà qualcosa per risolvere il nuovo problema ... beh, questo è solo un riutilizzo del codice e, a meno che non abbiano fatto cattive ipotesi sull'idoneità del codice per il riutilizzo , Penso che sia perfettamente ragionevole per loro fare. (ad esempio, lettura da un file, ricerca di input ... tutte le parti modulari che possono essere riutilizzate. Se non si desidera che lo facciano, è necessario rendere gli esercizi diversi.

Sfortunatamente, è così che funziona il cervello di molte persone. Quindi vai a questa comprensione che ci sono persone che non puoi "curare" di questo. Ci sono molte persone che non sono in grado di lavorare al livello di precisione mentale necessario per la programmazione. Alcune persone semplicemente non sono progettate per questo. Non sto dicendo di arrendermi agli studenti - sto dicendo che non dare per scontato che stai fallendo se non tutti lo raccolgono.

Senza sapere di più sul contesto della classe, direi di concentrarsi maggiormente con questi studenti problematici sulle strutture di base: semplici if / thens, loop, ecc. Semplici routine per stampare numeri dispari, ogni decimo numero, ecc. Nulla più di 10 righe di codice ciascuna. Se sono "pensatori magici", ovviamente non hanno ancora imparato queste basi. Invitali a fare molte semplici routine diverse fino a quando non capiscono cosa sta succedendo. Qualcun altro ha menzionato la scrittura del codice su carta: penso che sarebbe anche un ottimo modo per fare queste semplici routine.

Potresti anche prendere in considerazione la possibilità di far apprendere loro diagrammi di flusso. Per alcune persone, essere in grado di vedere il flusso di un algoritmo e quindi come si collega al codice, può essere utile per loro collegando il codice al flusso.

Idealmente nella prima lezione, inizia con qualcosa di completamente astratto: chiedi loro (come gruppo, con te come leader) di scrivere le istruzioni su come andare a fare la spesa da un elenco e di dividere progressivamente le istruzioni di alto livello fino a quando non raggiungono l'illuminazione.

Aiuta a dire loro che queste istruzioni saranno seguite letteralmente da un robot, che non sa come inferire le cose. Tuttavia, deve essere un'attività molto pratica in cui sei incaricato di guidarli.

Alistair Cockburn parla del concetto di Shu-Ha-Ri e di come si applica alla programmazione, http://alistair.cockburn.us/Shu+Ha+Ri . Penso che potrebbe essere importante tenere presente dove si trovano i tuoi studenti in questo continuum. In primo luogo ciò contribuirà ad alleviare parte della tua frustrazione. Copia / imita è una risposta molto naturale e una modalità accettata quando inizi a imparare qualcosa. In secondo luogo, può aiutarti ad avere alcune idee su come andare avanti. Ad esempio, potresti prendere in considerazione la scelta di un problema che può essere risolto in più modi (loop vs. ricorsione, console vs. web / gui) e poi esplicitamente risolverli prima in un modo, poi in un altro - bonus che possono imparare sul riutilizzo del codice legittimo, la componentizzazione, la creazione di librerie riutilizzabili, ecc.

Un altro modo di successo che ho visto usato è quello di avere una serie di progetti che si basano l'uno sull'altro, rendendo disponibile una versione funzionante di default in ogni fase dopo che i compiti sono stati consegnati per impedire alle persone di rimanere indietro. Ogni fase del processo dovrebbe introdurre qualcosa di nuovo. Ti concedo che ciò può essere più facile da fare in una classe di progettazione rispetto a una classe di programmazione, ma dovrebbe essere comunque fattibile. Una cosa bella di questo è che dai loro esplicitamente una buona implementazione (si spera) da confrontare con la loro ad ogni passo. Esporre questo confronto come un compito, cioè fare una revisione mini-codice del proprio codice contro il loro sforzo. Potresti voler rendere questa una delle diverse opzioni di credito extra.

Anche se in genere non sono grande sui "commenti", potresti voler rendere la documentazione del codice uno degli articoli di valutazione. Invitali a produrre un documento "Teoria del funzionamento" per ogni progetto che descriva il loro approccio, come ciascun componente si adatta e come risolvono insieme il problema. Normalmente, vorrei che il codice facesse gran parte di questo da solo, ma li avrebbe spinti a mettere i loro cappucci pensanti e metterli sulla carta.

Infine, potresti voler essere creativo e chiedere ai tuoi studenti di rivedere il codice reciproco e di dargli una valutazione. Metti la pressione dei pari a lavorare per te. Consenti a questo di diventare parte del voto o credito extra per il codice (e i documenti) con il punteggio più alto.

Solo un suggerimento veloce. Ogni volta che ho un problema di programmazione che deve essere risolto o debug mi piace guardare il mio codice e "giocare al computer" dove nella mia testa tengo traccia delle variabili e dei loro valori e di cosa mi aspetto che siano quando ogni riga viene eseguita . Quindi, se ho copiato del codice da qualche parte, a meno che non sia completo da solo e ho solo bisogno di fare riferimento a esso, mi piace andare riga per riga per capire esattamente cosa sta succedendo. Essenzialmente giocando al computer. VBA Debugger essenzialmente semplifica questo compito, ma fare in modo che i tuoi studenti lo facciano su carta potrebbe dare loro fondamenti simili. Cosa fa effettivamente questa linea?

Ho insegnato programmazione introduttiva a livello universitario. È stato un corso di pane e burro, lo ha fatto tutta la facoltà e penso che l'abbiamo fatto abbastanza bene. Abbiamo seguito un testo comune e abbiamo avuto esami comuni, ma ognuno di noi ha avuto il proprio metodo di classe che ha funzionato. È passato molto tempo da allora, ma a volte riesco a insegnare un bambino a programmare, e l'intera immagine è più o meno la stessa.

Il modo in cui lo faccio è iniziare dal basso, il più concreto possibile. Ciò che gli studenti sanno è una struttura. Hanno già molti concetti. Sto costruendo ulteriori concetti oltre a quelli e sto eliminando i concetti che possono formare che sono controproducenti. Allo stesso tempo, li faccio imparare facendo .

Avevo costruito un piccolo computer con un chip Intel 8008, alcuni EPROM e alcuni circuiti. L'avevo programmato per riprodurre un piccolo duetto quando il chip I / O era collegato a un paio di altoparlanti. Spiegherei come funzionava il piccolo programma, con un ciclo interno per il conto alla rovescia di un contatore. Sarebbe un ritardo. Quindi alterna il bit di output e lo fa di nuovo. Lo farebbe per un po ', quindi passerebbe a un altro ritardo, dando un altro tono e così via. Il chip di memoria aveva un piccolo timer e, se avessi inserito un cavo del condensatore sotto uno degli ingressi del timer, il programma avrebbe eseguito lentamente la visualizzazione . La classe poteva sentire i relatori che facevano clic, clic, clic ... Volevo che la classe capisse che il computer stava facendo cose molto semplici un passo alla volta. Quindi sgancerei il cavo del condensatore e la "musica" scoppierebbe. (applausi)

Quindi avevo creato un simulatore per un computer decimale molto semplice, con 1000 posizioni di memoria, ognuna con un numero decimale a 4 cifre con segno. Aveva codici operativi molto semplici come "aggiungi all'accumulatore", "salta se negativo" e così via. Vorrei che scrivessero piccoli programmi in questo "linguaggio macchina", come aggiungere due numeri o aggiungere un elenco di numeri. Quindi potrebbero vederlo funzionare facendo un singolo passo o tenendo premuto il tasto Invio per vederlo correre "veloce".

Il punto era quello di mettere in atto il concetto che i computer possono eseguire solo un numero molto piccolo di diverse operazioni di base, e le eseguono una alla volta. Questo per contrastare l'impressione che i computer siano complicati e che facciano tutto allo stesso tempo, e leggano la tua mente nell'affare.

Da lì siamo passati alla programmazione in un linguaggio "reale" (BASIC :), iniziando con programmi molto semplici ma interessanti, lavorando su condizionali, loop, array, file, fusione e così via. Lo scopo era mettere a punto un set di abilità sufficiente per poter intraprendere un progetto di propria scelta, perché questa è l'unica cosa che rende interessante la programmazione: l'uso a cui puoi metterlo. Avrei buttato via alcune idee per i progetti, e poi le avrebbero prese da lì. Chiederei idee scritte e poi rapporti sui progressi, per impedire loro di rimandare all'ultimo minuto e poi andare nel panico. Penso che i progetti siano stati la parte migliore, perché stavano imparando con le proprie forze.

Quella base iniziale in una comprensione molto concreta di ciò che fanno i computer ha reso molto più facile insegnare concetti in seguito che altrimenti sarebbero veri e propri dossi, come array o (in un corso successivo) puntatori. Tendiamo a glorificare il concetto di "astrazione" come questa cosa meravigliosa, ma deve essere costruita su una base concreta, non sull'aria.

Un programmatore autodidatta Credo che l' animazione sia la più impegnativa in termini di conoscenza del codice. Quando un programma contiene algoritmi e trasformazioni matematiche che eseguono manipolazioni astratte, l'unico modo per capire cosa sta facendo la matematica in un dato punto (a meno che tu non sia un genio) richiede la comprensione dell'esecuzione del codice stesso.

Correggimi se la mia idea ingenua non è corretta. Quello che vuoi fare è notimpedire ai tuoi studenti di usare "modelli di progettazione", ma trovare un modo per assicurarsi di capire cosa sono i CnP? Quindi sfida i tuoi studenti a manipolare un'animazione. Per modificare l'output in un'animazione è necessario capire cosa sta succedendo ad ogni passaggio. Per la tua preoccupazione dichiarata, immagino che un progetto di animazione ben concepito si manifesterà in modi ovvi quando uno studente lo "capisce" - quando hanno realizzato una trasformazione che non ti aspettavi o hanno modificato alcune variabili correlate e interdipendenti.

Senza conoscere i limiti pedagogici e gli obiettivi a cui stai lavorando, non posso dire che l'animazione sia la risposta completa. Un intero curriculum di animazioni al di fuori della professione di animatore è, dovrei rischiare di indovinare, fuori discussione. Alcuni progetti potrebbero comunque portare a qualcosa di abile e meraviglioso, che non è male.

In un'altra nota, ho letto un articolo di giornale (sì, carta!) Su una competizione per le Olimpiadi di programmazione di livello superiore - wot-wot - competizione per programmatori pre-college. La descrizione delle loro sfide era la più chiara articolazione del codice puro che posso ricordare di aver letto. I concorrenti sono giudicati l'uno contro l'altro e secondo gli standard di buona pratica. Per queste competizioni gli studenti devono sia pianificare la propria soluzione sia codificare a mano lo "schema progettuale" elementare che il problema richiede di finire entro i termini. Quindi, la soluzione alla tua preoccupazione riguardo alla programmazione CnP è testare se gli studenti possono scrivere gli stessi "pezzi di codice" che sono CnP'n!

Sono sicuro che fosse nel New York Times. Una rapida ricerca non l'ha trovata. Un esempio simile è il Concorso internazionale di programmazione collegiale di ACM. Questo concorso enfatizza la programmazione rapida: "La programmazione velocissima nella competizione a squadre è un'abilità decisamente eccentrica, non esattamente uno che molte persone in cerca di lavoro metterebbero in cima a un curriculum." Quindi consiglierei l' astrazione dai problemi del mondo reale è la risposta.

Anche,

HP Code Wars

Insegna alla classe usando un linguaggio di programmazione tecnicamente valido ma talmente oscuro da non riuscire a trovare alcun codice esistente da copiare.

Potresti anche trattarli nel modo più duro.

Trova un modo per rendere un copia-incolla dannoso per loro. Non ho un esempio preciso, ma se realizzi un primo esercizio la cui soluzione, se incollata in un secondo esercizio dall'aspetto simile, porta gli studenti di culto in un lungo e doloroso "instabilità instabile" o "bug silenzioso di corruzione dei dati". Nel frattempo un pensiero "non-cult-cult" avrebbe portato una soluzione ovvia anche al peggior studente (se non avesse visto la prima soluzione di esercizio). Quindi, forse c'è qualche possibilità che possano imparare la lezione e pensarci due volte prima di copiare il codice di incollaggio nel terzo esercizio.

Dubito che questo comportamento sia dovuto alla convinzione che i programmi siano incantesimi, più probabilmente pigrizia e mancanza di motivazione.

Quindi penso che il tuo lavoro come insegnante sia quello di motivare i tuoi studenti - nessuno studente che sia sinceramente motivato taglierà e incollerà una soluzione (che è solo per i programmatori che lavorano con scadenze e profitti da rispettare ...)

Insegnare subroutine. Invitali a prendere il codice che stanno afferrando da incarichi precedenti e trasformarlo in una subroutine. Insegnare loro sulla documentazione delle funzioni per aiutarli a capire cosa sta effettivamente facendo la subroutine.

Fagli fare il compito di fronte a te in classe senza accesso a Internet (chiedi alla scuola di interromperlo, non consentire l'uso del telefono durante le lezioni). Almeno fallo per i test. Non vi è alcun motivo per cui dovrebbero utilizzare Internet per esperimenti di programmazione di base. Il libro dovrebbe essere una risorsa sufficiente per le esercitazioni introduttive. Consenti l'utilizzo di Internet quando sei in una classe avanzata e hanno già imparato a pensare.

Non affidare mai incarichi simili.

O, più folle, imparali TDD dall'inizio. Spinge per scrivere (non copiare, scrivere) un sacco di codice (vale a dire test) che aiuta effettivamente a formulare il problema che viene risolto.

Qualcosa che ho trovato molto utile per le persone della mia classe è scrivere un piccolo progetto sulla loro, su un argomento che possono scegliere da soli.

Quando ho iniziato a programmare, è stato difficile anche per me e ho copiato molto in classe. Poi a casa, ho iniziato a creare piccoli giochi, poiché voglio diventare un programmatore di giochi e li ho trovati molto più facili da realizzare. Anche se erano molto più difficili delle cose che abbiamo visto in classe. Solo perché mi interessava.

Alcune altre persone della mia classe sono passate dal 40-50% degli esami al 90-100%, perché hanno fatto esattamente la stessa cosa.

Quando ero in un corso di programmazione introduttiva, l'istruttore richiedeva a tutti di scrivere un algoritmo in inglese, stamparlo e consegnarlo prima di iniziare a scrivere codice. Quindi dovremmo inserire molti commenti come Crea variabili, Ottieni input dall'utente, Esegui calcoli, Stampa output, ecc. Sono stato ancorato un paio di volte per non avere abbastanza commenti quando pensavo che ce ne fossero molti, quindi ho iniziato ad aggiungere Di Più. Questo mi ha costretto a pensare a quello che stavo facendo e scrivere le soluzioni e continuare a tradurre avanti e indietro tra inglese e Java.