Microsoft stopt functionele taal F# in Visual Studio

Microsoft heeft enkele dagen geleden bekendgemaakt dat de programmeertaal F# de campus van Microsoft Research gaat verlaten en wordt opgenomen in Visual Studio. Informatieverwerking vindt in de taal plaats door het evalueren van functies.

Volgens Microsoft is de functionele taal F# - spreek uit als F sharp - bij uitstek geschikt voor financieel en wetenschappelijk rekenwerk. Microsoft hoopt dan ook dat de taal in de academische wereld voet aan de grond zal krijgen en daar de populariteit van het .Net-framework kan vergroten.

In procedurele talen zoals C++ en C# ligt de nadruk op het manipuleren van variabele gegevens, maar in functionele talen is dit het definiëren van functies, die voor het uitvoeren van berekeningen worden geëvalueerd. Functies kunnen functies als argument meekrijgen en ook functies retourneren. Een speciaal geval dat door F# wordt ondersteund, is het zogeheten 'currying'. Hierbij wordt een functie met meerdere argumenten getransformeerd tot een nieuwe functie waar het eerste argument ingebakken zit, die dan vervolgens de overgebleven argumenten voor zijn rekening kan nemen.

In C# was dit overigens al mogelijk via delegates, maar de ontwikkeling van C# was vanaf versie 2.0 dan ook deels geënt op het implementeren van functionele programmeertechnieken. De opname van F# in Visual Studio betekent dat dergelijke constructies, onder meer nuttig bij het programmeren met recursie, compacter en eleganter gebruikt kunnen worden. Andere voordelen van F# zijn lazy evaluation en metaprogrammeren - het schrijven van programma's die broncode als data beschouwen. De taal is volgens Microsoft bovendien goed toegerust voor het programmeren voor multicores.

F# begon als onderzoeksproject bij Microsoft Research in het Britse Cambridge. Een van de doelstellingen daarbij was het aantonen dat het .Net-framework geschikt is als platform waarin uiteenlopende programmeerparadigma's zich thuisvoelen. Eerder dit jaar voegde het softwarebedrijf al ondersteuning voor dynamische programmeertalen aan .Net toe. Microsoft heeft nog geen releasedatum gegeven voor de Visual Studio-release van F#. Teams van Microsoft Research en de Developer Divsion van het bedrijf werken op dit moment nog aan de integratie.

Reacties (68)

[johnbetonschaar]

Ik denk dat de toepassing voor deze taal beperkt zal blijven tot academische vingeroefeningetjes, en zeker niet om complete commerciele applicaties of whatever te maken. Volgens mij weet iedereen met ervaring met functionele talen hoe ontzettend irritant het is om oh zo vaak voorkomende constructies zinnig te programmeren in een functionele taal. Op papier kan het er allemaal heel elegant uitzien met het curryen, maar zo gauw je een real-world scenario implementeert ontstaat een onbegrijpelijke en onleesbare keten van functies die functies callen waardoor het overzicht volkomen kwijt is.

Volgens mij zijn er ook maar 2 generieke functionele talen die af en toe nog gebruikt worden, en dat zijn LISP en Scheme. Beiden alleen gebruikt op een heel smal toepassingsgebied.

[Reactie gewijzigd door johnbetonschaar op 23 juli 2024 09:01]

[jmzeeman]

Ik denk dat het inderdaad nooit voor volledige applicaties gebruikt zal worden. Maar doordat het .NET is zou het erg makkelijk moeten zijn om kleine functionele blokken en dergelijke in een C# applicatie te hangen. Dit zou F# wel een groot voordeel geven ten opzichte van andere functionele talen.
De leesbaarheid van F# is inderdaad niet echt goed. de F# code die ik tot nu toe gezien heb is lastig te lezen vooral omdat er veel korte keywords en veel operators gebruikt worden.

Hier twee (simpele) snippets uit het voorbeeld script van MS:

