Joel on Software

Joel on Software   Joel over Software

 

Andere "Joel on Software" artikelen in het Nederlands

Andere "Joel on Software" artikels in het Engels

Email de auteur (uitsluitend in het Engels)

 

How Microsoft Lost the API War


Door Joel Spolsky
Vertaald door Ariene M. Kroeze
zontag, 13 juni 2004

Vandaag de dag hoor je vaak de theorie: "Microsoft is fini. Zodra Linux werkelijk doorbreekt op desktopcomputers en desktopapplicaties worden vervangen door webapplicaties, zal het machtige imperium omkukelen."

Hoewel er absoluut waarheid schuilt in het feit dat Linux een reusachtige bedreiging vormt voor Microsoft, zijn de voorspellingen over de ondergang van het bedrijf uit Redmond, om het zachtjes uit te drukken, voorbarig. Microsoft heeft een ongelooflijke hoeveelheid contant geld op de bank en is nog ongelooflijk winstgevend.  Er moet heel wat gebeuren willen ze echt omvallen. Ze moeten minstens 10 jaar werkelijk alles fout doen voordat ze serieus in gevaar komen, en dan weet je het nog niet… ze zouden zich op het laatste moment kunnen omvormen tot bedrijf dat in schaaf-ijs doet. Dus, schrijf ze niet zo gauw af.

In het begin van de jaren 90 dacht iedereen dat het voor IBM over en uit was: mainframes, dat was geschiedenis!  Daarna voorspelde Robert X. Cringely  dat  het tijdperk van de mainframes zou eindigen op 1 januari 2000,  omdat dan alle Cobol-applicaties  zouden vastlopen en deze applicaties (waarvan, naar men beweerde, de broncode al lang geleden verloren was gegaan) zouden niet worden aangepast maar worden herschreven voor client-server platforms.

Nou,  ga maar na! Mainframes zijn er nog steeds, er gebeurde niks op de eerste januari van 2000 en IBM hervond zichzelf  als een groot technisch adviesbureau dat toevallig ook in staat is om goedkope plastic telefoons te maken.  Dus om nu uit een paar gegevens de conclusie te trekken dat het afgelopen is met Microsoft, is echt veel te kort door de bocht.

Er is echter wel sprake van een ongehoord fenomeen dat grotendeels onopgemerkt is gebleven:  het strategische kroonjuweel van Microsoft, de Windows API,  is verloren gegaan. De hoeksteen waarop het machtige monopolie van Microsoft rust en dat aan de basis staat  van de ongelooflijk winstgevende Windows en Offices  licenties, die vrijwel volledig de inkomsten van Microsoft voor hun rekening nemen (en een enorme reeks van niet of nauwelijks winstgevende productlijnen verborgen houden), de Windows API doet er voor ontwikkelaars niet meer zo toe. De kip met de gouden eieren is nog niet geheel dood, maar is wel op sterven na dood en niemand heeft het in de gaten.

Dit gezegd hebbend, bied ik mijn excuses aan voor de gezwollen taal in de vorige paragraaf. Ik vrees dat ik begin te lijken op die hoofdartikelschrijvers in economische katerns, die maar doordrammen over het strategische kapitaal van Microsoft: de Windows API.  Het neemt een bladzij of wat om uit te leggen wat ik werkelijk bedoel en om mijn argumenten uiteen te zetten.  Trek alsjeblieft nog geen conclusies voordat ik volledig heb uiteengezet wat ik werkelijk bedoel. Dit wordt een lang artikel. Ik moet uitleggen wat de Windows API is, ik moet aantonen waarom het strategisch gezien van het grootste belang is  voor  Microsoft, ik moet uitleggen hoe het verloren is gegaan en wat de gevolgen daarvan zullen zijn op de lange termijn.  En omdat ik het over grote trends heb,  zal ik daarbij overdrijven en generaliseren.

 

Ontwikkelaars, Ontwikkelaars, Ontwikkelaars, Ontwikkelaars

 

Kunt u zich de definitie van een besturingssysteem herinneren? Het is datgene dat de onderdelen van een computer aanstuurt zodat programma’s daar gebruik van kunnen maken. Mensen maken zich niet erg druk over besturingssystemen: ze maken zich druk over programmatuur:  tekstverwerkers,  chat-programma’s,  e-mails, boekhoudprogramma’s, websites met foto’s van het Hilton in Parijs. Aan een besturingssysteem op zich heb je niks. Mensen kopen een besturingssysteem  omdat ze daarmee allerlei nuttige programma’s  kunnen gebruiken  En daarom is het nuttigste besturingssysteem die waarmee je de de nuttigste programma’s  kunt gebruiken.

Het spreekt dus voor zich dat als je probeert een besturingssysteem te verkopen, je topprioriteit is ervoor te zorgen dat softwareontwikkelaars software willen ontwikkelen voor jouw besturingssysteem. Daarom sprong Steve Blamer op het prodium rond , terwijl hij uitriep “Ontwikkelaars, ontwikkelaars, ontwikkelaars, ontwikkelaars". Zij zijn zo belangrijk voor Microsoft, dat de enige reden voor Microsoft dat ze de ontwikkeltools voor Windows niet gratis weggeven,  is omdat ze concurrende softwareverkopers  (althans, die er nog over zijn)  nog wel een beetje ruimte gunnen, omdat een grote variëteit van ontwikkeltools voor hun platform aantrekkelijker is voor ontwikkelaars. Maar het liefst zouden ze de ontwikkeltools  gewoon weggeven. Via hun Empower ISV programma kun je vijf complete sets van de MSDN Universal (ook wel bekend als  werkelijk elk Microsoft product, behalve Flight Simulator) krijgen voor pakweg $375.  Command line compilers voor de .NET talen zitten erbij, en ook de .NET runtime, … voor niets. De C++ compiler krijg je  tegenwoordig voor niets. Allemaal om software ontwikkelaars aan te moedigen om programmatuur voor het .NET platform te bouwen en net niet genoeg om bedrijven als Borland de nek om te draaien.

 

