\ 

Nederlog

 

28 December 2009

 

Over mij, ME en programmeren

 

Gisteren was er geen Nederlog, want ik ben verre van fit en ook geheel niet vrolijk.

Later meer daarover, en nu wat over programmeren, want mijn meest gebruikelijke recept tegen pijn en depressie is dat ik probeer na te denken over wiskundige onderwerpen, die in mijn geval gewoonlijk neerkomen op logica of programmeren, en wel omdat me dit werkelijk interesseert, ik het leuk vind, en het de bijzondere deugd heeft geen onzin te zijn en antwoorden op problemen in deze onderwerpen rationeel beargumenteerbaar c.q. programmeerbaar zijn.

Hier volgen dus wat opmerkingen over drie programmeer-omgevingen waar ik het een en ander van weet en de afgelopen week mee bezig ben geweest, voor zover ik niet moe en met pijn in bed lag of wat aan de site deed.

1. Over Forth
2. Over Masm32
3. Over Squeak
4. Over programmeren

Mocht u niets met programmeren hebben dan is wat volgt waarschijnlijk niets voor u al heb ik wel twee algemene opmerkingen voor u de rest overslaat:

  • Als u van schaken, dammen, bridge of het oplossen van sudoku's houdt, dan is programmeren heel wel mogelijk leuker, interessanter en nuttiger, omdat het (ook) redeneer-problemen betreft, met het grote voordeel dat de computer de oplossingen - inclusief de foute - genereert via uw programma-code, dat ook een onmiddellijke feedback vormt.

  • Er is veel te leren van programmeren, zoals geduld, begrip voor uw eigen beperkingen, abstract redeneren, formeel redeneren (dus: met formules, in een speciale notatie c.q. programmeer-taal) met als bijkomend voordeel, dat u (als het lukt) uw eigen werkende en zelfgemaakte programma's heeft die dingen doen die u anders niet, of niet zo goed, of niet met uw eigen programma-code kunt doen met uw computer.

1. Over Forth

Ik schreef een week geleden in Gently going forth-ward (Dutch) over de programmeer-taal en -omgeving Forth omdat deze interessant is (voor wie geinteresseerd is in programmeertalen c.q. hoe een mens een machine zo ver kan krijgen welbepaalde dingen te doen en laten) en nogal afwijkt van alle andere programmeer-omgevingen, en ook omdat ik er een behoorlijk goed verzorgde tamelijk recente implementatie van gevonden had Win32Forth.

Nu weet ik redelijk wat meer en heb bevonden dat Forth niet echt voor mij is, al zijn de ideen waarop het gebaseerd is interessant en zinnig, en waarschijnlijk bijzonder praktisch en geschikt voor kleine computers met weinig geheugen c.q. wat tegenwoordig wel als "embedded systems" omschreven wordt: programmeerbare processoren in chips in dingen als mobieltjes, wasmachines e.d.

Hiervoor is het oorspronkelijk ook ontwikkeld of iets beter gezegd: De eerste Forths waren voor computers met weinig geheugen en zonder OS (Operating System) of anders met een heel eenvoudig OS.

Forth is niet echt voor mij omdat ik niets bijzonders heb met "embedded systems" en omdat ik de taal weliswaar slim maar niet handig vind. Dit ligt vooral aan de zogeheten Reverse Polish Notation die ervoor gebruikt moet worden, waar ik verder niets over zal zeggen behalve dat wie wat van formele logica weet waarschijnlijk wel eens de zogeheten Polish Notation (*) voor propositie en/of predicaat-logica gezien heeft, die de deugd heeft veel korter te zijn dan de standaard-notatie, en ook zonder haakjes kan, maar de ondeugd heeft aanzienlijk moeilijker te lezen formules op te leveren. Het is net zo met Forth.

Nu kun je daaraan wennen, maar dat kost tijd en moeite, en dan nog denk ikzelf dat Reverse Polish Notation voor een programmeertaal op een machine met behoorlijk wat vrij beschikbaar geheugen geen goede keus is, eigenlijk net als met Polish Notation in de logica: Het werkt; het kan; het is aanzienlijk korter dan andere notaties; het biedt voordelen - maar het blijft moeilijk lezen voor mensen onder andere omdat het zo compact is (en veel dat expliciet zou kunnen zijn impliciet is dus door de lezer erbij bedacht moet worden voor goed begrip) en omdat de volgordes van termen anders zijn dan gebruikelijke. (Zie (*))

Theoretisch interessant vond ik het wel, maar afgezien van de moeilijkheid van het leren lezen van Forth programmeer-formules bleken mij twee praktische moeilijkheden met de Win32Forth die ik gebruik.

