Re: 6502 illegal opcodes questions

[pausch@saaf.se (Paul Schlyter)]

In article <hbOdncoOR8IOJxjZnZ2dnUVZ_vqdnZ2d@comcast.com>,
Michael J. Mahon <mjmahon@aol.com> wrote:

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

I couldn't have said that better myself....

In the end, it's really the customers' fault -- after all, we make the
choice to get stuff as cheaply and quickly as we can, rather than wait
for, and pay for, quality stuff.

So I guess we all get what we deserve....



>>>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."
-- 
----------------------------------------------------------------
Paul Schlyter,  Grev Turegatan 40,  SE-114 38 Stockholm,  SWEDEN
e-mail:  pausch at stockholm dot bostream dot se
WWW:     http://stjarnhimlen.se/