Functioneel programmeren, waarom ?

[Verwijderd]

Samenvatting: /me doet zijn uiterste best om het nut en de elegantie van functioneel programmeren in te zien, maar het wil hem maar niet lukken. Wie helpt?


Een paar maanden geleden hoorde ik voor het eerst iets over functioneel programmeren. Geïntrigeerd door de mystiek van een compleet andere manier van kijken naar programma's, algoritmes, en hogere abstracties ben ik vervolgens allerlei functioneel-programmeren-papers en -advocacy gaan lezen.

Tot mijn grote teleurstelling lukte het me echter geheel niet om het nut of de elegantie van functioneel programmeren in te zien; het lukte me niet om in de genoemde argumenten iets te zien waarvan ik dacht: "ja, met die feature of op die manier kan ik mooiere (elegantere) programma's schrijven", en gegeven voorbeelden spraken me absoluut niet aan (het leek alsof recursie voor het minste of geringste geheel werd verkracht, en alsof alles ERG omslachtig werd geprogrammeerd).

Ondanks mijn negatieve eerste indruk ben ik toch wat met Haskell gaan spelen. Functioneel programmeren bleek me echter ook in de praktijk zeker niet zonder problemen te vergaan, het lukte me simpelweg niet om mijn gedachtengang zover te krijgen dat 'ie Haskell code genereerde . Het leek heel.. onnatuurlijk. Ik besef me dat ik flink imperatief ben geindoctrineerd, maar ondanks dat lukt het me niet om enigszins in te zien waarom het functionele perspectief beter beter zou zijn dan het imperatieve.

Waarvoor is functioneel programmeren nou eigenlijk geschikt? In andere P&W topics zie ik mbravenboer vaak langskomen met z'n parsers en compilers, is functioneel programmeren misschien eigenlijk alleen geschikt voor het omgaan met sommetjes en grammatica? Kan het zijn dat functioneel programmeren gewoon niet echt geschikt is om ingewikkelde systemen en applicaties in te schrijven?

Wat overigens niet meehelpt is dat ik vrijwel nooit hoor dat functionele programmeertalen ergens serieus worden gebruikt. Het schijnt zo te zijn dat universiteiten en professors zwaar op functioneel programmeren geilen (), maar daar hecht ik bij een gebrek aan praktijkvoorbeelden eigenlijk niet veel waarde aan.

Dus, voor de functioneel programmeurs onder ons: wat doe je ermee? Had je in het begin ook dergelijke problemen met het waarderen van het paradigma? (En zo ja: was er een bepaald kwartje dat moest vallen?) Kloppen mijn vermoedens over de zeer beperkte toepasbaarheid van functioneel programmeren? (En zo ja: hoe ga je daarmee om?) Kortom: alle ervaringen zijn welkom.

[Varienaja]

Bij functioneel programmeren beschrijf je niet zozeer WELKE STAPPEN je moet doen om iets aan te pakken, maar eerder HOE je 't moet doen.

Functionele quicksort (heb je vast al 100x gezien):

Sorteer (array) = Sorteer Kleiner ++ Midden ++ Sorteer Groter
Midden = Eerste_Element_Uit(array)
Kleiner = AllesWatKleinerIsDanMiddenUit(array)
Groter = AllesWatGroterIsDanMiddenUit(array)

Het is toch in één oogopslag duidelijk dat dit correct is? Dat is juist het mooie van een functioneel ontwerp.

Als ik een brei C-code neerzet, wat hetzelfde doet, dan kan je nooit zomaar na 1x overlezen zeggen dat je zeker weet dat 't goed is.

Het is ook heel handig om een functioneel ontwerp te maken van een algoritme. Als je dat foutloos (en dat is vrij makkelijk, zoals je in het voorbeeld zag) hebt opgeschreven kan je 't vrij gemakkelijk omzetten naar een imperatieve taal. Als je meteen imperatief was begonnen, dan kan het zo zijn dat je iets totaal verkeerd implementeert. Daarbij kunnen managers/klanten vaak ook nog wel functionele code lezen. En het is toch wel makkelijk als zij in een vroeg stadium ontdekken dat er iets mis is in je ontwerp.

[koffercomputer]

Als ik dat voorbeeldje zo zie, dan lijkt functioneel programmeren wel op wat ik ooit als vak heb gehad, alleen was dat Logisch Programmeren. Toen hebben we een hoop in Prolog gedaan. Ik kreeg hoofdpijn van recursie.

[Soultaker]

Op dinsdag 25 juni 2002 23:45 schreef Sneechy het volgende:
Waarvoor is functioneel programmeren nou eigenlijk geschikt? In andere P&W topics zie ik mbravenboer vaak langskomen met z'n parsers en compilers, is functioneel programmeren misschien eigenlijk alleen geschikt voor het omgaan met sommetjes en grammatica? Kan het zijn dat functioneel programmeren gewoon niet echt geschikt is om ingewikkelde systemen en applicaties in te schrijven?

Functionele programmeertalen zijn over het algemeen nogal slecht in interactie met de imperatieve wereld. C, C++, assembly, Java, etcetera kunnen allemaal redelijk makkelijk van elkaar's interfaces gebruik maken. Functionele programmeertalen hebben dat niet, dus is het vaak moeilijk om imperatieve interfaces op een zinnige manier om te zetten naar een functionele omgeving.

Voor dingen als GUI's enzo lukt dat echter wel, maar het feit blijft dat het makkelijker is om dingen te doen, die uitsluitend binnen die functionele programmeertaal vallen. Parsers zijn daar het ideale voorbeeld van; ingewikkelde dingen die efficient en elegant kunnen worden geimplementeert. Dat laatste kun je absoluut niet van door yacc-gegenereerde C-code zeggen.

Ik denk inderdaad wel dat een functionele programmeertaal vooral geschikt is voor algoritmen ('sommetjes'). Een groot systeem zou ik liever op een OO-wijze ontwikkelen.

Wat overigens niet meehelpt is dat ik vrijwel nooit hoor dat functionele programmeertalen ergens serieus worden gebruikt. Het schijnt zo te zijn dat universiteiten en professors zwaar op functioneel programmeren geilen (), maar daar hecht ik bij een gebrek aan praktijkvoorbeelden eigenlijk niet veel waarde aan.

De meest geslaagde toepassing vind ik zelf tot nu toe de spelletjes van Mike Wiering (ontwikkelaar van Clean), hoewel er ook serieuzere toepassingen zijn:

http://home.wxs.nl/~mike.wiering/

