Microsoft ontwikkelt F# taal voor compilerbouw

Ik moet niet te veel tegengas meer geven. Je schijnt beter op de hoogte te zijn van functionele programmeertalen dan ik.

Over traagheid gesproken... ooit gehoord van Unreal Tournament geschreven in een functionele programmeertaal ?? (ik geef toe dat ik dat bij VB, Java en .net ook nog nooit gehoord heb)

Recursie is over het algemeen effectief en een recursieve datastructuur als een Linked List eist vaak een recursief pattroon. Echter als er 'nutteloze' recursie gebruikt wordt (ipv maps bijv) dan is dat toch de schuld van de programmeur?

Als een programmeur expliciet recursie (ipv bv een stack) gebruikt terwijl het wel anders kan is het de fout van de programmeur, maar als een programmeertaal het schrijven van recursie zo eenvoudigt maakt en de taal er zelf op gebaseerd is lijkt het mij de fout van de taal. (Helaas ken ik de details niet van de implementatie van haskell).

maar als een programmeertaal het schrijven van recursie zo eenvoudigt maakt en de taal er zelf op gebaseerd is lijkt het mij de fout van de taal

In het commentaar dat je in deze thread uit, spreek je over functionele programmeertalen met een stelligheid die lijkt te impliceren dat je weet waar je het over hebt. Welnu het spijt me het je te moeten mededelen, maar dat is dus niet het geval!

Ook nu weer doe je een aanname die niet op feiten (kennis van zaken) is gebasseerd. Heb je wel eens van 'tail recursion' gehoord? Zo niet, dan zou ik maar snel eens zoeken op Google en bijlezen voordat je nog meer ongefundeerde opmerkingen maakt.

BTW d'r is geen taal die voor alle doeleinde geschikt is. Een kernel scheduler zou ik niet direct in Java schrijven, net zo min als dat ik Unreal in een functionele programmeertaal zou schrijven. Elke klasse van talen heeft zo z'n toepassinggebied en bij elk toepassingsgebied is het altijd een afweging tussen de productiviteit die de programmeur kan behalen vs de executie snelheid van het uiteindelijk resultaat.

Pure en lazy funtionele programmeertalen betalen een prijs voor de hoge mate van expressiviteit die zij bieden. Doch deze is lang niet zo erg als dat jij doet voorkomen.

doeleinden:

Kun jij mij dan een doel geven van een functionele programmeertaal waarbij dus duidelijk is dat we deze talen verder zullen moeten ontwikkelen? Als je dan een doel hebt bedacht kun je mij dan vertellen waar ik een open-source project (ik neem aan dat het dat is) kan vinden die dat doel tracht te bereiken. En met een project doel ik op een stukje code dat meer dan twee paginas vult.


tail recursion:

Je kunt er allemaal moeilijke termen bij halen en ik heb het eventjes nagelezen op google. En tail recursion is recursion in een uitzonderingssituatie. Wordt gebruikt op plekken waar eigenlijk ook iteratie gebruikt had kunnen worden. Nu is het de grap dat de jongens van de compiler-bouwers er schijnbaar veel over hebben nagedacht (ze hadden zelf namenlijk ook wel door dat recursie niet de oplossing is) en een plak en lijm middel bedacht hebben voor bepaalde situaties. Oke is een beetje overdreven; je zou het ook anders kunnen zien dankzij tail-recursion kun je nu ook recursie gebruiken op plekken waar het eigenlijk niet nodig is, maar je hoeft er als programmeur niet meer over te tobben. Het is maar hoe je er tegen aankijkt

Kun jij mij dan een doel geven van een functionele programmeertaal waarbij dus duidelijk is dat we deze talen verder zullen moeten ontwikkelen?

Door de 'referential intergrity' van pure functionele programmeertalen is hergebruik van code een stuk minder probleematisch dan bij imperatieve talen. Daarnaast bieden functionele talen in het algemeen (niet alleen de pure) een grotere mate expressiviteit, hetgeen de productiviteit van programmeurs ten goede komt.

Vanuit een academisch oogpunt zijn functionele talen ook erg interessant. Deze talen zijn namelijk een stuk complexer om te implementeren dan de imperatieve talen en hebben zodoende de compiler technologie een stuk verbeterd. Dit komt ook de imperatieve talen ten goede. Dat jij schijnbaar geen nut ziet in functionele programmeertalen wil dus nog niet zeggen dat we de ontwikkeling ervan maar stop moeten zetten; dat zou van grote naiviteit getuigen.

Als je dan een doel hebt bedacht kun je mij dan vertellen waar ik een open-source project (ik neem aan dat het dat is) kan vinden die dat doel tracht te bereiken

Daar jij zojuist impliciet hebt aangegeven Google te kunnen gebruiken, ga ik je dat werk echt niet uit handen nemen. Enfin, veel compilers voor functionele talen zijn zelf in een functionele taal geschreven. De Clean 2.0 compiler is geschreven in Clean, The Glasgow Haskell Compiler is geschreven in Haskell, de Ocaml compiler is geschreven in Ocaml, etc, etc. Mocht je op zoek zijn naar een goede Bayesian spam filter, zoek dan maar eens naar SpamOracle, geschreven in jawel Ocaml. Wel eens gehoord van Emacs? Grotendeel geschreven in een Lisp variant. Wel eens gehoord Erlang? Het is een functionele programeertaal ontwikkelt door Ericsson die in een deel van hun producten wordt gebruikt. Ergens (oefening voor de lezer ) is er ook een webserver, geschreven in Erlang, te vinden. Enfin ik denk dat dat wel genoeg voorbeelden zijn; zoek en gij zult vinden.

