spyked bricks in the wall

atunci când limbajul de programare face mai mult rău decât bine

La sfârșitul articolului „o propunere privind predarea programării în școli” spuneam că, citez:

Încheind, adaug faptul că ideea în sine a predării programării „as soon as possible” nu e nouă și există implementată în România în cadrul unui set de cursuri numit Digital Kids. Inițiativa e una din care sistemul învățământului de stat ar avea multe de învățat. Cel mai important aspect, în opinia mea de om care nu prea are legături cu știința pedagogiei, e acela al impulsionării copiilor să gândească și să învețe să facă chestii, moment în care toată discuția privitoare la limbaje de programare devine superfluă.

Mă văd nevoit să justific afirmația, arătând astfel că dezbaterile pe marginea limbajelor de programare în cadrul educației sunt în mare parte inutile și, mai mult, că o astfel de gândire orientată către limbaje de programare nu face decât să dăuneze.

Să stabilim încă din capul locului un lucru: susținerea unui limbaj de programare sau al altuia nu face altceva decât să îi hrănească orgoliul — sau mai bine zis aerele — susținătorului, respectiv să întrețină o atmosferă de „circle jerking” în cazul în care există mai mulți susținători ai aceluiași limbaj. Nimic altceva. Susținerea lui X sau a lui Y necesită probe, ori „X e mort” și „Y e mai ușor de înțeles” nu sunt probe, deoarece se traduc drept „mie nu îmi place să programez în X” și respectiv „eu înțeleg mai ușor Y”, iar experiența personală nu are de-a face cu nimic aici. Ori susținătorul vine cu date concrete [i], ori măcar este propusă folosirea sau implementarea unui sistem educațional concret [ii], ori discuția s-a terminat.

Un set de argumente cât de cât decente ar suna deci în felul următor:

• (a) Pascal e un limbaj nepopular în industrie. Dorim să îi învățăm pe elevii de liceu limbaje care să le folosească mai târziu.
• (b) Programarea funcțională are dezavantajul că ascunde multe lucruri, cum ar fi de exemplu strategia de evaluare a expresiilor. Opacitatea asta îi poate induce în confuzie pe elevi.
• (c) C expune prea multe detalii „low-level” (pointerii). Astea îi încurcă mai mult pe elevi decât să îi ajute, dat fiind faptul că ei trebuie să învețe să implementeze algoritmi, nu să verifice dacă nu cumva au uitat să pună steluțe sau nu.

Exemplele ar putea continua, însă haideți să ne oprim aici și să invalidăm rând pe rând toate aceste argumente, pentru că ele sunt în fapt invalide. (a) este poate cel mai popular și în același timp și cel mai ușor de combătut. Plecăm de la premisa că nu există limbaj de programare „general purpose” în sensul absolut al sintagmei: fiecare limbaj a fost scris pentru a rezolva un set destul de restrâns de probleme sau s-a dovedit în timp a fi mai eficient în acest sens [iii]. Cu alte cuvinte orice limbaj e o unealtă distinctă, folosită în scopuri distincte [iv].

(a) susține că poate ajunge să îi învețe pe elevi o metodă de programare prin care să rezolve brusc toate problemele existente în software, ceea ce e în mod evident fals. În plus, industria caută tot soiul de limbaje, astfel că viitorul programator se va găsi nevoit oricum să învețe alte limbaje mai devreme sau mai târziu, ajungând la un moment dat să spună „a, da’ degeaba am făcut Python în liceu, că tot nu mi-a folosit la nimic”. Morala e că cea mai bună unealtă de programare în contextul educațional e unealta cea mai bună pentru educație, iar Python s-ar putea să fie un candidat în acest sens. Dar la fel de bun candidat e și Pascal, care la urma urmei a trecut testul timpului în educație: în urma predării lui în licee au ieșit mulți programatori buni, chit că aceștia nu mai programează în Pascal.

(b) mi se pare un argument foarte tare. Problema e că se aplică pentru toate limbajele de nivel înalt, nu numai în cadrul celor funcționale. Și Python are aceeași problemă, pentru că folosește duck typing. Limbajele orientate pe obiecte au aceeași problemă, însă la nivelul datelor: e foarte dificil să vezi când sunt create sau (mai ales) distruse obiecte chiar și pentru programatorii mai experimentați, mai ales dacă apelezi la mecanisme precum garbage collector-ul. Mi se pare însă că Scheme e un limbaj funcțional foarte util pentru educație, mai ales datorită faptului că are unelte foarte bune pentru programare interactivă, iar procesul de evaluare poate fi observat pas cu pas. Altfel, nivelul de abstractizare contează la fel de mult în cazul educației cât și în cel al industriei, neexistând un unic răspuns la problema asta.