Maak een form:
let form2 = new Form(Visible=true, TopMost=true, Text="Hello WinForms!")

Twee integer Functies:
let inc x = x + 1
let rec fact n = if n=0 then 1 else n * fact (n-1)

[Reactie gewijzigd door jmzeeman op 23 juli 2024 09:01]

[Verwijderd]

Dat is nu juist de kracht van f#, het is niet alleen een functionele taal maar ondersteund ook object georienteerd en imperatief programmeren . Je kan dus alle drie de paradigma's door elkaar gebruiken.

[sirdupre]

Het ligt natuurlijk maar net aan het domein. Als ik moet kiezen tussen het schrijven van een parser in een imperatieve taal of in Haskell, dan kies ik toch echt wel voor het laatste. Door currying en lazy evaluation kan je extreem elegante parsers schrijven (met zogenaamde parser combinators). Sowieso zijn functionele talen tegenwoordig best wel belangrijk bij de ontwikkeling van nieuwe talen, ik heb een jaartje geleden gewerkt met Attribute Grammars (een metataaltje dat weer haskell code als output heeft, uiteraard is de AG-parser ook in haskell geschreven) waarmee je echt ongelofelijk kort en bondig en elegant (als je eenmaal de syntax onder de knie hebt) informatie uit (parse) tree's kunt halen. Je kunt in circa 500 regels code een complete compiler maken die een taaltje met basisfunctionaliteiten als variabele assignment, functie aanroepen en dergelijke naar een stackmachine assembly omzet. Ik denk dat je in een imperatieve taal blij mag zijn als je in 500 regels je parse tree datastructuur en een parser naar die datastructuur geschreven hebt.

Als het echter gaat om GUI's programmeren of een efficient optimalisatie algoritme pak ik toch liever iets als java. Het kán wel in Haskell, maar het is inderdaad gewoon niet heel fijn, of het heeft weinig meerwaarde.

Wat nu juist het interessante is aan F#, is dat je door het .NET framework in principe een functionele taal en een imperatieve taal kunt mengen. Als je dus een stuk software aan het maken bent waar je ineens een parser wilt gebruiken voor een onderdeel, kan het dus heel fijn zijn als je dat onderdeel in een functionele taal kunt schrijven. Sowieso zijn manipulaties op lijsten en dergelijke erg fijn om te schrijven in functionele talen (met behulp van iets als map en foldr), waardoor het ook aantrekkelijk kan zijn om een hulplibrary in een functionele taal naast je imperatieve project te programmeren.

[Reactie gewijzigd door sirdupre op 23 juli 2024 09:01]

[jmzeeman]

Volgens mij is F# al gereleased voor Visual studio... Het draait bij mij in iedergeval er al wel binnen inclusief intellisense e.d.. Voor bamsebjorn, het is nu al gratis met shared source licence te downloaden van: http://research.microsoft.com/fsharp/release.aspx
zie de zelfde site voor meer informatie over F#. Ik heb nog niet echt tijd/zin gehad om het uit te proberen maar vooral de code generatie e.d. ben ik erg benieuwd naar, in C# heb je ook wel de mogelijk heid om IL code te genereren (via System.Reflection.Emit) maar dat is nou niet echt prettig werken. Waar ik het nodig had kom je dan al snel op lelijke oplosingen uit waarbij je een gedeelte van een klasse genereert en het algemene gedeelte als aparte klasse met static methods of als member object er bij in hangt.

p.s.
Toch wel jammer dat op een artikel over F# er maar ongeveer 1/3 daadwerkelijk over F# of een gerelateerd onderwerp gaan, 2/3 is weer MS is evil geschreeuw en ander offtopic geblaat dat er niks mee te maken heeft.

[Reactie gewijzigd door jmzeeman op 23 juli 2024 09:01]

[AlphaRomeo]

