'Microsoft .Net krijgt ondersteuning voor dynamische talen'

Microsoft zal volgens ZDNet op de komende Mix07 conferentie in Las Vegas waarschijnlijk aankondigen dat het verbeterde ondersteuning voor dynamische programmeertalen in het .Net-framework op gaat nemen.

Een dynamische programmeertaal kenmerkt zich door de mogelijkheid om tijdens het draaien aanpassingen aan het programma te doen. Hierbij is te denken aan uitbreidingen van de code en objecten en het niet hoeven declareren van variabelen. Waar een dynamische taal hiervoor standaard ondersteuning biedt, is dit bij gecompileerde talen na het compileren niet eenvoudig te doen. Bekende voorbeelden van dynamische talen zijn onder meer PHP, Ruby en Python. Ook logische talen als Prolog zijn onder de dynamische programmeertalen te scharen. Op dit moment zijn er wel mogelijkheden voor dynamische talen binnen het .Net-framework, zoals via het RubyClr-project, maar de ondersteuning laat nog veel te wensen over.

Microsoft wil graag het .Net-framework aantrekkelijker maken voor programmeurs die gebruik maken van dynamische talen. De belangstelling voor dit soort talen neemt steeds verder toe, en de verwachting is dan ook dat er grote interesse voor de ondersteuning hiervan binnen .Net zal bestaan. ‘Projecten zoals RubyClr zijn in verschillende smaken beschikbaar, maar geen van hen is compleet en er zitten grote verschillen tussen de diverse implementaties’, aldus Dion Almaer, ontwikkelaar en oprichter van de website Ajaxian.com. ‘Het is te hopen dat de communities zoals die van Ruby het initiatief van Microsoft omarmen. JRuby op de Java virtuele machine begint steeds beter te werken. Als er volledige ondersteuning voor Ruby op het .Net-platform beschikbaar zou komen zou dat geweldig zijn’, zo vervolgt hij.

De afgelopen tijd nam Microsoft met Jim Hugunin, van IronPython, en John Lam, van RubyClr, al twee experts op het gebied van dynamische programmeertalen in dienst. Hugunin lichtte enige tijd geleden al een tipje van de sluier met betrekking tot zijn plannen op. Hij vertelde dat er libraries boven op de Common Language Runtime zullen worden aangeboden die verbeterde ondersteuning voor dynamische talen moeten realiseren. ‘Wij gaan niet zelf een dynamische taal ontwikkelen, in plaats daarvan gaan we codebibliotheken, patterns en richtlijnen opstellen voor het gebruik van bijvoorbeeld Ruby binnen .Net’, aldus Hugunin.

Volgens zijn collega Lam zijn een groot aantal verschillende dynamische talen in de basis gelijk. Zo is ondersteuning voor integers van variabele lengte een standaard mogelijkheid van zowel Python als Ruby. Toch zullen deze functies steeds apart ontwikkeld moeten worden voor gebruik binnen de clr. Het team van Huninin en Lam hoopt door hun project, vermoedelijk Dynamic Language Runtime genoemd, ontwikkelaars die dynamische talen gebruiken richting het .Net-framwork te trekken. Een woordvoerder van Microsoft wilde voorlopig geen mededelingen doen over dit onderwerp.

Reacties (27)

[Niemand_Anders]

Microsoft wil natuurlijk gewoon zoveel mogelijk developers voor zijn .NET platform. Maar persoonlijk ben ik minder blij met dergelijke toevoegingen.

Sinds ASP (VB) werd vervangen door VB.NET en C# is het aantal bugs schikbarend terug gelopen omdat tijdens het compileren al de syntax fouten eruit worden gehaald.

Overigens kun je in .NET nu al dynamisch objecten in laden doormiddel van de System.Activator.GetObject methode. Het enigste wat je hier voor nodig hebt is de type (class name) en de naam van de assembly. Via interfaces kun je heel erg eenvoudig met deze object communiceren.

Wij gebruiken deze techniek o.a. om te kunnen switchen van database server (MsSQL, Oracle, MySql, Postgres, etc) in onze data layers en het laden van plugins/extenties.

Indien het niet mogelijkheid is om de 'dynamische' libraries te blokkeren, dan heeft Java bij ons een grote kans op een comeback. Dynamische talen komen er bij ons echt niet meer in.

[spone]

Sinds ASP (VB) werd vervangen door VB.NET en C# is het aantal bugs schikbarend terug gelopen omdat tijdens het compileren al de syntax fouten eruit worden gehaald.

Wat bedoel je daar precies mee? Is het niet altijd zo dat een compiler zich verslikt in syntaxfouten?

[Scidd0w]

