Dat bugs tot op heden nog steeds worden geaccepteerd, betekend niet dat software in de toekomst foutvrij kan worden ontworpen. Op het moment mag iedereen die weet hoe een "for"-loop werkt, zich programmeur noemen. Als we de vergelijking trekken met bv. het bouwen van schepen, dan zou dit hetzelfde zijn dat iemand zich scheepsbouwer mag noemen zodra hij weet dat een schip moet drijven. Dat komt omdat informatica zich nog steeds in de kinderschoenen bevindt.
Om software foutvrij te krijgen, zijn inderdaad methoden en bijbehorend tools nodig die software modellen kunnen doorrekenen. Ook Microsoft houdt zich hier mee bezig. Georges Gonthier van Microsoft Research gebruikt proof-systems (
http://coq.inria.fr/,
http://www.cl.cam.ac.uk/research/hvg/Isabelle/) om software correct te bewijzen. Hiermee zijn door delen van de Windows kernel in isolatie bestudeerd, fouten ontdekt en gerepareerd, die anders wellicht nooit ontdekt zouden zijn. Het nadeel van het gebruik van dergelijke software dat deze een hoge mate van abstractie en wiskundig inzicht vergen. Hetzelfde geldt voor het doorrekenen van het gedrag van gedistribueerde systemen en protocollen (
http://www.uppaal.com/,
http://spinroot.com,
http://mcrl2.org,
http://nusmv.fbk.eu/). Ik ben van mening dat software wiskunde wijze ontworpen zou moeten worden, ipv. een UML model tekenen, denken te weten hoe het zou moeten werken en dan er vrolijk op los programmeren. Een dergelijke werkwijze zou een hoop geld en ook mensen levens gespaard kunnen hebben.
Er zijn op het moment bedrijven die beweren dat ze door middel van formele methoden fout vrije code kunnen leveren. Helaas gaat deze vlieger alleen op voor relatief kleine software systemen. Het foutvrij opleveren realistische software systemen is op het moment echt nog een brug te ver. Ook al beloven ze vaak anders.
Te bedenken dat op ieder 1000 regels of code gemiddeld 2 fouten bevat, een vliegtuig voor zijn besturing vertrouwt op ruwweg 20 miljoen regels code, dan hebben we nog een lange weg te gaan. Om wederom de analogie met de scheepsbouw te trekken, als er van iedere 1000 klinknagels er 2 los zouden zitten, dan zou ik niet met dat schip willen gaan varen...
Daarom moet je softwaresystemen ook small en lean houden. Hoe minder code, hoe minder fouten en hoe overzichtelijker hij is, dus hoe sneller je die 2 fouten er uit gehaald hebt.
Verder worden schepen tegenwoordig gelukkig niet meer geklonken maar gelast.
Als we voor software eenzelfde revolutionaire oplossing kunnen bedenken, dan maken we een grote stap.
Als voorbeeldje:
Tot nu toe echter is hetgeen je kunt maken met de macro-recorder in Word VBA of Excel VBA veel minder krachtig en veel gevoeliger voor inputfouten (staat de cursor op de juiste plek) als iets dat handmatig ingetypt of aangepast is. Zelfs de meest simpele constructies zoals if-then-else, for-next, ontbreken, en Access VBA komt met de command-button-wizard niet veel verder als een paar eenvoudige standaard-handelingen het openen van een eerder gedefiniëerde form or report. UIteraard zijn er betere code-generatoren, maar het verschil in wat er met de taal mogelijk is, is enorm.
@celestion
Dat hangt ervan af hoe groot het schip is, hoeveel compartimenten de romp heeft, of er pompen aan boord zijn of een ander mechanisme (zelflozers) om het gemaakte water uit het schip te verwijderen.. Titanic verging ook door één lek (een scheur).
![[RSS]](http://tweakimg.net/g/if/v2/icons/rss_small.png){kind=icon}
![[quick]](http://tweakimg.net/g/if/icons/world_link_cropped.png){kind=icon}
16:59
16:44
Door 
![[show]](http://tweakimg.net/g/if/comments/button_down.png "Reactie uitklappen")
