Microsoft ontwikkelt F# taal voor compilerbouw

Microsoft is bezig met het ontwikkelen van een eigen versie van een meta language (ML) genaamd F# meldt Internetnews. Een meta language is een taal waarin onder andere compilers geschreven worden die broncode om kunnen zetten naar leesbare computercode. Microsoft wil graag een ML ontwikkelen om de eigen .NET-talen te verbeteren. Op dit moment is de ondersteuning voor onder andere subtyping en overloading niet volledig in de gebruikte ML. Ook zijn er volgens Microsoft te weinig mogelijkheden om de meta language uit te breiden. F# zou deze problemen op moeten lossen en de extra features toevoegen die Microsoft graag ziet.

Binnen de programmeurs-community is niet iedereen blij met deze stap van Microsoft. Verschillende programmeurs zien dit als de zoveelste poging van het bedrijf om van een eigen formaat een standaard te maken. Zij zijn namelijk bang dat Microsoft scholen zal pushen om studenten te leren werken met F#. Anderen zien dit weer anders en vinden dat dit de vrijheid is die elk ontwikkelbedrijf heeft om een eigen product beter te maken. Dit laatste hebben andere bedrijven namelijk ook wel gedaan; bijvoorbeeld SAP dat eigen classes heeft toegevoegd aan JSP. Ook wordt er gemeld dat het bedrijf uit Redmond vaker projecten is begonnen die uiteindelijk in de prullenbak eindigden. Het artikel sluit af met een opmerking over een ander onderzoeksproject van Microsoft, X#:

F# isn't the only language Microsoft is working on, although details about an "X#" are rather murky. X# is rumored to be a language focused on more intelligent processing of things like XML documents, much like ClearMethods' Water language, but there have been denials that the company is working on this.

Reacties (55)

F# ML? Volgens mij is F# eerder een 'verandering' van OCaML (ook een ML ja )

F# is een .NET implementatie van een Functionele programmeertaal ( zie voor intro hierover : http://gathering.tweakers.net/forum/list_messages/751361 ), wat een hele mooie aanvulling zou zijn op de louter imperatieve gerichte programmeer talen die .NET nu inhoud.

Hierdoor zou je kunnen kiezen voor mooie en bewijsbare implementaties van algoritmes in F# en de GUI of andere delen in C# kunnen coden. Vervolgens build alles naar IL en heb je alle voordelen van beide werelden

Even ter referentie, enkele voordelen van functionele talen tov iperatieve talen:
- Lazy Evaluation, waardoor het werken met (abstracte) oneindige data mogelijk is
- Pure, geen side effects mogelijk, dus de functie is wiskundig te bewijzen
- Pattern matching en het kinderlijk eenvoudig implementeren van recursieve functies.
- Functies die functies als parameter aan kunnen nemen.

Relevante links:
Microsoft pagina van F# http://research.microsoft.com/projects/ilx/fsharp.htm
Discussie @ GoT http://gathering.tweakers.net/forum/list_messages/760338

En nu de nadelen :

- Het is ongeloofelijk traag
- Functionele programmas zijn tov de huidige hardware te vergelijken met water en vuur.
- Op de meest nutteloze plekken wordt recursie gebruikt
- mbv een functionele programmeertaal verwijder je jezelf meer en meer van de oplossing ... uiteindelijk ben je alleen nog maar bezig met bewijzen en bewijs je dat je vorige bewijs met het zonet geleverde bewijs hebt bewezen, om dit bewijs te leveren heb je echter een vervolg bewijs nodig

En nu de nadelen :

Die zijn er natuurlijk ook

- Het is ongeloofelijk traag

Ik zie dat je hieronder spreekt over de traagheid van je ervaring met Haskell / Hugs. Zoals je misschien weet is Hugs geinterpeteerd, wat bijna inherent staat aan beretraag. Probeer eens de Glasgow Haskell Compiler. Deze optimaliseerd erg sterk en is niet traag te noemen in de code werlke deze uitspuugt.
http://www.haskell.org/ghc/