Ja maar de "ouderwetse" ASP code hoeft dus niet vooraf gecompileerd te worden!

[downtime]

Wat bedoel je daar precies mee? Is het niet altijd zo dat een compiler zich verslikt in syntaxfouten?

Dat zal ie inderdaad wel bedoelen. ASP (geen VB maar meestal VBScript) was niet gecompileerd en gebruikte standaard geen strong typing, en daardoor kwamen syntax fouten niet altijd direct aan het licht, terwijl ASP.NET (meestal VB.NET of C#) wel gecompileerd is en veel stomme fouten daardoor bij het compileren al naar voren komen.

[/\/\|)]

Voor mij hoeft het ook niet. Met dynamische talen is het risico op ononderhoudbare code nog groter.

[mxcreep]

Daar ben ik het niet helemaal mee eens...in elke taal kun je er een bende van maken...en andersom kan dus ook. Programmeurs moeten gewoon netjes werken, in welke taal dan ook.

[MisterBlue]

Als je met automatische unit testen werken en test driven design doet, heb je geen compiler nodig om syntax fouten eruit te halen.

Dynamische talen zijn enorm geschikt om test driven te werken, juist omdat je eerst je testen volledig kan maken zonder zorgen te maken over compileer fouten.

Automatische unit testen zijn pas de basis voor onderhoudbare code, omdat je dan pas echt goed kunt refactoren.

[Skit3000]

Je hebt toch ook JScript .NET? Met de JScript voor ASP kan je dynamisch objecten e.d. aanmaken, met de .NET versie misschien ook al?

[jurriaan]

Goede vraag, want inderdaad, ook JScript.NET is dynamisch en werkt prima. Al geloof ik niet dat Microsoft van plan is dat aan de grote klok te hangen. Practisch alle voorbeelden zijn of VB of C#.

Ik mis overigens Perl in het rijtje dynamische talen. Ik weet, het rijtje was niet uitputtend, maar Perl lijkt mij de meest logische kandidaat voor Microsoft zelf, gezien het feit dat zij in het verleden ook de voorkeur gaven aan Perl binnen ASP als niet-microsoft taal.

[mxcreep]

Maar welke PHP / Python of Perl programmeur zit er nu in godsnaam op te wachten om iets met .NET te gaan doen.
Ze worden grootendeels gebruikt op *nix platform...Ik persoonlijk moet er niet aan denken om straks op van die fijne Windows servers te moeten gaan werken en hosten.

[Verwijderd]

Veel applicaties worden in talen als C# vb en dergelijke geschreven omdat deze veel uitgebreider zijn dan jscript (en veel makkelijker in het gebruik) alleen deze talen moeten eerst gecompileerd worden voor de server de applicaties kan runnen.

Jscript is client side terwijl je je business objecten vooral aan de server kant wilt houden.

[Skit3000]

JScript is server side, Javascript is inderdaad wel client side. Maar JScript .NET maakt gebruik van de .NET engine, dus vraag me af of daar de voordelen van het dynamisch gebruik van objecten enzo ook gelden

[Verwijderd]

Niet echt. JScript is Microsoft's variant op de standaard Javascript (welke weer voortkwam uit ECMAScript). Beide zijn oorspronkelijk bedoeld voor client side toepassingen en andere scripting toepassingen buiten websites.

JScript .NET is weer een variant op JScript, waarbij de code niet langer door een interpreter gaat, maar daadwerkelijk gecompileerd wordt naar MSIL, de p-code van .NET.
'expando' properties, zoals in JScript dynamische toevoegingen aan code genoemd worden, zijn ook aanwezig in de .NET variant. Dus in zekere zin is JScript.NET ook een dynamische taal.

[7.01D]

JScript is Microsoft's variant op de standaard Javascript (welke weer voortkwam uit ECMAScript).

ECMAScript kwam pas na JavaScript en JScript. Microsoft leidde JScript af van JavaScript (Netscape) en diende het vervolgens in bij ECMA voor standaardisering. ECMAScript dient nu als basis voor beide varianten.

http://en.wikipedia.org/wiki/ECMAScript

[tjerkw]

Ze willen het de .NET runtime zo aanpassen dat men dynamische talen makkelijk kan compileren naar de .NET bytecode.

Het heeft dus niks te maken met talen die 'het' al kunnen.

[bush]

Dit is oud nieuws.
Local variable type inference en Anonymous Types zullen dit mogelijk maken in Orcas.

Meer info op
http://www.danielmoth.com...pe-inference-in-c-30.html

en

http://feeds.feedburner.c...ypes-in-c-30-and-vb9.html

[Verwijderd]

Dit heeft volgens mij niks met de post te maken. Verschil is namelijk dat bij local variable type inference gedurende compilatie al bekend is wat het type is van de variable.

