Re: Forth tutorial like Ketman's

On Jun 15, 1:43 am, "Rod Pemberton" <do_not_h...@xxxxxxxxxxxxxxxx>
I've been on both sides of that coin.  In one world, you get
paid to make sure that is done in addition to the programming.  
In another world, i.e., personal coding, one frequently does
not have the time nor desire needed to do that.

This professional/personal distinction doesn't make much sense to me.
I don't write comments only because I'm paid to. I write comments
because when I come back to the code days, weeks, months, or years
later, I want to be able to get back inside my own head and understand
the often complex set of assumptions and requirements that were made
when I wrote the code. My memory isn't any better for professional
over personal projects. And as even personal projects can migrate to
other people, the comments serve to help others trying to review and
modify the code.

The idea that one doesn't "have the time nor desire needed" to write
comments probably comes from exposure to heavy-handed corporate
commenting styles. I've seen code like that and it looks like
someone's high school science project:

// Function: bloopFraz
// Purpose: Provide a fraz for the bloop.
// Description: <long tedious description here>
// Programmer: Andy Nonomous
// Date: June 21, 2011
// Project: Gerfloop 3000
// Arguments: number, integer, number of foo
// whoop, float, whoop factor
// Returns: gleep, float, new bloop coefficient

Nearly everything in this comment block is superfluous. The name of
the programmer, date, and project are available from the version
control system. The function name, arguments, and returns are given
by the function signature. The purpose is probably best expressed by
the name of the function. The only thing that really matters is the

Now obviously, there are exceptions. Maybe a warning that 'whoop'
can't be zero makes sense and should be part of the comment-- that
sort of thing. But in general, when people complain about writing
comments, it's because the comments are stupid. When a comment is
limited to just what is needed to express intent, there is no
reasonable objection other than laziness.

I'd suspect ColorForth etc is an example of one of Chuck's
personal programming projects.  So, I'd take it as "good
personal programming" over "good corporate programming" ...

Considering that ColorForth is also known as ArrayForth, and that
GreenArrays is using it as their primary development tool, one would
certainly hope that ColorForth has "grown up" and a more mature style
is seen in code produced by the company. We'll see.

Oh, I *love* those and hardcoded constants too. If you
don't know what they are, then you shouldn't be mucking
with that part of code ... period.

That's idiotic.  The issue isn't "mucking" with code.

It's an important issue though.  How do you stop incompetent
programmers from messing up the working code?

Easy, you don't hire incompetent programmers. Incompetence hasn't
been a problem anywhere I've worked for the past 20-whatever years,
but comp.lang.forth seems to be filled with people who work in Dilbert-
style organizations. My recommendation is to change jobs in that
case, and focus more on small companies where hiring decisions are a
big deal and carefully considered.

But let's say some marauding band of incompetent programmers breaks
into my office and starts changing all my constants. Since only
raving idiots would write code without version control, I can simply
identify the changes and revert them. And since any reasonable
organization believes in code reviews, the changes would be seen by
someone else who presumably wasn't incompetent.

There is also getting over the assumption that just because Mr. X
wrote some code, tested it, and claims that it is "working" doesn't
mean it is. I've more than once been in the situation of finding bugs
in code that worked by some side effect. I would then fix it, and
occasionally be met by some blustery wind-bag who thought everything
he wrote was gold. There is great satisfaction in fixing such code
that goes beyond improving the system.

The issue is *reading* and *understanding* code,

That's an important issue too, but only with code that is
designed or intended to be modified or modifiable.  There
is much code where you only want experts making changes.  

Correct. And with modern version control systems and code reviews,
the experts are alerted about changes and can consider them.

You know most managers aren't capable of making the
distinction necessary to prevent "code destruction" by
a non-expert from happening.

Depends on the manager. For most of my career, all my managers have
been skilled software developers. Again, I'm sorry for those who have
to suffer under organizations where that isn't true, but it's your
choice of where you want to work.

But moving beyond that, you might want to invest some time in modern
software development practice and tools. You seem to come from some
old-school model. These days, agile practices and supporting tools
have won out. So any badness injected by an "incompetent" programmer
will be found in code reviews and test suites, and revertable by
version control.