× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



> From: Douglas Handy
>
> >... one of the leading causes of software failure in our industry -
> >the fact that software that worked yesterday doesn't work today
> because of
> >some change to the operating system that breaks working code.
>
> This has nothing to do with the arguments about MOVE or %fields()
> or %kds().
> Absolutely ZERO working code breaks.  Neither do the techniques
> you or any staff
> have learned over the years suddenly quit working.

Thanks for the comments, Doug, but since you miss my point completely, the
rest of the conversation while well written is a bit off the mark.  To keep
it brief, because I'm sure the normal readers of the list are bored with
this by now, let me just state my opinion: removing MOVE is going to be
counterproductive in the short and medium term, and the jury is out as to
whether it's more difficult long term.

There are three options: stick with MOVE, recode your MOVEs to evals, or
have a mix of /free and fixed code.  I don't accept the last one as a viable
option because it's just plain bad coding.  If you think that's a good
solution for your shop, then we have little to talk about, because then the
compiler people have done everything you need.

On the other hand, if like me you think it's a choice between /free and
fixed, then here's where working code breaks: you have to remove the MOVEs
to go to /free.  This is the point you're very stubbornly missing.  And
since just about every program ever written uses at least a few MOVE
instructions, then by definition you are recoding - and possibly breaking -
every sinble program.  Are you missing this fundamental point, or am I just
explaining it poorly?

So the only other option is to stick with MOVE, and thus be barred from
using the /free-only extensions.  This because the compiler team chooses not
to give us extended syntax in fixed form (even though, as I've shown, it can
be done).

Long term, I still don't agree with your comment about MOVE and EVAL.  My
personal opinion is that the people who can't read a MOVE instruction might
seriously want to consider other lines of work.  Try reading a J2EE API or
an SWT FAQ example, and you'll see some seriously unreadable code.  If we're
turning out generations of programmers who can't read a MOVE instruction,
then we're in a serious downward slide in programmer ability.  Cripes.

Joe


As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.