Maak anders eens een algortime in Haskell, laat GHC dit compileren naar C code en ga dit dan vergelijken met je eigen algoritme. Ik vermoed dat er niet echt veel verschil in O in gaat zitten

- Functionele programmas zijn tov de huidige hardware te vergelijken met water en vuur.

Hoezo? Het kijken naar lijsten is de manier van het bekijken van een linked list met pointermanipulatie. Het bekijken van een recursieve (lazy) functie is een gewone goto. Het bekijken van een pattern match is ook te gebruiken in imperatieve OO talen dmv Visitors. Ik zie princiepes die zo te vertalen zijn. Waar zitten de verschillen dan precies?

- Op de meest nutteloze plekken wordt recursie gebruikt

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?

- mbv een functionele programmeertaal verwijder je jezelf meer en meer van de oplossing ... uiteindelijk ben je alleen nog maar bezig met bewijzen en bewijs je dat je vorige bewijs met het zonet geleverde bewijs hebt bewezen, om dit bewijs te leveren heb je echter een vervolg bewijs nodig

Als ik het goed begrijp heb je het hier over een overdaad aan abstractie? Mja, sorry, maar dat vind ik toch echt een beperking van de programmeur ipv de programeertaal. Abstractie is juist ontzettend belangrijk voor het schrijven van herbruikbare code.
Ik ben het echter wel met je eens dat het OO abstractieniveau dichter bij de programmeur z'n beleving ligt, maar na een bepaalde periode ga je 'functioneel denken' en dan denk je er niet eens meer over na

Kortom functionele talen hebben inderdaad nadelen (zo is lazyness niet altijd goed), maar als je in een combinatie gaat kijken met andere .NET talen en dit laat mixen, kan ik niet anders dan voordelen zien

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.

Ongelooflijk traag?
Ocaml komt er juist erg goed uit in de Great Computer Language Shootout (http://www.bagley.org/~doug/shootout/).
Zelf zou ik al jaren eens met Ocaml aan de slag willen, maar we zitten hier een beetje vast in Java, een soort OO-taal voor dummies
Lijkt me een verfrissende wending na Basic, assembler, Fortran, Algol68, Pascal, C, C++ en Java...

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).

wat een onzin, heb je ooit een dergelijke taal gebruikt ? i doubt it

Euhm ja .... Haskell/Hugs ... ik zeg ook niet dat functionele programmeertalen geen toekomst hebben. Ik zeg alleen dat de huidige hardware er nog lang niet klaar voor is en ik betwijfel dat het dat wel is over vijf of tien jaar (alhoewel over tien jaar is natuurlijk moeilijk inschatten). Bovendien blijft het een feit dat je met dergelijke programmeertalen goed moet opletten wat je doet. Je geschreven programmas zijn weliswaar "Pure" zoals glimi meldt, maar vaak wordt door een verkeerde gedachten gang bij het opzetten van je functies, zware recursie gebruikt. En dit laatste komt de performance van je programma dan natuurlijk niet ten goede.

Mijn punt was dus alleen dat de voordelen die Glimi noemde in sommige gevallen ook een nadeel kunnen zijn

uit je lijstje van 4 punten waarom 't kut zou zijn

- traag ? visual basic is ook traag... ik heb overigens veel met clean gewerkt en sta er van te kijken hoe snel 't nog is gezien de opzet.. object oriented programmeren is "traag".. is dat een reden 't niet te doen ? nee, tuurlijk niet.. snelheid is bij 't gebruik van functionele talen echt ondergeschikt.

- kvind dat wel meevallen over je water/vuur vergelijking.. een functionele taal is net zo iteratief als iedere taal.

- nutteloos niet, vaak is 't bijzonder nuttig.. als 't nutteloos is moet je 't niet doen (dan was 't blijkbaar niet nuttig )

- 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.

- 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 ..

overigens is de labda calculus wel zodanig abstract dat je eigenlijk niet weet waar je mee bezig bent. (maw je berekent iets maar je weet niet waarvoor)

