L'orientamento agli oggetti è veramente buono per i bambini? [chiuso]

Silly user, Trix sono per i bambini, non concetti avanzati come la programmazione OO e il design. :)

Qualsiasi linguaggio che si concentri su come iniziare in piccolo, essere semplice, avviare un progetto e dare risultati immediati è un buon linguaggio per i bambini. Quel linguaggio per me era pre. Visual Basic .NET. È stato facile per me disegnare forme, scattare foto, scrivere facilmente semplici logiche condizionali all'interno degli eventi ed essere in grado di premere il pulsante Play per vedere il mio capolavoro prendere vita davanti ai miei occhi. Come un ragazzino che scrive i miei videogiochi è stato un vero e proprio vanto e mi ha appassionato abbastanza per perseguire questo come una carriera. (Ora che ho una vera carriera di successo, la gioia che un tempo sostenevo per lo sviluppo del software è stata brutalmente mutilata dalla realtà del mondo degli affari).

Introduci i bambini nei linguaggi di programmazione visiva che insegnano loro i concetti di base, mantenendo le cose divertenti e interessanti. Scratch sembra un progetto promettente. link

Altrimenti, se hai tempo e denaro da esaminare in Mindstorms, è un kit di programmazione robotica offerto da Lego. Semplici concetti di programmazione possono essere facilmente insegnati scrivendo programmi personalizzati da robot costruiti su misura. link

Generalmente sono propenso a introdurre OOP e la concorrenza in precedenza nelle istruzioni di quanto non sia generalmente fatto (o almeno è stato fatto nel mio tempo), MA ...

I bambini (presumo che stiamo parlando di pre-adolescenti) devono prima imparare le basi assolute, cose che diamo per scontate così tanto che non ci rendiamo neanche conto di conoscerle. Per quelli di noi che hanno imparato per la prima volta in età avanzata, potrebbero anche essere cose che sapevamo prima di apprendere la programmazione, ma le cose che i bambini potrebbero non fare ancora bene.

