'Apple wil tirannieke controle over ontwikkelaars' - update

Serieus, als je iets als een garbage collector nodig hebt, moet je toch nog maar eens opnieuw leren programeren hoor. Waarom zijn we zo lui en verwachten we dat de taal het voor ons oplost? Heb je enig idee hoe gevaarlijk dat is? Je kan je software 10 keer zo snel laten performen door niet dergelijke afhankelijkheden te hebben.

Ten eerste is het natuurlijk pertinent onwaar dat de taal het voor je oplost - een taal is slechts een definitie van hoe een zinnig programma eruit ziet (het geeft aan hoe je een lap text omzet in een parse-tree). Een compiler zet zo'n taal om in machinecode, of in het geval van sommige moderne talen een bytecode die in een virtual machine of interpreter wordt uitgevoerd. Dat sommige talen geen expressiviteit hebben om objecten op te ruimen, betekent niet dat "de taal" het oplost - dat is en blijft natuurlijk een implementatie kwestie.

Ik kan me zomaar voorstellen dat sommige C programma's ook een factor 10 langzamer draaien als ik ze door compiler uit 1980 haal. Het is natuurlijk een beetje zot om de maker dan te gaan zitten beschuldigen dat het programma afhankelijkheden heeft van de optimalisaties die "in de compiler van vandaag de dag gebakken zitten". Als je jezelf wilt vrijwaren van alle afhankelijkheden die er zijn kun je uiteindelijk gewoon het beste machinecode gaan zitten kloppen, maar dat doen de meeste C-programmeurs dan toch ook maar weer niet (omdat dat zoveel werk is - maar datzelfde argument kan je opvoeren vóór het gebruik van een garbage collector).

Verder draaien garbage collectors wel eens in een aparte thread, waardoor een single threaded applicatie wel eens meer processortijd kan benutten dan een enkele core op een multicore pc. Natuurlijk kun je dit ook zelf programmeren in C, maar dat is een flink programmeerproject op zich (en natuurlijk wil je gewoon liever zo snel mogelijk je gave idee uitwerken tot iPhone applicatie zonder eerst een volledige toolkit zelf te moeten schrijven). Maar hierdoor kan je je wel voorstellen dat applicaties die veel tijd kwijt zijn aan geheugenbeheer, op een pc met meerder cores efficienter zouden kunnen draaien met een garbage collector dan zonder.

Ik vind het altijd een buitengewoon conservatief idee dat garbage collectors iets slechts zijn - een goed geprogrammeerd programma zou van een goed geprogrammeerde garbage collector amper hinder moeten ondervinden. En ik heb eerlijk gezegd helemaal geen zin om zelf een garbage collector te gaan programmeren als er gratis oplossingen beschikbaar zijn die veel efficienter zijn dan hetgeen ik zal produceren, tenzij ik natuurlijk bereid ben ziekelijk veel tijd in het maken van een zo efficient mogelijke garbage collector te steken (maar dat ben ik niet). Wat dat betreft ben ik van mening dat je soms gewoon moet durven om op de schouders van reuzen te gaan staan.

Maar het belangrijkste is natuurlijk dat het voor de gebruiker vaak gewoon weinig uitmaakt of een programma binnen 1ms of binnen 0.1ms zijn antwoord heeft uitgerekend. Voor de programmeur betekent het kwartier nadenken over waar de objecten allemaal opgeruimd moeten worden echter misschien wel het verschil tussen het bouwen van een kleine leuke feature of niet. En voor grote hoeveelheden data geldt ook nog steeds vaak de vuistregel "een slimmer algoritme geeft meer winst dan een taal-optimalisatie die een factor 10 oplevert".