Op Python gebaseerde .NET-taal ziet binnenkort levenslicht

Naast de reeds bestaande talen als Visual Basic.NET en C#, wordt het palet van beschikbare programmeertalen voor het .NET-framework binnenkort uitgebreid met een nieuwe variant, genaamd Boo. Deze nieuwe programmeertaal is gebaseerd op de scripttaal Python en vult volgens de ontwikkelaar een gat in de markt. Boo is ontwikkeld door de Braziliaanse programmeur Rodrigo Barreto de Oliveira die op zoek was naar een taal die een combinatie was van Python en C#, waarbij hij van de eerste de syntax en enkele kenmerkende eigenschappen wilde gebruiken, gecombineerd met de Common Language Infrastructure en statische typering van C#. Omdat hij geen taal kon vinden die aan deze eisen voldeed, besloot hij om Boo te gaan ontwikkelen.

Inmiddels is Boo in een bruikbare staat en de Oliveira verwacht dan ook binnen enkele maanden versie 1.0 vrij te kunnen geven. Op dit moment is het grootste probleem dat er nog niet voldoende gebruikers zijn van het .NET 2.0-framework om de taal uitgebreid te kunnen testen. De syntax van Boo is gebaseerd op die van Python, maar de variabelen in de taal worden statisch getypeerd. Hierdoor is het voor de compiler mogelijk om eventuele fouten van de programmeur al op te sporen tijdens de compilatie, terwijl bij Python dergelijke fouten pas tijdens het uitvoeren van het programma aan het licht kunnen komen. Boo heeft wel de flexibiliteit van Python met betrekking tot het gebruik van de variabelen. Zo is het niet verplicht om variabelen van te voren te definiëren, zoals bijvoorbeeld bij C# wel het geval is. Daarnaast biedt Boo de mogelijkheid om eenvoudig de taal uit te breiden met eigen constructies, wat ook een van de ontwerpdoelen was van de Oliveira.

Miguel de Icaza, vice-president development platforms bij Novell en ontwikkelaar van de open source .NET-implementatie Mono, vindt Boo een goede toevoeging aan het bestaande palet van .NET-talen. Volgens hem is de taal uitermate goed geschikt voor de ontwikkeling van prototypes en daarnaast onthult Boo genoeg van zijn interne werking om eenvoudig een IDE voor de taal te kunnen ontwikkelen. Overigens is Boo niet de enige taal voor .NET die gebaseerd is op Python. IronPython is namelijk een pakket wat Python vrijwel naadloos integreert met de Common Language Runtime. Zowel IronPython als Boo werken onder Mono.

Reacties (31)

[Verwijderd]

.NET is toch één van de zaken die Microsoft wel goed aan pakt. Meer en meer talen krijgen .NET implementaties, voor zowel het Windows, Unix, Linux, BSD platform etc... En dat zonder vieze trucjes van MS En voordat we weer een Java vs .NET discussie krijgen, de beste ideeen komen niet voort uit de grote frameworken en worden altijd gekopieerd van elkaar

Daarnaast kan MS dankzij de opzet van versies van het framework simpel aanpassingen doen in het framework zonder dat al die andere talen er last van krijgen, omdat de verschillende versies van .NET netjes naast elkaar kunnen draaien. In het ergste geval zul je dus een x aantal versie van het framework geinstalleerd moeten hebben, maar met de huidige grootte en prijzen van harde schijven is dat ook geen ramp.

Op dit moment is het grootste probleem dat er nog niet voldoende gebruikers zijn van het .Net 2.0-framework om de taal uitgebreid te kunnen testen.

Ik ben bang dat dit ook nog wel even gaat duren. Wat je vooral ziet binnen bedrijven is dat ze nog volop zich aan het ontwikkelen zijn in .NET 1.1 en meer geinteresseerd zijn in migreren naar Visual Studio 2005, dan naar .NET 2.0, dat komt later wel. Ik denk toch wel dat zeker tot het einde van dit jaar gaat duren voordat 2.0 een minimale solide basis heeft in de IT wereld.