Waarom Apple and Sun geen computers kunnen verkopen

 

Nou ja,  dat klinkt natuurlijk een beetje bezopen, natuurlijk kunnen Apple en Sun wel computers verkopen,  alleen niet aan de meest lucrative computermarkten die er zijn, namelijk die voor de zakelijke desktop en die voor de homecomputer.  Apple zit nog steeds ergens onderin de markt met wel heel kleine getallen en de enige mensen met een Sun desktop zijn te vinden bij Sun. (Begrijp me alsjeblieft goed, ik praat over grote trends.  Als ik het heb over ‘niemand’ bedoel ik eigenlijk ‘minder dan 10.000.000 mensen’ en zovoort en zovoort).

Hoe komt dat? Omdat je op een Apple of Sun computer geen gebruik  kan maken van Windows programma’s, of, als je dat al wel kan, dat doet in een of andere dure emulatie die niet zo  goed werkt.  Nogmaals,  mensen kopen computers om de programma’s die ze er op kunnen gebruiken en er is zo veel meer fanatstische desktop programmatuur te koop voor Windows dan voor Mac dat  het niet gemakkelijk is om een Mac-gebruiker te zijn.

 

Terzijde Wat is eigenlijk dat ‘API’-gedoe?

Als je een programma schrijft, laten we zeggen, een tekstverwerker en je wilt een menu laten zien of een bestand wegschrijven, dan moet je het besturingssysteem vragen dat voor je uit te voeren. Daarvoor gebruik je een  speciale set van functieaanroepen die per besturingssysteem verschilt. Deze set functieaanroepen wordt de API genoemd: het is de ‘interface’ dat een besturingssysteem, zoals Windows  ter beschikking stelt aan software ontwikkelaars, die er dan ook gebruik van maken, of ze nu een tekstverwerker bouwen, een spreadsheet of wat dan ook. De API bestaat uit duizenden en duizenden gedetailleerde en pietluttige functies die programmeurs kunnen worden gebruikt  en die er voor zorgen dat het besturingssysteem aardige dingen doet zoals het tonen van een menu, het lezen en schrijven van bestanden,  of zaken die meer voor ingewijden is bedoeld, zoals het weergeven van een datum in het Servisch of buitengewoon complexe zaken als het weeergeven van een webpagina  in een venster op uw scherm.  Als uw programma gebruik maakt van functies onder Windows dat werkt dat programma niet onder  Linux, want die heeft andere API functies, ook al doen die soms min of meer dezelfde dingen. En dat is de belangrijkste reden waarom software voor Windows  niet werkt op een Linux machine. Als je het voor elkaar wilt krijgen om een Windows programma te gebruiken onder Linux dat moet de hele Windows API, die bestaat uit duizenden gecompliceerde functies  opnieuw implementeren en dat is bijna net zoveel werk als Windows zelf te implementeren, iets dat Microsoft duizenden  manjaren heeft gekost. En als je maar een klein foutje maakt, of  maar één functie achterwege laat die een bepaald programma nodig heeft dan crasht dat programma.

 

En daarom is de Windows API zulk belangrijk kapitaal voor Microsoft.

(Ik weet het, ik weet het, op dit punt aangekomen is 2.3 % van de wereld die Macintoshes gebruikt bezig om hun e-mail programma op te warmen om mij een vernietigende brief te zenden over hoeveel ze wel niet van hun Macs houden. Nogmaals, ik praat over belangrijke trends en generaliseer erop los, dus verspil daar geen tijd aan,  ik weet hoeveel jullie van je Mac houden. Ik weet dat alles wat jullie nodig hebben erop draait. Ik hou van jullie,  maar jullie zijn slecht 2.3 % van de wereld, dit artikel gaat dus niet over jullie.)

 

De twee machtsblokken binnen Microsoft.

 

Er zijn binnen Microsoft twee machtsblokken, die ik, een beetje tongue-in-cheek, het Raymond Chen Kamp en het MSDN-magazine kamp  zal noemen.

Raymond Chen maakt als ontwikkelaar  deel uit van het Windows team binnen Microsoft.  Hij zit er al sinds 1992 en zijn weblog  The Old New Thing staat tjokvol met gedetailleerde technische verhalen over waarom sommige zaken in Windows zijn zoals ze zijn,  soms gaat het over heel onnozele dingetjes, en waarvoor erg goede redenen blijken te zijn.

De zaken op Raymonds weblog die het meest imponeren zijn de verhalen over de ongelooflijke inspanningen die het Windows team zich heeft getroost om gedurende jaren de backwards compatabiliteit in stand te houden:

Bekijk het eens vanuit het standpunt van een klant. Je hebt programma’s X, Y en Z gekocht.  Toen  installeerde je Windows XP.  Vanaf dat moment crasht je computer soms zomaar opeens en programma Z doet het al helemaal niet meer. Dus vertel je je vrienden, dat ze  Windows XP niet moeten  installeren. Want dan crasht je computer soms zomaar opeens en programma Z werkt  niet meer. Ga je je systeem onder de loep nemen om er achter te komen dat X de crashes veroorzaakt en dat programma Z het niet doet omdat het gebruik maakt van niet-gedocumenteerde windows messages? Natuurlijk niet! Je brengt de doos met Windows XP terug en je wilt je geld terug. (Programma’s X, Y en Z kocht je enkele maanden geleden. De 30-dagen-geld-terug garantie geldt niet meer. Het enige dat je kan terugbrengen is Windows XP.).

