Re: RFC : SOME IDEAS FOR THE APPLE II FPGA'ers

["Michael J. Mahon" <mjmahon@aol.com>]

mdj wrote:

> I've spent years doing Java programming commercially. Test driven
> development becomes absolutely critical with large projects these days.
>
> Like most things, it's finally becoming accepted purely through
> necessity. The less disciplined methodologies don't scale, so to
> achieve anything really impressive now, you need methodologies that do.

I wondered how long it would be before we "hit the wall" and
necessity took over...

> I've always found it amusing how long good practices take to hit
> mainstream. Back when I started writing more sophisticated
> applications, it was just 'natural' to apply the concept of wriitng
> simple driver programs to exercise a modules capabilities, and prove
> that it worked correctly in isolation. I did this kind of testing back
> on Apple II with Pascal.

Culture is a bitch.  ;-)

> The nice thing now, that you couldn't really do then, as there wasn't
> the machine headroom to do it, is true automatic testing of the entire
> application. While I lament the relatively limitless environments of
> today for their 'boringness', I have to concede that having so much
> more horsepower than you need allows you to shift the burden of
> application validation onto the machine much more readily.

Very good point.

The Digitek company, in the 1960's, wrote FORTRAN compilers for,
initially, minicomputers.  Inspired by the SDS 940's POPs, they
designed a compiler using a multi-stack pseudo-machine that could
be either interpreted or macro-expanded into "fast calls" or in-line
code.

After porting a compiler to a new machine, they would run it fully
interpretive, in no more than half the memory of the machine, and
use the other half of the machine's memory for profile counters
for the pseudo instructions.

Then they would mark the *big* peaks for in-line expansion, the
middling peaks for fast call expansion, and the rest for interpretation.

This optimization tool allowed them to make the smallest, fastest
compilers in the world for several years--and it was all based on
being able to fit the compiler into less than half the available
memory!

> It's made me change my mind about typing somewhat too - ten years ago I
> would advocate languages that had excellent compile-time error
> trapping. Now, I advocate trapping errors with testing, and think you
> should use whatever languages that are most appropriate, and that's
> usually the one that the existing software teams are well-versed in.

I've always found syntax + compiler semantics to be quite weak in
catching the interesting errors.  It's fine for spelling errors and
the occasional type mismatch, but there are just too many utterances
that are perfectly syntactic, but meaningless:

"Colorless green ideas sleep furiously."

> But it's a tricky line to walk; make the environment too structured and
> bureaucratic and people will feel stifled and uncreative. Too
> unrestrictive, chaos will ensure your deadlines slip indefinitely.
>
> In the end, it's a fun journey watching a discipline mature, as long as
> you can withstand the bumps in the road along the way :-)

Yes, and a microcosm of life itself.  ;-)

-michael

Music synthesis for 8-bit Apple II's!
Home page:  http://members.aol.com/MJMahon/

"The wastebasket is our most important design
tool--and it is seriously underused."