Daarnaast is Visual Studio 2005 een ramp, traag als dikke stront. Maar daar heb je gelukkig met Boo geen last van .

Ik ga Boo zeker uitproberen. Eens kijken of ik iets leuks cross platform er mee kan bouwen.

@Gerco: Inderdaad, dat is ook nog een optie om zeker naar te kijken! Thnx voor de tip

@blouweKip: Heb je helemaal gelijk in over het winforms gedeelte. Helaas is dat gedeelte niet open, maar de GTK implementatie komt dichtbij. Ik weet niet waar je het vandaan haalt, maar MS drukt Mono absoluut niet de kop in. Ze ondersteunen het niet, maar dat hoeven ze ook niet en Mono zal nooit de snelheid op Windows krijgen, die .NET wel krijgt, omdat MS de mogelijkheid en know how heeft voor windows. Daarnaast zal MS een goede Mono implementatie (toch vooral gericht op niet Windows OSsen) binnen Linux eerder stiekem toejuichen (If you can't beat them, join them)!

[Gerco]

Ik ben persoonlijk meer geintersseerd in de mogelijkheid om Boo te gebruiken als scripting/macrotaal voor mijn applicaties. Programmeren doe ik zelf wel in C#, maar bepaalde gedeeltes (rulesets voor vanalles bijvoorbeeld) kunnen makkelijker in dit soort talen gedaan worden.

Als er een Boo interpreter/compiler is die ik gewoon kan aanroepen vanuit managed code zou dat helemaal perfect zijn.

[H!GHGuY]

Dit kan nu toch ook al met C# etc?

je schrijft een functie, gaat wat rondneuzen in System.Runtime.CompilerServices en hoppa je functie is gecompileerd en gebruiksklaar @ runtime...

[Gerco]

Dat kan ja, maar in korte scripts en macros wil je niet de rompslop van definities van variabelen, classes etc. Je wilt gewoon een regeltje of 10 schrijven aan functionaliteit en over de rest niet nadenken.

Ik denk dat Boo daar beter voor geschikt is dan C#. Niet dat het met C# niet kan, maar ik denk dat het minder handig is.

[blouweKip]

alleen jammer dat microsoft winforms niet vrijgeeft, en .net dus gewoon een manier lijkt om via het desktopmonopolie het momentum voor een echte platforminafahankelijk systeem weg te kapen (al deed java het redelijk goed)

als ze het echt goed hadden aangepakt hadden ze samen gewerkt ed, nu kunnen ze projecten als mono als deze succesvol worden (mono heeft wel een platformonafhankelijk widgetset in de vorm van gtk# itt .net) de kop indrukken (wat ze gezien hun trackrecord niet zullen nalaten)

maw: we moeten wel meegaan met .net omdat het nu eenmaal met windows geintergreerd gaat worden maar om het nu een goede aanpak te noemen gaat me wat te ver

[MacWolf]

Op mijn werk zijn we bij een project overgeschakeld van Visual Studio 2003 naar Visual Studio 2005. Tegelijkertijd is besloten om de code compleet te herschrijven naar .NET 2.0. Mijn ervaringen zijn op dit moment uitermate positief. De manier waarop met databases & datasets wordt omgegaan is een stuk verbeterd, wat uiteindelijk minder en veel stabielere code zal opleveren. En dat punt was voor mij het grootste probleem in .NET 1.0 of 1.1.

.NET is inderdaad 1 van de zaken die Microsoft wel erg goed doet (net als bijv. Visual Studio).

Wat dat betreft hoop ik dat Microsoft ooit nog eens een implementatie zal maken van .NET voor het Apple platform (gezien MONO gemaakt is door een derde partij ben ik een beetje wantrouwig om het te gaan gebruiken).

[jurriaan]

Ik zie niet helemaal de toegevoegde waarde t.o.v. JScript.NET, waar je ook zowel statisch getypeerde variabele als niet getypeerde variabelen kunt gebruiken. Zeker niet als er ook al IronPython is.

[Verwijderd]

Dat is het voordeel ook niet! Het voordeel is: first-class functies, anonieme functies en anonieme types. Gelul over wel of niet gedeclareerde variabelen is voor script-kiddies. Wikipedia naar lambda-calculus en first-class-functies en educate-yourself.

[re-enter]

logo trekt toch wel verdacht veel op PAC-man

[Verwijderd]

De vergelijking van .NET met JAVA is inderdaad goed te maken. Echter, JVM geeft platform onafhankelijkheid.
.NET geeft een onafhankelijk ontwikkelplatform. (niet gebonden aan een taal) Daarnaast heeft het nog wat voordelen die de ontwikkeltijd ten goede komen.

[Verwijderd]

Mag ik opmerken, dat het niet alleen zo is, dat je je programma in programmeertaal naar keuze kan schrijven, maar juist elke klasse, elk object, etc. Dat is de meerwaarde. Dat een team van mensen elk in z'n eigen favoriete programmeertaal te zamen 1 grote library en/of applicatie kan ontwikkelen.

Dit betekent dus dat je bijvoorbeeld de 3d api van je 3d engine in C# kan doen, de AI in F# en de scripted events in Boo. Grotere projecten zullen doorgaans alleen slagen als je toegang hebt tot verschillende niveaus van abstractie.

Bekijk bijvoorbeeld je favoritiete 3D engine en merk op dat er minstens van 2 programmeertalen gebruik is gemaakt:
- Far Cry is C++ code en LUA.
- Unreal is C++ code met Unrealscript. Unrealscript was (en is) z'n tijd voorruit. Het is C#-achtig maar dan met states (ala finite-state-machines), polymorphy en reflectie. Daarnaast is het ook platform onafhankelijk: draait op XBOX, Windows, Linux, Mac, PS2 etc.

Toendertijd was er geen .NET dus moesten ze zelf hun eigen framework ontwikkelen. Maar aan zulke projecten (er zijn echt miljoenen ingegaan) kun je goed zien hoe nodig zo'n framework voor de wat uitdagendere projecten is. Zie hier een ppt-presentatie-als-pdf van Tim Sweeneys' (de voornaamste autheur achter Unreal) over welke features van een programmeertaal belangrijk zijn en hoe belangrijk snelheid wel/niet is:
http://www.st.cs.uni-sb.d...vanced-fp/docs/sweeny.pdf

Tim Sweeney heeft het hier over haskell (www.haskell.org) .. ik vermeld de link maar even, misschien dat niet iedereen er bekend mee is. Ohja en waar hij het over STRef heeft, doelt hij op een transaktie-veilige variabele: zeg maar een object-attribuut, waarvan de getter en setter transactie-veilig zijn zoals in een database. IORef zijn gewoon pointers die niet null kunnen zijn.

Merk op dat alhoewel .Net dit nog niet is, en op cruciale punten zou moeten worden aangepast om dit aan te kunnen (.Net 4 anyone?) is het zonder meer een stap in de goede richting: omdat je je projecten op kan splitsen en afzonderlijke elementen in verschillende domein-specifieke-talen kunt implementeren. In de presentatie van Sweeney scheidt hij dan ook de gameplay-objecten van de wiskundige (grafische) transformaties. Beide zouden in een ideale wereld een andere taal met een ander soort compiler en type-systeem gebruiken. Gelukkig is deze scheiding der abstracties voor de shaders allang van toepassing.

Waarom is .NET zo goed voor domein-specifieke-talen? Omdat alle talen en paradigma's ondanks hun verschillen toch gemakkelijk informatie kunnen uitwisselen. Ze hebben beide altijd dezelfde core-types en hetzelfde core-type-systeem. Bijna 80% van alle libraries voor een (willekeurige) programmeertaal, zijn wrappers om functies aan te roepen gecompileerd met een andere programmeertaal.

Neem nou MySql libraries, die bestaan voor Python, Java, etc. Met .NET schrijf je een parser, een compilertje en whoppa je eigen programmeertaal, die al direct toegang heeft tot alle .NET libraries zonder extra MARSHALLING. Je hoeft geen mysql-library zelf te onderhouden. Als ik op m'n ubuntu hier alle installeerbare kandidaten opzoek met de naam mysql dan vind je onder andere: mysql-ruby, mysql-java, mysql-python, mysql-ocaml, mysql-pike. En guess what? Ze doen allemaal hetzelfde, maar voor een andere programmeertaal, en ze moeten allemaal up-to-date gehouden worden. Maar met de scheiding der abstracties, kan je met .NET nog veel verder gaat: Waarom code die SQL als een string opbouwt? Integreer SQL als .Net taal en whoppa, ook je SQL is getype-checked en geintregeerd in alle andere .Net talen.

Ohja en over de portemonnee-afhankelijkheid van Microsoft: er is natuurlijk ook Mono (http://www.mono-project.com/Main_Page), de opensource linux kloon die een compatible file-format gebruikt.

[Gerco]

De Java VM is ook te programmeren met een hele berg andere talen dan Java. Je moet de taal Java en de technologie Java VM dan ook niet door elkaar halen.

Java en de Java VM verhouden zich tot elkaar als C# en de .NET CLR. Java is de 'language of choice', maar zeker niet de enige keuze.

[NoepZor]

Wat is .Net eigenlijk? Ik dacht dat het een programmeertaal opzich was net zoals java, delphi enzovoorts.

[Wmm]

.NET is geen programmeertaal, het is een framework waar programmeertalen gebaseerd op .NET gebruik van maken. Dergelijke programmeertalen zijn Visual Basic .NET en C#.

Om programma's geschreven voor .NET te kunnen draaien moet je .NET dus ook geinstalleerd hebben op je pc. Net zoals je de JVM geinstalleerd moet hebben voor Java programma's .

Boo combineert dus zaken uit Python C# en maakt gebruik van het .NET framework.

[Verwijderd]

Sorry, maar ik moet je ongelijk bewijzen.... .Net is wel degelijk een programmeer taal. Alleen zijn programmeer talen als VB en C# die dit aansturen ipv de programmeur. (Wanneer je een .Net applicatie compileert wordt het omgezet naar een assembler-taal: MSIL)

[Verwijderd]

Precies! Maar MSIL is specifiek bedacht en ontworpen om naar toe te compileren, niet om met de hand zelf te schrijven. Het is dit uitgangspunt waardoor je MSIL beter kunt _beschouwen_ als specifiek datatype, dan als programmeertaal. Het moest makkelijk te parsen, makkelijk te generen en makkelijk te optimalizeren zijn. Het hoeft niet makkelijk te zijn om in te programmeren.

Het is niet moeilijk voor te stellen dat het schrijven van een optimizer voor een minimale taal zoals MSIL makkelijker is, dan voor een specifieke syntax-door-drenkte taal ala VB of C#. Zo'n optimizer werkt dan ook meteen voor _alle_ .Net talen. CLR is gewoon z'n binaire zusje, waar de operands door byte-codes zijn vervangen.

De vergelijking met JVM die sommige hier maken gaat een beetje mank: De JVM is een stuk minder krachtig.

Het kan bijvoorbeeld dynamisch linken als het geinterpreteerd wordt, maar het zou nooit dynamisch libraries kunnen linken die al naar machiene taal gecompileerd zijn. Je kan in theorie Java wel naar machiene taal compileren (er bestaan bijvoorbeeld speciale versies van Eclipse), maar dan worden het monolitische executables die geheel op zichzelf staan. Dus stel dat programma A, library C ergens eventjes gebruikt, dan moet hij in gecompileerde code
1) de gecompileerde code van library C bevatten
2) bij elke update van library C, opnieuw programma A compileren
3) bij elke update van library C, opnieuw programma A distributeren naar al je klanten