http://www.hilt.nl/

Een mooie eigenschap van functioneel programmeren is natuurlijk dat alle functies in principe vrij van side effects zijn. Hierdoor kan een functioneel programma in principe probleemloos en automatisch over meerdere threads/processoren verdeeld worden of zelfs over meerdere fysieke systemen worden gedistribueerd.

Voor parallelle berekeningen (denk aan supercomputers e.d.) zijn functionele programmeertalen dus ideaal, aangezien de compiler/interpreter altijd alle onderdelen kan verdelen. De volgorde van berekeningen maakt immers niets uit voor de resultaten.

Op dit moment is het zo, dat een besturingssysteem verschillende processen zo combineert, dat een proces dat bezig is met wachten op een respons van de harde schijf de ruimte laat aan een ander proces om te runnen. Als er slechts 1 relevant proces is, wordt er echter tijd verspilt. Met een functionele programmeertaal hoeft dit ook niet, voor zover het resultaat van de harde schijf operaties niet relevant is voor een ander deel van de uitvoer.

Als je van dit soort overwegingen niet geil meer wordt, waarvan dan wel!

Dus, voor de functioneel programmeurs onder ons: wat doe je ermee? Had je in het begin ook dergelijke problemen met het waarderen van het paradigma? (En zo ja: was er een bepaald kwartje dat moest vallen?) Kloppen mijn vermoedens over de zeer beperkte toepasbaarheid van functioneel programmeren? (En zo ja: hoe ga je daarmee om?) Kortom: alle ervaringen zijn welkom.

Ik vond leren functioneel programmeren een van de moeilijkste praktijkdingen die ik ooit gedaan heb. Dat komt natuurlijk omdat je, om functioneel te programmeren, ook een heleboel theoretische kennis van functies nodig hebt (samenstelling van functies, domein en bereik, etcetera). Er was niet echt een kwartje-moment voor mij. Ik heb het idee dat ik gewoon stukje bij beetje beter ging begrijpen hoe de functionele wereld in elkaar zat. Ik ben nu zover dat als ik snel een algoritme in elkaar moet flansen, ik dat vaak in een functionele programmeertaal doe (zeker als er recursie bij komt kijken).