Dus als ik schrijf:

var someVar = new SomeType();

Dan weet de compiler dat someVar van het type SomeType is, zonder dat je dat expliciet aangeeft. Vervolgens kun je dus niet in dezelfde functie schrijven:

someVar = new SomeOtherType();

Je compiler zal hier over klagen. Dit is echter iets wat wel in de dynamische talen die in het artikel genoemd worden kan. Daar kan je een integer variable eerst een integer waarde geven en daarna weer een string. Dat is natuurlijk leuk, maar je kan dan lang niet altijd garanties geven over het type van een bepaalde variable.

[Verwijderd]

Je hebt gelijk. Bush slaat de plank hier helemaal niks. Type inference en Anonymous types in C# en VB hebben niks met dynamic languages te maken.

[Verwijderd]

Maar dat is hem vergeven, want het plaatje bij het artikel legt de nadruk op hoe simpel het is in Ruby om ff snel een object te maken. Dat is in C# wel verbeterd. Dus het plaatje is niet zo illustratief volgens mij?

[Alarmnummer]

Prolog is trouwens geen functionele taal maar een declaratieve/logische taal.

Prolog werkt op basis van predicaten en proposities.

[P_de_B]

Aangepast, dom foutje idd

[Roland684]

Aan de ene kant wordt self-modifying code zoveel mogelijk geweerd (omdat virussen hier veelvuldig gebruik van maken om zich onherkenbaar te maken voor virusscanners), tot zelf op hardware-niveau toe wordt alles dichtgetimmert.
Een nu gaan we de deuren toch weer wagenwijd open zetten voor dit soort code en het gebruik aanmoedigen??
Volgens mij gaan we een heel nieuwe generatie virussen krijgen, de selfmodifying code die we kennen uit de lagere programmeertalen, maar dan in hogere programmeertalen toegepast.

Niets tegen self-modifying code overigens, er zijn zeker toepassingen voor, met name als performance of resources een issue zijn. Maar eerlijk is eerlijk, dat zie ik toch niet graag meer buiten een sandbox gebeuren.

Maar het blijft een beetje gerommel in de marge. Ze proberen wat 4GL (of 5GL) eigenschappen te integreren, maar .Net blijft een 3GL omgeving. De echte kracht van een 4GL of 5GL past gewoon niet binnen het framework.

[tjerkw]

Met self-modyfying code bedoel je dynamische talen die naar een of andere bytecode getransformeerd worden ( noem het compilen ).

Nu kan die bytecode zichzlef niet veranderen maar als het wordt geladen in het geheugen wel.. Dus de executie kan veranderen.

Virussen werken al vanaf het beginafaan zo: ze passen gewoon de code dat in het geheugen geladen is aan.

Dus er wordt helemaal geen deur opengezet. Ze passen .NET gewoon aan zodat ook dynamische talen kunnen draaien.

Ik weet niet precies wat je met GL bedoeld. Maar als je Generation of Languages bedoeld dan moet je je toch een keer over het hoofd krabben. Want die bestaan namelijk neit echt.

[SPee]

Ze kijken wel af van Java
Daar zit deze ondersteuning ook in de nieuwste versie

[jj71]

Inderdaad, in Java-land is dit iets waarmee men al een tijdje bezig is. Ruby draait nu op de Java VM: JRuby.

Het hele .NET platform is zo ongeveer afgekeken van Java. Typisch Microsoft: ze zijn zelf niet goed in innoveren, maar wel in kopiëren en aan de haal gaan met ideeën van anderen.

[Alex]

De grote grap is dat Microsoft juist de laatste jaren enorm innovrend is. Neem nou generics en hun introductie in Java en ik .NET. Kijk ook naar de implementatie met de OO-pet op.
Of Windows Communication Foundation. daarmee rennen ze alle mogelijkheden van J2EE op communictie gebied vér voorbij.
oed
Ze zijn misschien niet origineel, maar er word echt heel goed nagedacht. Vergeet bijv. niet dat de oude Pascal ontwerpen, Anders Hejlsberg, achter C# zit. Bij Borland werd hij de hemel in geprezen, nu bij Microsoft is hij ineens een zwart schaap.
Zie ook deze discussie: http://channel9.msdn.com/Showpost.aspx?postid=273697

Leuke is dat men in de 'hogere' regionen van software ontwikkeling(lead developer, architecten, infrastructuur architecten, etc) er word gekeken naar het beste van het moment en vooral niet naar wie-wie na doet / verbetert.

[reddog33hummer]

Blijkbaar wordt het dus een update van de Reflection.Emit
Hiermee kan je code genereren in code.