Path: csiph.com!usenet.pasdenom.info!gegeweb.org!de-l.enfer-du-nord.net!feeder1.enfer-du-nord.net!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail From: "Paul E. Bennett" Newsgroups: comp.lang.forth Subject: Re: Olympic Spririt for Forth Followup-To: comp.lang.forth Date: Wed, 10 Oct 2012 09:29:46 +0100 Organization: Hidecs Consultancy Lines: 50 Message-ID: References: <7xhaqc69sz.fsf@ruckus.brouhaha.com> <22489610.pnmz7RBueg@sunwukong.fritz.box> <7x391wsjjp.fsf@ruckus.brouhaha.com> <8997734.FPiUxMsVlB@sunwukong.fritz.box> <7xbogk71fc.fsf@ruckus.brouhaha.com> <1599725.MmvXeDaymt@sunwukong.fritz.box> <7xmx03bclp.fsf@ruckus.brouhaha.com> <1797229.DCWuoRaQ3N@sunwukong.fritz.box> <7x4nmauisn.fsf@ruckus.brouhaha.com> <2028826.7QaYsnLk6j@sunwukong.fritz.box> <7xd30x4t9c.fsf@ruckus.brouhaha.com> <2012Oct5.130829@mips.complang.tuwien.ac.at> <7xa9vyuwlo.fsf@ruckus.brouhaha.com> <8544930.KNqXtjcyQv@sunwukong.fritz.box> <7xwqz1vcdu.fsf@ruckus.brouhaha.com> <1755828.uKo66frh80@sunwukong.fritz.box> <7xa9vw9r99.fsf@ruckus.brouhaha.com> Reply-To: Paul_E.Bennett@topmail.co.uk Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7Bit X-Trace: individual.net B6605E3IinsjWC2e8epHKAksnkj52in272TCr0X6ceudhBMFWNXfDEdbX2mBusziRz Cancel-Lock: sha1:3kanRxl/oVetmUR79q5IaBqHFes= Mail-Copies-To: Paul_E.Bennett@topmail.co.uk User-Agent: KNode/0.99.01 Xref: csiph.com comp.lang.forth:16148 rickman wrote: > On 10/9/2012 4:10 AM, Mark Wills wrote: >> On Oct 9, 5:57 am, Paul Rubin wrote: >>> >>> Yeah, leaving bounds checks active all the time is probably best >>> practice in most applications. >>> >> >> No. Testing the absolute living shit out of the application to prove >> that a bounds error cannot happen is the way. Detecting a bounds error >> is very nice in a spreadsheet, or an app to convert GIFs to JPGs or >> whatever. It's not really much use on the rocket firing system on the >> alignment correction system of a telecommunications satellite. Out of >> bounds? Whoop de doo... You're still going to fall out of orbit! > > Really, you think the way to design critical systems is to test them > extensively? Unless you do an "exhaustive" test which means *proving* > it is truly exhaustive, testing can't prove the absence of errors. NASA > demonstrates this on a regular basis with some expensive and spectacular > failures, not to mention the tragic ones. Do you really think their > failures are because they didn't test the "absolute living shit" out of > them? As someone stated in another thread:- "Dijkstra had once said "Programs are either so simple that they contain obviously no bugs, or so complex that they contain no obvious bugs". Forth helps you to create lots of simple words which, even when gathered together, can still give the facility of remaining simple enough that errors become obvious (although programming style will have some impact on this). Even so, it is important to inspect and test each and every word to ensure they all meet their individual requirements (as you have stated them in the glossary entry). Part of the lesson to the younger generation should be how to analyse a problem and break it down into simpler fully understandable bits. They then need to explore suitable simple solutions that can build to solve the whole problem. Forth (philosophy and style) is great for such work. -- ******************************************************************** Paul E. Bennett............... Forth based HIDECS Consultancy Mob: +44 (0)7811-639972 Tel: +44 (0)1235-510979 Going Forth Safely ..... EBA. www.electric-boat-association.org.uk.. ********************************************************************