p.s.
Toch wel jammer dat op een artikel over F# er maar ongeveer 1/3 daadwerkelijk over F# of een gerelateerd onderwerp gaan, 2/3 is weer MS is evil geschreeuw en ander offtopic geblaat dat er niks mee te maken heeft.

Inderdaad, en dan vooral uit de monden van mensen die het hele artikel niet begrijpen, geen programmeerervaring hebben, maar alleen MS en .NET zien en beginnen te blaten.

OT:
F# is een mooie ontwikkeling, afgaande op de bestaande .NET talen en het gemak van de IDE en documentatie, moet het goed mogelijk zijn om dit snel te leren. Ik wil me sowieso nog eens verdiepen in functioneel programmeren.

[Verwijderd]

Negatieve mode:
We gaan dit vast zien verschijnen in Excel sheets van vage managers / Senior-IT-Consultants. De managers en die andere groep zullen na veel gehannes een mega stylesheet gebouwd hebben die natuurlijk voor geen meter presteert. Dit is een groot nadeel van de functionele programmeertalen... het steed weer terugvallen in extreme recursie. Het Wonder-woord hier is dan weer wel: Lazy-evaluation. Bovendien zullen veel universiteiten dit onderwerp aanpakken om in den diepsten treuren dit voor te schotelen aan studenten (waar ik op zich niet persee tegen ben). Helaas dat veel studenten dan van de unie afkomen en helemaal ziek zijn van die F# en look-a-like talen, maar een gewoon echte programmeertaal niet goed beheersen. Voor de rest komt er zodra je het over functionele programmeertalen hebt altijd weer de term Kunstmatige Intelligente naar voren. Ik ben echter gewend dat intelligente dingen (bijv. mensen) dat dan wel uit zichzelf zijn en ik ze dus niet hoef te vertellen hoe ze intelligent moeten zijn, laat staan dat ik er een taal voor nodig heb.

Positievere mode:
Zover ik weet (ja het is alweer een hele tijd geleden) zijn objecten in functionele programmeertalen altijd final (erg praktisch bij multithreading). Bovendien was er iets met goede opsplitsbaarheid van de functies. Al met al lijkt het erop dat dergelijk talen beter zijn voorbereid op multi-threading. Nu Microsoft een variant heeft gebouwd en dat in de Microsoft-style oplevert (dus redelijk compleet/stabiel/gedocumenteerd) heeft de taal misschien de kans om zich echt te bewijzen.

[Jeanpaul145]

In procedurele talen zoals C++ en C# ligt de nadruk op het manipuleren van variabele gegevens...
C++ is niet per definitie een procedurele taal. C is een procedurele taal.
C++ is echter een multiparadigm taal volgens Bjorne Stroustrup (degene die hoofdverandwoordelijk was voor t ontwerp van de taal)

[Xellence]

De taal is laagdrempeliger dan BASIC. Wanneer de voorbeeldprogramma's bekijkt, zie dat de taal bijzonder compact én leesbaar is. Het woordje "LET" heb ik sinds juttemis niet meer gezien maar maakt de sourcecode wel heel goed leesbaar.

F# lijkt niet geheel hetzelfde als Basic, C# of dergelijke. Je hebt wel een nieuwe manier van denken nodig om hierin te programmeren. Niet perse moeilijker trouwens.

[martijnvanegdom]

Hebben je ooit functioneel geprogrammeerd? Ik durf je te beweren dat als een onderzoek zouden doen bij mensen die nog nooit geprogrameerd hebben en we laten de helft Basisc coden en de ander helft een functioneele taal als Haskell dat de Basic groep het makkelijker zal oppakken dan de Haskell groep..

En daar voor zijn een aantal redenen

1) Basic is een imperatieve taal en een computer (lees : cpu) is imperatief.

2) Het imperatieve denken sluit veel meer aan bij de denk wijze van een gemiddeld persoon, dus redeneren in de trant van als dit dan dat..

3) Een functionele taal vereist toch meer kennis van wat algorithmen zijn en wat functies zijn.. In een imperatieve taal kun je meer aanklooien