De eerste keer dat ik hiervan hoorde kwam door een ontwikkelaar  van het succesvolle spel SimCity, die me vertelde dat er een cruciale fout in hun applicatie zat:  het maakte gebruik van geheugen vlak nadat het was vrijgegeven, een absoluut taboe, dat toevallig goed ging op DOS maar niet zou werken onder Windows omdat geheugen dat daar wordt vrijgegeven direct gebruikt wordt door bijvoorbeeld een actief ander programma. De testers van het Windows team werken allerlei populaire programma’s af, al testend om er zeker van te zijn dat ze goed functioneren, maar SimCity bleef maar crashen. Ze meldden dat aan de Windows ontwikkelaars, die nauwgezet SimCity ontrafelden en er stap voor stap door heen gingen in een debugger. Ze vonden de fout en voegden speciale code toe die nagaat of SimCity misschien actief is en als dat het geval is, het toewijzen van geheugen in een speciale stand zet, zodat je geheugen toch kan gebruiken nadat het al  is vrijgegeven.

Zo ongewoon was dit niet. Het Windows testteam is enorm groot en een van hun belangrijkste taken is te garanderen dat iedereen veilig en wel zijn besturingssysteem kan upgraden,  ongeacht de applicaties die zijn geïnstalleerd en dat die applicaties blijven werken, zelfs als die applicaties dubieuze dingen doen of niet-gedocumenteerde functies gebruiken of min of meer leunen op halve fouten die toevalligerwijs zo werken in Windows versie n maar niet meer  in Windows versie n + 1. Het is in feite zo dat als je eens rondkijkt in de AppCompatibility sectie van je registry, je een hele lijst zult zien van applicaties die van Windows een speciale behandeling krijgen, waarmee een heel stel oude fouten en eigenaardig gedragingen nageaapt worden waardoor die applicaties als het ware gewoon werken. Raymond Chen schrijft, ‘ Ik word buitengewoon kwaad als mensen Microsoft ervan beschuldigen dat die er met opzet voor zorgt dat applicaties niet meer werken door OS upgrades. Als welke applicatie dan ook niet meer werkte onder Windows 95, beschouwde ik dat als een persoonlijke mislukking. Ik heb heel wat slapeloze nachten doorgebracht om fouten in programma’s van derden op te lossen, alleen maar om ze te aan de praat te krijgen onder Windows 95.’

Veel ontwikkelaars en ingenieurs zijn het met deze werkwijze niet eens. Als een applicatie iets dubieus doet of leunt op niet-gedocumenteerde code,  vinden zij het niet nodig dat die nog steeds werkt als het besturingssysteem wordt ge-upgrade.  De ontwikkelaars van het Macintosh besturingssysteem bij Apple behoorden altijd tot dit kamp. Dat is de reden waarom zoveel programma’s uit de eerste dagen van de Macintosh het later niet meer deden. Bijvoorbeeld, veel ontwikkelaars waren gewend om hun Macintosh-programmatuur sneller te laten lopen door pointers uit de jump table te kopiëren en deze direct aan te roepen in plaats van dit te laten lopen via de interrupt  functie, zoals officieel de bedoeling was.  Zelfs ondanks dat in Inside Macintosh, Apple’s officiële bijbel voor het programmeren op de Macintosh,  een technische opmerking stond die zei ‘u kunt dit niet doen’, deden ontwikkelaars het toch en het werkte en hun programmatuur liep sneller… totdat de volgende versie van het besturingssysteem kwam en het allemaal helemaal niet meer liep. Als het een applicatie betrof die door een bedrijf was gemaakt dat er zich inmiddels niet meer met bezig hield (en dit gold voor de meeste bedrijven) , nou… jammer dan, pech gehad.

Daar staan DOS applicaties tegenover, die ik in 1983 heb geschreven voor de eerste IBM PC en die het nog steeds zonder enige strubbeling doen, dankzij het Raymond Chen kamp bij Microsoft. Ik weet het wel, het gaat natuurlijk niet alleen om Raymond:  het is de totale modus operandi  van het kernteam van de Windows API.  Maar Raymond heeft er het meest over gepubliceerd via  zijn excellente website  The Old New Thing,  dus voor mij staat hij voor dat hele team.

Dat is één kamp. Het andere kamp is wat ik ben gaan noemen het MSDN Magazine kamp,  vernoemd naar het gelijknamige tijdschrift voor ontwikkelaars dat vol staat met opwindende artikelen over alle mogelijkheden waarmee je jezelf een hoop ellende op de hals haalt door allerlei alleen bij insiders bekende koppelingen met Microsoft producten te gebruiken in je eigen software. Het MSDN Magazine kamp is altijd bezig je te overtuigen om nieuwe en gecompliceerde buitengaatse technologieën te gebruiken zoals COM+, MSMQ, MSDE, Microsoft Office, Internet Explorer en zijn componenten, MSXML, DirectX (de allerlaatse versie a.u.b.), Windows Media Player en Sharepoint… Sharepoint! Dat niemand heeft; een werkelijk compleet arsenaal van externe afhankelijkheden waarvan elk op zich je een krankzinnige koppijn kan bezorgen als het moment daar is dat je applicatie in gebruik wordt genomen door een betalende klant, bij wie het dan niet goed werkt. De technische naam daarvoor is DLL hel. Het werkt wel hier, waarom werkt het daar dan niet?

Het Raymond Chen kamp denkt dat het voor ontwikkelaars belangrijk is dat iets wat ze een keer geschreven hebben het ook overal doet (nou ja, tenminste op een Windows machine). Het MSDN Magazine kamp denkt dat ontwikkelaars het belangrijk vinden dat ze de beschikking krijgen over waarlijk geweldig krachtige stukken code, die met geringe inspanning enorm veel opleveren. Althans, zolang ze bereid zijn om de prijs te betalen voor ongelooflijk gecompliceerde problemen bij de integratie van al die van elkaar afhankelijke code en de ermee samenhangende installatieproblemen, om het nog maar niet te hebben over de gigantische leercurve. 
Het Raymond Chen kamp is het allemaal te doen om bestendigheid. Alsjeblieft, maak dingen dingen niet slechter, laten we de dingen die werken, werkend houden.
Het MSDN Magazine kamp moet
aan de lopende band gigantische stukken nieuwe technologie blijven produceren waar niemand gelijke tred mee kan houden.

