[Haskell] Wordt deze taal ooit gebruikt?

[Verwijderd]

Hoi

Op de universiteit krijgen we tijdens de informatica best veel les in Haskell (minimaal 4 studiepunten per jaar), nu vroeg ik me af of dit puur is om theoretische kennis op te doen, of heeft het ook nog practische zin, d.w.z. wordt Haskell ooit in het bedrijfsleven gebruikt?

Op zich vind ik het wel een mooie taal, maar ik heb in twee jaar nog geen enkele nuttige toepassing kunnen bedenken, en het zou wel prettig zijn als ik wist dat ik het ooit nog eens zou kunnen gaan gebruiken, dan voel ik me tenminste wat nuttiger

[Alarmnummer]

Ik denk dat het bij Haskell niet zozeer gaat om het toepassen van de taal zelf, maar eerder om de technieken die je leert. En dit gebruik je wel in een imperatieve taal.

[CyBeR]

ik heb er nog nooit van m'n leven van gehoord in elk geval

geef es een helloworld

[D2k]

wacht maar ff op mbravenboer
die kan er vast wel wat leuks over vertellen

[brammetje]

Uhm.. niet dat ik er veel vanaf weet, maar ik dacht dat het vooral voor dingen als AI werd/wordt gebruikt..

[Jelle Niemantsverdriet]

Haskell in practice
En hier staat in de beschrijving ook een stukje over "Does Anyone Use Functional Programming?"

[Verwijderd]

Op zaterdag 08 december 2001 19:15 schreef CyB3R het volgende:
ik heb er nog nooit van m'n leven van gehoord in elk geval

geef es een helloworld

module Main where

main :: IO ()
main = putStrLn "Hello World"


alsje

[Verwijderd]

wacht inderdaad op mbravenboer , maar sleutelwoord is toch wel parsers geloof ik

[Alarmnummer]

Op zaterdag 08 december 2001 20:19 schreef Stoned-cow het volgende:
wacht inderdaad op mbravenboer , maar sleutelwoord is toch wel parsers geloof ik

Ik ben geen ervaren haskell gebruiker maar weet wel het een en ander van prolog en ben zelf voor een expertsysteem bezig met een functionele taal die veel elementen van prolog bezit.

Het meest nuttige aan haskell is zeker geen parser maken, want dat kan je met mbv EBNF en een parser generator (dit is in principe volgens mij ook een functionele prog taal) ook uitstekend doen.

Je kunt met een functioneel programma meestal veel makkelijker aantonen dat je programma doet wat hij moet doen. Vaak is de source ook veel kleiner omdat veel functionaliteit is ingebouwd vb. backtracking.

vb van functionele taal waar ik zelf mee bezig ben.

code:

Persoon = record
 sofirnr int key;
 parentnr int;
 voornaam string;
  ....
end;

Parent(X:Persoon,Y:Persoon):=X.persoonnr = Y.parentnr;

Offspring(X:Persoon,Y:Persoon):=Parent(X,Y) or (Parent(X,Z) and Offspring(Z,Y));

Op zich staat de Z niet gebonden aan een bep verz. maar dat stuk moet ik nog in de taal toevoegen, maar het idee komt volgens mij wel over

Je ziet het.. in een paar regels kun je een vrij 'lastig' probleem oplossen.

[Verwijderd]

Dat was ook eigenlijk wat ik bedoelde te zeggen. Door een aaneenschakeling van relatief 'eenvoudige' methode (die inderdaad makkelijk te checken zijn op correctheid) kun je problemen oplossen die in een andere taal (imperatieve taal) lastig op te lossen zijn. Parsers zijn in imperatieve taal ook vrij lastig, en in haskell niet zo heel erg (worden op Uni ook aantal vakken aan besteed naar ik meen).

[tomato]

Functionele talen zijn bij uitstek geschikt voor prototyping. Het is met een functionele taal erg goed mogelijk de juistheid van je programma te bewijzen en te garanderen.

mbravenboer vindt functioneel programmeren volgens mij wel leuk en hij kan er vast het fijne van vertellen (misschien ook een stuk concreter?).
Zelf heb ik eigenlijk nog nooit echt iets gedaan met een functionele taal, maar ik vermoed dat ik later in mijn Wiskunde studie nog wel de kansen krijg hier mee in aanraking te komen.

