|
Everybody is concentrating on the MOVE and MOVEL but what /free BIF(s) or Op Code(s) could possibly replace MOVEA? ----- Original Message ----- From: "Bartell, Aaron L. (TC)" <ALBartell@taylorcorp.com> To: <rpg400-l@midrange.com> Sent: February 27, 2002 9:02 AM Subject: RE: MOVE opcode in freeform (was Strange behavior w/%editc) > >Since the intermixing of free and fixed calcs looks so gawd-awful horrible, > no one should even consider using free-form calcs unless they are prepared > to write whole new procedures or modules in free-form style. > > I was hoping you would say this because I wanted to ask why you(IBM) didn't > just create a new specification code like Z or something instead of having > to start and end your code with compiler directives(/FREE and /END-FREE)? > > I also agree that you shouldn't code both free and column-like coding in the > same program. > > Aaron Bartell > > > -----Original Message----- > From: boldt@ca.ibm.com [mailto:boldt@ca.ibm.com] > Sent: Wednesday, February 27, 2002 8:51 AM > To: rpg400-l@midrange.com > Subject: Re: MOVE opcode in freeform (was Strange behavior w/%editc) > > > Darn, another digest just rolled in while I was writing > this, and so some of my points are again redundant! I > promise, this will be my last post for the morning! > > Bob wrote: > >I think the bigger question is not even if a language that supports both > >free format AND fixed format useful, but rather, is the programmer that > >uses both free format and fixed format doing the right thing. In that, I > >can see your point. Mixing a MOVEL with all that free-format code isn't > >"cool". > > > >But to be honest, I have yet to see one example of free-format RPG IV > >code posted to this list that has been written in a way that is similar > >to code written by people that write applications with free-format > >languages for a living (not as a hobby). So perhaps we should continue > >using traditional RPG IV syntax (which includes the good old MOVE > >opcode) until we get a bit more experience or until is become more > >refined. > > You know Bob, I DO tend to agree with you more often than > you might think. I understand fully your concerns about > free-form calcs, and to a large extent, much of the talk > about free-form calcs is indeed hype. (Perhaps even from > us!) Since the intermixing of free and fixed calcs looks > so gawd-awful horrible, no one should even consider using > free-form calcs unless they are prepared to write whole new > procedures or modules in free-form style. Although I do > prefer coding in /free style, and I would like to see more > /free code out there, I'm not sure I agree with the large- > scale conversion of existing fixed-form calcs. > > Maybe you were right that RPG programmers weren't ready > for free-form. But then, when would they be? Perhaps > the problem was that expectations were too high? I don't > think any one of us expected the overnight conversion of > all existing calc code. Maybe some small percentage of > new V5R1 code will be written using /free. Maybe that > percentage will rise as time goes on. Unlike every > other enhancement we've done, this one has relatively > little practical importance in its first release. It will > likely become more important over time as programmers warm > up to it and learn how to use it. > > If anything, I think /free is a really profound statement > from us that we believe programmers will still be using > RPG many years from now. In a sense, /free is more useful > as a statement of IBM's commitment to the language, rather > than as a useful function. > > >On the other hand, since we have 6 or more ways to do the ADD operation > >in RPG, why not just include a new free-format opcode named MOVE and > >MOVEL? > > > >/free > > movel src target > >/end-free > > > >Oh crap! I just wrote free-format, and I told Hans I would never do > >that! ;) > > That's not valid free-form calc code anyways, so it doesn't > count, OK? ;-) > > As I pointed out in my previous note, we purposely did not > support all calcs in /free for the very reason that we > should not have lots of ways to code something. If, and > this is a big IF, all new RPG code is written using /free, > then the point is moot - there would be fewer alternatives > to choose from. > > >Actually, Joe, Hans is not your enemy. The enemy is us as a group, we > >RPG programmers who do not clearly articulate our views. I think rather > >than say "I demand feature X in RPG" we need to say something like: > >"Feature X is valuable to me because A, B, C, D... and this is how I > >think it should be implemented." And then let the smart compiler > >writing figure out how it should be realistically implemented. > > I agree. Often we see requests that we should add some > particular functionality where the request is worded in > terms of some specific syntax. What we try to do is extract > the real requirement and then try to determine the best way > to meet that requirement. That's not always easy, and it > might not always be obvious how some enhancement meets a > particular requirement. > > Basically, we prefer adding "enabling" enhancements, rather > than enhancements that directly meet some specific need. For > example, procedures "enable" a lot of functionality. For > many things that programmers want to do, we would prefer > that programmers write procedures to perform the desired > tasks. We had hoped that there would by now be a goodly > selection of procedures and modules commonly available > written by RPG programmers for the benefit of other RPG > programmers. Robust publically available function libraries > is a prominent feature of many other currently popular > programming languages, such as C++, Python, Perl, and Java, > and is a big reason for the success of those languages. > > I know someone will pipe up and point out some web page or > another with publically available RPG code. But often, > they're just touted as "demonstration" code. The biggest > problem is that there's no common repository of the code > that's available. And there's little sense of community > with respect to improving the quality of publically > available code (as there is with other languages). At any > rate, the amount and quality of publically available RPG > code just doesn't compare to what's out there for other > languages. Just look at www.cpan.org to see how the Perl > community deals with library packages. > > Cheers! Hans > > Hans Boldt, ILE RPG Development, IBM Toronto Lab, boldt@ca.ibm.com > > _______________________________________________ > This is the RPG programming on the AS400 / iSeries (RPG400-L) mailing list > To post a message email: RPG400-L@midrange.com > To subscribe, unsubscribe, or change list options, > visit: http://lists.midrange.com/cgi-bin/listinfo/rpg400-l > or email: RPG400-L-request@midrange.com > Before posting, please take a moment to review the archives > at http://archive.midrange.com/rpg400-l. > _______________________________________________ > This is the RPG programming on the AS400 / iSeries (RPG400-L) mailing list > To post a message email: RPG400-L@midrange.com > To subscribe, unsubscribe, or change list options, > visit: http://lists.midrange.com/cgi-bin/listinfo/rpg400-l > or email: RPG400-L-request@midrange.com > Before posting, please take a moment to review the archives > at http://archive.midrange.com/rpg400-l. >
As an Amazon Associate we earn from qualifying purchases.
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.