|
> 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 mailing list archive is Copyright 1997-2025 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.