En nu komt waarom het eigenlijk draait.

 

Microsoft heeft het geloof in de backwards compatibliteit verloren

 

Bij Microsoft heeft het MSDN Magazine kamp de strijd gewonnen.

De eerste grote slag was binnen door Visual Basic.NET niet backwards compatibel te maken met VB 6.0. Dit was letterlijk de eerste keer sinds mensenheugenis dat, nadat je een upgrade kocht van een Microsoft product,  je oude data (met name  de code die je geschreven had in VB6) niet fout- en  geruisloos kon worden overgezet. Het was de eerste keer dat een Microsoft upgrade geen respect toonde voor werk van gebruikers tijdens de vorige versie van het product.

En toch leek de hemel niet naar beneden te komen, althans niet binnen Microsoft. VB6 ontwikkelaars kwamen weliswaar in opstand, maar zij zouden hoe dan ook toch verdwijnen, omdat de meeste van hen zakelijke ontwikkelaars zijn die toch zouden migreren naar webontwikkelingen. De schade op lange termijn bleef verborgen.

Met deze  klinkende overwinning op zak, nam het MSDN Magazine kamp de zaak over. Plotseling was het OK om dingen te veranderen. IIS 6.0 kwam uit met een afwijkend threading model waarmee sommige oude applicaties niet uit de voeten konden. Ik was geschokt toen ik ontdekte dat  onze klanten met Windows Server 2003 problemen kregen met het gebruiken van Fog Bugz.

Vervolgens bleek .NET 1.1 niet volledig backwards compatibel met 1.0. En nu de geest uit de fles was, kreeg het OS team de smaak te pakken en besliste dat, in plaats van nieuwe toepassingen aan de Windows API toe te voegen ze het maar volledig gingen vervangen. In plaats van Win32 moeten we nu zo’n beetje klaar zijn voor WinFX: de volgende generatie Windows API. Waarin alles is veranderd. Gebaseerd op .NET met managed (voorgebakken) code. XAML. Avalon. Jaja, enorm verbeterd ten opzichte van Win32, ik geef het toe. Maar geen upgrade: een breuk met het  verleden.

Ontwikkelaars, die toch al niet zo gelukkig waren met de complexiteit van het ontwikkelen voor Windows, zijn en-masse ontrouw geworden aan het Microsoft platform en zijn gaan ontwikkelen voor het web. Paul Graham, die Yahoo! Stores opzette in het prille begin van de dotcom hausse, vatte het welbespraakt samen: “Er is meer reden dan ooit voor starters om Web-based software te schrijven, omdat het schrijven van desktop software steeds minder leuk is. Als je tegenwoordig desktop software wil schrijven doe je dat op door Microsoft gedicteerde voorwaarden, gebruik makend van hun API’s en je weg vindend om de fouten heen die in hun besturingssysteem zitten. En als het je lukt om iets te schrijven dat echt succes heeft, dan kom je er al gauw achter dat je vooral marktonderzoek heb gedaan voor Microsoft.

Microsoft, zo groot als het tegenwoordig is, met veel te veel ontwikkelaars, en verslaafd aan de opbrengsten van steeds weer nieuwe Window-versies, besloot plotseling dat het misschien wel een aardig idee was om alles opnieuw uit te vinden. Verrek, dachten ze, we kunnen het best allemaal nog eens doen, voor de tweede keer. Het oude Microsoft, het Microsoft van Raymond Chen, zou zaken als Avalon, het nieuwe grafische systeem, hebben opgezet als een set DLL’s die gebruikt zou kunnen worden op elke versie van Windows en die als onderdeel van de installatie zou kunnen worden meegeleverd bij applicaties die er gebruik van maken. Technisch gezien is er geen reden om het niet zo te doen. Maar Microsoft moet aannemelijk maken dat je Longhorn moet kopen en ze proberen een totale ommekeer tot stand te brengen, zoals de totale ommekeer toen DOS vervangen werd door Windows. Het probleem is alleen dat Longhorn niet zo’n grote verbetering is ten opzichte van Windows XP; het komt niet eens in de buurt van het grote verschil tussen DOS en Windows. Het is waarschijnlijk niet aantrekkelijk genoeg om mensen er toe over te halen om allemaal nieuwe computers en programmatuur aan te schaffen zoals dat wel het geval was bij Windows. Nou ja, misschien lukt het nog, voor Microsoft is het absoluut van groot belang, maar wat ik er tot nog toe van heb gezien heeft mij niet overtuigd. Microsoft heeft op heel wat verkeerde paarden gewed. Bijvoorbeeld, WinFS, dat verkocht wordt als een zoekmethode door bestanden die echt werkt omdat het bestandssysteem een relationele database wordt. Maar het gaat voorbij aan het feit dat de echte manier om het zoeken te laten werken is door het zoeken te laten werken. Laat me alsjeblieft niet voor elk bestand meta-data moeten opgeven, die mij dan helpt bij zoeken, waarbij ik nota bene gebruik moet maken van een query language. Doe mij nou een lol, en zoek die verdomde harde schijf af, vlug en voor elke willekeurige tekst die ik intik, door van full-tekst-indexering en andere technologieën gebruik te maken die al bekend waren in 1973.

 

Automatisch transmissie is aan kop

 

Begrijp me niet verkeerd… Ik denk dat .NET een fantstische ontwikkelomgeving is en Avalon met XAML een geweldige verbetering ten opzichte van de oude manier om GUI-programmatuur te schrijven voor Windows. De belangrijkste verbetering van .NET is het feit dat het automatisch geheugenbeheer kent.

