[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: 6502 illegal opcodes questions

mdj wrote:

Michael J. Mahon wrote:


<snip>


It will only be done better if a higher quality design and
implementation can be done, and that's a big "if".  For one thing,
management always thinks of the bad old solution as a _solution_,
so they are unwilling to invest much time and effort in re-solving
a problem "just" to obtain some "airy-fairy benefit" on the *next*
manager's watch...  ;-(



There are some good managers who see the benefits, but they're a rarity
for sure. I've seen at least one place do the opposite of everyone
else, and hire contract teams to maintain their existing systems, while
their staff went off and designed newer systems. The idea was that the
money they saved on maintenence down the track more than covered the
contracting costs, and they had better systems and happier staff, for
less money.


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.


This is the real world effect of Microsofts design decision (pollute
the new language with old problems) versus the Java model. Still
hobbling with legacy for no reason whatsoever than a couple of very
poorly concieved design ideas. And ones that history has already shown
has a simple, clean solution.


Many of the short-sighted additions to otherwise clean languages are
there *exactly* to solve short-term, schedule-driven problems.



Indeed. There have been a few additions to Java of late to make it more
like C, which makes it easier to port code. They've managed not to
break the portability of Java in the process, but they've added a lot
of functionality that allows some pretty ugly code. In some ways I
*like* it that you have to rework certain things, and if it's too much
effort, use the callthroughs.

The limitations placed in Java haven't prevented it from becoming one
of the most widely used languages today. The portability is a real
benefit too, especially now that we're starting to hit some real
limitations: floor space and heat. Having the option to pick different
hardware based on the restrictions of the physical environment has real
benefit.



We have a long history as a species of mortgaging the future for the
present.  Whoever said "Pay me now or pay me later" neglected to
mention the effect of high interest rates.  ;-)



lol!



As I often say, we tend to use our nose for a wall detector.  It works
very well in the sense that it detects all the walls, but by the time
it works, many of the wall's consequences are already felt.  ;-)



Brilliant analogy :-)



"Those who cannot learn from history are doomed to repeat it...."


And, statistically, that would be all of us...  ;-)



Actually, there are lots of people who do this, for their enjoyment.
I'm referring to vintage computing of course, and this very newsgroup is
part of that movement.

Yep, it belongs to "the real world" too....



Of course, but when your platform isn't evolving you don't need
evolving development methodologies. The older techniques are adequate,
and in the case of the Apple II, a great deal of fun on such a
constrained environment. However, old techniques only scale so high,
and hit those limits. In the case of C/C++, those limits have been hit,
or close to it. There's still a large problem domain you use these
tools for, as it's the most appropriate. But many new problem domains
demand tools that have less restrictions, particularly in terms of
development time. Sometimes this involves using a slightly more
constrained language. Less is more!


Software folks are more likely to be afflicted with grandiosity than
hardware folks.  Perhaps its the stronger engineering discipline of
the hardware world, perhaps its the real smoke when something "blows
up", or perhaps its because hardware people live *constantly* with
constricting limits that discipline their dreams.



I agree. I don't feel that I'm being grandious, though. I'm referring
to a language that's been in the field for a decade now. The Ruby boys
sure get a little grandious, but hey, a little dreaming is a necessity
to progression. It's all about balance.

I'm finding FPGA's pretty fun from that regard. Hardware, without
breadboards and blue smoke :-)


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.

My first software tools phase was a macrogenerator phase--anything
was possible, and complexity could flourish in five pages of code.
It was not well suited to team efforts.  ;-)

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.)

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.


Software folks seldom experience real limits anymore.  They find it
all too easy to imagine that they can accomplish *anything* through
programming (even if they don't understand how to do it  ;-).



And routinely fail to achieve anything useful in the process :-)


And those are the *good* cases.  Many times they achieve something that
is sold and wastes many people's time, but is actually worthless.

Remember the "Serius Computer Corporation", whose products were so
full of niggly little errors and inconsistencies that no one ever
found out that they actually didn't work at all! (Paraphrased ;-)


Most of the problems of todays software are a result of attempting to
deal with more complexity than we can actually manage--and on a short
schedule.  ;-)  The irony is that much of the complexity comes from
aspects of "solutions" that are entirely optional--like GUI eye candy.



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.)


<fogeymode>

Most of what is done with computers today is much like what was done
decades ago--text editing and formatting, modest number crunching.
Only now, instead of spending 20 minutes choosing your words when
writing a letter, you spend 10 minutes writing and 10 minutes choosing
fonts.  ;-)

High quality image processing is relatively new, because of its demand
for large memories and fast processors, but the basic image processing
operations are purely mathematical and easily disciplined.  The same is
true for most "media" processing.



Ultimately, that's all we do with machines - manipulate media. Now that
extremely cheap machines can manipulate high definition AV content in
better than realtime, we're running out of reasons to make faster
machines. This is a good thing, in many ways.


Since we're running out of silicon "smoothness", and with it Moore's
"Law", I suppose its just as well that we're feeling satisfied with
where we are.  ;-)

There are still orders of magnitude of improvements in cost/performance,
so the game certainly isn't up.  But those lavish resources will demand
ever more discipline from designers, lest they all go down the drain
(like much of the last few orders of magnitude ;-).

I have no problem conceiving computing tasks that would require 1000
times as much processing power as is currently affordable, but it all
needs to be spent on crunching, not on 3D widgets and redundant code.


Pasting databases together over the web is an example of an emergent
capability, but one that is largely done using scripting languages.

Sometimes it's hard to see just what real value is being created in
this endless hierarchy of levels of interpretation.  If anything
turns out to be really useful, then it could be rewritten "flatter"
to save about a factor of 1000 in computing resources!



It certainly opens up areas of research for 'real' Computer Science.
How do we get the computer to flatten the hierarchies for us ... ;-)


I think that will be done as a partnership between very clever designers
and very fast machines.

-michael

Parallel computing 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."