DikkeDouwe heeft zeker nooit in een functionele taal geprogrammeerd? Tjezus, wat een onzin!

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

- Lazy Evaluation, waardoor het werken met (abstracte) oneindige data mogelijk is
- Pure, geen side effects mogelijk, dus de functie is wiskundig te bewijzen

Twee eigenschappen die de ML dialecten niet eigen zijn! Clean en Haskell zijn daarentegen wel puur en maken gebruik van lazy evaluation. Clean is trouwens ook nog eens van Nederlandse makelij en behoorlijk snel!

Clean: http://www.cs.kun.nl/~clean

Naar analogie van het Nederlandse hekje spreek ik een # wel eens uit als gate. Zo is Seagate dus niet alleen een harddiskfabrikant maar ook de taal C#.
Dit F# is dus F-gate en dat heeft wel wat weg van F-side...
Verder zie ik nog een plaatje van golven waar dan Water bij staat... Krijgen we nu ook Water#?

Ik dacht dat "#" uitgesproken werd als "hash".
hoe kom ik daar dan weer bij...... ergens gelezen dan denk ik.

Voor het # teken kom je verschillende aanduidingen tegen. Hash en pound zijn beide termen die voorkomen. Ik meen afkomstig als benaming van de overeenkomstige toets op de telefoon. De sharp term die hier wordt toegepast komt uit de muziek, waar dit het teken is voor een zogenaamde 'mol', hetgeen een verhoogde noot aangeeft.

Laten we het maar houden op een kruis. Een mol verlaagt een noot waar die voor staat met een halve toon. Een kruis zorgt ervoor dat het een halve toon hoger wordt.

Daarmee zou je C# dus ook kunnen zien als C maar dan net de helft beter.

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.

Ze spreken het uit als "Sharp" omdat ze ook al C# hebben en ze moeten wel een beetje consistent blijven met uitspraak. En C-Sharp heet zo omdat MS niet helemaal blij is met de naam C hash

Bij Microsoft hebben ze wel meer vreemde uitspraak dingetjes. SQL = Sequel, # = sharp.

Sequel is de officiele verkorte uitspraak van SQL. De uitspraak Es Kuu El wordt voornamelijk gebruikt door Europeanen. Het gebeurt zelfs vaak genoeg dat als ik het over siekwel heb dat er een paar dba's zijn die geen idee hebben waarover ik het heb.

Tweakert heeft volledig gelijk! Een beetje muziekkennis is nooit weg

OnT: Ik vind het wel interessant dat Microsoft een taal ontwikkelt die het toelaat om uitbreidingen te knopen aan hun .NET verhaal en dat ze daarbij even losjes aangeven dat hun taal a) niet volledig is en b) wel degelijk voor verbetering vatbaar is en c) dat er misschien anderen zijn die het voor hun zouden kunnen doen (lees: jij ).

Het is dus wachten op het eerste OS dat op of met behulp van F# zal geschreven zijn

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.

De Sequal van SQL komt omdat SQL vroeger Sequal werd genoemd, niet zozeer bij MS maar ook bij IBM. Het heeft gewoon met de standaard te maken. En een # spreek je gewoon uit als sharp, daar is ook niks raars aan, in de muziekwereld gebruik je die dingen dagelijks en daar heten ze ook sharps.

hoe spreek je die # uit?

Een # wordt uitgesproken als 'sharp'. In dit geval wordt het dus F-sharp.

Wat weer komt van C#, waarbij die 'sharp' bestaat uit het op elkaar tekenen van de twee plusjes van C++.
Ze wilden het niet C+++ noemen.