[OddesE]

Dat laatste wordt dan ook vaak als nadeel genoemd
Het schijnt zo te zijn dat je van een programma geschreven in een pure functionele taal vrij eenvoudig wiskundig de correctheid kan bewijzen, terwijl datzelfde voor imperatieve talen alleen met hele eenvoudige programma's kan. Maar het fijne weet ik daar niet van.

[elmuerte]

Niet een "nieuwe manier", maar een andere manier van denken. Functioneel programeren is al heel oud en word al veelvuldig gebruikt. Een echte nieuwe manier van programeren is Aspect Oriented Programming.

[Reactie gewijzigd door elmuerte op 23 juli 2024 09:01]

[Verwijderd]

@decape:

Dit is niets meer dan een compiler (en wat zut voor de IDE, dus code completion, help bestanden etc), het doet dus verder niet zoveel.

De programma's die je ermee maakt zullen gewoon in CIL zijn en dus op ieder .NET platform kunnen draaien.

Dat is nu juist de kracht van .NET, je kunt programmeren in de taal die je wil het resultaat is hetzelfde.

Om antwoord te geven op je vraag: Het is goed, het is nu aan de gebruikers om dit ook echt te gaan gebruiken, we hebben al vaker gezien dat als de userbase niet al te groot is Microsoft er weinig aan doet (logisch ook). Als er inderdaad vraag is naar deze taal dan zal de userbase vanzelf groeien en Microsoft er weer meer tijd in steken.

[Reactie gewijzigd door Verwijderd op 23 juli 2024 09:01]

[elmuerte]

Word het naar CIL gecompileerd? Of krijgt het een support library. Want ik heb mijn twijfels of het nuttig/wenselijk is om functionele programma code te vertalen naar statische code. Je verliest op dat moment namelijk redelijk want functionaliteit.

edit: Na wat onderzoek ben lijtk het er op dat F# een support library nodig heeft, maar ook dat er een groot deel zo veel mogelijk naar direct naar CIL gecompileerd word. Er word dus zo veel mogelijk gebruik gemaakt van strict typing, maar dynamic typing is nog steeds mogelijk.

[Reactie gewijzigd door elmuerte op 23 juli 2024 09:01]

[Verwijderd]

Je verliest op dat moment namelijk redelijk want functionaliteit.

Nee dus, want alle code wordt uiteindelijk toch vertaald (naar processor instructies). F# stelt de programmeur in staat om zijn ideeen op een zekere manier in code uit te drukken. Voor bepaalde procedures is functionele code makkelijker in staat dit tot uitdrukking (sneller, korter, duidelijker) te brengen dan bijvoorbeeld C#. Daar zit dus de winst voor de programmeur.

Het helpt dat de CLI al met functies als objecten kan omgaan (delegates) want anders zou de vertaling niet mogelijk zijn denk ik. Maar zolang F# het resultaat heeft dat de programmeur met zijn 3 regels code voor ogen had, wat in C# 20 regels zou kosten, dan is het niet erg dat het vertaald wordt naar CIL, zolang het maar lekker snel is.

[Verwijderd]

@decape:

Waarom haal je dat nu weer erbij?

Microsoft is net als ieder ander gezond bedrijf: Is er in de markt vraag naar iets dan ga je aan die vraag proberen te voldoen, op het moment dat er geen vraag meer naar is dan ga je er verder ook geen tijd in stoppen.

Als je dat niet doet dan ben je gewoon fout bezig.

Het is nu dus aan de gebruikers om F# te gaan gebruiken, doet men dat niet dan zal de taal niet verder doorontwikkeld worden en op termijn weer uit VS verdwijnen.

offtopic:
En hoezo als? Microsoft heeft merendeel van de markt in handen, Firefox is relatief gezien een veel kleinere speler al hangt dat erg van het marktsegment af

