Het besturingssysteem UNIX is nauw verbonden met de programmeertaal C. Onmisbare UNIX structuren zoals het virtuele bestandssysteem, benoemde pijpen (invoeren met "opdracht < invoer" en doorvoeren met "opdracht > uitvoer") en ook het 4.2BSD UNIX sockets concept (1983) zijn in C en de C bibliotheken vastgelegd. In feite zijn alle moderne besturingssystemen (inclusief OS/2, Windows NT, 2000 en XP) op UNIX varianten gebaseerd. Vooral de MACH kernel was populair. UNIX werd de moeder van alle besturingssystemen.
Dit is geen toeval. Doordat UNIX in de hogere programmeertaal C geschreven werd kon de door UNIX gebruikte techniek relatief gemakkelijk naar andere platformen worden overgedragen. Dat was niet onbelangrijk, aangezien een gouden processorstandaard, zoals de nu gangbare (W)Intel compatibele x86 processor, nog niet bestond.
De basisingrediënten voor een besturingssysteem zijn een primitieve kernel, tekstmodus schil (shell), editor, assembler en c compiler. De overige programma's kunnen met compilers worden toegevoegd. Want zodra een platform over een goed werkende C compiler beschikt, zijn andere programma's naar dat platform om te zetten (porteren). Op die wijze werd niet alleen Linux groot, maar konden ook commerciële besturingssystemen van de in C geschreven BSD UNIX code profiteren.
De C programmeur schrijft zijn opdrachten niet in de taal van de processor, maar in de taal van zijn compiler. Dit maakt in C geschreven broncode in principe processor-onafhankelijk. De C compiler levert de vertaalslag naar de processor en het besturingssysteem. De C compiler werkt ze als volgt uit. Eerst worden de in C geschreven broncode (prog.c. header.h) door preprocesors en compilers in de assembleertaal vertaald. Vervolgens worden de voor de mens nog leesbare machine-instructies door een assembler in de binaire machinetaal (objectcode) omgezet. Ten slotte verbindt de linker de door het programma aangeroepen functies uit de c bibliotheken met de objectmodule van het programma (prog.o -> a.out). Dankzij UNIX' pipes concept (hier met => aangegeven) kan dat in een gang.
|
Hogere programmeertaal |
Preprocessor en compiler (processorspecifiek) |
Specifieke processor instructies (nog leesbaar) |
Assembler |
zoveel bits reeksen van enen en nullen |
|
Broncode |
===> |
Assembleertaal |
===> |
binaire machinetaal |
|
Hoger management |
De floormanager vertaalt (werkplekspecifiek) |
Doe dit, doe dat. |
uitvoerend personeel en "domme" technologie |
|
|
Targets |
===> <--feedback? |
Concrete werkinstructies |
===> <--feedback? |
Eindproduct |
Het gebruik van een hogere programmeertaal (Cobol, Fortran, C, C++, Pascal) heeft ook nadelen. Het hogere abstractieniveau de toegenomen flexibiliteit van een taal als c maken het weliswaar gemakkelijker om een programma te schrijven, maar het eindproduct zal eerder onbedoelde neveneffecten hebben. De ideale C compiler bestaat niet. Het delegeren van uitvoerende taken naar een C preprocesser, compiler en linker is vanwege het gebrek aan tijd en kennis van processor en besturingssysteem weliswaar noodzakelijk, maar ook riskant.
Een programmeur die in een hogere taal schrijft lijkt daarin op een directieven schrijvende directie die anderen (hoger en lager personeel) het werk laat doen. Het kan goed gaan, maar er gaat ook veel mis. Vooral als de directie de realiteit van de werkvloer (compiler en besturingssysteem) niet kent. Dan moet de directie niet mopperen, maar nagaan wat er mis ging. Belangrijk is dan hoe de feedback geregeld wordt. Worden de wrijvingen tussen theorie en praktijk opgemerkt? Wordt er uitgebreid getest? Verstaat iedereen hetzelfde onder kwaliteit? Spreekt iedereen dezelfde taal? In de regel is dat zelden het geval.
Helaas
zijn programmeurs niet alleen aan de nukken en grillen van hun
compilers overgeleverd. Ze werken in een context.
Bij de ontwikkeling van UNIX werkten getalenteerde wetenschappers samen om een algemeen bruikbaar besturingssysteem te maken. De programmeurs waren tevens als de eindgebruiker van het product. Ze waren de eerste enthousiaste UNIX en c gebruikers. De producten die ze bij de ontwikkeling gebruikten, kenden ze van haver tot gort. Ze wisten wat ze en deden wat ze wilden. Het resultaat was een revolutionair en verbluffend goed werkend besturingssysteem (Zie: Van Unix naar Linux).
Maar veel hedendaagse programmeurs hebben de pech dat ze door een bedrijf ingehuurd worden om de niet zo realistische ideeën van externe opdrachtgevers uit te werken. Hun direct leidinggevende (technische) productmanagers staan onder druk van directies, accountmanagers en klanten. Maar de eindgebruikers kennen ze niet. Ze kennen slechts de specificaties die door anderen opgesteld zijn. En als ze pech hebben zitten daar nog meer managers tussen, die met directies en IT-ers, maar zelden met de noodlijdende eindgebruikers spreken. Het cynisme en het misverstand liggen dus op de loer.
De programmeurs staan onder tijdsdruk om snel te produceren. Als ze niet snel genoeg zijn, gaat de opdracht misschien naar India. De gemakkelijkste manier om dan maar aan de onrealistische doelstellingen van hun management te voldoen is om het gewenste product zo goed mogelijk te implementeren en de bugs en onvermijdelijke tekortkomingen weg te moffelen onder een glimmende motorkap. Voor het laatste hoeven ze niet veel te doen: ze hoeven alleen maar de Windows API aan te roepen. Die is in uiterlijk vertoon gespecialiseerd. En hiermee zijn de oppervlakkig naar het product kijkende managers al snel tevreden. De problemen worden pas zichtbaar als de eindgebruikers hun werk moeten doen.
De distributeurs en bedrijven verkopen het product vervolgens weer aan de echte eindgebruikers: Ze presenteren het pakket als iets dat hij of zij wil en nodig heeft. Een monopolistische aanbod schept de vraag. Ook als wordt de klant hierbij uitgekleed. Maar diezelfde eindgebruikers (particulieren, medewerkers van een bedrijf) hadden daar geen zeggenschap over. Er werd voor hen gedacht. Door andere mensen die het met andere ogen zien. Eindgebruikers mogen hoogstens de bugs en onmogelijkheden rapporteren, maar ze hebben geen garantie dat daar iets mee wordt gedaan. Zeker als het bekend worden van een miskoop de verantwoordelijke beslissers geld, status of goodwill kost, is ontkenning van feiten aan de orde van de dag.
Omdat ook minder getalenteerde programmeurs steeds sneller de meest ingewikkelder producten klaar moeten stomen, heeft het Get it right the first time principe plaatsgemaakt voor een trial en error manier van werken die in het stelselmatig uitbrengen van onrijpe programma's resulteert. Niet de ervaren programmeur bepaalt of iets af is, maar de door zijn manager vastgelegde deadline. En die volgt meestal het contract en de ontwikkelingen op de markt. Een versie 1.001 product (en zijn opvolgers) kunt u dus niet vertrouwen. En een versie 95 of 2000 al helemaal niet. De productnamen zeggen immers niets over de kwaliteit. Zie de unieke VPRO opname van Nederlands beroemdste programmeur professor Edsger Wybe Dijkstra (Denken als discipline) voor een kritische beschouwing hiervan.
Maar met een succesvolle verkoop is de kous nog niet af. Want commerciële softwareleveranciers hebben helemaal geen behoefte aan blijvend tevreden klanten. Een zelfgenoegzame klant komt hoogstens bij de leverancier terug als hij iets totaal anders wil. Bijvoorbeeld omdat hij gehoord heeft van concurrerende "me too" producten. Of omdat u uw activiteiten echt uitbreiden wilt. Dan heeft uw softwareleverancier een probleem. Want goede software slijt niet en is voor meerdere doelen inzetbaar. En eenmaal verkocht is altijd verkocht. Tenzij u de software ging huren (dom, dom, dom).
Voor een softwareleverancier is een klant die een onderhoudscontact nodig heeft veel meer waard. En dus heeft hij er geen baat bij om u "goed genoeg" software te leveren. Pas als hij u de software verhuurt, zou hij een vaste bron van inkomsten kunnen hebben. En met dat geld kan hij potentiele concurrentie opkopen of aan de "noodzakelijke verbeteringen" werken van zijn product.
In de Microsoft cursus Cursus rijk worden voor beginners - deel XII adviseert Jort Kelder om in vastgoedhandel te stappen. Voor beginners is dat inderdaad geen gek idee. Want een huis dat gebouwd is op een rots (bijbels) of op palen (Hollands), is geld waard. En een nieuw huis bouwen kost tijd en geld.
Maar als je al rijk bent en over een monopoliepositie beschikt is het makelaarschap in software nog veel winstgevender. Vooral vanwege je monopoliepositie. Want een softwarepakket erbij maken is slechts een kwestie van een CD-tje kopieren. De kostprijs hiervan is nihil. Heb je eenmaal de markt in handen, dan is geen concurrent meer in staat om een softwarepakket te verkopen onder jou kostprijs. Ze weten zich gewonnen, ze sterven een stille dood of je koopt ze op.
Omdat maar weinige programmeurs hun compilers en assemblers (laat staan de processor) kunnen volgen, is het schrijven van betrouwbare software geen sinecure. Om die reden wordt assembleertaal nog steeds gebruikt. Het schrijven van een programmaonderdeel of stuurbestand in assembleertaal is namelijk de enige methode om de instructieset van de processor direct te kunnen benaderen. Voor stuurbestanden en programma's die altijd precies moeten doen wat de programmeur beoogt - een belangrijk kenmerk van besturingssystemen en onder het set-uid bit lopende programma's- is assembleertaal de enige weg. Assembler is dus nog steeds een taal waarin kritieke delen van besturingssystemen moeten worden geschreven.
Om het overzichtelijk en effectief te houden programmeerden de eerste UNIX programmeurs zoveel mogelijk klein en modulair. Het UNIX pijplijn concept (1972) liet dit toe. Kleine, vaak in assembler geschreven utilities werden via de shell aaneengeregen om een grote klussen met tekstinvoer te doen. Dit staat bekend als het KISS principe: "Keep It Simple, Stupid".
This lay the groundword for the Unix "toolbox" philosophy: "Write programs that do one thing and do it well. Write programs to work together. Write programs that handle text streams, because that is a universal interface."
Belangrijke kenmerken van de UNIX programmeerfilosofie zijn:
Specialisering. Een programma moet zich richten op het zo goed mogelijk uitvoeren van één taak. Specialisering leidt niet alleen tot kwaliteitsverbetering, maar maakt ook een eerlijke vergelijking tussen soortgelijke (yet another) programma's mogelijk.
Samenwerking door Unix -filters. De uitvoer van ieder programma moet als invoer voor een ander programma kunnen dienen. Vandaar de voorkeur van UNIX programmeurs voor de saaie text streams.
Het goede behouden. Mochten nieuwe functies nodig zijn probeer ze dan samen te stellen uit de al bestaande programma's in plaats van het wiel opnieuw uit te vinden. Integreer door de "missing link" te vinden. Onderzoek alles, maar behoudt het goede.
Portabiliteit is belangrijker dan effectiviteit. Probeer niet een "snelle" oplossing te vinden die het alleen onder een besturingssysteem/programmeeromgeving doet, maar zoek naar algemene oplossingen..
Begrippen als specialisering , standaardisatie, uitwisselbaarheid, flexibiliteit en portabiliteit stonden voor deze eerste UNIX programmeurs centraal. Het KISS principe van de UNIX wetenschappers was geen populisme, maar bittere noodzaak. Onderzoek alles, maar behoudt het goede. Zo'n no-nonsense toolbox filosofie werkt natuurlijk alleen als de met elkaar concurrerende programma's met elkaar uitwisselbaar zijn. En dat is nu net wat de patentgeile commercie niet wil. Zie Commerciële software en monopolievorming voor het antwoord hierop: Onderzoek alles, maar behoudt de cliënten en de patenten. Hiervoor moest het KISS principe naar de dekstop verplaatst worden.
Tegenwoordig werken we grafisch. Het "Keep It Simple, Stupid" is naar de grafische gebruikersinterface (GUI) verplaatst. Eenvoudige symbolen en metaforen als buroblad, map en document maken uw computer gemakkelijker te bedienen. Dankzij die krachtige metaforen leren we snel. Een kind ziet aan de prullenbak wat de bedoeling ervan is. Via intuïtieve opmaak, context-sensitieve menuopties en voorgekauwde wizards regisseren softwaremakers het gebruik van hun programma's en besturingssystemen.
Maar wat leren we? En wie bestuurt wie? Degenen die slechts op de symboliek van de GUI afgaan zijn wel erg van de regie van knoppenmakers afhankelijk. Een muis- en knoppencursus "Windows voor ouderen" of "MS Office" helpt hier niet. Het maakt u weliswaar productiever op de Windows desktop, maar ook afhankelijker van het idioom en de manier van denken van de Windows en Office programmeurs.
Moderne computeranalfabeten zien de iconen, mappen en vensters op de desktop, maar hebben geen notie van de onderliggende begrippen als programma, bestand en shell. Ze bestuderen de knoppen van de programmatuur, maar ze beschikken nauwelijks over algemeen toepasbare computerkennis. Ze geloven in de desktop metafoor.
Maar met het uit zicht verdwijnen van de onderliggende basale UNIX CLI shell handelingen als pipes en text streams ("DOS" voor de gewone man) is een meer realistische kijk op de computer verdwenen. Als de afsluitknop niet bij de startknop zit, raken ze al in paniek. Kleine klussen zoals het naar eigen inzicht aanpassen van een batch of een scriptbestand zijn voor hen al onoverkomelijk problemen. En als een virus zich aankondigt met Happy New Year, komt het niet in hen op dat de schone schijn bedrieglijk is.
Maar deze onwetendheid noopte de Linux ontwikkelaars (met name die van de distributies) tot het ontwerpen van een grafische installatie- en configuratiehulpmiddelen voor het Linux systeem. Daar zijn ze - naar Windows maatstaven gemeten - in geslaagd, maar Linux blijft Linux. En ook onder Windows zullen virusscripts op de achtergrond blijven werken.
Is dit een probleem? Ja, want de gebruikersinterface van de software is weliswaar verbeterd, maar de kwaliteit onder de motorkap niet. Een computer blijft de simpele digitale (met enen en nullen werkende) rekenmachine die via complexe wiskundige vertaalslagen door middel van software letters, muziek en afbeeldingen produceert. Een fraaie GUI verbetert die kerntaak niet. Het zorgt er alleen maar voor dat nog meer computeranalfabete Lemmings zich in het onheil zullen storten. Doordat het op de desktop zo simpel lijkt, verwachten computergebruikers alles van hun besturingssysteem.
Commerciële softwareleveranciers zullen de analfabetenvisie toejuichen; zolang men maar voor hun producten kiest. Maar door toegenomen complexiteit en afgenomen flexibiliteit zal de kwaliteit van de commerciële software eerder verslechteren dan verbeteren. De gebruikersinterface werd eenvoudiger, maar de software niet. In feite zijn we al afhankelijk van complexe interfaces, compilers en GUI's waarvan geen enkele programmeur de werking nog overziet.
Sommigen vestigen hun hoop op artificiële intelligentie en een vijfde generatie computers die ons wèl zal begrijpen. Maar dat is veel te optimistisch gezien de praktijk van de huidige programmeertechniek. Enkele assembler programmeurs (ze zijn inmiddels op een hand te tellen) hebben een notie van de gedocumenteerde programmacode van de processor. Maar ze kunnen geen weet hebben van de bedoeld of onbedoelde ongedocumenteerde soft- en firmware in de Palladium processor.
De gedigitaliseerde maatschappij wordt een ramp als we de waarschuwingen van "bottom-up-thinkers" als EWD en Ken Thompson negeren.
Computer. Your nominators and endorsers for the Kanai Award consistently characterized your work as simple yet powerful. How do you discover such powerful abstractions?
Thompson. It is the way I think. I am a very bottom-up thinker. If you give me the right kind of Tinker Toys, I can imagine the building. I can sit there and see primitives and recognize their power to build structures a half mile high, if only I had just one more to make it functionally complete. I can see those kinds of things.
The converse is true, too, I think. I can't from the building imagine the Tinker Toys. When I see a top-down description of a system or language that has infinite libraries described by layers and layers, all I just see is a morass. I can't get a feel for it. I can't understand how the pieces fit; I can't understand something presented to me that's very complex. Maybe I do what I do because if I built anything more complicated, I couldn't understand it. I really must break it down into little pieces.
Het modulair programmeren bestaat nog steeds. Maar nu worden enorme bibliotheken aaneengeregen. Met de in die bibliothekenbrei (DLL Hell) opgeroepen abstracte functies worden programma's dynamisch uitgebreid. Programmeurs blijven gebonden aan de gegeven Application Programming Interfaces (API) van hun besturingssysteem. Als ze de broncode al kunnen kennen, zijn de effecten nog moeilijk te voorzien.
Maar meestal moeten programmeurs met ondermaatse documentatie werken. Zelfs Microsoft programmeurs begrijpen Microsofts SMB protocol al niet. Laat staan de vele duizenden bladzijden niet door hen geschreven Windows code. Is het dan vreemd dat iedere week een "critical security leak" in Windows software gevonden wordt?
Unix and Beyond: An Interview with Ken Thompson
The Art of Unix Programming van Eric Raymond
The UNIX Time-Sharing System: klassieker.
Computable Achtergrond: 31/03/00 - Monopoliepositie Microsoft staat vooruitgang in de weg
Professor Edsger Wybe Dijkstra (EWD) over programmeren (mpg van VPRO's Noorderlicht) oa dijkstra.mpg .
Castles Built on Sand: Why Software is Insecure
Nieuwe software is zelden een verbetering van Gert-Jan Lokhorst.
Niklaus Wirth: A plea for lean software: Wirths Law "Software gets slower faster than hardware gets faster" komt eigenlijk van Martin Reiser.
Geschichte der Programmiersprachen van Horst Zuse.
Microsoft trots op wat anderen brij noemen .