Forth is een geinterpreteerde taal, dat prettig is voor debuggen, maar niet vanzelfsprekend gecompileerd kan worden tot zelfstandige executable (zal ik maar zeggen). Wel, Win32Forth kan gecompileerd worden - maar heeft de eigenaardigheid dat het grote executables levert, kennelijk omdat een deel ervan bestaat uit een gecompileerde Forth-omgeving.

Dit is echter iets dat mij niet aanstaat, want ik wil eigenlijk zo weinig mogelijk (gecompileerde of geinterpreteerde) code om een gegeven doel te realiseren, en ook omdat het me het zicht op wat de computer feitelijk doet ontneemt, omdat deze het gaat doen via die gecompileerde Forth-omgeving.

Dat is de eerste praktische moeilijkheid - en merk op dat ikzelf, die ondertussen enigszins gewend ben aan assembler, waarover hieronder wat meer, complete gecompileerde tekst-editors in 6 (of 11 of 14) Kb heb in assembly (**), terwijl een gecompileerde Forth-texteditor begint in de orde van 250 Kb.

De tweede moeilijkheid is dat Win32Forth wel kan werken met de Windows API - dus wel in staat is vensters, pop-up menus, knoppen etc. via Windows te leveren - maar dat maar gedeeltelijk kan, en dat alweer in de Forth-notatie, dus met alle argumenten anders geplaatst dan je zou verwachten, en het  bovendien kennelijk alleen doet in Win95-API-formaat.

Een en ander was voor mij voldoende niet serieus verder te gaan met Forth, ook al omdat het niet goed geeft wat ik wil: Direct zicht op wat de machine die ik programmeer feitelijk doet.

Dat leidt me tot het volgende onderwerp in dit programmeerverband.

2. Over Masm32

Ik heb eerder aangegeven dat ik de assembler RosAsm opgegeven heb en mensen die in assembly geinteresseerd zijn nu Masm32 aanraad.

Wel, n van de andere dingen die ik bevond terwijl ik met Win32Forth aan het worstelen was is dat ik een stuk beter uit de voeten kan met Masm32 dan met RosAsm en met Forth, en dat Masm32 heel kleine executables compileert, in assembly die ik heel wel leesbaar vind.

En Masm32 heeft de grote deugd wel direct op de machine te zitten, zogezegd, zodat ik feitelijk de afgelopen week ook redelijk wat aan Masm32 deed, ook al omdat ik had bevonden dat ik Forth kon begrijpen, in beginsel, omdat ik assembly begrijp, in beginsel.

Kortom... Masm32 bevalt me steeds beter, en als u er meer van wilt weten zie mijn verhandelingetje over Assembly, waar u ook een samemvatting treft van wat u nodig heeft voor een goede programmeeromgevibg voor Masm32.

Overigens in programmeer-verband: Assembly is niet makkelijk en als u meer geinteresseerd bent in programmeerbare resultaten en heldere programma-code dan in fundamenteel begrip dan zijn programmeer-talen c.q. -omgevingen als Delphi of JavaScript veel beter en makkelijker en ook veel sneller te leren.

3. Over Squeak

En van de andere programmeer-omgevingen waar ik veel van weet, die bovendien zeer verschilt van Assembly of Forth, is Squeak dat een Smalltalk is.

Zoals ik in november in Reviewing my positions on programming schreef raad ik Smalltalk niet meer aan voor mensen die Smalltalk niet kennen, vooral omdat het flink wat moeite kost om te leren, en dan vrijwel alleen bestaat in kennis en vaardigheden die buiten Smalltalk niet toepasbaar zijn, maar ondertussen ken ik de taal en de omgeving en programmeer er makkelijk in.

Ik programmeer dus ook nog wel eens in Delphi en JavaScript, maar als ik snel resultaat wil en het me vooral gaat om de uitkomsten dan gebruik ikzelf nog steeds vaak Squeak.

En daar is enig heugelijk nieuws over, omdat er de afgelopen maanden redelijk veel mee gedaan en aan verbeterd is door de ontwikkelaars, met als resultaat o.a. een verbeterde omgeving, die een stuk beter oogt en dingen kan die tot voor kort niet konden.

Voor meer zie mijn verhandelingetje over Smalltalk en de website van Squeak die trouwens Squeak laat zien.

4. Over programmeren

Afsluitend twee opmerkingen over programmeren en wel een tamelijk specifieke en een algemene, ook met een onderlinge samenhang.

De algemene opmerking is dat er nog steeds zeer veel te leren is over, van en met programmeren, en dat de programmeertalen, die het mogelijk maken voor mensen om machines taken te laten verrichten, tot nu toe verre van perfect zijn en opgetrokken zijn uit compromissen, concessies en ad hoc constructies, en bovendien gewoonlijk, zodra het een zogenaamde hogere programmeertaal betreft, het feitelijk zicht op het doen en laten van de computer bemoeilijken.