[Reactie gewijzigd door Verwijderd op 23 juli 2024 09:01]

[Verwijderd]

Dan gebruik je het toch vrolijk niet, in plaats van hier te gaan jammeren? Genoeg alternatieven, me dunkt.

[Hyronymus]

Tja, je kan ook zeggen dat de IT-sector het allemaal wel goed vindt, totdat de sector zelf alternatieven ontplooit. Ik vind het altijd zo slap geouwehoer als alleen MS de schuld krijgt. Als het gepeupel minder klapvee-gedrag had getoond was nu echt niet het meerendeel van de PC's van Windows voorzien. Maar de consument pioniert liever niet en kiest dus voor "dat wat de buurman ook heeft".

[Toolskyn]

Jammer genoeg misbruikt MS overal in de IT wereld zijn machtspositie om via kapotte "standaarden" het gebruik van deze alternatieven onmogelijk te maken.

Toch lijkt me dat in deze vrijwel onmogelijk om voor elkaar te krijgen. Tenzij Microsoft een manier vind om elke andere compiler verboden of zinloos te maken...

Daarbij zouden flink wat ontwikkelaars zich flink tegengewerkt voelen en zal het aandeel third party software voor Windows flink dalen, wat het Windows platform in het algemeen natuurlijk niet kan gebruiken. Het is dus daarnaast gewoonweg stom als Microsoft alleen het gebruik van zijn eigen producten zou willen.

En als laatste: zo kapot is .NET nu ook niet. Persoonlijk vind ik het een zeer goede ontwikkeling. Je kan er zo lang over praten als je wil, maar dat het .NET framework een krachtig product is valt lastig te ontkennen.

[Verwijderd]

@killercow en decape:
Dat heeft toch niks met F# te maken joh? Dat geklaag altijd op Microsoft, ondanks dat het vaak terecht is, heeft het zo vaak niets met het nieuwsbericht te maken. Je moet wel onderscheid kunnen maken, en positieve ontwikkelingen op hun waarde schatten.

[Reactie gewijzigd door Verwijderd op 23 juli 2024 09:01]

[Robtimus]

Hadden ze niet beter H# kunnen ontwikkelen - de .Net versie van Haskell? Dan hadden ze meteen een veel bredere userbase.

[Tukk]

