rtfblog

Pirmoji šio serialo serija čia, antroji čia.

Ar svarbu turėti debugerį? Kokiomis aplinkybėmis?

“O mein Gott! Kas čia per klausimas! Kaip gi galima programuoti be debugerio?!”

Bla bla. Ne apie programavimą kalbam. O apie vidurinę mokyklą. Ten niekas neprogramuoja, ten žmonės mokosi. Mokosi rašyti paprastas programas. Jas rašo ir skaito tik autoriai ir mokytojai. Jos yra tuoj pat išmetamos. Jos yra mažos.

Nematau kaip debugeris čia galėtų padaryti juntamą įtaką. Ypač jeigu vaikams yra paaiškinami kiti būdai ieškoti klaidų, iš kurių svarbiausias -- introspekcinis print.

Dar vienas akmuo į debugerio daržą -- vėl, interpretatorius. Kai kas nors negero įvyksta su interpretuojama programa, padorus interpretatorius parodys ir steką, ir kintamųjų reikšmes. O tai yra du trečdaliai to, ką aš, profesionalas, pirmiausiai noriu matyti, kai įsijungiu debugerį. Kam moksleiviui daugiau?

Taigi, debugeris lemiamos rolės negroja.

Dinaminis ar statinis tipizavimas?

Mane labai stebina kai kurių žmonių fobija dinamiškai tipizuotoms kalboms ir jų taikymui mokykloje. Žmonės sugeba pareikšti, kad vaikas gali pradėti painioti kur 3, o kur “3”. Arba, dar geriau, paporina, kad statiškai tipizuotose kalbose, atsiprašant, “anksčiau” sužinoma apie vienokį ar kitokį tipų nesuderinamumą.

1. Jeigu painiojami literalai, jie painiojami spausdinant programos kodą. Tai niekaip nesusiję su tuo, kaip tipizuota kalba. Painiojo Python’e, supainios ir Paskalyje. Painiojo C, supainios ir JavaScript’e. Aš, beje, būdamas Lispo pradinukas iki šiol kartais pripainioju kur reikia (quote), o kur nereikia.
2. Mokykloje rašomos programos yra mažos ir vienatikslės. Netgi olimpiadiniuose uždaviniuose vienas “test run’as” apima praktiškai visus kodo kelius. Tad nėra jokio skirtumo ar tipų nesuderinamumą randa kompiliatorius, ar vykdymo mechanizmas. Nereikia net unit testų.

Nėra skirtumo!

Kalbos lituanizavimas.

Kai EuroPython’2007 Guido pasakė, kad Python 3000 bus galima kintamuosius vadinti bet kuria kalba, vieni žmonės sutiko šią žinią aplodismentais, kiti šaltai. Aš buvau prie pastarųjų. Dėl to, kad šia tema mane drasko dvejonės.

Viena vertus, akivaizdu, kad iš šių trijų eilučių pirma yra gražiausia:

sąrašas = [1, 2, 3]     # (1)

sarasas = [1, 2, 3]     # (2)
listas  = [1, 2, 3]     # (3)

Kita vertus, neseniai parsisiunčiau vienos atvirojo kodo programos išeities tekstus. Išpakavau, pažiūrėjau į failus, vienas iš jų buvo pavadintas vokiškai. Pakvipo negeruoju. Netruko išaiškėti, kad kode esama angliškai pavadintų kintamųjų, esama ir vokiškai. Kai kurie komentarai angliški, kai kurie vokiški.

Nepaisant to, kad projektas mane iš principo domina, tokios betvarkės per akis pakanka, kad aš prie jo neprisiliesčiau. Ir neprisiliesiu.

Žiūrint toliau, kas jeigu tokia pati betvarkė komercinės įmonės kode? Ar norėtųsi dirbti tokioje kontoroje prie tokio kodo? Man ne.

Todėl aš atsargiai žiūriu į moksleivių skatinimą rašyti lietuvišką kodą. Vienas dalykas yra to nedrausti (juk transliatoriui vienodai šviečia, ar kintamasis pavadintas sarasas, ar list, ar x), o kitas dalykas skatinti. Juk paskui teks perauklėti!

Žinoma, mano nuogąstavimus pagrindžia tik tie moksleiviai, kurie vėliau taps programuotojais ir juos reikės atpratinti nuo mokykloje įgytų blogų įpročių. Tuo tarpu didžiąjai daliai moksleivių -- tai, kuriai programavimo pamokos bus tik susipažinimas, lietuvybės įvedimas tik palengvins supratimą, sumažins atgrasumą.