L'idea della sequenza è la più basilare. Le istruzioni sono eseguite in ordine. L'idea che le istruzioni causino cambiamenti deterministici nel programma e devono essere esatte. L'idea di ramificazione e looping in set di istruzioni. L'idea che le variabili abbiano un valore ma possono essere modificate e copiate. (Ricordo ancora quel momento di lampadina nell'algebra di seconda media quando capii che cosa era una variabile). L'esperienza di vita ci dà abbastanza per intuire queste cose, per raccoglierle velocemente una volta, ma i bambini potrebbero non avere l'esperienza di vita necessaria. Possono capirli una volta spiegati e dimostrati, ma spesso avranno bisogno di questa spiegazione.

Per iniziare, penso che abbiano bisogno di qualcosa in cui possano essere guidati alle istruzioni più basilari e vedere molto rapidamente le cose che accadono. Lascia che abbiano un'idea della relazione tra codice e azioni. Crea un ambiente che permetta loro di espandere il set di istruzioni ("Voglio fare in modo che la tartaruga vada in circolo!") E permetta loro di muoversi secondo i loro ritmi in modo da poter facilmente cambiare facilmente, ma c'è molto spazio per una maggiore complessità a seconda di quanto lontano e quanto velocemente sono in grado di andare.

Dopo aver compreso le relazioni concrete, allora farei abbastanza rapidamente (lasciandolo ad impostare il ritmo, ma spingendolo avanti mentre sembra pronto) passare a più astrazioni, come dividere il codice in funzioni, raggruppare i dati, connettere le funzioni allo stato (incapsulamento), quindi oggetti e polimorfismo. Se il bambino è ancora con te, sarà sulla buona strada e una volta acquisita una solida sensazione per l'astrazione, potranno essere introdotte cose come la concorrenza e altri concetti di programmazione avanzata.

Smalltalk non sembra essere più facile da imparare o usare di qualsiasi altro linguaggio moderno.

Potrebbe essere per il momento in cui è stato progettato negli anni '70 ... rispetto a LISP, sì.

La programmazione ha poco a che fare con i costrutti del linguaggio usati, e molto altro da fare con concetti come loop, funzioni, ricorsione ecc.

I programmi orientati agli oggetti potrebbero creare oggetti migliori del mondo reale, ma questo è fuorviante, poiché un buon design OO introduce il proprio insieme di problemi di progettazione.

Qualsiasi caratteristica rivoluzionaria di una lingua più vecchia rispetto a una moderna, o dovrebbe essere presente o già screditata.

Per finire con un aneddoto: Mentre ero piccolo (dato che l'inglese non è la mia prima lingua), i miei amici pensavano: "Se impari l'inglese, hai già quasi imparato a programmare". Anche allora sapevo che sono così lontani dalla verità.

Quindici anni dopo, sono fluente in inglese. Stai ancora imparando la programmazione e divertendoti.

Parla con i bravi programmatori che conosci come sono iniziati nella programmazione. Per i programmatori di una certa età, la mia ipotesi è che oltre 100X in più inizino con una qualche forma di "vecchia" base cattiva di qualsiasi cosa, come Smalltalk o persino Logo.

Dipende. La base dell'idea di progettazione orientata agli oggetti, quella degli oggetti essendo qualcosa a cui si inviano messaggi, può essere insegnata piuttosto bene. Quando ho visto il ricercatore dietro il progetto che alla fine è diventato Microsoft Kodu parlare a Ignite Seattle diversi anni fa, tutti i dubbi che avevo sui progetti orientati agli oggetti essendo un problema per i bambini sono stati eliminati. Alcuni aspetti di OO sono abbastanza intuitivi, dopo tutto. Ci sono idee molto specifiche che si adattano bene ai domini a cui i bambini (e altre persone curiose) possono riferirsi.

La più ampia domanda se le astrazioni comuni nei buoni progetti OO siano adatte per insegnare ai bambini? Uno molto più difficile. Ho iniziato con linguaggi imperativi (e Logo), e conosco molto il linguaggio dei pattern che rendono i progetti OO più flessibili, ma anche come professionista ho un piccolo problema a conoscere, per ogni problema, quale sia l'astrazione migliore. Ma quell'equilibrio è una grande quantità di ciò che riguarda la programmazione professionale, e non ho avuto bisogno di sapere tutte queste cose quando ero un appassionato fino a quando non è venuto fuori un problema che non sapevo come risolvere. Quindi non sono sicuro che sia un problema, a seconda di quali sono i tuoi obiettivi nell'insegnamento.

Per quanto riguarda le tue domande specifiche su Smalltalk, non posso rispondere, ma Squeak , un'implementazione Smalltalk, potrebbe essere divertimento per i bambini che vogliono andare oltre le basi che incontrano con qualcosa come Kodu o, ad esempio, Logo. L'unico vero modo per rispondere se è efficace per insegnare OO è provare.

Poiché la maggior parte della mia codifica da bambino era autodiretta e la disponibilità di qualsiasi comunità intorno a me era quasi inesistente, usavo gli strumenti disponibili con il sistema che avevo, che fondamentalmente significava base, logo e un quantità modesta di Assemblaggio (TMS9900 e 6502/8502). È giusto dire che un bambino adeguatamente curioso e determinato ti sorprenderà se fornisci strumenti che rendono le cose semplici divertenti e difficili, e forniscono un tutoraggio adeguato quando rimangono bloccati su qualcosa. Quindi sono abbastanza convinto che potresti dare il figlio giusto Lisp o Perl o C # o Elaborazione o Ruby e loro scopriranno molte cose da sole e diventeranno incredibilmente frustrati con cose che non ti aspetteresti necessariamente di essere un problema (che è dove un adulto esperto può aiutare). Ma molti bambini, almeno dopo una certa età, non saranno nemmeno curiosi o determinati abbastanza da andare oltre la stampa del loro nome alcune centinaia di volte sullo schermo. Non sono molto sicuro di quanto il linguaggio sia importante nelle prime fasi di apprendimento sui computer, a parte il fatto che dovrebbe essere relativamente a basso attrito per ottenere qualcosa di visivo.