F#, functioneel programmeren in .NET

[CubicQ]

Zie http://research.microsoft.com/projects/ilx/fsharp.htm

Zou dit de doorbraak kunnen worden van functioneel programmeren? Want, hoewel elke inf-student functioneel programmeren leert, wordt het in de praktijk toch nog vrij weinig tot niet gebruikt.

Wat ik bij Miranda erg miste was een makkelijke manier om data te in- en outputten. Omdat je bij F# van .NET libraries gebruik kan maken lijkt me dat probleem opgelost.

[Alarmnummer]

CubicQ schreef op 23 mei 2003 @ 16:06:
Zie http://research.microsoft.com/projects/ilx/fsharp.htm

Zou dit de doorbraak kunnen worden van functioneel programmeren? Want, hoewel elke inf-student functioneel programmeren leert, wordt het in de praktijk toch nog vrij weinig tot niet gebruikt.

Wat ik bij Miranda erg miste was een makkelijke manier om data te in- en outputten. Omdat je bij F# van .NET libraries gebruik kan maken lijkt me dat probleem opgelost.

Voor het java platform heb je ook een aantal andere talen zoals bv Prolog (compileerd ook weg naar bytecode). Maar ik zie er in de praktijk eigelijk weinig van terug, dus logischerwijs verwacht ik hiervoor (helaas) hetzelfde.

[reskobon]

Koel, ik heb vandaag heel de dag Clean gehad op school. Het is echt even wennen allemaal maar vind het best leuk om ook eens te doen. Mijn voorkeur gaat echter toch naar OO talen.

Prolog ga ik een half jaar op mijn stage gebruiken. Eens kijken of dat wat is

[Alarmnummer]

Afgezien van het ingebouwde backtracken heeft prolog nog veel te bieden tov functionele talen zoals Haskell of Clean.

[ Voor 25% gewijzigd door Alarmnummer op 23-05-2003 16:26 ]

[reskobon]

Ik ga er ook pas in de zomer aandacht aan besteden en zal wel kijken wat het allemaal wordt.

Onze docent is mede ontwikkelaar bij Clean en die man is helemaal fp gericht. Op zich best leuk maar of er nou toekomst in zit.....

[Verwijderd]

Artikeltje van extremetech

[bluewarlord]

Ik zou zeggen een gepasseerd station. Dat de meeste (Nederlandse) academicie na 30 jaar nog niet realiseren dat de rest van de wereld voor iets anders gekozen hebben is diep triest. Elke keer wordt het weer opnieuw geprobeerd en faalt het. Mischien zijn functionele en logische talen mischien iets te moeilijk? Moeilijk == duur personeel == kosten gaan omhoog == je bedrijf gaat failliet. Zolang er geen bewezen additionele tijdwinst met hetzelfde personeel valt te halen is acceptatie een groot probleem en wordt het nooit wat.

[ Voor 3% gewijzigd door bluewarlord op 23-05-2003 16:37 ]

[alienfruit]

maar is modulo 2 ook niet zoiets ?

[Alarmnummer]

alienfruit schreef op 23 mei 2003 @ 16:37:
maar is modulo 2 ook niet zoiets ?

Ik neem aan dat je bedoelt Modula? En modula is gewoon het vervolg op Pascal.

[edit]
En verder denk ik dat de toekomst zit in het combineren van allerlei paradigma`s. Een taal zoals c++ ondersteunt hogere orde functies en anders kan je een Strategy design pattern er tegenaan gooien om hetzelfde effect te verkrijgen. Hiermee heb je al 1 element van functionele talen. Verder kan je lazy structuren maken (virtual proxy als we het bij de design patterns willen houden) en daarmee heb je een ander element. Je kan het visitor design pattern gebruiken voor een lichte vorm van pattern matching en traversal/logica scheiding (kan je ook doen mbv een Iterator).

Zoals je ziet worden al veel interessante onderdelen van functionele talen gebruken in andere (lees oo) talen. En ik denk dat hier dus voor de mainstream de meeste toekomst in zit.

[ Voor 64% gewijzigd door Alarmnummer op 23-05-2003 16:44 ]

[bluewarlord]

Laatste versie is Modula-3, welke een imperatieve taal is. Enkele language features zijn:
- zeer sterke typering
- modules
- in-build build system
- generic interfaces

Oorspronkelijk door digital ontwikkeld, maar later min of meer gedumpt. Ik weet niet of het opensource is geworden, ik dacht van wel ....

[bluewarlord]

Ik denk niet dat er veel toekomst zit in het combineren van allerlei paradigma`s. Het is al vaak geprobeerd en de handicap is telkens weer dat een consistent plaatje een ramp is. Hierbij toegevoegd dat vele paradigma's nauwlijks "nut" hebben vanuit kosten perspectief maakt het niet waarschijnlijk. Meer toekomst zit in wat ook wel visueel programmeren wordt genoemd. Beetje slepen en sleuren met componentjes en die aan elkaar plakken is nu het credo. In de toekomst kan dit mijn inziens nog allemaal veel uitgebreider worden.

[reskobon]

bluewarlord schreef op 23 May 2003 @ 16:50:
Ik denk niet dat er veel toekomst zit in het combineren van allerlei paradigma`s. Het is al vaak geprobeerd en de handicap is telkens weer dat een consistent plaatje een ramp is. Hierbij toegevoegd dat vele paradigma's nauwlijks "nut" hebben vanuit kosten perspectief maakt het niet waarschijnlijk. Meer toekomst zit in wat ook wel visueel programmeren wordt genoemd. Beetje slepen en sleuren met componentjes en die aan elkaar plakken is nu het credo. In de toekomst kan dit mijn inziens nog allemaal veel uitgebreider worden.

Juist van die enge 4GL dingen zoals Sybase enzo

[Alarmnummer]

bluewarlord schreef op 23 mei 2003 @ 16:50:
Ik denk niet dat er veel toekomst zit in het combineren van allerlei paradigma`s. Het is al vaak geprobeerd en de handicap is telkens weer dat een consistent plaatje een ramp is.

Hmm.. ik vind het anders uitstekend werken, en ik zou niet terug willen naar 'klassiek' oo.

Meer toekomst zit in wat ook wel visueel programmeren wordt genoemd. Beetje slepen en sleuren met componentjes en die aan elkaar plakken is nu het credo.

Hier heb ik toch mijn twijfels over. Hoe lang is Delphi er al? Hoe lang is c-builder er al? Verder zie ik niet zozeer in waarom de kracht zozeer in het visuele moet zitten. Het maakt me niet zoveel uit of ik in een bestandje zit te werken, of in een mooie visuele tree bv. Als ik het in mijn hoofd maar goed voor elkaar heb, dan vind ik het medium om die ideeen in die pc te krijgen niet meer zo belangrijk.

[ Voor 9% gewijzigd door Alarmnummer op 23-05-2003 17:00 ]

[whoami]