Tiesą pasakius, nežinau…

(Ne)Prisirišimas prie OS.

Manau, šitas punktas nekvescionuojamas. Apie jį papildomai rašyti būtų laiko švaistymas, prirašyta jau tiek ir šitiek. Pakaks paminėti, kad tai turi tokią pat svarbą, kaip ir kalbos komerciškumas. Kalbos realizacija turi būti pasiekiama bent keliose populiariose platformose, būtinai bent vienoje nemokamoje. Kad nekainuotų ir nekvaršintų galvos.

O jeigu kas turite argumentų prieš, pateikite juos šitam vaikui: “mano tėtė alchitektaš, il paš muš namuoše tik Mašintokai; Tulbo Paškališ nedilba” ;-)

Neprisirišimas būtinas. Ir į jį reikia atkreipti daug dėmesio.

Rytoj baigiam.

Pirmoji šio serialo serija čia.

Gal verta mokykloje naudoti sudėtingesnę kalbą, "kad atsisijotų idiotai"?

Į šitą klausimą lengva atsakyti. Toks požiūris prieštarauja mano apibrėžtam pirmajam apribojimui -- neišgąsdinti. Tolimesnė diskusija šia tema iškrenta už šio serialo ribų.

Ne, neverta ir negalima.

Ar apskritai yra skirtumas nuo kurios kalbos pradėti?

Šia tema jau esu išsamiai pasisakęs.

Taip, yra!

Kompiliatorius ar interpretatorius?

Kad atsakyti į šį klausimą, reikia suprasti ar yra skirtumas ir jeigu yra, koks. Pradėsiu nuo to, kad mano nuomone, mokiniui nereikia suprasti kuo skiriasi šitie dalykai. Jeigu abu (t.y. dvi konkrečiai paimtos ir lyginamos realizacijos) vienodai patogūs pasiekti aukščiau aprašytiems tikslams ir nepažeidžia apribojimų, tai tinka vienodai. Kadangi kol kas kalbam abstrakčiai ir “turim” menamas geras realizacijas, skirtumo lyg ir nėra.

Bet kita vertus, kol kas nekalbėjom apie IDE. O kol nekalbėjom, į kompiliatorių privalom žiūrėti kaip į neinteraktyvią programą, kuria reikia išmokti naudotis vien tam, kad pasigaminti savo pirmąją programą. Maža to, nesuvokiant transliavimo stadijoje vykstančių procesų, gaunasi praraja mentaliniame modelyje: aš parašiau programą, tada vyksta kažkokie keisti dalykai, o tada programa paleidžiama ir (gerai jeigu) veikia.

Interpretatorius tokios spragos neturi. Tekstas rašomas tiesiai į interaktyvų interpretavimo ciklą. Kai norima parašyti didesnę už kelias eilutes programą, ji rašoma mėgstamame redaktoriuje, kas yra intuityvu: “kad patogiau būtų”. Pabaigta programa sumaitinama interpretatoriui, ir ji iškart pradeda veikti (arba, vėlgi, neveikti :-)).

Kitas svarbus aspektas, prigimtinis interpretatoriaus “dialogiškumas”. Richard’as Wareham’as yra parašęs straipsnį su savo pastebėjimais apie komandinės eilutės interfeiso privalumus prieš grafinius. Pradinukų kontekste! Jo pastebėjimai beveik vienareikšmiškai tinka svarstant kompiliatoriaus-ar-interpretatoriaus klausimą mokykloje.

Panašu, kad all else being equal, interpretatorius.

Kas svarbiau -- IDE, ar interpretatorius?

OK, tad kas gi stipresnis -- Arnoldas Švarcnegeris, ar Silvestras Stalonė? Kas, jeigu kompiliatorių apginkluosim IDE, gal jis tada nugalės interpretatorių? O jeigu abu -- gal pastiprės vienodai?

Visų pirma, svarstant IDE naudojimo mokykloje galimybę, reikia atkreipti dėmesį į komerciškumą. Netinka Visual This-and-that iš Microsoft. Netinka Borlando žaislai. Tinka Eclipse. Netinka Dev-C++ (tik dėl kitų priežasčių).

