mkristof blogja

Ezen az oldalon olvashatóak Alan Turing 14 és 19 éves kora közötti bizonyítványai.

Érdekes megfigyelni hogyan fejlődött 5 év alatt, ahogy azt is, hogy mennyi nyelvet tanultak (latin, görög, francia, német). Ha Turingnak jó volt, jó lesz majd a kölöknek is.

Ha valaki elkezdni olvasni a következő dokumentumot (azért, hogy megismerkedjen az excel object modellel és az agyrohasztó VBA-val) szembejöhet a következő feladat:

Look at the following fictitious Visual Basic code and answer the questions that follow. Assume that at the start, the Papers collection is empty; its Count property is equal to zero.

Dim numberOfPapers
Set paper1 = MyDesk.Papers.Add("The Foofle Report")
Set paper2 = MyDesk.Papers.Add("The Mooble Report")
numberOfPapers= MyDesk.Papers.Count
Set paper3 = MyDesk.Papers.Add("The Garble Report")
Set paper4 = MyDesk.Papers.Item(currentNumber)
Set paper5 = MyDesk.Papers.Item(1)
Set paper6 = MyDesk.Papers.Item(currentNumber + 1)

"But programming languages and programs are more restricted - any single program uses a very limited number of models. This can create a tendency to conflate the modeling approach being used with the thing being modeled, but that's a map/territory mixup, which shouldn't be allowed to affect our reasoning when we're comparing modeling approaches."

és

"[...] but no language "paradigm" advocate should be surprised should the complexities of reality start creeping into our programs and shaking the foundations of our simplifying abstractions."

(Ebből az érdekes vitából: http://lambda-the-ultimate.org/node/4235)

Sűrűsödik a dolog, gyorsan megoldok még két feladatot, amíg lendületben vagyok
és nem győz le megint Oblomov.
A könyv élvezetes, olvasmányos, de nagyon absztrakt. A címben jelzett feladatokig
bevezetik a black-box abstraction-t, a lokális nevek fogalmát, adnak egy gyors
definíciót a szabad és kötött változókra (egy kis csipkelődéssel a nagy logikusok felé).
Ezen felül elmondják, hogy mik azok az internal definition-ök és hogy miért jó
a block structure, és hogy miképpen működik a lexical scoping.

De mindez még csak az 1.1.8-ban, öt oldalon, ami után egyből jön is a létfontosságú
rekurzív/iteratív -- process/procedure megkülönböztetés-kombináció. Ez a rész (1.2.1) igen
világosan összefoglalja és illusztrálja a rekurzió itt használt két fogalmát. Egy procedure
rekurzív akkor, ha saját magát közvetlenül vagy közvetve meghívja, egy process rekurzív akkor
ha az őt megvalósító procedúra csak olyan gépen számítható ki amely rendelkezik
memóriával és egy process iteratív akkor, ha regisztergépen kiszámítható
(azaz vannak rögzített szabályaink és állapotváltozóink és nincs szükségünk deferred operatorok
nyilvántartására). Tesznek itt néhány kitérőt az implementáció kérdéséről is, de azzal majd
lényegében az ötödik részben fognak foglalkozni, szóval addig félreteszem. (Arról nem is
beszélve, hogy talán majd többet megértek belőle.)

Az 1.1.7-es részben a négyzetgyök kiszámításának newtoni módszerét mutatják be.
Nagyon tanulságos a leírásuk a matematikai és a számítógépes függvények különbségéről,
ami már eleve a matematika és a computer science közti különbségekre mutat rá. Röviden
és tömören: a matematika azzal foglalkozik, hogy "mi" az adott dolog a computer science
pedig azzal, hogy "hogyan" kell kiszámolni.

A feladatoknál megfigyelhető az a SICP-pel kapcsolatban emlegetett trend, hogy nem
a semmiből való programírásra helyezik a hangsúlyt, hanem meglévő eredmények megértésére,
korrigálására és továbbfejlesztésére (ez főleg az 1.7-es és az 1.8-as feladatokra igaz).

Régóta neki akartam kezdeni annak a projektnek, amit Eli Bendersky
már megcsinált. Szokták mondani, hogy a szentek létráin csak egyszer lehet
felmenni. Nos szerintem a SICP véigolvasása nem ilyen. Legalább egy embert ismerek,
aki azt állítja, hogy többedmagával végigolvasta és megcsinálta a feladatok többségét. A
felkészültségéből és az éles, analitikus hozzáállásából arra
következtettem, hogy még ha nem is a SICP végigolvasásától lett ilyen,
ártani valószínűleg nem árthat. Szóval most belevágok.

Innen:

"If you want a great deal of hot air, some papers nobody will read, and software that's theoretically interesting but impractical, produced at moderate expense before being abandoned, academia is the place to be.

On the other hand, if you want a poorly designed piece of junk that solves a trivial problem badly (if it works at all), produced very slowly at breathtakingly great expense, go for industry.

As a third option, if you need software that solves a difficult problem well, but with a bafflingly arcane interface and no documentation, produced at minimal expense, try open-source software.