[Verwijderd]

op de uva komt het maar 1x voor, en dat is in 't 1ste jaar.

[tomato]

plop: op de uva komt het maar 1x voor, en dat is in 't 1ste jaar.

Ik zeg ook bewust 'de kans krijg', ik denk dat ik er ook best met een grote boog omheen kan lopen.

[Nexopheus]

Van haskell kan ik zo geen voorbeelden geven van daadwerkelijk producten.
Er wel nog een andere (betere) (No flame) taal, nml Clean.
Clean wordt wel in het bedrijfsleven gebruikt.
http://www.cs.kun.nl/~clean/body_index.html

De syntax is bijna hetzelfde alleen is de taal veel "schoner".....

[Verwijderd]

Op zondag 09 december 2001 00:13 schreef Nexopheus het volgende:
Van haskell kan ik zo geen voorbeelden geven van daadwerkelijk producten.
Er wel nog een andere (betere) (No flame) taal, nml Clean.
Clean wordt wel in het bedrijfsleven gebruikt.
http://www.cs.kun.nl/~clean/body_index.html

De syntax is bijna hetzelfde alleen is de taal veel "schoner".....

Clean HEERST ! ! !

[mbravenboer]

Leuke vraag . Altijd leuk om op dit forum een keertje Haskell tegen te komen .
Gokje: je studeert zeker aan de Universiteit Utrecht?

Ik kan eigenlijk niet echt antwoord geven op je vraag. Ik zit niet in het bedrijfsleven en heb er ook geen zicht op in welke mate Haskell wordt toegepast. Wel kan ik je vertellen waarom ik vind dat Haskell uitstekend toegepast zou kunnen worden. Waarom het eventueel niet toegepast zou worden?: gebrekkige kennis, niet al te eenvoudige combinatie met andere paradigma's. In .NET kan je ook (een soort?) Haskell gaan gebruiken. Wellicht dat dit een goede stimulans zal zijn.

Allereerst wordt Haskell vaak een declaratieve taal genoemd. Declaratief is echter een extreem slecht gedefinieerde notie. Wat is declarativiteit? Vaak wordt er gezegd dat een taal declaratief is als je niet beschijft hoe de computer iets moet doen, maar wat de computer moet doen. Een compiler moet dan maar uitvogelen hoe dit gedaan moet worden. Een imperatieve taal is volgens deze definitie geen declaratieve taal omdat je in feite exact opgeeft hoe een computer iets moet doen.

Eigenlijk vind ik dit geen aangename definitie. Ik vind namelijk dat een taal helemaal niet declaratief is in het paradigma van deze taal. Je geeft namelijk binnen het model van dit paradigma precies aan hoe iets moet gebeuren. Een taal is dan ook alleen declaratief ten opzichte van een ander paradigma. Functionele talen kan je daarom declaratief noemen ten opzichte van het imperatieve paradigme. Ten opzichte van dit paradigma geef je aan wat er moet gebeuren. In het paradigma van de taal zelf geef je aan hoe iets moet gebeuren. Omdat alle paradigma's worden vergeleken met het imperatieve paradigma worden vaak alle andere paradigma's declaratief genoemd. Mijn interpretatie nuanceert dat een beetje .

Mijn aangepaste definitie komt eigenlijk voort uit het bewijzen van programma-correctheid. Er wordt namelijk weleens beweert dat een programma geschreven in functionele taal geen bewijs nodig heeft voor correctheid. Dit argument komt voor uit de aanname dat deze taal declratief is en dus beschijft wat er moet gebeuren. Een bewijs van correctheid vergelijkt over het algemeen wat er moet gebeuren met hoe iets moet gebeuren. Als er alleen maar een 'wat er moet gebeuren' is, valt er natuurlijk ook niets te bewijzen! Maar goed, iedereen die ooit weleens in Haskell gewerkt heeft zal weten dat je ook daarin makkelijk een incorrect programma kan maken. Neem bijvoorbeeld een stukje code die een lijst zou moeten sorteren, maar dit niet goed doet. In principe is dit programma een vertaling vanuit een specificatie-paradigma: je geeft aan wat je wilt bereiken met het programma. Je geeft in Haskell code aan hoe dit moet gebeuren (let op het woordje 'hoe'!). Ik vind dat je altijd de correctheid van een programma moet bewijzen als je vanuit het ene paradigma op het andere paradigma over gaat.

