[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: 6502 illegal opcodes questions
mdj wrote:
Paul Schlyter wrote:
<snip>
My concern is the manner in which small libraries or copy/paste chunks
of code pollute the relatively portable space of newer languages. In
..NET, you can issue a keyword and switch into old-school mode. It
doesn't exactly provide an environment that encourages good design. Why
you would include features that good developers won't use is beyond me,
unless of course it's lousy developers you're catering to, which may
well be the point.
I suppose you mean "the commercial world" when you say "the real
world". Yes, the commerical world is a continuous hectic race where
there's not really any time to do solid work. It's more important
that the product is flashy and that it appears early. Buggy? Of
course, but so what? Let customer support take care of the
complaining customers while we're developing the next product to
appear early and being flashier still .... the lifetime of a software
product is nowadays so short anyway.....
It's actually irrelevant what sector we speak of - productivity
enhancements are productivity enhancements. While there are sectors
where you can 'afford' the extra time investment required to develop in
legacy languages, there's little reason to do so.
The previous exchange neglects to make the important distinction between
time spent "up front" on design and implementation, and time spent
"after the fact" on support and maintenance.
It is a sad but inescapable fact of commercial life that there is never
time to do a job right, but always time to try to make it work.
One of my development laws is: "'Quick and dirty' is never quick but
always dirty."
The commercial pressure to get a product out the door that Paul refers
to is so real that it generally precludes the design and implementation
team from doing what they would do in the "best of all possible worlds"
and instead condemns them to shipping a product that has many structual
flaws. Those flaws will cost dearly over the next few years, but, given
the structure of corporate software teams, it is unlikely that senior
team members will have to deal with much of the flak.
Management will be rewarded for "making the schedule" and the elevated
support costs won't hit the fan until months later--when they can be
blamed on an inexperienced implementation team.
Matt is making a idealistic argument for what is achievable with great
discipline--and there's nothing wrong with that! But in the "real
world", discipline is much harder to come by, and almost impossible to
stick to without (rare) management support.
In such an environment it's probably best to throw away old code and
let everyone reinvent their wheels once more .... with humps and bumps
that there's no time to polish away.
In this case, the old wheel has humps and bumps with regards to
portability and security. Should we throw those away? Absolutely.
Never assume that doing something over will mean doing it better.
Life is full of counterexamples.
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... ;-(
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.
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. ;-)
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. ;-)
"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.
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 ;-).
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.
<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.
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!
Maybe in computers, too, power corrupts. ;-)
</fogeymode>
-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."