Alarmnummer schreef op 23 May 2003 @ 16:59:
[...]
Hier heb ik toch mijn twijfels over. Hoe lang is Delphi er al? Hoe lang is c-builder er al?

Delphi, C++ Builder en consorten zijn toch wat meer dan sleur en pleur werk. Wil je iets functioneels, dan moet je zowiezo nog code schrijven.
Wil je iets dat goed en degelijk werkt, dan zal je zeker de nodige aandacht aan die code moeten besteden.

[Verwijderd]

bluewarlord schreef op 23 May 2003 @ 16:35:
Elke keer wordt het weer opnieuw geprobeerd en faalt het. Mischien zijn functionele en logische talen mischien iets te moeilijk?

Ooit was programmeren in het algemeen moeilijk, nu doet elke boer het, waarom? Omdat talen makkelijker geworden zijn, of misschien wel omdat het tegenwoordig beter uitgelegd wordt?

Moeilijk == duur personeel == kosten gaan omhoog == je bedrijf gaat failliet. Zolang er geen bewezen additionele tijdwinst met hetzelfde personeel valt te halen is acceptatie een groot probleem en wordt het nooit wat.

Dus? De pogingen om functionele talen om te vormen naar iets in de praktijk bruikbaars moeten maar gestaakt worden?

[mbravenboer]

bluewarlord: Ik zou zeggen een gepasseerd station. Dat de meeste (Nederlandse) academicie na 30 jaar nog niet realiseren dat de rest van de wereld voor iets anders gekozen hebben is diep triest.

Ik denk dat je de invloed van onderzoek naar functionele talen nu toch wel onderscheid. Invloed is iets anders dan concrete toepassing.

Lisp is bijvoorbeeld nog steeds een enorm invloedrijke taal. Wat denk je van de imperatieve talen uit die tijd? Lisp werd voornamelijk afgewezen vanweze performance problemen. Met de computerkracht en compilertechnologie van tegenwoordig spelen deze zaken veel minder een rol. Nu speelt de als maar groeiende complexiteit van software: hoe houden we software intwikkeling in de hand? Abstractie mogelijkheden en code generatie spelen daarbij een belangrijke rol imho. Lisp was op dat punt al vrijwel het summum. 'Moderne' talen introduceren nog regelmatig features die in Lisp al aanwezig waren. Abstractie mogelijkheden zijn nog steeds beperkt, om over code generatie maar helemaal te zwijgen.

Wat dacht je bijvoorbeeld van XSLT? XSLT is sterk beinvloed door de kennis die James Clark heeft opgedaan van functionele talen. XSLT was geen XSLT geweest als hij niet had geleerd hoe Haskell in elkaar zit. XSLT is wellicht wel de eerste 'declaratieve' (wat dat ook moge zijn) die door 'de massa' wordt toegepast.

[mbravenboer]

bluewarlord: Beetje slepen en sleuren met componentjes en die aan elkaar plakken is nu het credo. In de toekomst kan dit mijn inziens nog allemaal veel uitgebreider worden.

Niet alle programmeurs zijn hetzelfde en niet alle programmeurs doen hetzelfde werk. Voor het grafisch aan elkaar plakken van componenten is uiteraard een markt, maar er wordt gelukkig ook nog ander werk gedaan.

Voor een taal die zelf zonder een olifant achtige IDE wel abstractie en compositie mechanismen biedt is imho juist een toekomst.

[__fred__]

Functionele talen zullen altijd hun nut blijven bewijzen binnen de informatica. Simpelweg omdat ze voor bepaalde toepassingsgebieden de mogelijkheid bieden om problemen te modelleren in een "taal" die daarvoor op maat gemaakt is.

Vraag de gemiddelde informaticastudent (na de initiële fuck-wat-stinkt-dit-omschakelperiode) of deze talen hem meer programmeerinzicht hebben gegeven en geleerd hebben om op een andere manier tegen problemen aan te kijken en hij zal dit onderkennen.

Functionele talen zijn vaak ook ontdaan van allerlei initialisatie en imperatieve opsmuk, waardoor je ontzettend compact problemen kunt formuleren. Dit geeft je helaas niet de mogelijkheid om met drie klikken een interface te bouwen, maar wel om uiterst helder en compact de oplossing van een probleemstelling weer te geven. Voeg daar aan toe de volgende mogelijkheden die niet of nauwelijks mogelijk waren met imperatieve / OO talen zoals:

- hogere orde functies
- pattern matching
- recursieve en inductieve definities (zo kinderlijk eenvoudig en uitnodigend tenminste)
- polymorfe functies op basistypen
- partiele parametrisatie
- ingebouwde lambdacalculus
- Lazy evaluatie (waardoor deels met oneindige data gewerkt kan worden)
- definitie in lijstcomprehensies

Verder biedt Prolog specifiek nog zoiets als richtingsloze definities. Een functie kan dus ook min of meer "andersom" uitgevoerd worden, indien die geschikt is. (voer het resultaat in en de parameters komen eruit). Ook biedt prolog naieve implementatie van DCG grammatica's die zijn toepassing vinden in allerlei taalkundige software. Je zult de eerste niet zijn die zijn taalverwerkingsalgoritme in prolog programmeert vanwege de uitstekende grammaticale mogelijkheden en zijn stevige basis in modale en gewone logica.

Parsen, sorteren, boomalgoritmen, graafproblemen, het gaat allemaal een stuk handiger in een functionele taal.

Acceptatie is niet zozeer een probleem. Het toepassingsgebied is alleen vrij beperkt. OO is voor veel problemen gewoon een ideaal gereedschap om snel resultaat te bereiken. Er zijn maar zeer weinig bedrijfsmatige toepassingsgebieden waar geld te verdienen valt met functioneel programmeren. Vraag me toch alleen af of in bepaalde toepassingsgebieden, functionele talen dan wel concepten compleet weg te denken zijn.

[ Voor 2% gewijzigd door __fred__ op 23-05-2003 18:00 . Reden: layout bijgewerkt ]

[__fred__]

Inderdaad. Dan vergat ik nog ff te noemen de code-genererende mogelijkheden van lisp, waardoor deze taal ideaal geschikt is voor zelflerende algoritmen en andere futuristische genetische algoritmen (als je niet gestoord wordt van die k#thaakjes overal). En het declaratief modelleren van problemen die zich uitstekend leent voor massieve paralelle verwerking. (Ooit hopelijk met quantumcomputing)

[whoami]

offtopic:
__fred__, kan je ff letten op de 'lay-out' van je posts? Deze zijn nl. niet echt goed leesbaar...

[bluewarlord]

Zo te zien heeft mijn post nogal wat reacties los gemaakt ;-) Hierbij mijn reactie:

Juist van die enge 4GL dingen zoals Sybase enzo

Robje, nee geen enge dingen. Huidige programmeertalen hebben de grote handicap dat de concepten vrij ver van de denk wereld van de oplosser staan (== programmeur op dit moment) een mens kan nu eenmaal makkelijker visuele informatie verwerken dan abstracte textuele informatie. Kijk maar hoe moderne IDE's steeds meer door vormgeving de programmeur proberen te helpen ...

