«

On Wed, 18 Apr 2007 21:57:39 +0000, BobR wrote:

> Victor Bazarov <> wrote in message...
>> Howard wrote:
>> > Personally, I prefer Zen Programming. No need for compilers, or even
>> > code editors. The program simply is.
>>
>> IIUIC, when you practice Zen Programming, there *is* no program. Only
>> your awareness of it exists.
>
> Does this 'Zen Programming' have as steep a learning curve as C++? Is
> there an IDE for Zen, or is it all in your id(in your mind)?

You may use the "gzz" system:

http://www.nongnu.org/gzz/nutshell.html

Ah, but wait, it's "ceased to exist" (can we say it ever really did?) ...

http://www.nongnu.org/gzz/

....and been superseded by:

http://fenfire.org/

Quote:

"Everything has to do with everything else. Fenfire is a Free Software
project developing a computing environment in which you can express these
relationships and benefit from them."

--
Lionel B

* James Kanze:
>
> For the debugger, I agree. Because it's a tool that you'll
> normally only use two or three times a year. (About the only
> exception would be for post mortems, and how much effort does it
> take to remember the single command bt?)

Depends what a debugger is used for.

In at least half of the cases I don't debug to find some bug I've
introduced or some bug in the system I'm working on, but in order to
figure out how some library really works, e.g. what's called in what
order with what arguments, and how's that internal message dispatch?,
and what function or class is a good way to accomplish effect X, due to
lack of proper documentation or complete public interfaces.

And many times when using Visual Studio I just run the program in the
debugger as a matter of course, because if there is a bug (and they do
happen! ) what usually happens is that the program does something
like asserting or dereferencing a nullpointer, control is passed to the
debugger automatically, which either points out the offending line
directly or provides a call stack where that bug is very evident.

Debugging in Windows development using Microsoft's tools is, anyway,
very different from debugging a post mortem.

When the program is run and does something that in *nix would produce a
core dump, e.g. during testing, what happens in Windows development is
that the debugger is fired up automatically (Just In Time debugging),
and you get to inspect the live (suspended but restartable) process.
Those tools are very handy and productive. On the other hand, Charles
Petzold wrote an article about how the IDE tools dumb us down so that we
no longer really construct things but just put things together from
menus, canned programming, and I partly agree with that: it's come to a
point where a normal human being just can't keep track of all those tens
of thousands member functions and classes, and must rely on browsing and
try-and-fail, only dimly understanding why things appear to work and
relying on the heuristic that if it works for the most common case then
it probably works, which, not surprisingly, leads to heavy use of
debugging tools for the many cases where it doesn't really work, because
that heuristic is just a guideline that's more like a wish than reality.

--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?