Re: A Brief Look at History

On Sat, 15 Mar 2008 12:09:14 -0600, John Doty
<jpd@xxxxxxxxxxxxxxxxxxxxxxx> wrote:

I agree. But "good" often requires great flexibility, the opposite of
the "should not be tolerated" rigidity Elizabeth says is necessary to
make Forth work well in groups.

Change requires flexibility. But Elizabeth's point is that house
standards are a necessity to produce maintainable code. If you
make a mistake and hire a programmer who will not produce
maintainable code, the cheapest thing to do is to get rid of

At the cutting edge, you don't even know which of your objectives are
achievable, and you have to accommodate a diversity of standards which
still contain holes. It's jazz: sometimes you just have to make it up as
you go.

As a statement of the bleeding obvious, that's wonderful. But in
those cases you need project management even more.

In scientific projects the participants often have intense personal
commitment to the project: the challenge is to harness that energy
without draining it away through management bullshit.

Project management and the leading and bleeding edges isn't

MPE has done several multi-company,

There's that word again: company. Why does this discussion always turn
back to the subset of projects that only involve companies? Innovation
often requires a broader base. Companies usually don't really
collaborate in the sense that I'm using the word. That's the kind of
collaboration that produces shared code bases.

But you haven't defined what you mean by collaboration! MPE has
collaborated with companies and universities in European ESPRIT
projects for our mutual benefit.

So, what problems with Forth restrict it to cultures with rigid,
corporate-style project management (or individual hermits)?



Stephen Pelc, stephenXXX@xxxxxxxxxxxx
MicroProcessor Engineering Ltd - More Real, Less Time
133 Hill Lane, Southampton SO15 5AF, England
tel: +44 (0)23 8063 1441, fax: +44 (0)23 8033 9691
web: - free VFX Forth downloads

Relevant Pages