Hmm.. ik vind het anders uitstekend werken, en ik zou niet terug willen naar 'klassiek' oo.

Hangt ervan wat "het" is. Bedoel je daar taalextensies mee of meer functionele of logische aspecten?

Hier heb ik toch mijn twijfels over. Hoe lang is Delphi er al? Hoe lang is c-builder er al? Verder zie ik niet zozeer in waarom de kracht zozeer in het visuele moet zitten. Het maakt me niet zoveel uit of ik in een bestandje zit te werken, of in een mooie visuele tree bv. Als ik het in mijn hoofd maar goed voor elkaar heb, dan vind ik het medium om die ideeen in die pc te krijgen niet meer zo belangrijk.

Met die laatste zin geef jezelf al aan wat het punt is. Abstract kunnen denken is slechts aanwezig in 5% van deze wereldbevolking. Elke mogelijkheid van het dichter tot de werkelijkheid brengen zal dan ook moeten worden gebruikt. Tegenwoordig is er bijna geen bedrijf meer dat zonder een IDE met grafische tooling een user interface in elkaar sleutelt. Zeg nu niet dat het niet relevant is, want 50% van de code in een systeem wordt gespendeerd aan user interactie.

Delphi, C++ Builder en consorten zijn toch wat meer dan sleur en pleur werk. Wil je iets functioneels, dan moet je zowiezo nog code schrijven.
Wil je iets dat goed en degelijk werkt, dan zal je zeker de nodige aandacht aan die code moeten besteden.

Zie vorige opmerking, 50% heb je al weggeoptimaliseerd. Kijk maar eens hoe weinig glue code je tegenwoordig nog bij hoeft te voegen ... wie schrijft tegenwoordig nog alle componenten zelf?

Ooit was programmeren in het algemeen moeilijk, nu doet elke boer het, waarom? Omdat talen makkelijker geworden zijn, of misschien wel omdat het tegenwoordig beter uitgelegd wordt?

Het is relatief makkelijker geworden, m.a.w. je hebt minder geschoold personeel nodig == goedkoper product. Kijk maar, de echte code klopperij wordt tegenwoordig in oost europa of India gedaan ....

Dus? De pogingen om functionele talen om te vormen naar iets in de praktijk bruikbaars moeten maar gestaakt worden?

Ja en nee als je na 30 jaar nog steeds niks hebt bereikt qua bedrijfsmatige prestatie wordt het toch wel eens tijd om mischien iets anders te overwegen ... ...

hoe houden we software intwikkeling in de hand? Abstractie mogelijkheden en code generatie spelen daarbij een belangrijke rol imho. Lisp was op dat punt al vrijwel het summum. 'Moderne' talen introduceren nog regelmatig features die in Lisp al aanwezig waren. Abstractie mogelijkheden zijn nog steeds beperkt, om over code generatie maar helemaal te zwijgen.

Goed punt, maar lisp is toch echt wel een research toy taal. Leuk voor nieuwe ideeen en kleine dingen, maar onbruikbaar voor echte grote systemen. Imho zou lisp als het zo geweldig is toch na 30 jaar ook wel in het bedrijfsleven mogen worden gebruikt, maar dit is duidelijk niet het geval en het wordt een tijd dat men dit zich realiseerd.

Wat dacht je bijvoorbeeld van XSLT? XSLT is sterk beinvloed door de kennis die James Clark heeft opgedaan van functionele talen. XSLT was geen XSLT geweest als hij niet had
geleerd hoe Haskell in elkaar zit.

Ik heb zelf wat met XSLT geprogrammeerd en ik vond het ontzettend moeilijk. Nu ben ik zelf iemand die zeer goed abstract kan denken, maar ik denk dat XSLT voor velen een brug te ver is. XSLT zal dan ook geen succes worden als programmeertaal. De enige hoop voor het is dat er mischien een tooling komt of vereenvoudige taal die XSLT genereerd om niet een vroege wiegendood te sterven ....

Niet alle programmeurs zijn hetzelfde en niet alle programmeurs doen hetzelfde werk. Voor het grafisch aan elkaar plakken van componenten is uiteraard een markt, maar er wordt gelukkig ook nog ander werk gedaan.

Door de toenemende integratie wordt dit een uitstervende soort. Het wordt namelijk veel goedkoper om het snel en inefficient te doen dan goed en efficient. Deze grens schuift steeds meer de kant van snel en inefficient op. Bedenk dat ik met het sleuren en pleuren van componenten niet alleen grafische zaken bedoelde zoals de huidige IDE dat ondersteunen, maar generieke componenten.

Functionele talen zullen altijd hun nut blijven bewijzen binnen de informatica. Simpelweg omdat ze voor bepaalde toepassingsgebieden de mogelijkheid bieden om problemen te modelleren in een "taal" die daarvoor op maat gemaakt is.

Er zijn zeker domeinen waar een functionele taal zeer goed tot zijn recht komt. Het zijn er alleen niet zoveel Triest maar waar.

Voeg daar aan toe de volgende mogelijkheden die niet of nauwelijks mogelijk waren met imperatieve / OO talen zoals:

- hogere orde functies
- pattern matching
- recursieve en inductieve definities (zo kinderlijk eenvoudig en uitnodigend tenminste)
- polymorfe functies op basistypen
- partiele parametrisatie
- ingebouwde lambdacalculus
- Lazy evaluatie (waardoor deels met oneindige data gewerkt kan worden)
- definitie in lijstcomprehensies

Allemaal zeer leuke, intressante technieken. Punt is, niemand gebruikt ze, met ze bedoel ik de Philips, Nokia, Microsoft, IBM, Tweakers etc., in andere woorden het bedrijfsleven. Kennelijk is er iets mee en wordt het niet gebruikt. Vraag is waarom niet?

[__fred__]

bluewarlord schreef op 23 mei 2003 @ 20:55:

[...]


Allemaal zeer leuke, intressante technieken. Punt is, niemand gebruikt ze, met ze bedoel ik de Philips, Nokia, Microsoft, IBM, Tweakers etc., in andere woorden het bedrijfsleven. Kennelijk is er iets mee en wordt het niet gebruikt. Vraag is waarom niet?

- Erlang - RTL functionele taal speciaal voor Short time to market development van mobile software

- Elegant - Deels functionele taal van Philips om grammaticale bewerkingen uit te voeren binnen software.

- Hibase - een functionele programmeertaal en omgeving om software te schrijven speciaal voor telecommunicatieapparatuur

- Toepassing van functionele programmeertechnieken bij IBM bij XML/XSLT toepassingen.

- Xilinx gebruikt haskell om FPGA circuits te berekenen.

Dit zijn toch duidelijk voorbeelden waarbij het gebruikt wordt in het bedrijfsleven. Redenen waarom het niet voor alles gebruikt wordt zijn waarschijnlijk:

