Warning: philosophical thread hijack ahead ;)
> A scientific theory is an approximation of observed behaviour
> WITH NO KNOWN HOLES.
This has nothing to do with the topic at hand, but it is a pet peeve of
mine. Sorry for hijacking a thread.
The above is a good one sentence approximation of what a theory is in
science, but it's not correct. The classic example, of course, is
quantum mechanics, which is a very good theory, and has the glaring
notorious hole of lacking an explanation for gravity.
>
> Once there are known holes in the theory, it's not a
> scientific theory. At best it's an approximation, but quite
> possibly it's just plain wrong.
>
Alas, the difference between theory and practice is much larger in
practice. Most scientific theories have known holes in them. Not
always as glaring as the lack of quantum gravity, but always present.
There are even well documented cases where the theory was not supported
by the observations, so the observations were, eventually, redone, only
to determine that they were done wrong in the first place; so it's not
even as simple as 'must agree with reality'.
Science, once you lift the lid is a very messy endevour.
> And that's my point. Specs are not only almost invariably
> badly written, they also never actually match reality.
Ooops. I'm going to have to go back on topic here. I think that a
large part of this debate over specs is due to looking at two different
aspects of specs. I have often worked in a world where specs were very
accurate, and kept current with reality. This is the world in which
specs are the basis for new things. When it works, it works very well.
Most of us, though, are living in the world of finished devices. The
problem in our world is that specs are allowed to bit-rot. Architects,
when they care a lot about their work, maintain two sets of plans, the
'as designed' plans and the 'as built' plans. We in the computer
industry, for a lot of reasons, tend not to maintain the 'as built'
plans.
> So don't talk about specs.
Unfortunately, even in our imperfect world of imperfect specs, we still
need them. Rather than 'don't talk about specs', in the real world, we
have to deal with 'here's a spec, add a grain of salt'. You don't get
interoperability without that, and you don't get code portability
without it either.
>
> Talk about working code that is _readable_ and _works_.
>
Once upon a time, we converted an (unnamed) fortune 500 company's C
compiler from vendor X to vendor Y. As head of the OS team, I
volunteered our kernel as a test ap. Eventually, we found a very
readable implementation of select that, unfortunately, was utterly
busted C code. "luckily", the old compiler had a bug in it that caused
it to generate working code for the utterly busted C code.
Needless to say that reality and the spec differed in this case.
And we fixed reality to match the spec.
> There's an absolutely mindbogglingly huge difference between the two.
>
Yes. "Be pragmatic about specs" is very good advice. "Ignore specs" is
a recipe for anarchy. ;)
We now return your thread to its regularly scheduled debate.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
| |
 |