Microsoft heeft slechte ervaringen met andermans talen in hun eigen omgeving, zie bijvoorbeeld Java dat ze net weer gedumpt hebben voor hun eigen taal (C#).

Hier hebben ze alle invloed op, iets wat al bestaat, incuis de aanhangers, zijn lastige mensen voor ze.

[elmuerte]

Hoe kom je daar bij. Microsoft past zoals gewoonlijk embrace and extend toe. Het heeft niks te maken met "slecht ervaringen" maar meer dat ze het op hun manier willen doen. En ze hebben geen zin in samenwerken met andere partijen om een gezamelijke standaard te ontwikkelen (leverd namelijk vertragingen op).

C# is gebasseerd op Java (en C++, maar omdat Java al gebasseerd is op C++ is het een beetje overbodig).
F# is gebasseerd op OCaml, sterker nog, volgens MS is F# en OCaml code enigzins compatible.

[Devata]

Het klopt dat Java is gebaseert op C++ maar C# is niet gebaseert op java hoor.. C# is gewoon gebaseert op C++ en lijkt oook veel meer op C++ dan op Java.

Zo is het bij Java zo dat je het compileert naar een tusseltaal (Java-Bit dacht ik) en die taal word weer geintrepeteert met software die voor ieder platform anders is zodat dat java tussesnaal (java-bit) universeel is.

C++ word gecompileert fhankelijk van eht systeem ent als C# dat is dus wat heel anders als Java en C# is dus ook duidelijk op C++ gebaseert en absoluut niet op Java ook al is Java ook op C++ gebaseert.

Wat ik me nu alleen afvraag is of ze het weer zo gaan doen dat ej al makkelijk met die F# een platformafhankelijke taal hebt..

Zoals je dat ziet bij C#.. nee je kunt met C# ook programmeren voor Linux enzmaar er zitten allerlij handige truckjes (in visual studio) erbij om C# een makkelijkere en snllere (te maken) taal dan C++ te maken.. maar gebruik je er eentje van dan ben je wel meteen platform afhankelijk.. voorbeeltje is zo'n form.. zo egmaakt bij C# en dus zalje eht je ook aanleren om te gebruiken, maar als dat er in zit kan eht dus wel alleen nog maar voor Windows worden gebruik en ik ben bang dat ze bij F# ook van die truckjes erin gaan duwen... (Al heb ik geen idee wat die F# precies in houd.. ben nu bezig emt C# en wil erna dingen gaan bijleren van C+ en me gaan aanleren voornamelijk C++ te gebruiken)

[praseodymium]

C# wordt toch echt gecompileerd naar MSIL, een intermediate language die door de .NET Just-in-time-compiler bij runtime wordt omgezet in machinetaal. Eigenlijk net als Java.

[OddesE]

Precies hetzelfde als Java inderdaad. En de taal lijkt qua syntax ook wel degelijk veel meer op Java dan op C++, en dat is maar goed ook want zo geweldig is die C++ syntax niet. Dat kwam doordat ze echt compatible zijn gebleven met C (je kunt een C programma met een C++ compiler compileren), maar het is er wel een warrig taaltje door geworden.

C# wordt ook niet gecompileerd naar binary code zoals C en C++, maar naar een tussentaal, net als Java. Bij .Net heet die tussentaal Intermediate Language, bij Java heet het Bytecode.

En Sun is nu druk bezig om aan Java ondersteuning voor alternatieve talen toe te voegen, dus de platformen groeien steeds meer naar elkaar toe wat dat betreft.

Oh en JP, het heeft geen zin om alleen C++ te gebruiken, tenzij je dat echt letterlijk neemt en dus geen calls vanuit je programma naar een API maakt.

Bijvoorbeeld zo'n Form waar je het over hebt. Dat is een venster waar je applicatie in draait. Vanuit C++ zul je om een Windows venster te maken gebruik maken van de Win32 API of MFC of zo.. maar ook die zijn platformafhankelijk. Dus dan kom je uit bij trolltech of zo. En trouwens, mono is toch druk bezig met de implementatie van de WinForms library?

[Reactie gewijzigd door OddesE op 23 juli 2024 09:01]

[Verwijderd]

maf....

Punt 1, Java is niet alleen een taal. Java is ook een platform. C++ is alleen een taal.

Punt 2, the Java taal is gebaseerd op C++ maar meer gericht op OO programmeren en minder op efficiente ASM generatie.

Punt 3, generic progamming in C++ is pure code generatie, terwijl de JVM (en waarschijnlijk MSIL ook) generics op runtime interpreteren.

Punt 4, Java/C# is goed voor toepassingen waarbij de architectuur enorm uitbreidbaar moet zijn, terwijl C++ veel wordt gebruikt voor high-performance computing en gaming. Lees elk boek over C++ en het valt op dat het altijd over snelle code gaat... lees elk boek over Java/C# en het valt op dat het altijd over modellen gaat...

Punt 5, zoek even op "java c# comparison" en het is duidelijk dat C# een direkte kopie van de Java taal is, met extras zoals delegates en generic programming. Java heeft generic programming weer van C# overgenomen, gelukkig.... C++ heeft operator overloading, multiple inheritance, destructors, etc. Java heeft dat allemaal niet.

Punt 6, Java is soms sneller dan C++ omdat het op runtime nog kan optimaliseren, bijv. virtuele functies static kan maken en functies kan inlines, etc. Het is echter onwaarschijnlijk dat de snelste Java implementatie sneller is dan de snelste C++ implementatie. Hoe dichter bij de CPU hoe sneller! (over het algemeen.) Bovendien zit je met Java met het punt dat je Java programma wordt gecompileerd naar een stack-based machine (JVM), en dan op runtime wordt door-gecompileerd naar een register-based machine (aangenomen dat je Intel gebruikt.) Zo'n dubbele conversie is in principe niet echt bevorderlijk voor de snelheid

Punt 7, zowel Java als alle .NET talen zijn in principe platform onafhankelijk, maar in de praktijk wil dat niet zeggen dat een C# programma ook op non-Windows systemen werkt... hangt ervanaf of er een .NET implementatie is op die platformen. In principe is dat dus "nee". By the way, mag ik opmerken dat C++ ook platform afhankelijk is, het is slechts een taal, als U maar geen CPU-specifieke truukjes gebruikt is de code prima portable (bv.: MAME.) Er zijn C/C++ compilers voor praktisch elke CPU, maar er zijn niet JVMs/.NET machines voor elke CPU. Dus wat is nou meer platform onafhankelijk dan C/C++ vraag ik dan...

[Reactie gewijzigd door Verwijderd op 23 juli 2024 09:01]

[SKiLLa]

Om nog preciezer te zijn: C# is gebaseerd op J++ en J++ was een regelrechte Java clone. Vervolgens hebben we dus tegenwoordig de (doorontwikkelde) J++ variant J# en de "nieuwe" taal C#, waar compatibility met J++ of Java geen beperkende factor is.

Bron: Anders Hejlsberg, chief architect van zowel Delphi, later J++ en nog later C#

[Snake]

Dat ze Java hebben gedumpt is goed. Ze hebben hun alternatief ervoor.

Maar er is ook Python.net, PHP.net en derlijke...

[Verwijderd]

Kijk eens naar J#.

[Jeanpaul145]

@sanderev66: J# is grotendeels incompatible met huidige Java code...

[beany]

Zoek op google eens naar haskell en .net. Er zijn wat initiatieven op dit gebied.

edit: dit is er 1 van: http://www.cin.ufpe.br/~haskell/haskelldotnet/

[Reactie gewijzigd door beany op 23 juli 2024 09:01]

[Verwijderd]

Dan hadden ze meteen een veel bredere userbase.

Zoals je op de F# site kan lezen, F# is gebaseerd op OCaml. En, OCaml heeft volgens mij ook een redelijk grote userbase.

[Reactie gewijzigd door Verwijderd op 23 juli 2024 09:01]

[Verwijderd]

of de .Net versie van Clean: C# ... oh nee

[Kaw]

F#, spannend! Ik hoop dat er wat standaardcomponenten in zullen zitten voor het werken met grote getallen en neural networks.

Begrijp ik nu goed dat je runtime gegenereerde code in dezelfde runtime kunt draaien? Zou erg leuk zijn! Ik zie het al helemaal voor me: een neurologisch netwerk die een bepaalde taak moet programmeren en dat je die multicore laat draaien om een optimaal resultaat te krijgen. Ik heb al eens zoiets geprogrammeerd, maar omdat het allemaal virtueel was, was de performance te telleurstellend om nuttig te zijn. Nu zou dat misschien anders gaan liggen!

[ThjK]

Het mooiste is natuurlijk een taal die oo-functionaliteit koppelt aan functioneel-programmeer eigenschappen, zoals python met z'n lambda constructies. Ikzelf gebruik in mathematica ook altijd een mengelmoesje van functioneel en procedureel. Als je dan ook nog eens een standaard library hebt met een enorme hoeveelheid functies, ontwikkelt het lekker snel!

[mOrPhie]

C# 3.0 heeft LINQ en is precies wat jij zoekt.

[morpheus]

Nu maar wachten op de toevoeging van een logische programmeertaal waarmee makkelijker AI geprogrammeerd kan worden

[drZymo]

http://www.dcs.ed.ac.uk/home/stg/Psharp/