.NET kan dus voor machiene executable (een .EXE onder windows) toch nog de volgende features bieden:
1) dynamische linking
2) seperate compiling

En dat maakt .NET ideaal voor het bouwen van evolutionair product zoals een Operating Systeem en superieur aan de JVM.

Daarnaast is de JVM hartstikke crippeled in het type systeem. Puur de aanwezigheid van de cast operator in Java verraad al dat het type-systeem een lachertje is. Op elke plek waar een cast staat ga je van compile-time-type checking naar dynamische-type-checking. Dit is onnodig en heeft de volgende nadelen:

1) sommige fouten zullen pas boven komen drijven bij een bepaald soort gebruik van je applicatie. Als jij het test doe het het, maar als de klant het gebruikt krijg je opeens een run-time-exception.
2) om toch type-safety te garanderen, gaan we gedurende run-time de types controleren: dit kost CPU! Een cast in een inner-loop maakt Java van Just-in-Time-achtige-performance naar Is-dit-Qbasic-performance?

Daarnaast kent de JVM het probleem dat het zich tijdens start-up-time tegen hostile-code beschermt ipv tijdens compile-time. Daardoor starten al die Java programma's ook zo kut op: eerst wordt ff gecontroleerd of de code 'veilig' is, wat ok is voor een applet die je 1 keer gebruikt op een of andere website, maar niet voor applicaties die je installeert, en vier keer per dag opstart. Met .NET zou je (in theorie) kunnen compileren tijdens installatie: en dus op dat moment de code evalueren tegen misbruik.