Een en ander heeft trouwens een goede reden: De bestaande programmeer-talen zijn vrijwel allemaal geschreven voor computers met weinig geheugen en een geringe snelheid en moesten keuzes maken uit allerlei beperkingen om het ueberhaupt mogelijk te maken voor een mens om met hulp van een geschreven taal een machine naar z'n hand te zetten.

De specifieke opmerking is dat ikzelf redelijk uit de voeten kan (of kon) met een handvol programmeer-talen + omgevingen (de twee hangen gewoonlijk nogal nauw samen, bovendien) en daarin tot oplossingen kan komen van problemen die ik in zo'n taal kan aanpakken, maar ook dat dit bijna altijd blijkt te bestaan in de oplossing van het probleem in die taal in die omgeving, gewoonlijk met weinig begrip voor hoe de onderliggende machine het feitelijk doet.

In feite is dat ook waarom een HLL (High Level Language) bestaat: Je hoeft niet meer te proberen de geheugenchips en processor van je computer tot iets te brengen - je probeert in feite dat iets te reduceren tot de termen en mogelijkheden van een HLL, zoals Delphi of C++, en de ontwerpers daarvan hebben ervoor gezorgd dat de machine doet wat moet volgens de opdrachten in zo'n taal als het programma in die taal gecompileerd wordt.

Het gaat mij echter om werkelijk begrip van de machine, en van het doen en laten en de beperkingen en mogelijkheden ervan, en ook van programmeren in het algemeen, en voor dat doel blijkt assembly tot nu toe het meest geschikt, omdat het het minste verbergt of reduceert tot voorgebakken abstracties, en bovendien in beginsel het meeste kan en wat het kan bovendien het snelste kan. (Waar tegenover staat dat de code vaak langer en ingewikkelder is dan in een HLL, juist omdat er geen voorgebakken schematische oplossingen zijn.)

Ik heb het meest geleerd van wat ik wilde weten over programmeren van assembly en ik zou iedereen die serieus geinteresseerd is in programmeren of de vraag hoe computers werken iets over assembly te leren: Alle andere programmeertalen zijn gebaseerd op abstracties van hun ontwerpers die beogen bepaalde dingen makkelijker, sneller en korter te programmeren dan in assembly, door het ontwerpen van voorgebakken grammaticale structuren die ver kunnen staan van wat de computer - processor + geheugen - feitelijk moet doen.

Voor meer, zie mijn Why learn assembler? uit 2007 - met alleen dit verschil dat ik tegenwoordig Masm32 aanraad voor assembly.

Maar zoals gezegd: Als u alleen in geprogrammeerde resultaten geinteresseerd bent, en niet in het waarom ervan, dan zijn bijvoorbeeld Delphi of JavaScript veel makkelijker te leren.


P.S. Dit was dus - weer eens - een stukje alleen voor zeldzame lezers. Later mogelijk meer, maar voor het moment is het probleem dat ik fit noch vrolijk ben.

(*) Laat ik dit althans verduidelijken. In standaard propositie logica wordt een formule "Als p dan q" gewoonlijk aangegeven met iets als "(p --> q)" waar de pijl "-->" voor het "als... dan---" staat en geen pijl hoeft te zijn, maar in standaard notatie tussen de proposities staat die het verbindt. Dit maakt haakjes nodig bij ingewikkelder formules, bijvoorbeeld om "(p --> (q --> r))" en "((p --> q) --> r)" uit elkaar te kunnen houden, maar is redelijk makkelijk leesbaar.

De Poolse notatie hiervoor bestaat erin de logische termen voor de formules te schrijven die ze verbinden, dat het mogelijk maakt haakjes te vermijden. Het gebruikelijke teken voor "als... dan---" in Poolse Notatie (PN) is de letter "C" zodat de laatste twee formules als volgt geschreven worden in PN: "CpCqr" en "CCpqr". Hieruit kunt u zien dan het korter is, maar dat u o.a. moet weten dat "C" twee argumenten heeft om PN te kunnen lezen, en ook dat de volgorde niet meer noodzakelijk van links naar rechts is (want "CCpqr" werkt dus uit als "((Cpq)Cr)" i.e. "((p --> q) --> r)".

Wel, de PN begint dus altijd met de logische term of functor, gevolgd door de argumenten, en de Reverse PN begint met de argumenten, gevolgd door de functor: "rqCpC" en "rqpCC".

Kortom... makkelijk is anders.

(**) Ja, het is verbazend - maar een deel van de reden is dat dit via de Windows API komt. En het is wellicht aardig om te weten dat een gewone ASCII-teksteditor, zoals Kladblok/Notepad dat met Windows komt, in Windows slechts 6, 11 of 14 Kb hoeft te tellen, inclusief code voor het venster en de popup-menus. (Voor relatieve kenners: ik heb het over implementaties van richedit.)

Maarten Maartensz

        home - index - top - mail