Veel van ons dachten in de jaren negentig dat de grote strijd zou gaan tussen procedureel en object georienteerd programmeren, en we dachten dat object georienteerd programmeren de productiviteit van een programmeur enorm zou verbeteren. Ik dacht er net zo over. Sommige mensen denken het nog. Het ziet ernaar uit dat we het mis hadden. Object georienteerd programmeren is superhandig, maar het heeft niet die enorme push aan de productiviteit gegeven die ons was voorgespiegeld. Productiviteitsverbeteringen die echt voor ons van belang zijn, danken we aan talen die het geheugenbeheer automatisch voor hun rekening nemen. Door gebruik te maken van reference counting (waarbij objecten worden automatisch vrijgegeven zodra er niet meer aan gerefereerd wordt) of garbage collection (waarbij geheugen wordt verzameld waaraan nog wel gerefereerd wordt zodat de rest automatisch kan worden vrij gegeven); door talen als Java, Lisp, Visual Basic (zelfs 1.0), Smalltalk of de eerste de beste scripttaal. Als jouw programmeertaal je toestaat dat je je een stuk geheugen toe-eigent zonder dat je erbij hoeft na te denken hoe dat geheugen weer wordt vrijgegeven zodra je het niet meer nodig hebt, maak je gebruik van een managed- memory taal (een taal met voorgebakken geheugenbeheer) en ben je aanzienlijk efficiënter dan iemand die een taal gebruikt waarin iemand het geheugengebruik expliciet moet aansturen. Als je iemand hoort opscheppen  over hoe effectief de door hem of haar  gebruikte taal wel niet is, dan wordt waarschijnlijk de meeste productiviteitwinst gehaald uit het automatische geheugenbeheer, zelfs als hij of zij het ten onrechte aan iets anders toeschrijft.

 

Terzijde
Hoe komt het dat automatisch geheugengebruik je zoveel productiever maakt? 1) Omdat je  f(g(x))  kunt schrijven zonder je zorgen te maken hoe je het geheugen dat gebruikt wordt voor de door g teruggekregen waarde, weer vrij moet geven, hetgeen betekent dat je functies kan gebruiken die interessante complexe data types als waarde teruggeven en functies die interessante xomplexe data types omvormen,  zodat je op een hoger abstractie niveau kan werken.  2) Omdat je geen enkele tijd hoeft te besteden aan het vrijgeven van geheugen of opsporen van memory leaks (weggelekt geheugen.) 3) Omdat je je niet meer zo zorgvuldig hoeft af te vragen waar een functie verlaten kan worden, als je er niet zelf voor moet zorgdragen dat alles weer netjes opgeruimd wordt achtergelaten.

 

Race-autoliefhebbers zullen me nu waarschijnlijk haatbrieven gaan schrijven, maar het is mijn ervaring dat er maar één situatie is, bij normaal rijden, waarin een automatische transmissie minderwaardig is aan handmatig schakelen. Op dezelfde manier zie je dat terug bij software-ontwikkeling: in bijna alle gevallen is automatisch geheugenbeheer superieur boven handmatig geheugenbeheer en resulteert in een aanzienlijk grotere productiviteit bij programmeurs.

Al je gedurende de eerste jaren van Windows desktopapplicaties ontwikkelde had Microsoft twee manieren in de aanbieding om dat aan te pakken: C code schrijven met directe aanroepen van de Windows API en zorg dragen voor je eigen geheugenbeheer of Visual Basic gebruiken en het geheugenbeheer voor je laten verzorgen. Dit zijn de twee ontwikkelomgevingen die ik persoonlijk gedurende de afgelopen 13 jaar het meest heb gebruikt. Ik ken ze binnenstebuiten en mijn ervaring is dat Visual Basic is beduidend meer productief is. Ik heb dezelfde code vaak een keer in C++, de Windows API aanroepend en een keer in Visual Baisc, en C++ gebruikte altijd drie of vier keer meer werk. Waarom? Geheugenbeheer. De eenvoudigste manier om dit te begrijpen is om de documentatie te bekijken voor een willkeurige API functie die een string als functiewaarde teruggeeft. Let eens op hoeveel woorden er gebruikt worden om uit te leggen wie het geheugen moet alloceren dat nodig is voor de string, en hoe je er achter komt hoeveel geheugen dat moet zijn. Vaak zie je dat je de functie tweemaal moet aanroepen, de eerste keer geef je aan dat je nul bytes hebt gealloceerd, en dan mislukt de aanroep met de boodschap ‘niet genoeg geheugen gealloceerd’, maar gelukkig word je ook verteld hoeveel geheugen je wel had moeten alloceren. Dat is wanneer je het geluk hebt geen functie aan te roepen die een lijst met strings teruggeeft of een structuur met een variabele lengte. Hoe dan ook, eenvoudige operaties als het openen van een bestand, er een string naar schrijven en hem dan weer sluiten kunnen wel een pagina met code vragen. In Visual Basic heb je voor dezelfde operaties drie regels nodig.

Maar goed, je hebt dus te maken met deze twee programmeer werelden. Iedereen geeft wel toe dat de wereld van managed (voorgebakken) code duidelijk superieur is aan de wereld van unmanaged code. Visual Basic was (en waarschijnlijk, blijft) de best verkochte taal aller tijden en ontwikkelaars geven er de voorkeur aan boven C of C++ voor het ontwikkelen voor Windows, ondanks het feit dat in de naam van het product het woord “basic” voorkwam dat maakte dat hardcore programmeurs het uit de weg gingen, ook al was het een tamelijk moderne taal met een handvol  mogelijkheden om object georienteerd te programmeren en maar heel weinig oude troep van vroeger (regelnummers en het LET statement zijn dezelfde weg gegaan als de hoelahoep). Het andere probleem met VB was dat als je er gebruik van maakt de VB runtime meegeleverd moet worden, en dat was nogal wat voor shareware die over modems moest worden verspreid en, nog erger, andere programmeurs liet zien dat je programmatuur was ontwikkeld in (de schande!) Visual Basic.

 

Eén runtime om alles te regelen

 