Eind-conclusie: .NET is een stuk krachtiger dan de JVM.

PS. Ik moet wel opmerken dat inmiddels het type systeem van Java zelf verbeterd is: http://java.sun.com/j2se/...de/language/generics.html
(of dit ook op het niveau van de JVM opgelost is in mij onduidelijk: ik ben bang dat achter de schermen nog steeds casts plaats vinden: met alle run-time-performance problemen die dat oplevert)

Talen zoals Haskell (met de GHC extensies) en sommige ML varianten konden dit soort geintjes al tijden, maar toen noemde alle (*vul hier een eufenisme voor dom in*) programmeurs gewoon alles wat ze niet snapte AI. Maar daar heeft 't weinig mee te maken! Overigs was dit al enigzins mogelijk voor de die-hards in C++ zonder type-checking dmv templates :-)

Maar laat je niet misleiden door de term generics. Dat is het namelijk niet: het is type-polymorphie! Hier is dezelfde toelichting van Microsoft over het onderwerp, die wat eerlijker zijn over hoe het gemarketeerd wordt en hoe het eigenlijk heet en waar het vandaan komt: http://research.microsoft.com/projects/clrgen/.

Echte generics betekent dat je zowel polymorfische functies, polymorfische types, alswel type-indexed functies hebt. Zodat je polymorphische sorteer routine automatisch met al je eigen abstracte datatypes werkt, zonder dat je ooit een comparision-routine hoeft te defineren. Er zal slechts een comparision-routine voor de core-types nodig zijn. En dat dan allemaal met compile-time-type-safety: zodat er geen run-time-exceptions mogelijk zijn in code die geen IO doet, en er tijdens run-time geen type-informatie opgeslagen hoeft te zijn, wat weer performance winst oplevert. Laat het je uitleggen: http://en.wikipedia.org/wiki/Generic_programming