Als je namelijk een 'wat er moet gebeuren' beschrijving hebt in een functioneel paradigma en je implementeert dit in een imperatief paradigma, dan heb je een bewijs nodig dat deze implementatie voldoet aan je specificatie. Als je echter een 'wat er moet gebeuren' beschrijving hebt in een functioneel paradigma en je implementeert dit in Haskell, dan is er geen bewijs nodig. Je blijft namelijk in hetzelfde paradigma, of anders gezegd: je specificatie is je implementatie.

Wat is Haskell nu eigenlijk?
Haskell is een hogere-orde functionele taal. Dit betekent dat Haskell twee belangrijke features heeft:

1. Hogere orde functies: functies zijn toegestaan als argumenten van andere functies of als return waarden.
2. Geneste functies met lexical scope: een functie kan een sub-functie bevatten, waarbij de sub-functie de variabelen van de omringende functie kan gebruiken. Deze sub-functie kan ik een hogere-orde functionele taal ook worden opgeleverd als een resultaat.

Samen vormen deze twee features een uitermate aantrekkelijk paradigma, waarin je uitermate goed generieke code kunt schrijven. Een hele interessante feature van Haskell is de partiele parameterizatie van een functie: Stel dat je de functie 'add' hebt met als type: Int -> Int -> Int (er komt een int in, nog een int en er komt een int uit). De code 'add 5' is nu een partieel geparameterizeerde functie en dit is zelf ook weer een functie, namelijk een functie van Int -> Int. Deze functie telt bij een gegeven Int, 5 op.

Een ander belangrijk aspect is het ontbreken van side-effects: variabelen zijn altijd immutable. Dit heeft grote voordelen voor het bewijzen van correctheid en biedt ook interessante mogelijkheden tot optimalisering en uitgebreidde analyse in een compiler.

Haskell leent zich uitstekend voor het handmatig schrijven van parsers met behulp van parser-combinators. Met behulp van parser-combinators kan je op een hele eenvoudige manier een parser schrijven (in feite: samenstellen). Dit is een hele aantrekkelijke manier van het schrijven van een parser die interessante mogelijkheden biedt. In de praktijk wordt een parser inderdaad altijd gegeneerd uit een gegeven grammatica. Parser combinators zijn echter wel een leuk alternatief die ook zeker voordelen hebben.

Tja, ik kan nog wel even doorpraten over al de leuke features van Haskell maar dan wordt dit wel een heel erg lang verhaal . Waarschijnlijk is dit hierboven al complex genoeg. Als je ergens meer over wilt weten moet je daar maar even specifieker naar vragen.

Het is in ieder geval belangrijk om even door te bijten bij het leren van Haskell. De taal is in feite verschrikkelijk als je uit een volledig imperatieve achtergrond komt. Haskell zal echter zeer zeker je analytische vermogens verbeteren en het zal ook zeker helpen bij het leren of formaliseren van andere talen. Je krijgt meer inzicht in typering, data-structuren en generiek programmeren.

[Verwijderd]

wow... ik ben even stil en dat om 01:37!
Een heel verhelderend verhaal moet ik zeggen! Bedankt!

Gokje: je studeert zeker aan de Universiteit Utrecht?

In één keer goed!

Deze periode had ik zowel Programmeren & Correctheid (wel over Basic, en niet over Haskell) als Grammatica & Ontleden (wel in Haskell) en het doet me dan ook vreugd dat Parsers als een van de sterkste punten van Haskell gezien worden.
Ik moet ook zeggen dat die parsers zich HEEL goed in Haskell lieten schrijven. Totaal geen overhead of andere troep, maar echt precies wat je wilt wat het zou moeten doen. Hierdoor blijft je code heel mooi transparent.

Verder is het idd wel een mooi taaltje waar je veel dingen mee kan doen die niet makkelijk met imp. talen kunnen. Vooral die partitionele parametisering (wat een woord ) is heel mooi, en mis ook als ik in andere taaltjes zit te proggen. Wel jammer dat ik er waarschijnlijk later niks meer mee ga doen

Het zou wel leuk zijn als het in .NET mogelijk zou worden om stukjes code Haskell tussen VB.Net code door te prakken, dat bied zeker mogelijkheden!

[GBits]