Wat betreft het nut: iets leren is natuurlijk altijd nuttig (cliché, ik weet 't), maar een goede baan zul je er waarschijnlijk niet mee vinden. Dat is een beetje hetzelfde verhaal als 'alternatieve' programmeertalen als Prolog. Het is voor je eigen ontwikkeling best zinnig om eens op andere manieren tegen het oplossen van problemen aan te kijken.

Als je gewoon een taal zoekt waar je je brood mee kunt verdienen, moet je natuurlijk gewoon Delphi, C, C++ of Java leren.

[Soultaker]

Op woensdag 26 juni 2002 00:00 schreef koffercomputer het volgende:
Als ik dat voorbeeldje zo zie, dan lijkt functioneel programmeren wel op wat ik ooit als vak heb gehad, alleen was dat Logisch Programmeren. Toen hebben we een hoop in Prolog gedaan. Ik kreeg hoofdpijn van recursie.

Het lijkt inderdaad wel enigszins op elkaar, in de zin dat er niet zoiets is als 'staat', 'tijd' of 'volgorde'. Het verschil tussen een functionele programmeertaal en een declaratieve programmeertaal als Prolog, is dat je in een functionele programmeertaal in principe top-down te werk gaat, door een functie te definiëren, die gebruik maakt van een paar andere functies, etcetera (waarbij je oplossing dus steeds complexer wordt) en je in een declaratieve programmeertaal onderaan begint door eerst alle bekende feiten in te voeren en vervolgens te vragen wat daaruit is af te leiden met betrekking tot een zeker beginpunt.

Een declaratieve programmeertaal kan dan ook tegenstrijdigheden bevatten, of het kan onmogelijk zijn om gegeven de bekende feiten terug te werken naar een gewenst beginpunt. In een functionele programmeertaal werk je top down, dus kun je zo ver komen als je zelf hebt geprogrammeerd, maar zonder dat er (bijvoorbeeld) meerdere antwoorden zijn.

[mbravenboer]

Allereerst even een stukje over de vraag waarom functionele talen eigenlijk uberhaupt bestaan. Daar verschillen de meningen eigenlijk nogal over. Ik zal een aantal dingen behandelen die misschien kinderachtig of simpel overkomen, maar het is belangrijk om goed te beseffen wat nu eigenlijk wat is als je het hierover gaat hebben.

Voordat ik iets ga zeggen over imperatief <-> functioneel moet ik toch even iets zeggen over het begrip 'programmeertaal'. Een programmeertaal is in feite een taal waarin je een uit te voeren berekening kunt specificeren. Je geeft aan de 'generieke' rekenkern van de computer (de processor) een programma in deze programmeertaal (in termen van talenleer een 'zin' of een element van de taal). Deze generieke rekenkern voert dit programma uit. Je hoeft zo dus niet voor elke berekening een nieuw stukje hardware te maken, wat in het verleden wel gebeurde.

Als je begrepen hebt waarom ik hierover begin, is het tot je doorgedrongen dat je in een programma dus in feite in een bepaalde taal een probleem specificeert. Deze interessante bezigheid is dus 'programmeren'.

De imperatieve programmeerstijl is ontstaan door een taal te ontwerpen bij de architectuur van een computer: je hebt geheugen, geheugen kan veranderen, je hebt instructies die achter elkaar worden uitgevoerd enzovoorts. Omdat een computer op deze manier werkt wordt dus op dit moment ook wellicht ongeveer 99% van de problemen gespecificeerd in een imperatieve taal: de taal die eigenlijk 1 op 1 aansluit bij de architectuur van de computer.

Deze imperatieve denkwijze is dus ontstaan vanuit de computer: computer -> taal. Het is echter de vraag of dat voor ons nu wel een geschikte manier is onze berekening/programma te beschrijven. Waarom zouden we een probleem eigenlijk zo beschrijven zoals een computer dit ongeveer uitvoert? Het gaat ons immers helemaal niet om de uitvoering maar om het resultaat.

Via deze gedachte zijn er nieuwe paradigma's ontstaan. Deze paradigma's bieden ons andere manieren om ons probleem te beschrijven. De informatica is natuurlijk voor een groot deel ontstaan uit de wiskunde: de eerste informatici waren gewoon wiskundigen en uiteraard hebben nu eenmaal ook veel concepten in de informatica een directe link met wiskunde.

Functies spelen in de wiskunde al lange tijd een belangrijke rol: functies worden gebruikt om problemen te beschrijven, definities te geven, berekeningen te beschrijven enzovoorts. Functies zijn eigenlijk een heel simpel en compact formalisme. Het voordeel van deze eenvoud is dat je ook goed over functies kunt praten: het is makkelijk om te redeneren over problemen met functies en het is goed mogelijk om functies te gebruiken in wiskundige bewijzen: het vorm een stevige, logische en compacte basis.

De gedachte van de ontwerpers van functionele talen is zo bekeken eigenlijk helemaal niet zo origineel: in de wiskunde worden veel functies gebruikt om problemen en berekeningen te specificeren, waarom zouden we ook geen functies gebruiken als basis voor een programmeertaal om onze computerberekeningen te specificeren?

Helaas bleek deze logische gedachte niet gelijk te realiseren omdat het functionele programmeren nu eenmaal niet het uitvoeringsmodel van een computer is (dat is immers het imperatieve paradigma). Een programma specificatie in een functionele taal zal daarom vertaald moeten worden naar een imperatieve taal. Hierdoor heb je als functionele programmeur minder directe controle over de uitvoering. Het idee van de functionele taal is nu echter ook juist dat je dat ook helemaal niet wilt: het gaat je niet om de uitvoering maar om het resultaat. Helaas bleek dit toch wel een beetje te hoog gegrepen om menselijke controle over de uitvoering van een programma lange tijd noodzakelijk is geweest.

Het functionele paradigma zoekt dus een weg naar de belevingswereld van de programmeur. De centrale vraag is: kunnen we ons programma prettiger en compacter specificeren in een functionele taal? Dat is een erg lastige vraag, maar feit is in ieder geval dat functies bedacht zijn door de mens om problemen te specifieren. Imperatieve talen zijn in feite afgedwongen door de architectuur van een computer.

Boze tongen beweren echter dat functionele liefhebbers wanna-be wiskundingen zijn: de echte wiskundigen denken helemaal niet in termen van functies en functionele liefhebbers zijn meestal mensen met een informatica achtergrond. Deze tegenstanders beweren dat wiskundingen functies alleen gebruiken om hun berekeningen in een formeel model te gieten, maar niet denken en werken in termen van functies...

Sneechy: Tot mijn grote teleurstelling lukte het me echter geheel niet om het nut of de elegantie van functioneel programmeren in te zien; het lukte me niet om in de genoemde argumenten iets te zien waarvan ik dacht: "ja, met die feature of op die manier kan ik mooiere (elegantere) programma's schrijven"

Het staat in ieder geval vast dat je beter kunt redeneren over een functioneel programma dan over een imperatief programma. Dit zal je nu wellicht vreemd in de oren klinken omdat je er geen hout van snapt , maar het formalisme van functies is compact, consistent en duidelijk. Hierdoor is het goed mogelijk om bewijzen te gaan geven over de werking van een applicatie. Voor imperatieve talen is dit eigenlijk in serieuze lappen code vrijwel onmogelijk.

Of je er mooiere en elegantere programma's in kunt schrijven hangt eigenlijk af van je eigen beleveningswereld. Zoals ik net uitgebreid besproken heb proberen functionele talen aan te sluiten bij je belevingswereld: je probleem specificeren in termen van functies zou makkelijker moeten zijn dan bijvoorbeeld in een imperatieve taal. Of dat zo is, is lastig te beoordelen. In ieder geval is zo dat de belevingswereld van vrijwel elke programmeur bij voorbaad ingesteld wordt op imperatief denken. Juist dat maakt de overstap naar een functionele taal zo lastig...

Hum laat ik maar ff op submit drukken... Misschien zo meer .

[Verwijderd]

Op woensdag 26 juni 2002 00:25 schreef mbravenboer het volgende:
...

Het gaat ons immers helemaal niet om de uitvoering maar om het resultaat.

waarom zouden we ook geen functies gebruiken als basis voor een programmeertaal om onze computerberekeningen te specificeren?

Het woord 'computerberekeningen' in deze laatste zin geeft eigenlijk precies aan waarom ik vermoed dat functioneel programmeren zo beperkt is: dit uit wiskundige voortvloeiende paradigma lijkt er vanuit te gaan dat de computer eigenlijk alleen dienst doet als uitgebreide zakrekenmachine.

Computers zijn naar mijn mening geen zakrekenmachines meer. Computerprogramma's hebben niet meer als primair doel het berekenen van een som of het uitvoeren van algoritmes op datastructuren; tegenwoordig zijn het resource-managers. Ze hebben toegang tot allerlei resources (waaronder gebruikers), en voeren operaties uit op die resources (over het algemeen input/output). Ik heb het gevoel dat functioneel programmeren gewoon helemaal niet geschikt is voor dit 'modernere' model van waar computers tegenwoordig over het algemeen voor gebruikt worden.

Ik vind het om deze reden ook heel 'scheef' om te zien hoe mensen dit soort resource-management taken functioneel proberen uit te drukken (zoals ik in enkele voorbeelden zag).

Bedankt verder voor de rest van je (zoals altijd) verhelderende uitleg .

[mbravenboer]

Sneechy: Ondanks mijn negatieve eerste indruk ben ik toch wat met Haskell gaan spelen. Functioneel programmeren bleek me echter ook in de praktijk zeker niet zonder problemen te vergaan, het lukte me simpelweg niet om mijn gedachtengang zover te krijgen dat 'ie Haskell code genereerde . Het leek heel.. onnatuurlijk.

Kan ik me goed voorstellen.... Ik heb functioneel programmeren geleerd in het eerste jaar van mijn opleiding op de UU en heb toen dus een cursus van 4 punten gedaan met veel practica en een tentamen. Deze cursus heb ik gehaald, maar zonder de bekende 'aha erlebnis'. Ik kon het allemaal wel uitvoeren, maar echt de kern van de zaak doorhebben: nee. Pas bij later werk heb ik toch wel de schoonheid van het concept ingezien.

Ik zou eigenlijk willen voorstellen om als je niet weet hoe je een bepaald probleem moet uitdrukken in Haskell omdat gewoon hier een topic te plaatsen? . Uiteindelijk moet je het toch leren met behulp van voorbeelden en uitwerkingen en bovendien zou het wel een toevoeging zijn aan P&W .

Wat voor literatuur gebruik je eigenlijk?

Ik besef me dat ik flink imperatief ben geindoctrineerd, maar ondanks dat lukt het me niet om enigszins in te zien waarom het functionele perspectief beter beter zou zijn dan het imperatieve.

Waar het functionele perspectief in ieder geval beter in is, is qua uitdrukkingskracht. Functionele talen als Haskell en Clean worden toch vooral getypeerd (voel de grap ) door een enorm krachtig type-systeem. Dit wordt mogelijk gemaakt door het formalisme achter de talen: alles is een functie. Ik kan hier wel een heel verhaal op gaan hangen over hoe fantastisch dit allemaal werkt, maar dat heeft niet zoveel nut: je moet het zelf ervaren.

Waarvoor is functioneel programmeren nou eigenlijk geschikt?

Goede vraag.... Welke problemen kan je goed specificeren in een functionele taal? Ik denk dat het grootste probleem van functionele talen is dat ze anders zijn dan de computer. IO, wat in elke imperatieve taal vrij eenvoudig te realiseren is en vaak zelfs een beginnersvoorbeeld, is gewoon lastig te realiseren en interactie met bijvoorbeeld een userinterface helemaal. Ik kan een hele behandeling geven van alle problemen, maar het komt er toch eigenlijk op neer dat functionele talen vooral geschikt zijn voor 'invoer -> uitvoer' problemen. Dat is ook niet zo gek omdat 'invoer -> uitvoer' nu eenmaal een functie is .

Het schijnt zo te zijn dat universiteiten en professors zwaar op functioneel programmeren geilen (), maar daar hecht ik bij een gebrek aan praktijkvoorbeelden eigenlijk niet veel waarde aan.

Inderdaad is het zo dat functionele talen toch vooral gebruikt worden in de academische wereld.

Je kan bijvoorbeeld eens hier kijken:
http://www.haskell.org/practice.html

Dus, voor de functioneel programmeurs onder ons: wat doe je ermee?

Ik programmeer op dit moment eigenlijk zelden of nooit in Haskell, maar mijn kennis van Haskell heeft me wel enorm geholpen. Stratego, waar ik wel dagelijk mee werk, is eigenlijk voor een deel geinspireerd op functionele talen en de manier van denken komt toch wel erg over een. Stratego is niet getypeerd, wat wel jammer is, maar je kan er wel allerlei zaken in doen die mensen aantrekken in functionele talen.

Had je in het begin ook dergelijke problemen met het waarderen van het paradigma? (En zo ja: was er een bepaald kwartje dat moest vallen?)

Jazeker: dat heb ik in mijn vorige post al vertelt: ik heb een tijd geprogrammeerd in Haskell zonder de 'aha erlebnis'.

Kloppen mijn vermoedens over de zeer beperkte toepasbaarheid van functioneel programmeren?

Ik zie vooral een toekomst in interactie tussen het imperatieve en functionele paradigma. Tot nu toe was het streven er eigenlijk vooral op gericht om IO en GUI zaken prettig te verwerken in het functionele paradigma, maar daar geloof ik niet zo in: ik wil in een functionele taal programmeren wat daar goed in te specificeren valt en de rest gewoon in een ander paradigma. Tot nu toe moest je je dan eigenlijk beperken tot op zichzelf staande tools die je bijvoorbeeld kan gebruiken vanuit andere applicaties.

Je ziet echter toch steeds meer werk richting de samenwerking tussen beide paradigma's. Allereerst zijn er OO talen met nogal wanna-be functionele eigenschappen (Python bijvoorbeeld), maar er worden ook serieuze pogingen gedaan voor een volledige samensmelting van OO en FP. Verder is er nog .NET: omdat compilatie naar IL nu eenmaal een stuk eenvoudiger is dan copilatie naar native code zullen erg veel experimentele talen kiezen voor compilatie naar IL. Je kunt de functionele code dan gewoon gebruiken vanuit bijvoorbeeld C#.

Overigens heeft kennis van functioneel programmeren me toch ook wel geholpen bij mijn algemere begrip van het programmeren. Sowieso is het voor dit begrip eigenlijk vereist dat je meerdere paradigma's kent. Ik merk dat ik in een OO-design vaak toch functionele constructies gebruik, die ik vroeger niet toegepast zou hebben. Vaak zijn deze constructies enorm geslaagd, maar kenmerken ze zich uiteraard wel door een grote verbositeit (een functie schrijven in Java is nu eenmaal wat meer tikwerk dan in Haskell ).

[Soultaker]

Op woensdag 26 juni 2002 00:25 schreef mbravenboer het volgende:
Zoals ik net uitgebreid besproken heb proberen functionele talen aan te sluiten bij je belevingswereld: je probleem specificeren in termen van functies zou makkelijker moeten zijn dan bijvoorbeeld in een imperatieve taal. Of dat zo is, is lastig te beoordelen. In ieder geval is zo dat de belevingswereld van vrijwel elke programmeur bij voorbaad ingesteld wordt op imperatief denken. Juist dat maakt de overstap naar een functionele taal zo lastig...

Ik denk dat dat weinig te maken heeft met programmeren, maar met de manier waarop mensen werken in het algemeen. Mensen werken vaak eigenlijk net als computers; op een imperatieve manier. Als je iemand vraagt twee grote getallen te vermenigvuldingen, zal hij ze opschrijven en er een aantal stappen op uitvoeren tot hij het gewenste antwoord krijgt. De vraag welke cijfers uit de uitkomst beïnvloed zijn door welke cijfers in de opgave moet je dan niet stellen.

Andere voorbeelden zijn handleidingen, recepten, etcetera. Vrijwel altijd is de vorm gekozen van een stapsgewijze beschrijving van wat er gedaan moet worden om het resultaat te bereiken. Er zou ook gekozen kunnen zijn voor een omschrijving van de onderdelen van de operatie en het doel van de onderdelen, waardoor de lezer zelf zou kunnen beslissen in welke volgorde ze uitgevoerd worden, maar dit is ongebruikelijk.

Op zich is dit natuurlijk niet onlogisch. Als een mens in de echte wereld iets moet doen, moet 'ie uiteindelijk op de een of andere manier bedenken wat 'ie gaat eerst gaat doen en wat daarna. Zelfs als de taak in een 'hogere' vorm omschreven is, zal deze uiteindelijk omgezet worden naar imperatieve vorm.

Het is voor een programmeur dan ook (relatief) makkelijk om een algoritme om twee grote getallen te vermenigvuldigen in imperatieve (iteratieve) vorm uit te schrijven, omdat die alleen de stappen die 'ie zelf zou nemen, in de juiste vorm in hoeft te typen.

Wanneer je functioneel programmeert, ben je dus op een onconventionele manier bezig. Je specificeert hoe een bepaalde operatie samengesteld is en laat het afleiden van het daadwerkelijke stappenplan over aan de compiler.

Ik durf dan ook te beweren dat functioneel programmeren vooral gedaan wordt ten behoeve van de wiskundige eigenschappen die eraan te koppelen zijn (zoals mbravenboer wél aangaf) en niet omdat het een meer natuurlijke manier van redeneren zou zijn. Als dat zo was, zou het niet zo verdomde moeilijk zijn.

[mbravenboer]

Sneechy: Ik heb het gevoel dat functioneel programmeren gewoon helemaal niet geschikt is voor dit 'modernere' model van waar computers tegenwoordig over het algemeen voor gebruikt worden.

Mwah, daar kan ik het toch niet helemaal mee eens zijn. Uiteraard is het zo dat heel erg veel applicaties niet goed in een functioneel paradigma te gieten zijn, maar toch vind ik 'helemaal niet geschikt' toch wel erg ver gaan.

Persoonlijk zie ik op dit moment bijvoorbeeld een kans op de server-side: veel server-side applicaties doen in feite niets anders dan het transformeren van een stukje data in een database naar een view. Deze transformatie is heel complex beschreven in PHP of Java code, maar eigenlijk kan dit veel compacter: het is een functie van data naar output. Ik speel al een tijd lang met het idee om op dit gebied eens wat experimenten te doen met Stratego. Stratego is een transformatie-taal en een functie is natuurlijk in feite een transformatie (of beter gezegd: een transformatie is ene functie ). De transformatie van data naar een presentatie kan je heel goed uitdrukken in een transfomatie-taal (duh ). Dit zie je nu al terug in het gebruik van XSLT. XSLT is ontworpen door James Clark, die ook nogal gecharmeerd is van functionele talen. XSLT is eigenlijk een hele, maar dan ook hele, bijzondere taal. Het is namelijk de eerste min of meer declaratieve taal die doorgedrongen is tot 'het grote publiek'. XSLT wordt massaal ingezet om transformaties uit te voeren op data. Sommige mensen noemen XSLT een functionele taal, maar die hebben waarschijnlijk nog nooit in een echte functionele taal gewerkt: dat is onzin. XSLT is wel geinspireerd op functionele talen, maar dat zijn eigenlijk alle alternatieve paradigma's wel...

[mbravenboer]

Soultaker: Mensen werken vaak eigenlijk net als computers; op een imperatieve manier. Als je iemand vraagt twee grote getallen te vermenigvuldingen, zal hij ze opschrijven en er een aantal stappen op uitvoeren tot hij het gewenste antwoord krijgt.

Inderdaad, zie daarvoor ook het stukje over 'boze tongen'. Er zijn mensen die beweren dat het een misvatting is dat het succes van functies in de wiskunde gebaseerd is op het denken en werken van de wiskundigen in termen van functies. Ze formaliseren problemen in termen van functies, maar denken er niet in.

Hetgene wat mij het meeste aantrekt in functionele talen is het uitermate krachtige type-systeem, niet zozeer het denken in functies. Helaas is het echter zo dat de kracht van het type-systeem volgt uit het paradigma: functies . Kip... ei...

[Verwijderd]

Ik kan me eigenlijk best goed vinden in Soultaker's betoog dat imperatief programmeren eigenlijk van nature dichter ligt bij de belevingswereld van programmeurs.

Verder is het voor mij in ieder geval een geruststelling dat jullie ook grote moeite hebben gehad met het leren begrijpen en waarderen van de vermeende schoonheid van functioneel programmeren; het ligt dus niet aan mij .

Tot slot lijkt het dus 't verstandigst om het beste van de twee paradigma's te proberen te combineren: imperatief/OO voor het resource-management, en af en toe een beetje FP voor berekeningen, algoritmen, en eventueel data-transformaties.

[Soultaker]

Op woensdag 26 juni 2002 01:03 schreef mbravenboer het volgende:
Hetgene wat mij het meeste aantrekt in functionele talen is het uitermate krachtige type-systeem, niet zozeer het denken in functies. Helaas is het echter zo dat de kracht van het type-systeem volgt uit het paradigma: functies . Kip... ei...

Tja, om gebruik te 'mogen' maken van de krachtige analysetools, moet je de prijs betalen om je probleem op een formele manier uit te drukken.

Het probleem van veel andere talen (vooral uitsluitend imperatieve talen zoals C) is dat elk 'stukje' in verband staat met elk andere stukje. Elke statement kan in potentie gebruik maken van een globale variabele en hierdoor zijn alle statements die daadwerkelijk van diezelfde variabele gebruik maken met elkaar verbonden.

Om zinnige dingen af te leiden uit een programma, moet elk onderdeel zo min mogelijk met andere delen te maken hebben. Een functionele programmeertaal voert dat tot in het extreme door. De meeste OO talen zoeken de gulden middenweg, door in principe staat te verbergen achter objecten en zo min mogelijk relaties tussen klassen en objecten te introduceren.

Zelf vind ik het echter erg jammer dat de meest gangbare OO programmeertalen nog steeds ondersteuning bieden voor dynamische typeinformatie. Ik kan me niet herinneren ooit een goed ontwerp gezien te hebben dat die functionaliteit vereist. Met een goed OO-ontwerp zijn zaken als dynamische invocatie en het casten naar subklassen absoluut te vermijden. Dit heeft echter weinig meer met functionele programmeertalen te maken. (Al ging 't om type safety.)

[mbravenboer]

Sneechy: Ik kan me eigenlijk best goed vinden in Soultaker's betoog dat imperatief programmeren eigenlijk van nature dichter ligt bij de belevingswereld van programmeurs.

Merk op dat ik ook juist heel voorzicht ben geweest met het doen van een uitspraak hierover .

Op de UU wordt je onder leiding van Erik Meijer (nu hoog geplaatst bij het .NET ontwikkel-team), Doaitse Swierstra en in mindere mate de andere docenten geindoctrineerd met het 'feit' dat functioneel programmeren per definitie superieur is aan imperatief programmeren en de rest van de wereld dat alleen nog maar hoeft te gaan inzien voor een totale dominantie van het functioneel programmeren .

Als je daar echter wat andere geluiden en eigen ervaringen tegenover zet kom je toch wel tot een wat genuanceerdere kijk op de zaak. Het doel van het paradigma is best aardig, maar ik denk dat de kern van het programmeren toch echt is dat er juist verschillende paradigma's nodig zijn om elke probleem prettig uit te drukken. Het ontstaan van deze paradigma's is dan ook zeker iets positiefs, zeker als je ook nog echt de vrijheid hebt om een paradigma bij je probleem te zoeken. Tot nu toe is die vrijheid er eigenlijk niet omdat je paradigma's maar lastig kunt combineren.

Verder is het voor mij in ieder geval een geruststelling dat jullie ook grote moeite hebben gehad met het leren begrijpen en waarderen van de vermeende schoonheid van functioneel programmeren; het ligt dus niet aan mij .

Ik ben eigenlijk wel benieuwd in hoeverre ik er een probleem mee had gehad als ik niet eerst jarenlang imperatief had geprogrammeerd. Je wilt tijdens je eerste functionele programmeren nu eenmaal voortdurend alles in een variabele stoppen en assignments doen aan die variabele om je probleem op te lossen: maar ja, dat kan niet . Stel dat je nu nog niet de notie van een assignment kent? Hoe zou functioneel programmeren dan op je overkomen?

[Soultaker]

Op woensdag 26 juni 2002 01:05 schreef Sneechy het volgende:
Tot slot lijkt het dus 't verstandigst om het beste van de twee paradigma's te proberen te combineren: imperatief/OO voor het resource-management, en af en toe een beetje FP voor berekeningen, algoritmen, en eventueel data-transformaties.

OO is natuurlijk bij uitstek geschikt voor het representeren van 'dingen', 'objecten'. Als je een resource als een object beschouwt, waar je dingen mee kunt doen en waarvan je de eigenschappen wilt opslaan, is een OO oplossing inderdaad geschikt.

Resources zullen in het algemeen echter ook gemanaged moeten worden en hier zijn algoritmen voor nodig. Wanneer je zaken als deadlock avoidance wilt implementeren, is een functionele aanpak weer ideaal, mits je een manier kunt vinden om het aanvragen en vrijgeven van resources als functies weer te geven.

(Ik denk dat 't eerder genoemde Prolog dat ook goed kan trouwens.)

[Soultaker]

Op woensdag 26 juni 2002 01:17 schreef mbravenboer het volgende:
Ik ben eigenlijk wel benieuwd in hoeverre ik er een probleem mee had gehad als ik niet eerst jarenlang imperatief had geprogrammeerd. Je wilt tijdens je eerste functionele programmeren nu eenmaal voortdurend alles in een variabele stoppen en assignments doen aan die variabele om je probleem op te lossen: maar ja, dat kan niet . Stel dat je nu nog niet de notie van een assignment kent? Hoe zou functioneel programmeren dan op je overkomen?

Hmm, dat vraag om een experiment.

Het zou niet zo moeilijk moeten zijn om een groep eerstejaars informaticastudenten op te splitsen in twee groepen, waarvan de eerste groep het eerste trimester een imperatieve taal leert en het tweede trimester een functionele taal, en de tweede groep het omgekeerde. Zou er opmerkelijk verschil zijn in de resultaten?

Zou het volgen van het eerste vak gevolgen hebben voor de cijfers voor het tweede vak? Is het makkelijker om over te schakelen van imperatief naar functioneel programmeren of omgekeerd?

Het hangt er natuurlijk wel een beetje van af wat de inhoud van de vakken zou zijn. In C kun je ook al veel recursieve algoritmen implementeren en die zijn natuurlijk min of meer 1 op 1 om te zetten naar een functionele programmeertaal.

Ik vermoed dat het om die reden (maar dat is misschien niet helemaal eerlijk) beter is om eerst een imperatieve programmeertaal te leren. Het kan trouwens ook goed zijn, dat mensen die eerst functioneel hebben leren programmeren, in een taal als C ook zelden gebruik maken van variabelen (eventueel om resultaten samen te stellen e.d.) en control structuren (behalve om de functieselectie van een functionele programmeertaal te simuleren).

[mbravenboer]

Soultaker: Hmm, dat vraag om een experiment.

Als ik het goed heb werd er in het verleden op de UU functioneel programmeren gegeven voor imperatief programmeren . Het probleem bij zo'n experiment is echter dat veel mensen die aan een informatica studie beginnen al wel eens geprogrammeerd hebben... We moeten eigenlijk 50 babies nu afzonderen van de wereld en verplichten om een informatica opleiding te gaan doen over 18 jaar .

In C kun je ook al veel recursieve algoritmen implementeren en die zijn natuurlijk min of meer 1 op 1 om te zetten naar een functionele programmeertaal.

Nou ja, je kunt natuurlijk in elke zichzelf respecterende taal wel recursief programmeren . Ik geloof dat dit in de meeste boeken en cursussen ook wel ter sprake kunt.

Een probleem bij het compileren van een (niet-lazy ) functionele taal naar C is trouwens currying: als een functionele taal dit niet zou ondersteunen is er eigenlijk een direct vertaling naar C mogelijk. Dit is dan ook precies wat Stratego doet (wat geen currying toestaat). Probleem is alleen dat currying toch wel voortkomt uit het basis-idee van een functionele taal .

[Infinitive]

koffercomputer: Als ik dat voorbeeldje zo zie, dan lijkt functioneel programmeren wel op wat ik ooit als vak heb gehad, alleen was dat Logisch Programmeren. Toen hebben we een hoop in Prolog gedaan. Ik kreeg hoofdpijn van recursie.

Recursie is naar mijn mening juist een mooi aspect van talen die dat ondersteunen (en zolang je maar niet al te diep gaat is dat bij de moderne talen wel het geval). Bewijzen leveren over code kan met recursie juist heel aardig (inductie).

Soultaker: Functionele programmeertalen zijn over het algemeen nogal slecht in interactie met de imperatieve wereld. C, C++, assembly, Java, etcetera kunnen allemaal redelijk makkelijk van elkaar's interfaces gebruik maken. Functionele programmeertalen hebben dat niet, dus is het vaak moeilijk om imperatieve interfaces op een zinnige manier om te zetten naar een functionele omgeving.

Ik heb gehoord dat je je met Haskell toegang hebt tot het .NET gebeuren... het hoe en wat weet ik niet, maar dat geeft wel aan dat mogelijkheden tot interactie tussen deze verschillende werelden steeds beter worden.
Als voorbeeld heb ik een stukje haskell gezien van een afstudeerproject van iemand van de Universiteit Utrecht (

edit:
dat was dacht ik Erik Meijer die toevallig in de beurt was om een gast college te geven

), die Agents van Microsoft via haskell aanstuurt. Degene die dat gemaakt had kon op een zeer korte en gemakkelijke manier die agents allerlei truuckjes asynchroom laten doen, wat in vergelijkende c of java code bladzijden code zou zijn.

Dus, voor de functioneel programmeurs onder ons: wat doe je ermee? Had je in het begin ook dergelijke problemen met het waarderen van het paradigma? (En zo ja: was er een bepaald kwartje dat moest vallen?) Kloppen mijn vermoedens over de zeer beperkte toepasbaarheid van functioneel programmeren? (En zo ja: hoe ga je daarmee om?) Kortom: alle ervaringen zijn welkom.

Mijn aanraking met een functionele programmeertaal vond ik juist best leuk. Nu had ik ook een leerboek dat zich vooral op een grafisch aspect richtte: dus niet alleen allerlei rekensommetjes om te oefenen, maar ook tekeningetjes maken in een window.
Ik kan me herinneren dat de eerste paar uur wel even wennen waren, maar al snel merkte ik dat het eigenlijk allemaal niet zo nieuw en anders is zoals iedereen riep, maar dat gewoon kennis van andere programmeertalen ook hier toepasbaar is en dat het juist veel meer creativiteit biedt.
Als je naar m'n sig kijkt, dan zie je een stukje Haskell. Wel, het stukje code dat zo'n formule kan bakken was eigenlijk m'n eerste echte Haskell programmatje (was op een dag dat ik niets te doen heb en de opvolgende dag een toetsje had van haskell, dus wat oefening kon geen kwaad). Anyway, in haskell was dat maar betrekkelijk weinig code (past op 2 a4'tjes met een normaal lettertype en dat voor een eerste programmatje), terwijl ik het in een taal als c++ niet eens aan begonnen zou zijn.

Wat betreft het nut: iets leren is natuurlijk altijd nuttig (cliché, ik weet 't), maar een goede baan zul je er waarschijnlijk niet mee vinden.

Vooral het probleem dat maar relatief weinig mensen met functionele programmeertalen in aanmerking komen (ze weten niet wat ze missen ). M'n docent die ik had van functioneel programmeren vertelde me dat hij mij IBM had gewerkt dan daar een keer om een probleem op te lossen in now-time een correct werkend haskell programma had gemaakt, maar omdat er niemand anders die code zou kunnen onderhouden kon hij het weggooien en had iemand anders met veel werk een of ander monster groot c programma in plaats daarvan gemaakt.

Helaas bleek dit toch wel een beetje te hoog gegrepen om menselijke controle over de uitvoering van een programma lange tijd noodzakelijk is geweest.

En wat als je programma binnen expliciet gedefinieerde tijdgrenzen moet draaien? Kan je daar eigenlijk wel een uitspraak over doen bij een functionele taal? Want als je aan tijd denkt in de vorm van instructies, dan is dat juist hetgene wat je bij een functionele taal niet doet. En heeft dit ook niet als gevolg dat efficiency een wat lastiger begrip is? (hoewel je natuurlijk ook op een wat hoger niveau naar algoritmen kan kijken).

Het is voor een programmeur dan ook (relatief) makkelijk om een algoritme om twee grote getallen te vermenigvuldigen in imperatieve (iteratieve) vorm uit te schrijven, omdat die alleen de stappen die 'ie zelf zou nemen, in de juiste vorm in hoeft te typen.

Wanneer je functioneel programmeert, ben je dus op een onconventionele manier bezig. Je specificeert hoe een bepaalde operatie samengesteld is en laat het afleiden van het daadwerkelijke stappenplan over aan de compiler.

Kijk maar daar maak je volgens mij de fout. Je zegt nu dat je als programmeur zelf liever een bepaalde volgorde aangeeft, maar dat dat in een functionele taal niet kan want je compiler/interpreter doet dat.
Maar een functionele taal blinkt hier nu juist in uit! Als programmeur kan je gewoon zeggen van doe dit, doe dat en met het resultaat daarvan doe dat. Hoe het in werkelijkheid uitgevoerd wordt weet je niet, maar een ding weet je wel, het resultaat is consistent met het resultaat dat je zou krijgen als je het in jouw bedachte volgorde uitvoert.
Heb ik nog een leuk voorbeeld? Ja: ik heb een practicum opdracht gehad waarbij we een LOGO interpreter moesten bouwen (heel simpel) dat een schildpadje op het scherm aanstuurt. Hierbij schreef ik gewoon op van: zet eerst alle commando's in het bestand om in een lijst van commando's (dat was dus eigenlijk een lijst van functies ). Daarna werd er nogmaals doorheen gelopen om control-structuren te vinden en zodaning structuur aan te brengen in de lijst met functies (ok, dat was geen lijst meer, maar dat doet niet terzake). Vervolgens moest de code uitgevoerd worden en op het scherm gezet.
Dit heb ik opgeschreven en het programma deed dit dan ook. Dat door de lazy evaluation en dergelijke het bestand nog niet eens gecompileerd was terwijl de schilpad al vrolijk rondhuppelde op het scherm zou me in dit geval echt helemaal niets kunnen schelen.
Maar vertel mij nu is, waarom wat ik hierboven schreef zo anders is?

Ik zou eigenlijk willen voorstellen om als je niet weet hoe je een bepaald probleem moet uitdrukken in Haskell omdat gewoon hier een topic te plaatsen? . Uiteindelijk moet je het toch leren met behulp van voorbeelden en uitwerkingen en bovendien zou het wel een toevoeging zijn aan P&W .

Mij lijkt het wel leuk om af en toe eens wat over aparte programmeertalen als topic te zien verschijnen. Al dat php gedoe begint ook de vervelen

[mbravenboer]

Infinitive: Ik heb gehoord dat je je met Haskell toegang hebt tot het .NET gebeuren... het hoe en wat weet ik niet, maar dat geeft wel aan dat mogelijkheden tot interactie tussen deze verschillende werelden steeds beter worden.

Kijk eens hier:
Microsoft .NET Language Partners

en dan kom je hier:
Massey University met Mondrian en Haskell .NET

Een uiteraard:
http://www.mondrian-script.org

Dit topic ken je vast nog wel:
[topic=386183/1/25]

Helaas heb ik zelf nog niet de gelegenheid gehad om met deze mogelijkheden concreet wat te proberen. Er zijn ook nog twee functionele talen van Microsoft zelf, die ik ook nog niet bekeken heb:

SML .NET (gebaseerd op Standard ML) en F# (gebaseerd op Caml)

Nu kan iedereen zich weer even vermaken .

[Soultaker]

Op woensdag 26 juni 2002 02:04 schreef Infinitive het volgende:
Recursie is naar mijn mening juist een mooi aspect van talen die dat ondersteunen (en zolang je maar niet al te diep gaat is dat bij de moderne talen wel het geval). Bewijzen leveren over code kan met recursie juist heel aardig (inductie).

Het vervelende is dat er een belangrijke klasse van algoritmen bestaat, die je juist beter niet recursief kan oplossen. Dat is eigenlijk trouwens een implementatiedetail en daar kom ik zo op terug.

En wat als je programma binnen expliciet gedefinieerde tijdgrenzen moet draaien? Kan je daar eigenlijk wel een uitspraak over doen bij een functionele taal? Want als je aan tijd denkt in de vorm van instructies, dan is dat juist hetgene wat je bij een functionele taal niet doet. En heeft dit ook niet als gevolg dat efficiency een wat lastiger begrip is? (hoewel je natuurlijk ook op een wat hoger niveau naar algoritmen kan kijken).

Het bekende 'foute' voorbeeld van recursie is de recursieve implementatie van Fibonacci-getallen:

code:

fib 1 = 1
fib 2 = 1
fib n = fib (n-1) + fib (n-2)

In Clean (en ik vermoed ook Haskell) resulteert dit in een algoritme met complexiteit (grofweg) O(2^n), aangezien op elk nivo twee aanroepen gedaan worden. Miranda is een functionele omgeving met een geïnterpreteerde taal, die gebruik maakt van caching, waardoor het algoritme in O(n) uitgevoerd kan worden (in feite gebeurt min of meer hetzelfde als in de iteratieve variant).

Het is dus niet zo eenvoudig om eigenschappen van algoritmen te beschrijven aan de hand van broncode alleen. Het is erg afhankelijk van het gebruikte systeem, hoe de geschreven functionele code uiteindelijk geëvalueerd wordt. In dit geval is het (doorgaans trage) Miranda superieur ten op zichte van Clean, dat op efficiëntie ontwikkeld is.

Natuurlijk is de manier waarop een functioneel programma uitgevoerd wordt per taal wel bekend, dus kun je best naar de tijd- en ruimte-complexiteit van functionele programma's kijken. Het vervelende is echter dat de complexiteit van in essentie dezelfde broncode in verschillende omgevingen sterk uiteen kan lopen.

Kijk maar daar maak je volgens mij de fout. Je zegt nu dat je als programmeur zelf liever een bepaalde volgorde aangeeft, maar dat dat in een functionele taal niet kan want je compiler/interpreter doet dat.
Maar een functionele taal blinkt hier nu juist in uit! Als programmeur kan je gewoon zeggen van doe dit, doe dat en met het resultaat daarvan doe dat. Hoe het in werkelijkheid uitgevoerd wordt weet je niet, maar een ding weet je wel, het resultaat is consistent met het resultaat dat je zou krijgen als je het in jouw bedachte volgorde uitvoert.

Dat klopt, maar mijn punt was dat je dan geen stappenplan maakt. Je specificeert (zoals je al zegt) wat je nodig hebt en wat je daar mee wilt doen.

Heb ik nog een leuk voorbeeld? Ja: ik heb een practicum opdracht gehad waarbij we een LOGO interpreter moesten bouwen (heel simpel) dat een schildpadje op het scherm aanstuurt. Hierbij schreef ik gewoon op van: zet eerst alle commando's in het bestand om in een lijst van commando's (dat was dus eigenlijk een lijst van functies ). Daarna werd er nogmaals doorheen gelopen om control-structuren te vinden en zodaning structuur aan te brengen in de lijst met functies (ok, dat was geen lijst meer, maar dat doet niet terzake). Vervolgens moest de code uitgevoerd worden en op het scherm gezet.
Dit heb ik opgeschreven en het programma deed dit dan ook. Dat door de lazy evaluation en dergelijke het bestand nog niet eens gecompileerd was terwijl de schilpad al vrolijk rondhuppelde op het scherm zou me in dit geval echt helemaal niets kunnen schelen.
Maar vertel mij nu is, waarom wat ik hierboven schreef zo anders is?

Je geeft het verschil zelf al aan. In een imperatieve implementatie zou je zoiets doen:
1. filetje inlezen
2. gegevens parsen
3. scherm initialiseren
4. commando's uitvoeren

Het is ondenkbaar dat tijdens de uitvoeren van stap 2 al met stap 3 begonnen kan worden. Dit zal je in een imperatieve programmeertaal nooit gebeuren, omdat je hebt aangegeven wat van begin tot eind moet gebeuren. Niet alleen heb ik hier aangegeven in welke volgorde de commando's uitgevoerd worden, maar ook in welke volgorde ze opgesteld zijn.

In een functioneel programma kun je ook best beginnen met het schrijven van de code voor stap 1, maar in je uiteindelijke programma begin je bij je doel. De startregel bestaat uit het uitvoeren van de commando's die in een lijst staan. De lijst wordt gevuld met gegevens uit een lijst met strings, die lijst met strings wordt gevuld uit het bestand.

Of eerst het scherm wordt geinitialiseerd en vervolgens het bestand ingelezen, of andersom, is niet relevant en dat komt in je code tot uitdrukking. Uit je code blijkt op geen enkele manier dat je een voorkeur zou hebben voor de ene of de andere volgorde.

Het simpele feit dat ik geen stappenplan kan maken van het functionele programma geeft al aan dat ik het programma op een andere manier geconstrueerd heb. Ik heb niet gespecificeerd wat er achtereenvolgens gedaan moet worden, maar gespecificeerd wat ik nodig heb om m'n doel te bereiken.

Natuurlijk zijn er overeenkomsten tussen functionele en imperatieve talen. Een groot deel van de aspecten van programmeren zijn gewoon universeel. Er zijn naar mijn mening echter nog wel genoeg verschillen over om over verschillende klassen programmeertalen te kunnen spreken.

Mij lijkt het wel leuk om af en toe eens wat over aparte programmeertalen als topic te zien verschijnen. Al dat php gedoe begint ook de vervelen

Agreed.

[mbravenboer]

Soultaker: Agreed.

Ik ben bang dat de mensen die serieus een ander paradigma gebruiken hier geen vragen hoeven te stellen . Misschien moeten we gewoon af en toe even een leuk progsel plaatsen en daar over gaan kletsen ofzo .