[Brent]

Waarom zou je als programmeur of gebruiker een framework willen? Wat is daar de toegevoegde waarde van of wat mis je als je er geen gebruik van maakt?

[Verwijderd]

Voor NeopZor en Breepee en die andere die niet echt weten wat .NEt is of meer willen weten over .NET, hier is wat info daarover. Het is wel een handig manier van ontwikkelen.. Ik ben heel blij mee en ontzettend makkelijk om te gebruiken.
http://www.microsoft.com/netherlands/msdn/aspnet/nodig.aspx
http://www.microsoft.com/...roducts/netframework.aspx
http://www.beeone.nl/content/SoftwareDevelopment.aspx

[Verwijderd]

Het is gewoon een verzamelnaam van verschillende tools en libraries. Net als J2EE b.v. Met elke programmeertaal gebruik je dergelijke zaken wel.

[Verwijderd]

het .NET framework is eigenlijk een virtual machine, net als de java virtual machine, dat tussen jouw code en het computersysteem (OS, hardware) draait. Het zorgt bijvoorbeeld dat geheugen voor jouw gealloceerd en gedealloceerd wordt (vooral dat laatste kan in c++ wel ns voor memory leaks zorgen). Het is een soort veiligheidsbuffer waarin je als programmeur vrij kan spelen, zonder het systeem te verkrachten (meestal). Je code wordt gemanaged door het framework.