Die Microsoft .Net goeroe, Erik Meier, die was toch prof aan de Universiteit van Utrecht??

[mbravenboer]

KoenM: Een heel verhelderend verhaal moet ik zeggen! Bedankt!

Mooi . Ik vind het wel jammer dat ik pas in de latere jaren heb kunnen ontdekken wat er nu eigenlijk theoretisch anders is aan Haskell. Dat heb ik een klein beetje geprobeerd uit te leggen...

In één keer goed!

Was te verwachten bij een Haskell vraag .

Deze periode had ik zowel Programmeren & Correctheid

Oeps, heb ik dan nu de zaak in de war geschopt met m'n declarativiteitsverhaal? Als er een vraag op het tentamen komt kan je misschien maar beter de behandelde definitie aanhouden (tenzij je dit heel goed begrijpt, misschien dat het je dan pluspunten oplevert ).

als Grammatica & Ontleden (wel in Haskell) en het doet me dan ook vreugd dat Parsers als een van de sterkste punten van Haskell gezien worden.

G&O is een leuk vak he? Johan Jeuring weet het erg goed te brengen .

Wel jammer dat ik er waarschijnlijk later niks meer mee ga doen

Je kan altijd nog in de academische wereld blijven .

Lecram: Die Microsoft .Net goeroe, Erik Meier, die was toch prof aan de Universiteit van Utrecht??

Hij was docent/onderzoeker volgens mij. In ieder geval geen professor (= hoogleraar). Hij ga toendertijd de vakken functioneel programmeren en software constructie (met extreme programming). Helaas vond ik hem ondanks zijn capaciteiten een matige docent bij functioneel programmeren, waardoor het mij pas vrij laat duidelijk is geworden waar het hierbij om gaat .

[ACM]

Op zaterdag 08 december 2001 21:32 schreef tomato het volgende:
Ik zeg ook bewust 'de kans krijg', ik denk dat ik er ook best met een grote boog omheen kan lopen.

Jij hebt een klein kansje om les te krijgen in CaML
Maar dat was bij mij ook maar 1 practicumpje.

[mbravenboer]

Nexopheus: Van haskell kan ik zo geen voorbeelden geven van daadwerkelijk producten.

Er wordt op dit moment op de UU een XML editor geschreven in Haskell. Op zich klinkt dit niet bijzonder, maar het heeft nogal een bijzondere generieke en visuele aanpak als ik het goed heb begrepen. Ik weet er verder het fijne niet van.

Voor z'n afstuderen heeft een student op de UU een XSLT engine geschreven in Haskell.

Verder zijn er vooral developers tools zoals een AG systeem, parser combinators, XML parsers enzovoorts. Ik ken verder geen producten die uit het bedrijfsleven komen, maar ik heb daar ook nooit naar geinformeerd.

[Verwijderd]

mbravenboer: wat heb jij met de UU dat je iedereen daar zo goed kent?

G&O is een leuk vak he? Johan Jeuring weet het erg goed te brengen.

Óók in een keer goed! Johan weet het idd goed te brengen, vooral z'n eindeloze hoeveelheid quizvragen, en de dreigementen (als je slim wilt zijn bij het schrijven van parsers dreigt hij een toetsenbord op je kop kapot te meppen )! Toch is hij nog niet zo goed als die gast van Programmeren & Correctheid, die gast kan zelfs het saaiste vak boeiend maken met z'n aparte woordgebruik .

Voor z'n afstuderen heeft een student op de UU een XSLT engine geschreven in Haskell.

Daar had Johan het idd over, en ik moet zeggen dat hij er niet echt enthiausast over was... Een beetje wanhopig zelfs!
Dus zo fantanstisch is Haskell dus ook niet, want als het allemaal goed gaat is het leuk en aardig, maar als er ook maar iets fout gaat ben je uren aan het zoeken naar de fout, en dan is het meestal één of ander lullig tikfoutje. Maar Hugs (wat een k*t programma!) komt dan met zo'n lap tekst dat je meteen geen zin meer hebt...

Hoe kan je trouwens überhaupt een Haskell programma gebruiken buiten bv. Hugs om? Wij moeten meestal een .hs filetje proggen, dat inlezen met Hugs en dan de functies testen, maar zou je een .hs filetje bijv. ook kunnen compilen naar een .exe bestand, of is dit onmogelijk