Toliau. Jeigu naudojam IDE, ką jis mums duoda? Duoda gerą programos kodo redagavimo įrankį (jeigu pasisekė!). Bet jų ir taip pilna, tik imk ir naudok. Duoda integraciją su kompiliatoriumi: nereikia mokytis dirbti su komandine eilute. Bet tokia integracija yra built-in interpretatoriuje. Duoda integraciją su debugeriu. Čia privalumas. Bet apie tai žemiau.

Panašu, kad IDE sulygina kompiliatorių su interpretatoriumi. Tad jeigu nekreipsime dėmesio į Okamo skustuvo principą, galime tarti, kad skirtumo nėra.

Ar IDE išvis reikalingas?

Ką dar duoda IDE?

• Integraciją su įrankiais,
• Produktyvumą didinančius įrankius: efektyvią paiešką per kodo bazę, valdymo personalizavimą, adaptaciją prie asmeninių ir kompanijos kodo standartų ir pan.,
• Kai kurių sudėtingesnių ar nuobodesnių aspektų paslėpimą. Read: kodo generavimio wizardai ir pan.

Ir ką gi visa tai duoda vidurinėje mokykloje? Ogi nieko!

Apie integraciją su įrankiais jau buvo šiek tiek kalbos. Ir bus dar. Kas liečia porą klavišų paspaudimų bekainuojantį kompiliatoriaus pakvietimą, čia būtų grįžimas prie kompiliatoriaus-interpretatoriaus klausimo. Kalbant apie GUI redagavimo įrankius, vėl, gaunam mokyklinio kurso smūgį į kaktą -- O KAM?!

Atitinkamai “o kam?” reikia paieškos per kodo bazę, kai jos nėra? Valdymo personalizavimo? Adaptacijos standartams?

Atrodytų, kad sudėtingumus paslepiantys kodo generatoriai tai jau tikrai pliusas… Tikriausiai taip. Profesionalui. Ir tai dar diskutuotina. O kam moksleiviui generuotis MFC event mapus, handlerius, stdafx ir ką jie ten dar moka generuot?

Peršasi išvada, kad IDE nereikalingas.

Tęsinys rytoj.

Metų pradžioje susidūriau su blogerių diskusijomis apie tai, kuria kalba geriau būtų dėstyti programavimą mokykloje.

pro-Ruby: http://emptydot.com/vidmantas/2007-12-29/ruby-kalba-mokykloms/ pro-Python: http://blog.sandbox.lt/lt/Paskalis+mokyklose pro-Pascal: http://www.arvydas.net/bevertes-programavimo-kalbos

Nuomonės, dideliam mano nustebimui, smarkiai varijavo. Ne, aš nesu naivuolis. Nemanau, kad tokiame “religiškame” klausime kaip vaikų mokymas gali būti lengvai randama bendra nuomonė. Tačiau kad taip diverguotų atskirais, lengvai išaiškinamais klausimais…

Kadangi mane ši tema gana smarkiai domina (pradedančiųjų programuoti mokymas: ar tai būtų savamoksliai, ar moksleiviai, ar pirmakursiai), pabandysiu čia surašyti kelias mintis, kurias sukėlė fleimai bloguose.

Kalbant apie mokymą (be sangrąžinės dalelytės!), pirmiausia reikia apsibrėžti tikslus ir priemones, be šito nėra prasmės toliau kažką nagrinėti.

Taigi, šio serialo kontekste, mokydami spuoguotus nebrendylas programuoti, mes siekiame:

1. Parodyti žmogui, kaip, kokiu būdu yra valdomas kompiuteris. Ne kaip juo naudojamasi, o kaip jis valdomas.
2. Išvengti situacijos, kai vidurinį išsilavinimą turintis žmogus nenutuokia kas yra programavimas ir išgirdęs, kad jo naujasis pažįstamas yra programuotojas, džiugiai klausia “o! Pas mane Vindousai flash rakto neskaito! Tu profas, sakyk ką daryt?”.

To mes norime pasiekti, sutilpdami į tokius apribojimus:

1. Neišgąsdinti žmogaus. Išvengti situacijos “dalykas šūdas, mokytojas gaidys, man gyvenime to neprireiks, švietimo sistema čiulpia”.
2. Sudominti žmogų.
3. Neapkrauti žmogaus tuo, ko jam (bent jau kol kas) nereikia.

Žmonės minėjo tokias kalbas: Pascal, C, C++, C#, Java, Python, Ruby, PHP, BASIC, ECMA Script, Perl, Lua.