Daarenboven zal het idd een aantal standaard libraries standaard geïmplementeerd hebben.

Het grote nadeel vind ik dan weer dat je code compleet afhankelijk is van het al dan niet beschikbaar zijn van dat framework (linux, handhelds, embedded systems, ...) Sun doet nog moeite om voor elke mogelijke printplaat waar een chip op zit Java beschikbaar te maken ... Microsoft heeft nogal de neiging om Windows-only stuff te doen. Raar maar waar.

[dtech]

Hmm, toch maar is phython gaan leren, schijnt dat het heel makkelijk is, en hierdoor is het alleen maar handiger, dan kan het gemakkelijk gekoppeld worden aan C# applicaties.

[Verwijderd]

Wat is hier de nieuwswaarde van? Je hebt tegenwoordig voor zo'n beetje iedere taal een .NET versie, van Ook!.NET, Brainfuck.NET tot Haskell.NET.

[arjankoole]

Wat is hier de nieuwswaarde van? Je hebt tegenwoordig voor zo'n beetje iedere taal een .NET versie, van Ook!.NET, Brainfuck.NET tot Haskell.NET.

Misschien dat het jou niet boeit, en met jou vast ook wel anderen, maar een site met de userbase als t.net zal ook zeker scores aan bezoekers hebben die het wel intresseert en voor wie het zeker nieuwswaarde heeft.

Al helemaal als ik de reacties op dit item zo eens bekijk.

Misschien is het voor jou een leuke uitdaging om dingen eens vanuit iemand anders' perspectief te bekijken, in plaats van loos-boe-bah geroep te spuien. Maakt 't leven op t.net weer wat gezelliger

[Verwijderd]

Je hebt gelijk, bedankt

[Mitchell2.24v]

MS werkt zelf (uiteraard?) ook aan een .NET implementatie van Python. Ik heb er zelf nog niet naar gekeken, maar wellicht is dat ook interessant:

IronPython Beta 3

edit:

@ drZymo

hehe, maar wel *met* link

waarschijnlijk te snel gelezen , maar volgens mij stond die tekst er eerder niet...

[drZymo]

Spuit 11

Uit artikel

Overigens is Boo niet de enige taal voor .NET die gebaseerd is op Python. IronPython is namelijk een pakket wat Python vrijwel naadloos integreert met de Common Language Runtime.

[Ferdinand Oeinck]

Jullie vergeten te vermelden dat onder .Net ook Managed C++ (1.1) en nu ook C++/CLI geimplementeerd is.

Een perfecte oplossing om een C# (of wat dan ook) scripting engine aan je bestaande win 32 C++ software toe te voegen!

[Ventieldopje]

Nu is het dus de Boo man