Gepubliceerd: Maandag 11 mei 2009
Microsoft biedt een nieuwe programmeertaal aan voor zijn ontwikkelraamwerk .NET. De taal, Axum, is speciaal gemaakt voor multicore-processors.
Toon volledig artikel
Microsoft heeft controle over het OS, de programmeertaal, en de programmeeromgeving. Daardoor hebben ze de mogelijkheid om zaken als verdeling van instructies tussen cores zelf op kernel-niveau te regelen. Het is jammer dat ze ontwikkelaars opzadelen met een probleem dat ze beter zelf kunnen oplossen.
Apple pakt dat toch slimmer aan met Grand Central.
Het opzet is dan ook verschillend. In Grand Central regelt het OS zelf voor jou de verdeling van de toepassingen onder de verschillende cores, zonder dat je daar verder zelf mee te maken krijgt. In Axum is het de bedoeling dat je daar net wél volledige controle over krijgt en je er je ding mee kan doen...
Mav.
Met de API's van Grand Central kun je als programmeur erg veel invloed uitoefenen op hoe instructies verdeeld worden tussen cores. Grand Central zorgt er echter voor dat je geen expert in multithreading hoeft te zijn om een applicatie te optimialiseren voor multicore, dat gedeelte handelt het zelf af.
Het effect van dit verschil van aanpak zal zijn dat de meeste applicaties voor de Mac geoptimaliseerd zullen zijn voor mulitcore, en bij Windows alleen de applicaties van de allergrootste ontwikkelaars.
Hoe lang blijft Microsoft Axum ondersteunen? Mag ik verwachten dat code die ik nu schrijf over 10 jaar nog bruikbaar is? Hoe zit het met OSX en Linux ondersteuning?
Het is een aanvulling op het .NET framework. Ik vrees dus dat dit niet erg veel vandoen heeft met OSX en Linux.
Wat code betreft die binnen 10 jaar nog bruikbaar is: als je programmeert volgens de kunst en de juiste afspraken volgt, dan is de meeste software, eventueel na een paar beperkte aanpassingen, vrijwel altijd en overal 10 jaar later nog bruikbaar. Dat is zo onder Windows, Linux, OSX en whatever welke andere "serieuze" omgeving...
Mav.
als je programmeert volgens de kunst en de juiste afspraken volgt, dan is de meeste software, eventueel na een paar beperkte aanpassingen, vrijwel altijd en overal 10 jaar later nog bruikbaar
Maar dan moet je 10 jaar later wel een compiler hebben met ondersteuning voor Windows 9 of 10 en .NET zoveel... Praat eens met Visual Basic programmeurs over de overgang van VB5 naar VB.NET om te horen hoe leuk het is om met een berg goede code te zitten die geport moet worden omdat er geen compilerondersteuning meer is.
Praat eens met Visual Basic programmeurs over de overgang van VB5 naar VB.NET
Dat verhaal zit nog vers in het geheugen. En toch: dat was toen behoorlijk goed gedocumenteerd, Microsoft had allerlei zaken voorzien om dat makkelijk te maken en als je software, opnieuw, een beetje deftig geschreven was, dan was allemaal nog niet zo erg. Zij die er echter met de pet naar gegooid hadden, zijn waarschijnlijk nu nog bezig met hun software te herschrijven.
Hier is overigens niets nieuw onder de zon: als je b.v. je Mac-software deftig had geschreven, dan was de overgang naar OS X wel wat gedoe, maar zeker geen ramp. Als je er een zootje van gemaakt had, dan kon je maar beter opnieuw beginnen.
In praktijk is het gros van de programmeeromgevingen die vandaag bestaan voor de verschillende platformen best in orde en is het vooral de programmeur zelf die er een knoeiboel van kan maken...
Mav.
Daarbij mensen konden immers in hun oude VB6 compiler de oude software onderhouden, en geleidelijk overgaan
Klopt helemaal. Als je daarenboven ziet dat de runtime van VB6 gesupporteerd is onder Vista en zelfs onder Windows 7, dan denk ik dat jouw vraag "werkt dit allemaal nog binnen 10 jaar" ruimschoots postitief beantwoord werd (VB6 is van 1998)...
Mav.
Microsoft helpt??? Whahaha, ze willen geholpen worden om hun product beter te maken. Microsoft doet zoiets toch niet voor niets, elk voordeel heb zijn nadeel en omgekeerd.
Tuurlijk, MS maakt dit gratis zodat je vendor lock-in krijgt. Maar dat probeert iedereen. Zelf moet je de afweging maken of je project geschikt is voor dit soort oplossingen. Het klinkt als een short-term iets, maar dat is soms best ok. Voor langere termijn oplossingen wil je misschien iets robuusters.
Maar dat probeert iedereen.
Nee, niet iedereen. Het zijn voornamelijk de closed-source applicaties die vendor-lockin creëren. Met Qt bijvoorbeeld heb je geen last van vendor-lockin.
Om te kunnen reageren, dient u ingelogd te zijn.
2 jaar geleden: 13 februari 2010
3 jaar geleden: 13 februari 2009
4 jaar geleden: 13 februari 2008
5 jaar geleden: 13 februari 2007
14 jaar geleden: 13 februari 1998
IDG Nederland is uitgever van: AppFish
, CIO, Computer!Totaal, Computerworld, ITworld, Jobworld, MacWorld, RAW fotomagazine, TechFish, Tips & Trucs, Webwereld en Zoom.nlMeer informatie: IDG Nederland, IDG.com, Privacy-statement, Cookie-statement Hosting by Terremark.