- interfacing met imperatieve programma's en code is slecht
- geen grote component libraries beschikbaar
- stevig geworteld in console omgevingen
- de toegenomen helderheid gaat ten koste van uitvoersnelheid (er zijn echter bijvoorbeeld wel compilers ipv interpreters. En recente microsoft IL code is ook niet echt supervlug)
- 100% functionele code bestaat niet, delen blijven altijd imperatief en dit moet dus ook te programmeren zijn. Niet elke strict academische taal is daar even goed in.
- Doet een groter beroep op het abstract denkvermogen

Ow en niet te vergeten zitten aardig wat Excel programmeurs te hobbyen met HASKELL in hun vrije tijd waardoor Excel ondertussen aardig richting functionele taal begint te gaan.

[ Voor 5% gewijzigd door __fred__ op 23-05-2003 21:48 ]

[__fred__]

bluewarlord schreef op 23 mei 2003 @ 20:55:
Zo te zien heeft mijn post nogal wat reacties los gemaakt ;-) Hierbij mijn reactie:

Robje, nee geen enge dingen. Huidige programmeertalen hebben de grote handicap dat de concepten vrij ver van de denk wereld van de oplosser staan (== programmeur op dit moment) een mens kan nu eenmaal makkelijker visuele informatie verwerken dan abstracte textuele informatie. Kijk maar hoe moderne IDE's steeds meer door vormgeving de programmeur proberen te helpen ...

Misschien is het wel zo dat de populariteit van OO in de hand werkt dat er zoveel IDE's voor te vinden zijn. Ik geef in de vorige post bij Hibase (dacht ik) aan dat daar een IDE voor is. Waarschijnlijk zijn er meer. Een IDE is niet noodzakelijk met het OO concept verbonden. Ik kan me een hele goede IDE voorstellen die aansluit bij een functionele taal.
Feit is wel dat een functionele taal een hogere orde taal is dan een imperatieve taal en in die zin dichter bij de denkpatronen van de mens aansluit dan een imperatieve.

Met die laatste zin geef jezelf al aan wat het punt is. Abstract kunnen denken is slechts aanwezig in 5% van deze wereldbevolking. Elke mogelijkheid van het dichter tot de werkelijkheid brengen zal dan ook moeten worden gebruikt. Tegenwoordig is er bijna geen bedrijf meer dat zonder een IDE met grafische tooling een user interface in elkaar sleutelt. Zeg nu niet dat het niet relevant is, want 50% van de code in een systeem wordt gespendeerd aan user interactie.

Hier komen we tot de kern van de zaak. Het is niet alleen het abstractieniveau wat een probleem is, maar het hele imperatieve idee moet voor functioneel programmeren op de helling. De uitkomst van een functioneel programma is de evaluatie van een expressie, geen reeks achter elkaar uitgevoerde instructies. Elk temporeel probleem is handiger imperatief te programmeren dan functioneel. En dat geldt vooral voor interfaces. Overigens is het discutabel dat een IDE ervoor zorgt dat meer mensen ermee kunnen programmeren. Kijk bijvoorbeeld naar PHP. Er is een veelheid aan factoren wat maakt dat de instap/overstap naar een nieuwe taal problematisch verloopt. Bovendien vind ik nog steeds niet dat een IDE strikt voorbehouden is aan een OO taal.

Zie vorige opmerking, 50% heb je al weggeoptimaliseerd. Kijk maar eens hoe weinig glue code je tegenwoordig nog bij hoeft te voegen ... wie schrijft tegenwoordig nog alle componenten zelf?

Heeft ook weer weinig met het verschil tussen OO en FP te maken. Middels de CLR staat het hele .NET framework tot je beschikking in F#. Lijkt me genoeg om te kunnen optimaliseren. Ook een fraaie IDE lijkt me. En de code moet je toch nog steeds wel zelf schrijven helaas, als je tenminste iets meer wilt maken dan een Windows version checker.

Het is relatief makkelijker geworden, m.a.w. je hebt minder geschoold personeel nodig == goedkoper product. Kijk maar, de echte code klopperij wordt tegenwoordig in oost europa of India gedaan ....

Ehm... Laten we hopen dat er niet te veel gaststudenten Tweakers.net lezen. Ik heb zelf aardig wat te maken gehad met Indiase en Russische / Oost-europese studenten en stuk voor stuk leggen ze een hoger niveau (zowel qua kennis als intelligentie) aan de dag dan hun hollandse luie volgevreten papstudentjes (waar ik ook toe behoor). Het is waar dat door de uiterst zware competitie alleen de top komt bovendrijven in die landen. Maar ze investeren enorm in scholing en in absolute cijfers hebben ze nog steeds het grootste aantal hooggeschoolde mensen in die landen (kijk maar hoeveel Indiers en Russen er zijn, zelfs als je bijvoorbeeld alleen de Brahmaanse kaste uit India neemt).

Goed punt, maar lisp is toch echt wel een research toy taal. Leuk voor nieuwe ideeen en kleine dingen, maar onbruikbaar voor echte grote systemen. Imho zou lisp als het zo geweldig is toch na 30 jaar ook wel in het bedrijfsleven mogen worden gebruikt, maar dit is duidelijk niet het geval en het wordt een tijd dat men dit zich realiseerd.

Commerciele Lisp applicaties

Ik heb zelf wat met XSLT geprogrammeerd en ik vond het ontzettend moeilijk. Nu ben ik zelf iemand die zeer goed abstract kan denken, maar ik denk dat XSLT voor velen een brug te ver is. XSLT zal dan ook geen succes worden als programmeertaal. De enige hoop voor het is dat er mischien een tooling komt of vereenvoudige taal die XSLT genereerd om niet een vroege wiegendood te sterven ....

De kans dat XSLT uitsterft lijkt me klein, want er zijn altijd mensen die zich er mee bezig blijven houden. Success/Failure rates hangen denk ik meer af van acceptatie van deze standaard door Microsoft bijvoorbeeld.

Door de toenemende integratie wordt dit een uitstervende soort. Het wordt namelijk veel goedkoper om het snel en inefficient te doen dan goed en efficient. Deze grens schuift steeds meer de kant van snel en inefficient op. Bedenk dat ik met het sleuren en pleuren van componenten niet alleen grafische zaken bedoelde zoals de huidige IDE dat ondersteunen, maar generieke componenten.

Ik zie dit nog steeds niet als een strikte OO eigenschap.

Er zijn zeker domeinen waar een functionele taal zeer goed tot zijn recht komt. Het zijn er alleen niet zoveel Triest maar waar.

Inderdaad. Maar dat OO in alle gevallen beter is / beter toepasbaar dat denk ik niet.

[Verwijderd]

__fred__ schreef op 23 May 2003 @ 17:50:
Voeg daar aan toe de volgende mogelijkheden die niet of nauwelijks mogelijk waren met imperatieve / OO talen zoals:

- recursieve en inductieve definities (zo kinderlijk eenvoudig en uitnodigend tenminste)