În fine, (c) se bate cap în cap cu (b), deși e deseori susținut de una și aceeași persoană. Pur întâmplător, C este și unul din cele mai simple [v] limbaje de programare, în ciuda faptului că are pointeri, sau poate în virtutea acestui fapt. Problema apare atunci când trebuie să îl înveți pe elev programare, adică atunci când ești nevoit, vrei nu vrei, să intri în detalii urâte cum ar fi acela că variabila se află într-un soi de container, în memoria calculatorului, și nu în ceva univers paralel; și că vrei să accesezi valoarea variabilei, iar asta poate implica un nivel în plus de indirectare. Vă urez mult succes să explicați conceptele astea unui neinițiat, folosind limbaje de nivel cât mai înalt.

Am pus exemplele astea pe foaie nu întâmplător, ci pentru a demonstra un punct de vedere foarte tare și foarte dureros din lumea științei, matematicii, ingineriei și în particular a calculatoarelor: de cele mai multe ori limbajul de programare face mult mai mult rău decât bine. Cea mai mare nerozie ar fi să uităm că limbajul matematic, specificațiile formale și limbajele de programare au fost făcute pentru a fi concise și neambigue [vi], fapt ce aduce cu sine constrângeri de expresivitate. Din acest motiv, înainte de toate elevii ar trebui învățați să exprime corect probleme de orice natură folosind limbajul natural [vii] și abia apoi să le implementeze într-un (alt) limbaj oarecare.

Limbajul de programare este deci important — strict din punctul de vedere al profesorului — și trebuie ales cu atenție, și mai ales trebuie aleasă cu grijă metoda de a preda programare, indiferent de limbaj. Însă mai importantă de atât este obligația de a-i face pe elevi să înțeleagă ce programează (calculatoare numerice), cum (folosind limbaje de programare), și care sunt prăpăstiile [viii] acestei discipline. Asta e în opinia mea o provocare mult mai mare decât alegerea limbajului potrivit pentru predarea programării — deși întreb din nou: ce predăm, programare sau informatică? — în licee sau în școli generale.

1. e.g. în Somethinglandia s-a implementat un program de educație bazat pe Y care a dat rezultate pozitive, deci în virtutea faptului că sistemul nostru educațional are anumite fapte în comun cu cel din Somethinglandia, Y ar funcționa destul de bine și la noi. [↩]
2. Am menționat Alice în cadrul discuției de la care am pornit articolul anterior. Reacția la el a fost aproape zero, semn că cei mai mulți oameni nici măcar nu s-au obosit să vadă ce au făcut alții, poate oleacă mai cunoscători decât ei în domeniu. [↩]
3. De exemplu C e foarte util în sisteme embedded, Python e folosit la „hacking”, Haskell e util pentru a scrie programe „robuste” și verificabil-corecte, Java și C++ pentru proiecte software mari și așa mai departe. Nu zic că nu merge să scrieți în Python programe pentru microcontrollere, zic doar că „it beats the purpose”. [↩]
4. Cam ca diferența între sapă, cazma și lopată. [↩]
5. Nu în ceea ce privește curba de învățare. A nu avea concepte precum „tipuri algebrice” sau „metode virtuale” se dovedește însă de multe ori a fi un factor simplificator. [↩]
6. Un alt domeniu unde se aplică în egală măsură ideea este cel judiciar. [↩]
7. Fapt de care mulți ingineri și oameni de știință de seamă sunt incapabili. Mulți nu se pot înțelege între ei nici măcar în cadrul aceleiași arii de studiu, să nu mai vorbim de momentul în care punem calculatoristul față în față cu fizicianul sau geologul. Iar dacă ne gândim că cei mai mulți profesori — înafară de Feynman poate — sunt incapabili să explice fenomene fundamentale într-un mod care să îl facă să înțeleagă pe prostul de rând, deja e jale. [↩]
8. O traducere zic eu decentă pentru „pitfalls”. [↩]