Re: 6502 illegal opcodes questions

["mdj" <mdj.mdj@gmail.com>]

Michael J. Mahon wrote:

> And most organizations give maintenance tasks to new programmers, as
> a kind of hazing, I think!
>
> But not supporting the code that you produced, at least for its first
> year in the field, deprives a team of the *real* learning experience,
> in which you discover which of your grand ideas worked and which didn't.
>
> And it also serves as a test of whether the code is *actually*
> maintainable, as opposed to theoretically maintainable.
>
> I see doing at least "early" maintenance as a kind of accountability.

Fully agree. All of the applicable data that needs to be fed into the
improvement process comes directly from supporting the code. Severing
the connection between the development group and this process is most
unwise, as it's these people that need to come up with ways of
improving this process. That's where you get real efficiency.

Of course the problem is that if your development team is spending its
time doing support, it doesn't have the time to develop new versions of
code. This is where the the process I outlined previously comes in.
Once the support issues around the product stabilise, you bring in
short-term resources to handle that support, free up the development
team, and start the process again.

> As we enter the era of 10 million transistor FPGAs, system compilers,
> and "turnarounds" measured in seconds--in short, as the constraints on
> hardware design are eased--I expect to see many of the same problems
> that have afflicted software shift into the "hardware" realm.
>
> Discipline is hard-won.  Discipline can only coexist with ease and
> convenience *after* it has been formed through hard experience, since
> ease puts greater demands on discipline.
>
> Tools can give the appearance of discipline by restricting expression,
> but to a truly disciplined mind, tools are merely secondary.
>
> I think of "strict" tools as "discipline for the undisciplined", but
> so much of system design is outside the realm of any formal tools, that
> there is no substitute for design discipline.  A terrible fate awaits
> those who think that there is.

It's also premanaged complexity, for those that have neither the time
or the resources to mangage it themselves. Tools don't necessarily have
to be strict, just work, and provide access to complex functionality
that's already proven. This is where tool and language evolution is
key. This complexity goes up all the time, while human discipline
evolves slowly and has real, known limits. In order to build more
complex systems, more complex toolsets that encapsulate that complexity
must be employed.

> My second software tools phase was strict typing and enforced structure.
> My mantra was, "If you think you need a macro, then something is missing
> from the language."  Experienced programmers chafed at the "training
> wheels" the language forced upon them.  Some of them filled their code
> with unstructured "workarounds", perhaps a sign of their resentment at
> the strictures of the programming environment.  (Unstructured code can
> be written in any language.)

Been there too. Time has proven it doesn't work well, and that test
driven development techniques provide more safety, and allow more
flexible forms of expression in the process, easing chafing.

> My third software tools phase was "the only thing that matters is
> the team".  I strove for a small team of 98th percentile people, who
> implicitly understood the need for and benefits of discipline, and
> who had learned this by experience.  Tools are useful, but secondary.
> If a tool is really needed, it will be written.  (Structured code can
> be written in any language.)
>
> Although I don't consider any of the three approaches ideal, there
> is no doubt that the third worked the best, both in terms of team
> esprit and in terms of product quality (function & reliability).
>
> Don't count too much on tools--it's the people that make the real
> difference.

The problem is such teams are very hard to build, and keep. And often
the 98th percentile people are already consumed by the very companies
that produce the technology you're trying to leverage. It's really up
to say, the 90th percentile group to manage the complexity for the
rest, and provide it in more accessible forms, through tools that
support higher abstractions, allowing more to be done.

It's certainly not ideal either, and it shifts a lot of 'waste' onto
the machines. But this is the only place you can feasibly put it,
because the machines are cheap and get bigger all the time. The humans
on the other hand....

> > This is the principle reason for evolving languages and tools. Improved
> > langugages allow ideas to be expressed more concisely, support
> > encapsulation mechanisms that allow complex modules to reused, thus
> > allowing complexity to be more effectively managed. Sure it's
> > idealistic to expect new tools solve all the problems, they don't. They
> > do however mitigate some of the old issues and allow some progress to
> > be made.
>
> For balance, I have to point out that they also permit *needless*
> complexity to be more effectively managed.  When "Hello, World!"
> executes 8 megabytes of code, you know something has gone sour.
> (And, yes, I do include *all* the code executed, not just the code
> in the "Hello, World!" module.)

Sure. Of course, it bares pointing out that you're referring to 8mb of
code that Hello World won't execute, but will carry around as a payload
anyway. Runtime systems are getting larger that's true, but they also
only have to be loaded once, thanks to copy on write memory, and much
of the initialisation work can be cached and shared amongst running
applications. Over time the issues bought about by this approach are
being mitigated, and besides, it's good fun work finding ways to tune
it out.

It's not ideal, but what's the alternative? If you don't follow this
road, a cap is placed on the possible solutions you can build. The
overheads introduced by high level abstraction systems is a very
interesting field of research, and one that great inroads into managing
has been made.

I can see a time when massive parallel computing clusters 'churn'
through algorithms, fitting them to particular machines are problem
domains. Programming done by the human will be not much more than
assembling from vast libraries of prevalidated solutions. It doesn't
take much thinking into the future to imagine a time when software
complexity is so high that this is the only feasible solution to
building more complex systems.

I think we're more or less on the right track, but breaking the ties to
legacy implementations that simply cannot be scaled in this way is one
of the biggest hurdles to moving further towards solving the current
issues in software design.

Matt