/me vraagt zich af Bedoel je nou dat recursieve definities niet mogelijk zijn met een OO taal (zeg c++, C# of java) of dat dit erg moeilijk te ontwikkelen is?

[__fred__]

Verwijderd schreef op 23 mei 2003 @ 22:24:
[...]


/me vraagt zich af Bedoel je nou dat recursieve definities niet mogelijk zijn met een OO taal (zeg c++, C# of java) of dat dit erg moeilijk te ontwikkelen is?

Ik bedoel hiermee dat een recursieve definitie niet zo gemakkelijk te maken is als in een functionele taal. Het is wel mogelijk, maar niet zo elegant als in een functionele taal. Door een functiedefinitie te combineren patttern matching is het bijvoorbeeld mogelijk om in 2 regels een functie uit te voeren die alle elementen van een array omwisselt. Ik daag je uit in een imperatieve taal met gebruik van 1 functie en 2 regels.

[Verwijderd]

__fred__ schreef op 23 May 2003 @ 22:37:
[...]


Ik bedoel hiermee dat een recursieve definitie niet zo gemakkelijk te maken is als in een functionele taal. Het is wel mogelijk, maar niet zo elegant als in een functionele taal. Door een functiedefinitie te combineren patttern matching is het bijvoorbeeld mogelijk om in 2 regels een functie uit te voeren die alle elementen van een array omwisselt. Ik daag je uit in een imperatieve taal met gebruik van 1 functie en 2 regels.

Die uitdaging wil ik wel aangaan, maar wordt wel een erg lange regel . Vroeg me enkel af of je dacht dat dit uberhaupt niet kon in een OO taal, blijkbaar wist je dat wel.

Ben wel benieuwd hoe een recursieve functie in een functionele taal eruit ziet als het in 2 regels kan. Show me!

[__fred__]

Voor de nieuwsgierigen onder ons ;-)

code:

reverse [] = []
reverse (h:t) = reverse t ++ [h]

[__fred__]

De kortste pseudocode imperatieve versie waar ik mee kon komen:
(Met dezelfde techniek als de functionele versie, en ervan uitgaande dat je een deel van de array kunt kopieren. In elke functionele taal kun je zowel het eerste als het laatste element heel makkelijk van een lijst(array) afhalen).

code:

function reverse (array A) {
  if (A.count <= 1) {
    return A;
  } else {
    B = A.copyElements(1,A.Count-1);
    reverse(B);
    B.append(A[0]);
    return B;
  }
}

[ Voor 40% gewijzigd door __fred__ op 23-05-2003 23:00 . Reden: Ik kan het ook nooit in 1x goed intikken :-) ]

[Verwijderd]

offtopic:
De functionele implementatie in Haskell en de imperatieve in bijv. c draaien in O(n^2) met n de lengte van de te reversen lijst. De reverse in de imperatieve versie kan je uiteraard herschrijven zodat de elementen geswapt worden. De pseudo code ziet er dan heel anders uit. Wanneer je echter naar de functionele versie kijkt, zie je dat daar maar weinig aan verandert:

code:

reverse = reverse' []
reverse' r [] = r
reverse' r (h:t) = reverse (h:r) t

Of in twee regels

code:

reverse = flip reverse' []
reverse' = foldr (\h t r -> t (h:r)) id

[ Voor 51% gewijzigd door Verwijderd op 24-05-2003 09:42 . Reden: moet ik het wel goed opschrijven :+ ]

[nhimf]

Wat mensen vaak vergeten bij functionele talen, is dat het wiskundig gezien te bewijzen valt.
Dwz dat als je een stuk code hebt geschreven, dat je dan kan bewijzen dat je code geen fouten bevat. Maw foutloos coderen is makkelijker dan in een imperative taal.
Dat is dus iets wat niet een klein voordeel is.
Voor mission critical spul kan je dus eigenlijk beter een (puur)functionele taal gebruiken.

Verder (maar dat is al gezegd) zijn wiskundige dingen vele malen makkelijker in een functionele taal dan in een imperative taal.

Je moet een taal ook gebruiken waar hij voor bedoeld is en dus ook mee gaan met de gedachtengang van die taal (het paradigma dus).
Je moet niet willen om een irc client te schrijven in haskell, daar is het gewoonweg niet voor bedoeld.
Ik vind het een goed ding dat ms komt met een commerciele functionele taal, dat heeft het wel nodig (niet ms dan ).
Maar ms kennende, zal het in elk geval geen puur functionele taal zijn en dus meer een mix tussen imperatief en functioneel.

Mensen die beweren dat functionele talen achterhaald en nutteloos zijn, die moeten maar eerst eens gaan kijken wat het paradigma achter een functionele taal is. Want dan zou je logische talen nl ook achterhaald noemen, die bestaan ook al lang, en worden ook nauwelijk commercieel gebruikt, maar zodra je in aanraking komt met AI, dan kan je niet om logische talen heen.

[Verwijderd]

Maar ms kennende, zal het in elk geval geen puur functionele taal zijn en dus meer een mix tussen imperatief en functioneel.

http://caml.inria.fr/FAQ/general-eng.html

Caml is a strict language, as opposed to lazy ones. However, first-order value functions allows the manipulation of delayed expressions, and thus lazy evaluation of potentially infinite data structures is still possible.

Caml provides full imperative capabilities, including updatable arrays, imperative variables and records with mutable fields.

[mbravenboer]

bluewarlord: Zo te zien heeft mijn post nogal wat reacties los gemaakt

Waarschijnlijk door het gebrek aan nuance .

Goed punt, maar lisp is toch echt wel een research toy taal. Leuk voor nieuwe ideeen en kleine dingen, maar onbruikbaar voor echte grote systemen. Imho zou lisp als het zo geweldig is toch na 30 jaar ook wel in het bedrijfsleven mogen worden gebruikt, maar dit is duidelijk niet het geval en het wordt een tijd dat men dit zich realiseerd.

Ik denk dat je m'n punt mist. Ik probeerde juist het verschil te benadrukken tussen invloed en toepassing. De invloed van Lisp lijkt alleen maar te groeien.

XSLT zal dan ook geen succes worden als programmeertaal. De enige hoop voor het is dat er mischien een tooling komt of vereenvoudige taal die XSLT genereerd om niet een vroege wiegendood te sterven ....

Ik geloof dat je op dit punt toch niet een al te beste kijk op de toepassing van XSLT hebt: XSLT is een succes en XSLT is al lange tijd geleden uit de wieg gestapt ...

[__fred__]

Verwijderd schreef op 24 May 2003 @ 09:20:

[...]
__________________
putStr (map (\x -> chr (round (21/2 * x^3 - 92 * x^2 + 503/2 * x - 105))) [1..4])

He, Arie

[__fred__]

taylorreeksen-Arie

[ Voor 74% gewijzigd door __fred__ op 24-05-2003 12:45 ]

[Verwijderd]

taylorreeksen-Arie

Wat is er met taylor reeksen? (lol, dat iedereen die mijn sig ziet hem ook gaat uitrekenen...)