Kad nebūtų per maža, galėčiau pridurti dar kandidačių: Common Lisp, Haskell, Logo, OCaml, Ada.

Bet čia nebus propaguojama nė viena iš jų.

Trumpa serialo apžvalga. Žmonės iškėlė ir apifleimino va šiiitiek temų ir aspektų:

• Kompiliatorius ar interpretatorius?
• Kas svarbiau -- IDE, ar interpretatorius?
• Ar IDE išvis reikalingas?
• Ar svarbu turėti debugerį? Kokiomis aplinkybėmis?
• Kalbos lituanizavimas.
• Dinaminis ar statinis tipizavimas?
• (Ne)Prisirišimas prie OS.
• Ar apskritai yra skirtumas nuo kurios kalbos pradėti?
• Gal verta mokykloje naudoti sudėtingesnę kalbą, "kad atsisijotų idiotai"?

Apie visa tai turiu ką pasakyti. Na, ar bent jau žibalo į ugnį įlieti :-). Bet pirmoje serijoje nuo savęs pridedu dar porą aspektų:

• Kalbos komerciškumas.
• Kalbos sukūrimo tikslas, tikslinė niša.

Čia pat juos ir aptarkim.

Kalbos komerciškumas.

Visų pirma, čia aš nekalbu apie kalbos autorystę. Tegul tą Java sukūrė viena korporacija, o C# kita. Tiek jau to. Tarkim, kad jos nuo to komerciškomis nepasidaro.

Kalbėdamas apie komerčiškumą, aš turiu omenyje kalbos realizacijos komerciškumą. Arba, kalbant paprasčiau, galutinio produkto, leidžiančio dirbti ta kalba, kainą. Jos nebuvimą. Galimybę bet kuriam moksleiviui bet kur ir bet kada ja naudotis. Mokykloje, namie, pas draugą, pas tėvą darbe, bet kur!

Neturint nemokamos kalbos realizacijos, pažeidžiami iškart du apribojimai:

1. Slopinamas žmogaus susidomėjimas (per pamoką susidomėjo, grįžo namo, paaiškėjo, kad negalima, nusispjovė, žiūri teliką).
2. Žmogus apkraunamas. Net jeigu pinigai kaipo tokie ir būtų visiškai eliminuoti iš šitos istorijos (pvz., bet kur ir bet kada moksleivis galėtų pasiekti realizaciją, pasinaudodamas savo moksleivio pažymėjimo numeriu), tai nekeistų fakto, kad žmogus apkraunamas absoliučiai bereikalingu šlamštu.

Žinoma, šiais laikais praktiškai visos kalbos turi nemokamas realizacijas. Tačiau nereikia pamiršti, kad kai kurios nemokamos realizacijos nusileidžia komerciniams ekvivalentams. Kai kurios kokybe, kai kurios naudojimosi patogumu, kai kurios paplitimu (pvz., gera realizacija Unix sistemoms, bet prasta Windows).

Kalba privalo turėti gerą nemokamą realizaciją.

Kalbos sukūrimo tikslas, tikslinė niša.

Viena iš kalbos meta-savybių yra jos sukūrimo tikslas; uždavinių ir problemų klasės, kurioms spręsti ji yra skirta. Tai neprivalo ką nors reikšti, bet praktika rodo, kad neretai reiškia.

Moksliniams tyrimams sukurta kalba dažnai turi tam tikrų savybių, kurios geriausiai perprantamos jau išklausius aukštosios matematikos bei transliavimo metodų kursus (pvz., Haskell, Lisp). Tad tokių kalbų dėstymas mokykloje būtų mažų mažiausiai keistas.

Atitinkamai keista būtų dėstyti mokykloje kalbas, kurios yra skirtos industrijai. C, C++, Java, C# ir daugelis kitų kalbų turi savybių, kurių privalumai išryškėja vien tik industrinėje aplinkoje. Tuo tarpu savybės giliai “įsiūtos” į kalbą ir išmokti ja programuoti neperkandus į industriją orientuotų savybių, sunku; arba, mažų mažiausiai, pažeidžia trečiąjį apribojimą: apkrauna nereikalingais dalykais.

Tad svarstant mokyklai skirtas kalbas, pravartu prieš viską pažiūrėti į kalbos tikslinę nišą. Toks pažiūrėjimas gali padėti greičiau identifikuoti tam tikras “no-no” savybes. Ir tik tokių neradus, verta žiūrėti toliau.

Tęsinys rytoj.