From owner-freebsd-questions@FreeBSD.ORG Sat Jan 14 10:42:27 2012 Return-Path: Delivered-To: freebsd-questions@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C199A106564A for ; Sat, 14 Jan 2012 10:42:27 +0000 (UTC) (envelope-from freebsd-questions@herveybayaustralia.com.au) Received: from mail.unitedinsong.com.au (mail.unitedinsong.com.au [150.101.178.33]) by mx1.freebsd.org (Postfix) with ESMTP id 741D18FC15 for ; Sat, 14 Jan 2012 10:42:27 +0000 (UTC) Received: from laptop1.herveybayaustralia.com.au (laptop1.herveybayaustralia.com.au [192.168.0.179]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mail.unitedinsong.com.au (Postfix) with ESMTPSA id 40A225C26 for ; Sat, 14 Jan 2012 20:54:21 +1000 (EST) Message-ID: <4F115ADA.5050103@herveybayaustralia.com.au> Date: Sat, 14 Jan 2012 20:37:14 +1000 From: Da Rock User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:7.0.1) Gecko/20111109 Thunderbird/7.0.1 MIME-Version: 1.0 To: freebsd-questions@freebsd.org References: <201201140954.q0E9sOgM037468@mail.r-bonomi.com> In-Reply-To: <201201140954.q0E9sOgM037468@mail.r-bonomi.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: access(FULLPATH, xxx); X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Jan 2012 10:42:27 -0000 On 01/14/12 19:54, Robert Bonomi wrote: >> From owner-freebsd-questions@freebsd.org Sat Jan 14 02:32:15 2012 >> Date: Sat, 14 Jan 2012 09:28:21 +0100 >> From: Polytropon >> To: Robert Bonomi >> Cc: freebsd-questions@freebsd.org >> Subject: Re: access(FULLPATH, xxx); >> >> On Sat, 14 Jan 2012 02:00:12 -0600 (CST), Robert Bonomi wrote: >>> To repeat some advice from one of my Computer Science professors, many years >>> ago, whenever I asked 'how does it work' questions: "Try it and find out." >> I bet my professor can beat up your professor. :-) >> >> Mine used to say several times: "Trial and error is NOT >> a programming concept!" > As far as writing applications goes, that is _somewhat_ correct. > > However, 'trial and error' is _not_ the same thing as 'try it and find out'. > See the entire subject area of 'benchmarking'. > > And, the only way to definitively establish if an alternate approach is > 'better' -- i.e. 'faster', or 'smaller', or 'more efficient', etc. -- *IS* > to run a trial. > > Your professor undoubtedly would not of approved when I wrote bubble-sort > code that _out-performed_ any other sorting technique -- up to the limits > of memory. Or when I re-wrote an application that used binary searches > of records, with a new version that used a brute-force linear search. I > thought I could 'do it better/faster' than the existing code, but the only > way to "definitively" find out was to 'try it'. And the 'trial' proved > out -- the replacement code was 'merely' somewhat over 100 times faster. > *grin* Ha! Love it... :D > As far as 'doing it once' for the purpose of answering a 'how does it work' > question -- where one has _not_ read the documentation, *OR* the existing > documentation is _not_clear_, then simple experimentation -- to get *the* > authoritative answer -- is entirly justified. > > When I got the 'try it and find out' advice, I was asking questions about > situations where the language _specification_ was unclear -- there were > two 'reasonable interpretations' of what the language inthe speciication > said, and I just wanted to know which one was the proper interpretation. > > Now, given that the language in the specification _was_ abiguous and both > interpretations were reasonsble, different compiler builders could have > implemented differently, and 'try it and find out' was _necessary_ to > establish what that particular implementation did. There appears to be 2 schools of thought on this subject: a classic case of the "old" vs the "new", in this case "punchcards/slow compilers" vs "gcc/all-in-one compile, link and go"of todays tech. I saw a similar conversation about 5 years ago on the linux lists... :) Technically (depending on their era) they're both right. For reference as far as the linux lists played out no one won the argument, but it was a helluva nostalgic/historical debate! In the light of this conversation and given todays tech I'd say give it a shot unless you think something could break (as in fatal to service quality in production/hardware).