Hi Edward and All:
To me your post is very interesting and needs
time to think it through and respond (i enjoyed
reading it and digesting each point/thought).
It is certainly thought-provocative. To me,
it is about a fundamental mechanism of programming.
Just a brief preliminary comment for now (later
with details, hopefully). Many people noticed a mystery
of programming. I tried to understand programming
from control science viewpoint, and the idea was that
a building a program is a inverse problem, and what
a programmer does is to use the "use cases", "unit tests"
and similar constraints to reconstruct step-by-step
the program using the mismatches as a feedback to update/correct
the program. Each constraint typically has input/output or similar
format (e.g., context/data).
Imagine a 'programmable' (that is, flexible, reconfigurable)
material. Each constraint is in fact a control which drives an
iterative process of reconfiguring the material so that the
constraint is matched. Sure, the material can be pre-configured
('the art of programming') to make its programming "more efficient"
(vs. doing it from scratch).
So, looking from this angle, you came to the heart of programming.
Unit tests is a reference/control info to incrementally build-up
a program - 'configure' a programmable material. To me, this is
how animals (and some humans) 'effortlessly' program their behavior
under control of 'environmental challenges'.
Sure, this line of thinking has a long history, but in the
programming world i think this is relatively fresh and exciting
development, and your focus on tools for code exploration and
understanding seems to me extremely valuable. Actually, this
'probing' technique is applicable to exploration of the whole class of
'complex systems'.
Does this 'angle' make any sense?
My best, Val
Edward K. Ream wrote:
I have gotten *zero* responses to my 42 post:
http://groups.google.com/group/leo-and-pylint/browse_thread/thread/3cf874d0b41eefab
I should have remembered that nobody reads long posts. So here is the
Aha in a nutshell:
Unit tests are not just for testing! They are *the* master tool for
programming, design, testing, refactoring, studying code, or *anything
else*.
Think of a unit test as the root of a tree. The tree represents any
task (including designs).
The unit test *formalizes*, *automates* and *protects* the task or
design.
Expanding the notion of unit tests this way is a *stupendous* Aha. It
has *totally altered* how I approach my work.
For details, read the long post. Print it out, including the lengthy
"reply". Study it. Respond. Please.
Edward
P.S. I expect three possible responses to this post, and the longer
post:
1. Yeah, I knew that. Welcome to the club of highly effective
programmers.
2. Wow! I didn't know that. This is going to change my life.
3. Huh? I have no idea what you are talking about. Your writing
sucks. Can't you do a better job of explaining your ideas?
EKR
--
You received this message because you are subscribed to the Google Groups
"leo-editor" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/leo-editor?hl=en.