[mbravenboer]

KoenM: mbravenboer: wat heb jij met de UU dat je iedereen daar zo goed kent?

Studeer daar ook . Ben 5e jaars en bezig met afstuderen.

Daar had Johan het idd over, en ik moet zeggen dat hij er niet echt enthiausast over was... Een beetje wanhopig zelfs!

Auw . Ik weet er verder niets van en heb de implementatie ook niet gezien... Ik kan het dus ook verder niet beoordelen. Dergelijke transformaties kan je ook beter in Stratego uit drukken (krijg je later nog wel). Compilatie van XSLT naar Stratego was misschien interessanter geweest (maar ook weer te makkelijk ).

Hoe kan je trouwens überhaupt een Haskell programma gebruiken buiten bv. Hugs om? Wij moeten meestal een .hs filetje proggen, dat inlezen met Hugs en dan de functies testen, maar zou je een .hs filetje bijv. ook kunnen compilen naar een .exe bestand, of is dit onmogelijk

Glasgow Haskell Compiler (GHC): Deze compileert een Haskell programma naar native code (of C).

[Verwijderd]

Ik zat net ff bij die GHC te kijken, en dat ziet er idd wel geinig uit vooral

It implements numerous experimental language extensions to Haskell 98; for example: concurrency, a foreign language interface, multi-parameter type classes, scoped type variables, existential and universal quantification, unboxed types, exceptions, weak pointers, and so on.

En dat terwijl ik nu steeds leer dat die extistentiële quantor en universele quantor (als je dat zo schrijft ) helemaal niet te programmeren valt! Maar het zal hier wel door lazy evaluation komen, dat ze het toch kunnen doen Wel knap trouwens!

[mbravenboer]

KoenM: En dat terwijl ik nu steeds leer dat die extistentiële quantor en universele quantor (als je dat zo schrijft ) helemaal niet te programmeren valt!

In principe valt het wel te programmeren, maar daar krijg grote moeilijkheden mee . In Haskell zijn er in feite wel quantoren, maar deze staan allemaal vooraan in het type. Dat is een beperking. Quantoren binnen quantoren zijn op zich prima te implementeren, maar dan kan er geen type-inferentie meer plaats vinden (bij type-inferentie worden at compile-time de types van niet opgegeven functies bepaald door berekening). Als je echter een taal neemt waarbij je overal het type moet opgeven, is er geen type inferentie nodig en kan je dus gewoon quantoren in quantoren gebruiken. Het heeft dus eigenlijk niets met lazy evaluation te maken.

Je leert hier nog wel meer over bij XML Generiek Programmeren en Implementatie van Programmeertalen .

[Theswitch]

Clean is beter, wordt tenminste nog geod actief onderhouden. KUN-studenten weten dit wel

[mbravenboer]

Theswitch: Clean is beter, wordt tenminste nog geod actief onderhouden. KUN-studenten weten dit wel

Ik heb helaas nog niet met Clean gewerkt, dus kan daar niet direct over oordelen. Je argumenten zijn echter niet al te overtuigend . Haskell is ook een behoorlijk actieve gemeenschap en bovendien vind ik dat niet zo goed argument voor het 'beter' zijn van Clean .

Als ik het goed begrepen is het grootste verschil tussen Haskell en Clean de aanpak van functies met side-effects. Uiteraard horen functies in een functionele taal geen side-effects te hebben, dus is daar een speciale constructie voor nodig. In Clean worden functies met side-effects aangegeven met een unique-type. Dit unique type zou er dan voor moeten dienen dat er single-threaded gebruik kan worden gemaakt van een state van de applicatie.

Haskell lost dit op met een ander systeem: monads. Monads zorgen ervoor dat je de puurheid van de taal niet bederft met side-effects. Monads scheiden dergelijke functies netjes. Bij gebruik van unique-types is deze state is echter niet netjes gescheiden zoals bij een monad.

Waarom is volgens jou (jullie ) Clean beter (en in het bijzonder op dit punt)?

Ik kwam dit stukje tekst tegen, geschreven door ene Clean aanhanger op de mailing-list:

one way of doing it without asking Clean's
designers to spoil the important properties of the language or extend its type system would be to use a monad. Haskell's designers think monads so wonderful that they used them instead of Unique types to support IO,
state, etc.

en elders:

The standard way to incorporate a global state which can change during evaluation into a functional program is by way of a monad [Wad90, Wad92, Wad95] Unlike Haskell [HAB 96] Clean does not provide a special syntax for monads.

Ik heb eens een heel duidelijk stukje langs zien komen waar deze oplossingen werden vergelijken. Helaas kan ik het niet meer vinden .

[Verwijderd]

mbravenboer: Als ik het goed begrepen is het grootste verschil tussen Haskell en Clean de aanpak van functies met side-effects.

Haskell lost dit op met een ander systeem: monads.

Zou je bovenstaande puntjes een klein beetje meer willen verduidelijken? Want ik ben bang dat ik je niet helemaal kan volgen . En opzich lijkt het me wel interresant om te weten wat er zoal nog meer aan talen is...

Is de syntax van Clean en Haskell ongeveer gelijk, of is dat helemaal verschillend?

[mbravenboer]

KoenM: Zou je bovenstaande puntjes een klein beetje meer willen verduidelijken? Want ik ben bang dat ik je niet helemaal kan volgen .

Bij functionele talen horen functies eigenlijk per definitie geen side-effects hebben: er is geen 'State'. Dit is natuurlijk heel anders dan imperatieve talen, die barsten van de side-effects.

Op zich is dit allemaal prachtig omdat je nu heel goed kunt redeneren over een programma en de compiler in theorie veel beter zou kunnen optimaliseren, maar de computer-wereld is helaas geen wereld zonder side-effects. IO of GUIs zijn typische voorbeelden van toepassingen waar side-effects. Een functionele taal moet natuurlijk wel de mogelijkheid van IO bieden, dus moet er een oplossing komen voor het side-effect probleem. Over het algemeen wordt dit gedaan door een notie van 'World' in te voeren die aangepast kan worden. Deze World kan dan meegegeven worden aan functies. Het probleem is echter dat er maar 1 World is. Elke World mag daardoor maar 1 keer gebruikt worden. Haskell lost dit op met monads, Clean met Unique types. Je kan meer vinden over Monads in dit stukje:

What the hell are Monads?

Hier is ook sectie met wat monad links:

http://www.haskell.org/bookshelf/

Is de syntax van Clean en Haskell ongeveer gelijk, of is dat helemaal verschillend?

Na wat ik gezien heb van Clean geloof ik dat ze erg veel op elkaar lijken, maar ik heb dus nooit echt met Clean gewerkt.

[Nikel]

1. Wat zjin side-effects bij een functie?

2. Hier aan de UT hebben ze sinds dit jaar functioneel programmeren uit het curriculum van technische informatica gegooid, dat doet vermoeden dat het weinig in de buitenwereld wordt toegepast.

Ik heb zelf dit jaar Miranda gehad, maar dan alleen het schrijven van conrete functies/programma's zonder theorie er om heen.

Het lijkt er op dat er hier nogal een verschil is tussen echte informatica en technische informatica (?).

[mbravenboer]

Nikel: Wat zjin side-effects bij een functie?

Tja, precies wat het zegt eigenlijk... In een functionele taal stop je argumenten in een functie en er komt een resultaat uit. Dat is alles. Je krijgt bij een functie-aanroep met bepaalde argumenten dus altijd hetzelfde resultaat terug. In imperatieve talen heb je wijzigbare variabelen (in functionele talen zijn variabelen immutable) en heb je vaak een state. Het komt er op neer dat een methode aanroep dan de state ook kan aanpassen en bij dezelfde aanroep verschillende resultaten op kan leveren omdat de state anders is.

Hier aan de UT hebben ze sinds dit jaar functioneel programmeren uit het curriculum van technische informatica gegooid, dat doet vermoeden dat het weinig in de buitenwereld wordt toegepast.

Dat is wel jammer. Ik denk dat met de voortgang van de informatica steeds meer declaratieve en special purpose languages gebruikt zullen gaan worden. Imperatieve talen zullen in de toekomst wellicht zelfs zowat een rol krijgen als ASM nu speelt .

Het lijkt er op dat er hier nogal een verschil is tussen echte informatica en technische informatica (?).

Het verschil tussen echte informatica en technische informatica vind ik nogal onduidelijk. Ik zou eigenlijk ook niet weten waarom een van deze varianten eerder FP in het curriculum zou moeten hebben...

[Verwijderd]