PS: we zitten aardig offtopic te gaan hier

[ Voor 17% gewijzigd door Verwijderd op 24-05-2003 13:38 ]

[whoami]

__fred__ schreef op 24 mei 2003 @ 12:43:
taylorreeksen-Arie

Je kan je berichten ook editten hoor.
Dat leest makkelijker dan een paar keer onder elkaar te posten.

[Soultaker]

CubicQ schreef op 23 May 2003 @ 16:06:
Zou dit de doorbraak kunnen worden van functioneel programmeren? Want, hoewel elke inf-student functioneel programmeren leert, wordt het in de praktijk toch nog vrij weinig tot niet gebruikt.

Aan de Universiteit Twente hebben ze vorig jaar functioneel programmeren uit het curriculum gegooid. Erg jammer, vind ik, want nu wordt in het begin van de opleiding alleen maar met Java gewerkt en hoewel dat een aardig taaltje is, biedt het absoluut niet die structuur en veelzijdigheid waarmee je een student een brede basis biedt voor de kennismaking met verdere programmeertalen. (Later in de opleiding komt ook een beetje C langs, maar dat blijft vrij beperkt.)

Wat ik bij Miranda erg miste was een makkelijke manier om data te in- en outputten. Omdat je bij F# van .NET libraries gebruik kan maken lijkt me dat probleem opgelost.

Miranda mist ook een goede compiler met duidelijke foutmeldingen, vlotte executie, goede libraries, een handige IDE, een debugger, profiling tools, enige ondersteuning voor geavanceerde concepten als uniqueness typing, monad passing, arrays, destructive updates, en misschien wel het belangrijkste, de syntax (voor zover die afweek van gebruikelijke functionele talen) was belabberd.

De beschikbaarheid van .NET libraries is inderdaad een heel sterk punt van F# en lijkt me ook van doorslaggevend belang om het in de markt te kunnen plaatsen. Zelfs 'goede' functionele talen als Haskell, Objective CaML, Clean (de laatste meer dan de eerste) lijden vaak onder het gebrek aan geschikte libraries, die ervoor zouden kunnen zorgen dat ze je niet elke keer from scratch hoeft te beginnen (wat in een praktijksituatie met beperkte tijd en middelen niet acceptabel is). Dat geldt natuurlijk voor alle programmeertalen.

Ik vind het sowieso wel praktisch dat de verschillende .NET-talen dezelfde libraries gebruiken. Als je één taal kent, wordt de drempel om een tweede taal te gaan leren en gebruiken een stuk lager.

[Verwijderd]

Haskell(voorbeeld) is in mijn ogen veel beter dan C++/JAVA, maar het probleem ermee, is dat het niet mogelijk is om op een eenvoudige manier Threads, GUI's te implementeren. Op het moment dat die beschikbaar worden, voorspel ik een explosie van Haskell gebruikers.

[Soultaker]

Verwijderd schreef op 24 mei 2003 @ 20:35:
Haskell(voorbeeld) is in mijn ogen veel beter dan C++/JAVA, maar het probleem ermee, is dat het niet mogelijk is om op een eenvoudige manier Threads, GUI's te implementeren. Op het moment dat die beschikbaar worden, voorspel ik een explosie van Haskell gebruikers.

Op zich vind ik het GUI model van Clean best aardig in elkaar steken. Het blijft natuurlijk altijd moeilijk om de moderne event-gestuurde GUI modellen om te zetten in een zinnig functioneel model.

Het ontbreken van threads zou in een functionele taal niet zo'n probleem mogen heten, aangezien het ontbreken van side effects concurrente executie zonder expliciete taalondersteuning mogelijk maakt. Uiteraard moet dat dan wel geïmplementeerd worden, maar het feit dat je je geen zorgen hoeft te maken over thread safety zou een groot voordeel kunnen zijn ten op zichte van huidige imperatieve programmeertalen.

[Apollo_Futurae]

Er wordt op dit moment druk gewerkt aan een gestandaardiseerde, cross-platform GUI library voor haskell. Threads zijn al uitstekend geïmplementeerd (en helemaal niet zo lastig om mee te werken ).

Het wachten is denk ik op het moment waarop een kritische massa wordt bereikt: als er eenmaal een flinke community is, die zich meer richt op beginnelingen en alledaags gebruik, kan functioneel programmeren heel groot worden.

[curry684]

Verwijderd schreef op 23 May 2003 @ 22:48:
Die uitdaging wil ik wel aangaan, maar wordt wel een erg lange regel . Vroeg me enkel af of je dacht dat dit uberhaupt niet kon in een OO taal, blijkbaar wist je dat wel.

Recursiviteit vereist nauwelijks iets van een taal, enkel van de compiler dat deze reentrant code genereert. Sommige antieke C/C++ compilers doen dit namelijk *niet*. Bijvoorbeeld COBOL is per definitie niet reentrant (en kan dus niet recursief) omdat het volledig gestoeld is op static data.

[Alarmnummer]

bluewarlord schreef op 23 mei 2003 @ 20:55:
Hangt ervan wat "het" is. Bedoel je daar taalextensies mee of meer functionele of logische aspecten?

Ik bedoel er niet zozeer taalextensies mee, maar idd de functionele aspecten. Visitors zijn oa een manier om functionaliteit toe te voegen aan je types en deze manier van werken zie je ook bij functioneel programmeren. In het begin leer je bij traditioneel oo dat je alles data+logica bij elkaar moet plaatsen, maar bij een groter systeem kom je vaak hierdoor hopeloos in de knoei. Daarom vind ik het dus fijn om allerlei handige technieken te gebruiken die je vaak (tot in het extreem) terugziet bij een andere taal/paradigma.

Met die laatste zin geef jezelf al aan wat het punt is. Abstract kunnen denken is slechts aanwezig in 5% van deze wereldbevolking. Elke mogelijkheid van het dichter tot de werkelijkheid brengen zal dan ook moeten worden gebruikt.

Hmm... als je niet abstract kan denken, moet je denk ik geen programmeur gaan worden Maar ik snap wel wat je bedoelt.

Tegenwoordig is er bijna geen bedrijf meer dat zonder een IDE met grafische tooling een user interface in elkaar sleutelt. Zeg nu niet dat het niet relevant is, want 50% van de code in een systeem wordt gespendeerd aan user interactie.

Niet alleen gebruikers interfaces worden visueel in elkaar gezet, maar ook allerlei andere aspecten van een systeem. Ik vind het persoonlijk behoorlijk vervelend werken, alhoewel ik absoluut niet vies ben van gegenereerde code. Maar ik zie verder niet in waarom daar iets visueel aan te pas moet komen. Een scriptje of een ander tooltje die ik kan aanroepen vanuit mijn buildscript vind ik vele malen fijner werken.

[Oogst]

mbravenboer schreef op 23 May 2003 @ 17:34:
...
Lisp werd voornamelijk afgewezen vanweze performance problemen. Met de computerkracht en compilertechnologie van tegenwoordig spelen deze zaken veel minder een rol.
...