En toen kwam .NET. Dat was me een project, het keigave project dat eens en voor al alles onder een noemer zal brengen en alle troep in een keer opruimt.  Het zou natuurlijk geheugenbeheer bevatten. Het zou ook nog Visual Basic bevatten, maar het zou ook een nieuwe tal verdiene, een die in de geest werkelijk hetzelfde is als Visual Baisc maar met een syntax die op C lijkt met accolades en puntkomma’s. En het allerbeste, de nieuwe Visual Basic/C bastaard zou C# worden genoemd, dus je zou nooit meer iemand hoeven te vertellen dat je een “Basic” programmeur bent. Al die verschrikkelijken Windows functies met hun haken en ogen en backward-compatibliteits fouten en strings die ik-weet-niet-wat-nu-weer voor betekenis hebben, zouden er eruit gegooird worden, en vervangen door een enkele, schone, object georienteerde interface die maar een soort string kent. Een runtime om het hele zootje te regelen. Het was prachtig. En ze hebben het klaargespeeld, technisch gesproken is .NET een fantastische programmeeromgeving die het geheugen voor je beheert en die een rijk, compleet en consekwent samenhangende interface naar het besturingssyteem heeft en een rijke, overcomplete en keurige object bibliotheek voor de basis operaties.

En toch, mensen gebruiken .NET niet echt veel.

Ja,  tuurlijk, ze bestáan wel.

Maar het idee om de warboel van Visual Basic en Windows API programmering onder een noemer te brengen door een compleet nieuwe, van de grond-af opgebouwde programmeer ongeving met niet een, twee, maar drie talen (of zijn het er vier?)  lijkt op het idee dat je twee ruziemakende kinderen stopt door keihard “kappen nou” te roepen, nog harder dan zij het doen. Dat werkt alleen op TV. Als je in het echte leven tegen twee ruziemakers schreeeuwt “kappen nou”, is het resultaat een nog ergere ruzie tussen drie mensen.

(Trouwens, voor degene die de geheimzinnige maar politiek beladen wereld van  blog syndication feed formats volgen, zien daar hetzelfde gebeuren. RSS raakte verbrokkeld over meerdere, van elkaar verschillende versies, onnauwkeurige specificaties en een hoop politieke gevechten en de poging om alles in een keer op te lossen door nog een ander formaat te creëren die ze Atom noemden heeft geresulteerd in meerdere, van elkaar verschillende versies van RSS plus een versie van Atom, onnauwkeurige specificaties en een hoop politieke gevechten. Wanneer je probeert om twee tegen over elkaar staande krachten onder een noemer te brengen door een derde alternatief in het leven te roepen, dan zit je op het einde met drie tegen over elkaar staande krachten. Je hebt niks onder een noemer gebracht en je heb niks echt opgelost.)

Dus in plaats dat .NET voor eenheid en eenvoud heeft gezorgd, hebben we nu te maken met een grote spraakverwarring van zes kanten, en iedereen probeert uit te vogelen welke ontwikkelstrategie er nu moet worden gevolgd en of ze in staat zijn om hun bestaande applicaties over te zetten naar .NET.

Het doet er niet toe hoe hardnekkig Microsoft is in haar boodschap naar de markt  (“gebruik .NET nu maar-je kunt ons vertrouwen”), de meeste van hun klanten gebruiken nog steeds C, C++, Visual Basic 6.0 en het klassieke ASP, om het maar niet te hebben over al die ontwikkeltools van andere bedrijven.  En degene die .NET gebruiken gebruiken ASP.NET, om webapplicaties te ontwikkelen, die worden gebruikt op een Windows server maar die geen Windows clients nodig hebben, wat een essentieel punt is waarop ik dieper zal ingaan als ik het over het web zal hebben.

 

Oh, wacht, er komt nog meer!

 

Nu Microsoft zo veel ontwikkelaars aan het werk heeft gezet is het niet voldoende om de gehele Windows API één keer opnieuw uit te vinden, nee, ze gaan hem twee keer opnieuw uitvinden. Op de PDC (Professional Developers Conference) van verleden jaar kondigden zij aan de volgende major versie aan van hun besturingssysteem, met de codenaam Longhorn, die onder meer zal bestaan uit een compleet nieuwe user interface API, met de codenaam Avalon, van de grond af opgebouwd om alle voordeel te trekken uit de snelle grafische kaarten in moderne computers en de realtime 3D weergave. Als je op op dit moment een Windows GUI applicatie aan het bouwen bent waarbij je gebruik maakt van Microsofts “officiële” nieuwste-en-te-gekke Windows programmeer omgeving, WinForms, dan zal je alles over twee jaar nog eens overnieuw moeten doen als je dan het gebruik van Longhorn en Avalon wilt honoreren. Dat verklaart waarom WinForms in totale stilte ter wereld is gekomen. Ik hoop dat je er niet al te veel in geinvesteerd hebt. Jon Udell vond een dia van een presentatie van Microsoft met het opschrift “Hoe moet ik kiezen tussen Windows Forms en Avalon” en vroeg zich af, “Waaróm moet ik kiezen tussen Windows Forms en Avalon? Een goede vraag, en een waarop hij geen goed antwoord gevonden heeft.

Dus, je hebt de Windows API gehad, je hebt VB gehad en nu heb je .NET, in meerdere taal-smaken en wen maar niet teveel aan een en ander, want we zijn Avalon aan het maken, begrijp je, die alleen op het allernieuwste besturingssysteem van Microsoft zal draaien  en dat voorlopig nog nieeeeemand zal hebben. En persoonlijk heb ik nog geen tijd gehad om .NET echt te doorgronden en hebben we de twee applicaties van Fog Creek nog niet overgezet van het klassieke ASP en Visual Basic 6.0 naar .NET omdat het voor ons geen return on investment is. Geen.  Wat mij betreft komt het neer op Schieten en Bewegen: Wij zouden Microsoft een plezier doen als wij zouden ophouden met nieuwe functies aan onze bug tracking software en content management software  toe te voegen en in plaats daarvan een paar maanden tijd zouden verspillen om die software over te zetten naar een andere programmeeromgeving, iets waar geen klant voordeel van heeft en me dus nul extra omzet oplevert en wat dus een complete verspilling van tijd is, maar fantastisch voor Microsoft, omdat zij ook content management software hebben en ook bug tracking software,  dus voor hen is niets leuker dan dat ik in cirkels ronddraai om alles aan te passen aan de waan van de dag en dan ook nog eens twee jaar om een Avalon versie te bouwen,  terwijl zij ondertussen nieuwe functies toevoegen aan hun eigen vergelijkbare sofware. Natuurrrlijk.