Nikel : Het lijkt er op dat er hier nogal een verschil is tussen echte informatica en technische informatica (?).

Dit lijkt me ook logisch, er is immers altijd een enorm verschil tussen theorie en praktijk, en ik denk dat je Haskell maar onder het kopje 'theorie' moet plaatsen. Want het idee erachter is zeer nuttig en verhelderend, maar in de praktijk is het niet echt spetterend... maar wel een geinig taaltje

[Verwijderd]

nou ik ben blij dat er bij mijn studie maar 1 trimester aan vuil werd gemaakt want ik doe veel liever iets praktisch als C/java

[Nikel]

[b]Op zondag 09 december 2001 20:24 schreef mbravenboer het volgendeTja, precies wat het zegt eigenlijk... In een functionele taal stop je argumenten in een functie en er komt een resultaat uit. Dat is alles. Je krijgt bij een functie-aanroep met bepaalde argumenten dus altijd hetzelfde resultaat terug. In imperatieve talen heb je wijzigbare variabelen (in functionele talen zijn variabelen immutable) en heb je vaak een state. Het komt er op neer dat een methode aanroep dan de state ook kan aanpassen en bij dezelfde aanroep verschillende resultaten op kan leveren omdat de state anders is.

Dat dacht ik zelf ook al.

Dat is wel jammer. Ik denk dat met de voortgang van de informatica steeds meer declaratieve en special purpose languages gebruikt zullen gaan worden. Imperatieve talen zullen in de toekomst wellicht zelfs zowat een rol krijgen als ASM nu speelt .

Ik zou een beetje oppassen met dat soort uitspraken . Maar als de huidige "lijn" zich doorzet heb je wel gelijk. Ik zou denken dat er ergens wel een evenwicht bereikt wordt, want elke asm/imperatieve/wat dan ook laag moet nog wel gebouwd worden, en hoe meer lagen je op elkaar stapeld, hoe meer mensen er dus ook nodig zijn voor dat totaal.

Het verschil tussen echte informatica en technische informatica vind ik nogal onduidelijk. Ik zou eigenlijk ook niet weten waarom een van deze varianten eerder FP in het curriculum zou moeten hebben...

Volgens mij is het zo dat het ipv technische inf ook toegepaste inf had kunnen heten, en volgens Utwente filosofie komt daar tegenwoordig bijvoorbeeld ook management bij, ten koste van de theorie achter hetgeen je aan het doen bent. Ik zou zeggen dat gewone inf meer theorie gericht is en technische inf meer praktijk gericht. Als ik nu 6 vwo-er was geweest zou ik denk ik eerder voor gewone inf kiezen, omdat ik liever meer weet dan van grotere waarde voor het bedrijfsleven ben. Maar ik weet er eigenlijk niet genoeg van om uitspraken met enige waarde te kunnen doen.

[mbravenboer]

Nikel: Ik zou een beetje oppassen met dat soort uitspraken .

Er stond ook niet voor niets een knip-oog achter . Toch denk ik dat er wel een grote kern van waarheid in zit. Computer-power wordt steeds minder een probleem (naar mijn mening loopt de hardware tegenwoordig behoorlijk op de software vooruit) en men verwacht daarbij ook steeds grotere en geavanceerdere applicaties. Deze kunnen gewoon niet allemaal in imperatieve talen ontwikkeld worden. Je ziet de beweging al een beetje komen: steeds meer compilers kiezen voor C als target (soort intermediate representation). De C compiler kan zich daarna verder bezighouden met de rest van het probleem. Het heeft zo bijvoorbeeld ook meer nut om extreem veel aandacht te besteden aan optimalisaties in componenten (als de C compiler). Declaratieve, special-purpose domain-specific languages bieden precies wat er in de toekomst nodig is: overzichtelijkheid, compacte code, mogelijkheden tot verificatie en optimalisatie enz.

Volgens mij is het zo dat het ipv technische inf ook toegepaste inf had kunnen heten, en volgens Utwente filosofie komt daar tegenwoordig bijvoorbeeld ook management bij

Daar heb je wellicht wel aan aardig onderscheid ja. Maar goed, in principe is de theoretische informatica natuurlijk niet just for the fun bezig . Het is tenslotte toch het doel om research-projecten en ontwikkelde technologien naar de praktijk, de toepassingen te brengen .