Niet alleen zijn computers tegenwoordig sneller, ook de compilers leveren snellere code. Inderdaad leveren de oude compilers voor functionele talen zeer trage code, maar dit geldt niet voor de nieuwe. De HGC Haskel compiler levert, met de O2-functie aan, bijna net zo snelle code als C.

[Glimi]

Oogst schreef op 26 May 2003 @ 14:56:
De HGC Haskel compiler levert, met de O2-functie aan, bijna net zo snelle code als C.

offtopic:
GHC bedoel je: http://www.haskell.org/ghc/

[Soultaker]

Oogst schreef op 26 May 2003 @ 14:56:
Niet alleen zijn computers tegenwoordig sneller, ook de compilers leveren snellere code. Inderdaad leveren de oude compilers voor functionele talen zeer trage code, maar dit geldt niet voor de nieuwe. De HGC Haskel compiler levert, met de O2-functie aan, bijna net zo snelle code als C.

Hmm, bij de benchmarks die ik heb gezien levert Haskell niet de snelste code; onder de functionele talen was dat juist OCaml dacht ik, maar zelf de snelste taal zat gemiddeld genomen nog een factor 2 of 3 onder C code.

Geen idee meer wat ik zoal gezien had, maar een beetje Googlen levert o.a. dit op:
http://www.lib.uchicago.edu/keith/crisis/benchmarks/tak/
http://dada.perl.it/shootout/craps.html

[ Voor 14% gewijzigd door Soultaker op 26-05-2003 15:07 ]

[CubicQ]

Maar als dat maar een factor 2 is is dat voor de meeste toepassingen niet echt boeiend: da's 1.5 jaar 'wachten'. Natuurlijk geldt dit niet altijd, maar ik denk dat je normaal gesproken meer moet kijken naar andere eigenschappen (als bewijsbaarheid, onderhoudbaarheid, leesbaarheid, develop-snelheid).

Kijk ook maar naar het relationele model. Vroeger ook alleen maar tijdens design gebruikt om daarna in een hierarchische databasemodel omgezet te worden. Computers zouden nooit zo snel kunnen worden dat je rechtstreeks met een RDBMS kon werken, maar dat is ook niet waar gebleken...

[Soultaker]

CubicQ schreef op 26 May 2003 @ 15:13:
Maar als dat maar een factor 2 is is dat voor de meeste toepassingen niet echt boeiend: da's 1.5 jaar 'wachten'. Natuurlijk geldt dit niet altijd, maar ik denk dat je normaal gesproken meer moet kijken naar andere eigenschappen (als bewijsbaarheid, onderhoudbaarheid, leesbaarheid, develop-snelheid).

Dat is waar, maar dat betekent nog niet dat een functioneel programma net zo snel is als C een programma. Als je punt is dat snelheid niet heel relevant is, doe er dan geen uitspraken over.

Kijk ook maar naar het relationele model. Vroeger ook alleen maar tijdens design gebruikt om daarna in een hierarchische databasemodel omgezet te worden. Computers zouden nooit zo snel kunnen worden dat je rechtstreeks met een RDBMS kon werken, maar dat is ook niet waar gebleken...

Hiërarchisch databasemodel? Hoe werkt dat?

[CubicQ]

Soultaker schreef op 26 May 2003 @ 16:00:
[...]

Dat is waar [...]

Dat is waar

Hiërarchisch databasemodel? Hoe werkt dat?

Records (met data) verbonden met Parent-Child relaties, zie bijvoorbeeld http://www.rcost.unisanni...d/html/disbd/pdf/ims6.pdf. Als je vind dat dat vrij veel op het huidige XML-database-hype-gedoe lijkt... tsja, lang leve de vooruitgang... Ik heb dat stukje trouwens uit het dictaat van Ontwerpen van Informatiesystemen (uit '99, maar ik mag hopen dat ze nu eindelijk dat Information Engineering eruit gegooid hebben en het vak iets gemoderniseerd hebben), maar ik kan het daar niet meer in terugvinden.

[Infinitive]

Hmm, bij de benchmarks die ik heb gezien levert Haskell niet de snelste code; onder de functionele talen was dat juist OCaml dacht ik

Dit zal waarschijnlijk te maken hebben met dat OCaml strict is en Haskell niet.

[Soultaker]

Infinitive schreef op 26 mei 2003 @ 20:03:
Dit zal waarschijnlijk te maken hebben met dat OCaml strict is en Haskell niet.

Dat zou zomaar kunnen. In de benchmarks die ik net tegenkwam scoorde Clean ook goed, en daar is het ook mogelijk om strictness te specificeren. (Daarbij kan de strictness in veel gevallen ook afleiden).

[EfBe]

Ik vind F# onleesbaar. Sorry dat ik het zeg, maar ik vind het niks. Vroeger vond ik functionele talen leuk, want je kunt veel met erg weinig statements, maar als je ineens een nieuwe functionele taal voor je kiezen krijgt dan zie je wel meteen de zwakheid van het geheel: je moet eerst er diep induiken voordat je er iets uitkrijgt, en dat zegt al genoeg over de bruikbaarheid van deze taal: voor individuen die geen code sharen met anderen is het wellicht nuttig.

Begrijp me niet verkeerd, het zal voor sommige toepassingen een uitkomst zijn, maar voor het leeuwendeel van de software heb je zo duidelijk mogelijke statements nodig die door iemand met ook maar 10% van de kennis van de taal nog redelijk duidelijk zijn. Niet een complexe functionele taal die behalve voor taalnerds nauwelijks interessant is. (Sorry Martin ) Met C++ templates kun je ook de meest fantastische dingen. Er zijn echter maar weinig programmeurs die zich C++ kenner noemen die na 1 keer lezen volledig de std begrijpen. Dan doe je toch iets verkeerd als taalmaker.

Bravenboer stipt Lisp aan hierboven, ik moest daar eerlijk gezegd wel om glimlachen. Ik begrijp de redenatie wel, maar Lisp is ook voor een average programmeur veel te complex. Hele simpele 2-liners lukt nog wel, maar ga maar eens een wat groter programma schrijven, dan ziet het er heel anders uit: Lisp ontpopt zich dan net als andere functionele talen als een complexe set talen die pas bedwongen kunnen worden door veel ervaring en dat is nu juist niet meer nodig hedentendage met talen die een veel lagere drempel hebben en ook de ruimte bieden waarmee je goede software kunt schrijven.

(om dezelfde redenen vind ik Perl bv ook een van de meest wanstaltige verzinsels ooit. Het zal absoluut slim in elkaar zitten, maar er valt zonder gedegen studie naar de taal zelf, nauwelijks iets zinnigs (dus niet een mailscript, maar heuze software) mee te bouwen.)

(disclaimer: ik heb zelf Lisp en Perl geprogrammeerd en vond Miranda en Prolog leuke talen , dit voor de mensen die menen dat hun zere schenen door mij zijn veroorzaakt )

