On 01/14/12 22:06, Polytropon wrote:
On Sat, 14 Jan 2012 20:37:14 +1000, Da Rock wrote:
On 01/14/12 19:54, Robert Bonomi wrote:
From owner-freebsd-questi...@freebsd.org Sat Jan 14 02:32:15 2012
Date: Sat, 14 Jan 2012 09:28:21 +0100
From: Polytropon<free...@edvax.de>
To: Robert Bonomi<bon...@mail.r-bonomi.com>
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
Mee too - except that I didn't want to show that
"typical attitude". In fact, I tried to make a
(kinf of humourical) statement about a habit that
I could observe at many students when I was at
university.
Background:
When you write source code, you can make errors.
Compiler shows errors. Some students started
with "trial& error" to just silence the compiler.
One form was that all functional parts of the
program were enclosed in /* and */ (it was a
C class) - no errors, but no action. A different
approach was to arbitrarily (!) change the source
code, something like that:
void *foo(int blah, void *meow())(int ouch);
Hmmm... gives me segfaults. Maybe something's
wrong with the pointers?
void *foo(int blah, void **meow())(int ouch);
Not much better, segfaults too. How about that?
void *foo(int blah, void meow())(int *ouch);
Well... also not better. I've heared about parentheses,
maybe those can help?
void *foo(int blah), void *meow)(int ouch);
Shit, doesn't even compile anymore! Uhm... _what_ did
I change? Oh wait, I know:
void *foo(int blah, (void *)meow())(int ouch);
Just produces garbage, then segfaults... what could I
change next?
I think you get the idea.
Other students could not understand that even if a
program compiles without any errors, there _may_ be
the possibility that it doesn't do what they intended
it to do. They seemed to believe in some kind of
magical "semantic compiler":
int x, y, sum;
x = 100;
y = 250;
sum = a - b;
They expected the compiler to notice what's wrong here
if you consider the _meaning_ of the identifiers. It's
not that obvious if you use x, y, and z. :-)
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.<grin>
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... :)
I didn't want to complain about using a test case,
with determined variables (relative path vs. absolute
path) to see if the interpretation of "man 2 access"
was matching the actual inner workings of the function
in use. In fact, I would even judge this the _preferred_
method to be sure.
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).
Fully agree. Know your variables and construct a
test within a fixed environment. The result will
be a valid source of conclusion.
Now back to "trial& error": what if I use
brackets instead?
void *foo(int blah, void *meow[])(int ouch);
Hmmm... :-)
I think the problem these days is a combination of many things.
Firstly, in the old days (I sound like grandpa... :/ ) punch cards were
hard to do, time consuming, and machine time was very expensive. So
programmers had to get it right the first time (or close to it), and
documentation was paramount.
Secondly, in the early years the internet wasn't exactly up and running
(as such), and so global programming teams weren't a problem with
language differences (and people were taught far better english and
speling- whoops spelling :) none of this and other shortenings;
ambiguity kept to a minimum).
Thirdly, when things did become easier (gcc era?) the documentation
slipped, and programmers started getting more sloppy, as the mistakes
were easily fixed. The docs became more ambiguous, and language did
start slipping (globally- not just in computing).
Fourthly, globalisation occured, internet was up and running on a global
scale, international teams were working on programs, and people were
attempting to translate japanese manuals into english (if you catch my
drift... :) I used to be a Xeroid and this was a standing joke). So not
all docs were as clear anymore.
Lastly, we have the travesty of a lack of discipline in skills. Near
enough's good enough, and so on. No one is taking the time anymore to
become "skilled" - they want it now or never. Take a 6 week course and
become an expert. The masters and gurus are becoming few and far between
now (although there appears to be a nice concentration here- thats why I
stick around. Linux lists seem to have the cranky ones :) ). And so we
have the case as you have outlined Poly. That said the docs are getting
to be of not much help either unless you're partly clairvoyant too in
more cases than should be.
It is not always easy to articulate exactly what something does and how
it works, but the basics should be there. Given the global society we
live in with the numerous dialects its a hard task to try to ensure
everyone will understand precisely. Care needs to be taken to ensure
everyone does, though, if something in the code will blow something up.
Ideally, it would be handy to have translators on hand to help with
documentation projects, but that is not a feasible prospect. Examples
would probably work better than a thousand words (like a picture)- no
translation required.
Myself I believe that one needs to read the docs thoroughly and then if
it is ambiguous then run a test case, if all else fails: ask. But one
needs to be as exact as possible when doing anything. "Any job worth
doing is worth doing properly", and "god/devil is in the details" - Is
say "God _and_ the devil is in the details": if you don't pay attention
to the details the devil _will_ make sure it bites you in the ass!
Its a crazy world, though, isn't it? :)
_______________________________________________
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