Er is geen ontwikkelaar met een volledige baan die genoeg tijd heeft om alle nieuwe ontwikkeltools afkomstig uit Redmond bij te houden, al was het alleen maar omdat er teveel bijdehante werknemers bij Microsoft ontwikkeltools maken!

 

Het is niet 1990

 

Microsoft werd groot gedurende de tachtiger en negentiger jaren, toe de groei van personal computers zo waanzinnig was dat er elk jaar meer nieuwe computers werden verkocht dan er op dat moment in gebruik waren. Wanneer je in die tijd een product maakte dat alleen werkte op nieuwe computers je toch binnen twee jaar de wereld kon overnemen, zelfs als niemand overstapte naar jouw product. Dat is de reden waarom Word en Excel WordPerfect en Lotus compleet konden vervangen: Microsoft wachtte gewoon op de volgende generatie nieuwe hardware en verkocht Windows, Word en Excel aan bedrijven die toewaren aan hun volgende lading nieuwe bureau computers (en soms was het hun eerste aanschaf).  Dus in veel opzichten heeft Microsoft nooit hoeven leren hoe je een bestaande infrastructuur over kunt zetten van product N naar product N + 1. Als mensen een nieuwe computer krijgen zijn ze best in hun nopjes dat ze er de nieuwste Microsoft spullen bijkrijgen, maar ze zijn nauwelijks geneigd om het alleen daarom te doen. Dat deed er ook niet toe toen de PC industrie als een gek groeide, maar nu de wereld verzadigd is met PC’s, waarvan de meeste Prima in Orde zijn, Dank U, realiseert Microsoft zich plotseling dat het veel meer tijd vraagt om de nieuwste spullen te slijten. Toen ze vonden dat “End of Life” (een soort laatste houdbaarheidsdatum) van Windows 98  was breikt aankondigden een zoete dood wilde laten sterven, werd duidelijk dat nog zo veel mensen er gebruik van maken dat ze moesten beloven het oude krakende omaatje nog een paar jaar te ondersteunen.

Spijtig genoeg kunnen deze Nobele Nieuwe Strategieën, zaken dus als .NET en Longhorn en Avalon, het bouwen van een nieuwe API om daarmee mensen mee te verleiden, niet lekker werken als iedereeen nog tevreden is met zijn computer uit 1998. Zelf als Longhorn in 2006 leverbaar is, zoals de bedoeling is maar wat ik nog geen seconde geloof, zal het nog jaren duren voordat genoeg mensen het hebben, laat staan dat het algemeen beschouwd wordt als een ontwikkelplatform. Ontwikkelaars, ontwikkelaars, ontwikkelaars en ontwikkelaars zullen zich niet door Microsofts meervoudige persoonlijksheidsstoornis laten vertellen hoe we software moeten ontwikkelen.

 

Betreed het web

 

Ik begrijp niet hoe ik het voor elkaar heb gekregen zover te komen zonder het Web ter sprake te brengen. Iedere ontwikkelaar dient een keuze te maken als een nieuw software-programma moet worden opgezet: het kan gebouwd worden voor gebruik via het web of het kan gebouwd worden als een “rich client” applicatie die op een PC draait.  In basis zijn de pro’s en contra’s eenvoudig: Webapplicaties kunnen eenvoudiger worden ingezet, en ‘rich clients’ hebben een betere performance en reactietijd die een veel betere user interface mogelijk maken.

Webapplicaties zijn gemakkelijker in te zetten omdat er geen sprake is van een installatie. Het installeren van een webapplicatie houdt in het intikken van een URL in de adresbalk. Vandaag het ik Googles nieuwe emailprogramma geïnstalleerd door het intikken van Alt + D, gmail, Ctrl + Enter. Er zijn veel minder compatibiliteitsproblemen en problemen die samenhangen met andere software. Iedere gebruiker van uw product gebruikt dezelfde versie, dus je hoeft nooit een stel verschillende versies te onderhouden. Jhet doet er niet toe van welke programmeeromgeving je gebruik maakt, wanneer je hoeft het alleen maar aan de praat te krijgen en te houden op je eigen server. Je applicatie is automatisch beschikbaar voor werkelijk elke redelijke computer op deze aardbol. En ook de gegevens van je klanten zijn automatisch beschikbaar op werkelijk elke redelijke computer op deze aardbol.

Maar je betaalt een prijs voor het ‘smoelen’ van je user interface.  Hier volgende een paar voorbeelden van dingen niet echt goed mogelijk zijn in een webapplicatie:

  1. het bouwen van een snel tekenprogramma;
  2. het bouwen van een real-time spellingscontrole, waarbij de fouten met een rood golflijntje worden onderstreept;
  3. je gebruikers waarschuwen dat ze hun werk verliezen als ze bezig zijn hun browser af te sluiten;
  4. als een gebruiker iets gewijzigd heeft, maar een klein gedeelte van zijn scherm bijwerken, zonder dat je weer eerst helemaal langs de server moet;
  5. een interface die gebaseerd is op toetsgebruik en waarbij de muis niet nodig is;
  6. nogelijkheid om mensen door te laten werken als ze geen verbinding meer hebben met het internet.

