On 07/04/2012 01:01 PM, Gene Wirchenko wrote:
On Wed, 04 Jul 2012 12:32:58 -0700, Patricia Shanahan <pats@acm.org>
wrote:
On 7/4/2012 10:47 AM, Gene Wirchenko wrote:
On Wed, 04 Jul 2012 10:14:54 -0700, Patricia Shanahan <pats@acm.org>
wrote:
On 7/4/2012 10:04 AM, Gene Wirchenko wrote:
...
Knowing something of the layer below (or even more) can
help one
get more out of the system. If you insist on using black boxes and
keeping it that way, then you do not understand the system.
...
I've treated emacs and other tools as black boxes on systems I
understood at every level down to details of the processor design.
If you know the system to that level, it is not a black box.
If you define "black box" in such a way that it is not possible to treat
something as a black box even if one understands the system, then "If
you insist on using black boxes and keeping it that way, then you do not
understand the system." is indeed a tautology.
No. If you know the inner details, it is going to help in using
such a system. You do not just turn off your knowledge. You will not
have a black box in that case.
This is different from black box testing where you can do so.
(Just base your tests on use cases, not the algorithm. (Of course, I
like white box testing, too.))
I prefer a more functional view of "black box" in which one can treat
something as a black box by only considering and using its external
features, regardless of deeper understanding.
I do that, too.
I detect common ground between your viewpoints, with differences in the
nuances.
Patricia's point of view relates to trust of a tool or layer.
You can rest on what an IDE does, as far as its functions go. You don't
question its ability to syntax-color your source beyond the settings
screen. That's a black-box approach.
Many recommend, however, that you understand what it does generate for
source code, build scripts, server configuration, and other tasks that
one normally would script, or perform through an external
service-management interface. NetBeans Ant scripts are an infamous
example, as are Eclipse .classpath files. Both of these work in
IDE-osyncratic ways that tend to play poorly with industry standards.
Ditto the GUI generators. Many laud the Matisse generator built in to
NetBeans, but its code style is its own. What if you gotcherself a
corner case?
At this point you lose trust in the IDE at least somewhat. While you
have no doubt that the symbols you type into a dot-java file will
persist to disk safely, you might question its choices for variable
scope or 'toString()' implementation.
The common ground, then, is to blackbox what you trust and whitebox or
greybox what you doubt, to varying degrees. "Trust but verify", in the
language of arms agreements.