[ Voor 5% gewijzigd door EfBe op 26-05-2003 22:40 ]

[Verwijderd]

Mijn neef is op dit moment bezig aan een nieuwe programmeertaal te schrijven. Allé vooral nu issem zijn compiler aan't schrijven in zijn eigen taal.
Het wordt een mengeling tussen een functionele en een OO taal
Heeft ook wat weg van cobol.

Het basis idee erachter is: schrijf zo weinig mogelijk code met een zo snel mogelijk resultaat.
het is idd zeer steile leercurve, maar voor eigen gebruik >> je zelfgemaakte programma's kunnen op het scherm vliegen in no time!

[Verwijderd]

(disclaimer: ik heb zelf Lisp en Perl geprogrammeerd en vond Miranda en Prolog leuke talen , dit voor de mensen die menen dat hun zere schenen door mij zijn veroorzaakt )

Hey EfBe, ga je nu al disclaimen VOORDAT iemand ook maar gereageerd heeft? Zo is er ook niets meer aan :-)

Ik ben het overigens volledig met je eens dit keer, F# heeft wat mij betreft een hoog "zal wel" gehalte. Het is voor de meeste programmeurs als moeilijk genoeg om object-georienteerd te denken, laat staan dat ze de constructen waarmee F# werkt goed begrijpen.

Veel interessanter vind ik het werk dat ze bij Microsoft aan het doen zijn op het gebied van data/oo integratie. Meeste concrete voorbeeld daarvan is X# http://www.eweek.com/article2/0,3959,808302,00.asp , hoewel dat ook allemaal nog erg vaag is spreekt het concept me erg aan.

[EfBe]

Verwijderd schreef op 26 May 2003 @ 23:59:
[...]
Hey EfBe, ga je nu al disclaimen VOORDAT iemand ook maar gereageerd heeft? Zo is er ook niets meer aan :-)

heh, ik zag de bui al hangen, vandaar

Ik ben het overigens volledig met je eens dit keer, F# heeft wat mij betreft een hoog "zal wel" gehalte. Het is voor de meeste programmeurs als moeilijk genoeg om object-georienteerd te denken, laat staan dat ze de constructen waarmee F# werkt goed begrijpen.

Precies. Neemt niet weg dat F# best in sommige onderdelen geschikt kan zijn en met de CLR heb je het voordeel dat je een in functionele talen gespecialiseerd iemand in bv F# kunt laten programmeren en de software in je eigen business applicaties kunt gebruiken. Ik worstel alleen een beetje met het feit dat functioneel gericht denken niet echt matcht in een oo wereld. Je ziet dat ook in de example code, zodra ze .NET libs gaan aanspreken is de code stukken leesbaarder.

OO is ook erg complex, zeker als je bedenkt dat het veelal pas na een paar pogingen lukt om een goed OO model te ontwerpen van een wat groter systeem, plus dat je echt wel wat tijd moet investeren om truuks als deze je eigen te maken dat je er compleet in gaat denken.

Veel interessanter vind ik het werk dat ze bij Microsoft aan het doen zijn op het gebied van data/oo integratie. Meeste concrete voorbeeld daarvan is X# http://www.eweek.com/article2/0,3959,808302,00.asp , hoewel dat ook allemaal nog erg vaag is spreekt het concept me erg aan.

Klinkt idd erg vaag allemaal maar wellicht is't wat XSL is op zich wel te doen, maar het is voor een mens ook nauwelijks leesbaar. Ik moet zeggen dat, ondanks dat ik er nooit meer in hoef te programmeren (behalve code ports) ik VB.NET een van de meest leesbare OO talen vind op dit moment. Taalbouwers gaan vaak voorbij aan het feit dat de mens bar en bar slecht is in het interpreteren van computertaal-teksten.

[Oogst]

Een voorbeeldje van een wel zeer compacte functie (in Haskel) die je imperatief echt niet zo klein geschreven gaat krijgen is de zeef om priemgetallen te krijgen:

zeef (x:xs) = x : zeef (filter ((/= 0) . (`mod` x)) xs)

Roep je deze aan met

take n (zeef [2..])

dan krijg je de eerste n priemgetallen. Dit is dus een voorbeeld van hoe enorm compact een functionele taal kan zijn.

Ik zie hier een heleboel mensen die denken dat functionele talen haast nergens gebruikt worden, maar een toch wel heel mooi voorbeeld is de Yahoo webwinkel. Die is functioneel geprogrammeerd.

Een groot voordeel van functionele talen is de sterke typering. 80% Van de bugs in software bestaat uit typeringsfouten en die zijn in Haskel bijna helemaal uitgeroeid.

Soultaker schreef op 26 mei 2003 @ 15:01:
[...]

Hmm, bij de benchmarks die ik heb gezien levert Haskell niet de snelste code; onder de functionele talen was dat juist OCaml dacht ik, maar zelf de snelste taal zat gemiddeld genomen nog een factor 2 of 3 onder C code.

Geen idee meer wat ik zoal gezien had, maar een beetje Googlen levert o.a. dit op:
http://www.lib.uchicago.edu/keith/crisis/benchmarks/tak/
http://dada.perl.it/shootout/craps.html

Maar van wanneer zijn deze tests? Aan Haskel wordt momenteel sterk ontwikkeld en ik zie hier geen datum.

[Scare360]

Verwijderd schreef op 26 May 2003 @ 23:59:
Het is voor de meeste programmeurs als moeilijk genoeg om object-georienteerd te denken, laat staan dat ze de constructen waarmee F# werkt goed begrijpen.

De spijker op z'n kop. Ik zou graag nog eens een project doen op basis van een solide domein model Een "zo lijkt het" goed boek is in aantocht m.b.t. OOP design. En dan komt daar nog eens bij dat alles maar naar een hoger abstractie niveau brengen niet per definitie betekend dat de kwaliteit en beheersbaarheid erop vooruit gaan. Denk hierbij aan AOP technieken.

"Getting the job done and acknowledging the tradeoffs", ontwikkelaars die problemen met techniek bestrijden zijn gedoemd te falen.

ps: Chris Hollander heeft trouwens te kennen gegeven dat MS mikt op XPath.

[EfBe]

offtopic:
Als iedere OO developer nu de 1e paar hoofdstukken van het GoF boek zou lezen zouden er heel wat meer goede OO classmodellen worden gebouwd. m.a.w.: ik denk dat het goede boek over OO er allang is. Je moet nl. ook weer niet overdrijven dat het grootschalig is, dat is het nl. niet. Het is wel complex, maar niet grootschalig, dus zeker samen te vatten in een pagina of 60, meer heb je niet nodig.

[Scare360]

offtopic:
EfBe: ik denk dat het goede boek over OO er allang is.

Ik praat dus over domain driven design, wat meer het proces omvat dan het resultaat (een domein modeldiagram). Tja ik ben nou eenmaal een methodiek neuker, de manager in mij