'sharp' (#) en 'flat' (b) zijn muziektermen die aangeven dat je een toon moet verhogen dan wel verlagen met een halve toon.

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

in het nederlands: hekje. C-hekje, F-hekje, X-hekje

Tssss, kijk bijna iedereen negatief zijn dan.
Wat hypocriet.

Microsoft staat er wel om bekend dat ze degelijke en zelfs goede talen ontwikkelen.
Meer dan de helft blaft Microsoft hierop af, maar ondertussen wel coderen met hun C/C++/C#/C64.
Neem C++, dat is echt wel een goede taal.
En ook al is C# een ripp-off van Java, toch is het sneller dan Java en intuitiever.

Ik heb zo het gevoel dat het gros hier niet objectief is en Microsoft afblaft om het afblaffen.
Populair meeblaffen met de kudde/massa.

Give me a break...

Microsoft staat er wel om bekend dat ze degelijke en zelfs goede talen ontwikkelen.
Meer dan de helft blaft Microsoft hierop af, maar ondertussen wel coderen met hun C/C++/C#/C64.

C is ontwikkeld door Ritchie en Kernighan van destijds AT&T (+ ANSI/ISO standaard)
C++ is ontwikkeld door Bjarne Stroustrup, die iig niet bij Microsoft werkt (+ ANSI/ISO standaard)
C# is wel ontwikkeld door Microsoft.

Dat Microsoft compilers maakt voor een taal, wil niet zeggen dat de taal van hun is? Ander hebben Borland, Intel en GNU ook C++ ontwikkeld

Ik heb een beetje het gevoel dat je totaal geen idee hebt waar je over praat

Ik weet niet op basis van welke reacties jij nu vindt dat Microsoft onterecht wordt aangevallen, ik lees ze niet. C++ is geen taal van Microsoft, C++ bestaat al veel langer, en kent vele (niet) standaarden.

De discussie hierboven gaat over het vermeende performance verschil tussen functionele talen en imperatieve talen in het algemeen. Aangezien dit de eerste functionele taal van Microsoft gaat worden kan die discussie dus niet negatief tov Microsoft gezien worden.

Ik herken de discussie wel, maar ik weet uit eigen ervaring dat het meer van het probleem afhangt welk paradigma de mooiste oplossing kan bieden. Problemen die erg wiskundig zijn en goed geformaliseerd kunnen worden, maar erg complex zijn, zijn vaak makkelijker en efficiënter op te lossen in functionele talen. Maar GUI code, simpele bedrijfsregels en database interactie zijn dingen die in imperatieve talen makkelijker zijn op te lossen.

Het is dus maar net wat je wil doen. Helaas wordt de discussie functioneel<->imperatief vaak uitgevochten met technologische argumenten, ik vind het zelf veel interessanter om te bekijken waarom de twee paradigma's nog steeds zo sterk gescheiden zijn. Misschien dat dit nieuwe initiatief van Microsoft toch wat meer een best-of-both-worlds oplossing kan bieden. Dat zou ik heel positief vinden.

Ik ben geen Progameur noch whizzkid.
Als MS dit project doorzet, zal ik als consument er iets van ondervinden?
dat alle programma's van MS afkomstig moeten zijn zijn ofzo?
of een verbetering voor windows en omgeving?

no lameing intended ^_^;

Als MS dit project doorzet, zal ik als consument er iets van ondervinden?

Merk jij überhaupt iets van een onderliggende programmeertaal in een applicatie? Ik hoop het eigenlijk niet voor je _{En laten we Swing hier es buiten laten}

Het antwoord is Nee. Vooral omdat F# gericht is op de ontwikkeling van compilers binnen het .NET framework, zal de kans van een desktop applicatie in F# erg klein zijn

De ontwikkelaars hebben nu al iets van: F### IT!!

Is misschien leuk, maar voorlopig is er nog helemaal niks. Alleen omdat er het stempeltje 'Microsoft' op staat wordt het hier genoemd, de hype-engine is al weer in volle gang.

Hoe zit het met al die andere talen die bedacht worden? Elke twee maanden komt er wel weer een andere taal op de 'markt'. Waarom worden die nooit genoemd? Omdat er geen stempeltje 'Microsoft' op staat?

wat voor iets moet ik me bij F# voorstellen ? een declaratieve taal zoals prolog / clean / haskell of zo ?

Zie Glimi, ja dus

Interessant? Iemand stelt een vraag die er boven al is beantwoord en dat is dan interessant? Het is een vreemde wereld!