Je kunt er allemaal moeilijke termen bij halen

'Tail recursion' is nou niet bepaald een moeilijke term; zeker niet voor iemand die enigzins verstand heeft van functionele programmeertalen of claimt er mee gewerkt te hebben!.

ze hadden zelf namenlijk ook wel door dat recursie niet de oplossing is) en een plak en lijm middel bedacht hebben voor bepaalde situaties

Nogmaals je slaat een toon aan alsof je weet waarover je praat, maar je slaat de plank telkens compleet mis. Ik zou zeggen pak er eens lekker een boek over functionele programmeertalen bij, installeer Hugs nog maar eens een keer, ga er serieus mee aan de slag en hopelijk kan je dan iets zinnigs over functionele programmeertalen schrijven.

Dit wordt vermoeiend

Ik vind het heel mooi dat Haskell in Haskell is geschreven en Ocaml in Ocaml, maar C/C++ is in de meeste gevallen ook in C/C++ geschreven. Dus dit is echt een waardeloos argument om het nut van functionele talen te bewijzen. Ik weet dat het schrijven van compilers een complexe taak is. En ik kan me dus goed voorstellen dat functionele talen zeer geschikt zijn voor het schrijven van compilers. Helaas is het volgens mij zo dat de meest gebruikte compilers uiteindelijk handgeschreven compilers zijn. Het lijkt allemaal wel mooi om daar hogere talen voor te schrijven en Lex & Yacc zijn ook hele mooie tools, maar een handgeschreven compiler is vaak velen malen sneller.

Ergens (oefening voor de lezer ) is er ook een webserver, geschreven in Erlang, te vinden.

Apache doet zijn werk prima .. ik ken echt niemand die een webserver in Erlang heeft draaien. Laat staan dat ik Erlang zelf ken.

Nogmaals je slaat een toon aan alsof je weet waarover je praat, maar je slaat de plank telkens compleet mis. Ik zou zeggen pak er eens lekker een boek over functionele programmeertalen bij, installeer Hugs nog maar eens een keer, ga er serieus mee aan de slag en hopelijk kan je dan iets zinnigs over functionele programmeertalen schrijven.

Ten eerste ontwijk je mijn reactie. Ten tweede beweer je dat ik absoluut niet weet waar ik het over heb en volgens mij sla jij hier de plank mis. En als laatste probeer je, door te beweren dat je er meer van weet dan ik (waar ik ook niet aan twijfel) en dat op een vernederende mannier brengt, mijn punten te ontkrachten. Dit is een beetje een rare mannier van handelen. Het lijkt wel alsof je je blind staart op de "voordelen" maar de NADELEN niet wilt zien of wilt horen.

T'zijn idd goede benchmarks voor Ocaml, Java moet het flink afweten... kun je mij ook een link versieren met daarop een programma geschreven in Ocaml die een beetje groter is dan 1 pagina?

Dit is niet negatief bedoelt ... ik ben onder de indruk ... maar voor ik me ergens in ga verdiepen wil ik graag weten of er met een taal overzichtelijk in geprogrammeerd kan worden. En hoe groter een stuk code hoe beter het bewijst dat het overzichtelijk is (aaaj is een gevaarlijke uitspraak).

- je verwijdert je meer en meer van de oplossing ? juist niet !! in een taal als clean of prolog houdt je je juist ALLEEN maar bezig met het oplossen of op laten lossen van een probleem door je programma. dat is juist het prachtige van deze talen.

Ik denk dat hij bedoelt dat je je meer verwijdert van het probleemdomein. Wel kom je dichter bij het oplossingsdomein, maar dat is misschien juist wel het gevaar...

Volgens mij is prolog geen functionele programmeertaal ... ik dacht nog altijd dat het een logische programmeertaal is/was ..

Jawel dus ... een taal genaamd Hugs ... was erg spannend.

Nee, want C++ was alweer twee keer beter dan C, en C# (zie dit maar als vier plusjes) is dus weer twee keer beter dan C++ en dus vier keer beter dan C.

Yes, SQL is sometimes pronounced "sequel," but mostly by people who have experience only with Microsoft's database system SQL Server, usually pronounced "sequel-server," which is one of the most commonly used database systems today. The more accepted pronunciation is "ess cue ell," in which each letter is spoken separately. A few people, for whatever reason, pronounce it "squeal" or "squirrel" but this is rare.

msdn.microsoft.com/library/en-us/odbc/htm/odch02pr_1.asp?frame=true

Of hoe Microsoft zelf aangeeft dat ze 'es ku el' (het begint hier op Klingon te lijken ) zelf leuker vinden. 't Is dus een kwestie van smaak.

Yoy say 'potaatow' I say 'potaytow'

Toen SQL ontwikkeld werd heette het: Structured English Query Language, wat afgekort werd naar SEQUEL. Later kwamen ze er echter achter dat de naam SEQUEL al een geregistreerde merknaam was, en toen hebben ze het omgedoopt naar SQL.

C# was toch de Microsoft vervanger van J#, wat weer de vervanger was van Java