Dit zijn allemaal niet zulke grote issues. Sommige ervan zulke binnenkort opgelost zijn door slimme  Javascript ontwikkelaars.  Twee nieuwe webapplicaties, Gmail en OddPost, beide e-mail applicaties hebben werkelijk keurig werk geleverd met het omzeilen of juist oplossen van sommige van deze issues. En het lijkt erop dat gebruikers niet zo zitten met kleine oneffenheden in de UI en wat vertraging in een web interface. Bijna alle normale mesen die ik ken zijn om de een of ander reden volmaakt gelukkig met web-based e-mail,  en het doet er niet toe dat ik hen probeer te overtuigen dat een ‘rich client’, ehh, richer is.

Dus de Web gebruikersinterface is er voor pakweg 80%, en zelfs zonder nieuwe webbrowsers kunnen we er waarschijnlijk 95% van maken. Voor de meeste mensen is dat meer dan genoeg en het blijkt zeker goed genoeg te zijn voor web-ontwikkelaars die er voor kiezen om bijna elke belangrijke nieuwe applicatie op te zetten als een webapplicatie.

Hetgeen plotseling betekent, dat de Microsoft API er niet zoveel meer toe doet. Webapplicaties hebben Windows niet nodig.

Het is niet zo dat Microsoft niet in de gaten had wat er gaande was. Natuurlijk hadden ze dat en zodra de gevolgen duidelijk werden stonden ze vol op de rem.  Beloofde nieuwe technieken als HTA’s en DHTML werden tegengehouden. Het Internet Explorer team lijkt te zijn verdwenen; het is al verschillende jaren niet meer in actie geweest. Er is geen sprake van dat Microsoft zal toestaan dat DHTML zal worden verbeterd met wat het al kan; het is gewoon te gevaarlijk voor hun kernactiviteiten, de ‘rich client’. Het enige deuntje dat je bij Microsoft hoort is: “Microsoft zet alles op de ‘rich client’”. Je vindt dat terug op vrijwel elke presentatiedia over Longhorn. Joe Beda, van het Avalon team, zegt het zo “Avalon en in het algemeen Longhorn is uitgangspunt voor Microsoft. Wij geloven in de kracht van de desktop, wij zullen op die plek en nergens anders onze beste kunsten gaan vertonen. We investeren in de desktop, we denken dat we daar op de juiste plek zijn, en we hopen dat we een nieuwe golf van opwinding te weeg kunnen brenegn…”

Het probleem is: het is te laat.

 

Het maakt me wel een beetje verdrietig

 

Het maakt me wel een beetje verdrietig. Het Web vind ik fantastisch maar webbased applicaties, met hun sloom reagerende en inconsistente user interfaces zijn een enorme stap terug in het normale gebruik.  Ik hou van mijn ‘rich client’ applicaties en zou gek worden als ik webversies zou moeten gebruiken voor applicaties die ik dagelijks gebruik: Visual Studio, CityDesk, Outlook, Corel Photopaint, Quickbooks. Maar dat is wel wat ontwikkelaars ons van plan zijn. Niemand (waarmee ik, nogmaals, “minder dan 10.000.000 mensen” bedoel) wil nog ontwikkelen voor de Windows API.  Geldschieters willen niet investeren in Windows applicaties omdat ze bang zijn voor de concurrentie met Microsoft. En de meeste gebruikers lijken minder dan ik te zitten met klungelige Web UI’s.

En nu waar het uiteindelijk altijd op uitdraait: Ik heb opgemerkt (en het werd bevestigd door een bevriende recruiter) dat Windows API programmeurs hier in New York City die in C++ en voor COM kunnen programmeren per jaar ongeveer $130.000 verdienen, terwijl een gewone Webapplicatie programmeur die managed code talen (scripttalen) gebruikt (Java, PHP, Perl en zelfs ASP.NET) ongeveer $80.000 per jaar verdient.  Dat is een enorm verschil en toen ik hierover eens met sommige vrienden van Microsfot Consulting Services praatte gaven ze toe dat Microsoft een hele generatie ontwikkelaars is kwijtgeraakt. De reden dat het $130.000 kost om iemand te huren die COM-ervaring heeft is omdat niemand de laatste acht jaar of zo, nog zin had om te programmeren voor COM, dus je moet een echte senior vinden, vaak zitten ze al in het management, en hem ervan overtuigen dat hij een baan moet nemen als een doordeweekse programmeur, die moet klooien met (God sta me bij) marshaling en monikers en apartment threading en aggregaties en tearoffs en een miljoen andere zaken die, uiteindelijk alleen Don Box ooit heeft begrepen en zelfs Don Box kan deze dingen nauwelijks meer aanzien.

Tot mijn grote spijt moet ik zeggen dat een enorme groep ontwikkelaars zich lang geleden heeft bekeerd tot het web en niet meer terug wil. De meeste .NET ontwikkelaars zijn ASP.NET ontwikkelaars, en bouwen voor de webserver van Microsoft. ASP.NET is briljant; ik heb nu tien jaar webontwikkeling achter de rug en het is werkelijk een generatieverschil met alles wat je daarbuiten vindt. Maar het is servertechnologie, dus de gebruikers kunnen elke soort desktop gebruiken die ze maar willen. En het werkt best goed onder Linux als je Mono gebruikt.

Dit alles voorspelt niet veel goeds voor Microsoft en voor de winst die ze maken met hun krachtige API. De nieuwe API is HTML en de nieuwe winnaars in de markt van de applicatie-ontwikkelingen zullen de mensen zijn die HTML laten zingen.



De originele versie van dit artikel verscheen in het Engels onder de naam

How Microsoft Lost the API War

 

Joel Spolsky is de oprichter van Fog Creek Software, een klein softwarebedrijf in New York. Hij studeerde af aan de Yale universiteit, en heeft als programmeur en manager gewerkt bij Microsoft, Viacom en Juno.


De inhoud van deze pagina's vertegenwoordigt de mening van één persoon.
Alle inhoud Copyright ©1999-2005 door Joel Spolsky. Alle rechten voorbehouden.

FogBUGZ | CityDesk | Fog Creek Software | Joel Spolsky