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



Joe,

>>
To take a language and remove functionality is questionable.  To do it
without good reason is absurd.  To do it because you think you know
better
without having actually used the language for what it is intended is
criminal.
<<

I agree with this, but what did Hans & Co take away from RPG? Because
the MOVE opcode isn't directly supported as a free-format opcode,
they've taken it away.

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.

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! ;)

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 fought that war with the EVALR operation code. Originally there was a
long list of nested built-in functions to do the same functionality as
EVALR does today. I sent my view off to George Farr and he ask others if
they would like option "A" or "B". Fortunately, the best choice (in my
view) one out; we have EVALR instead of the other option.


Bob Cozzi
cozzi@rpgiv.com
Visit the on-line  Midrange  Developer  forum at: http://www.rpgiv.com


> -----Original Message-----
> From: rpg400-l-admin@midrange.com [mailto:rpg400-l-admin@midrange.com]
On
> Behalf Of Joe Pluta
> Sent: Tuesday, February 26, 2002 6:58 PM
> To: rpg400-l@midrange.com
> Subject: RE: Strange behavior w/%editc()
>
> > From: boldt@ca.ibm.com
> >
> > Joe wrote:
> > >...
> > >I can only imagine that the decision was made by some
> > >"compiler experts" who have never worked a single day in an
application
> > >development environment.  More than likely, it's a group of
computer
> > science
> > >academicians who have never programmed a business algorithm in
their
> > lives.
> >
> > Which would you prefer?  Would you rather have your RPG IV
> > compiler developed by application programmers?  Or by
> > compiler experts?
>
> I thought I'd get a response from this.  To be honest, if I had to
choose,
> I'd rather my business languages were designed by people with business
> application experience than someone with no business experience.  I'm
from
> SSA.  We had a language developed by compiler experts.  It was called
> AS/SET.  While it was great for generating code, it was useless for
> developing business applications.
>
> In the best of all worlds, I'd have my syntax designed by applications
> development experts and my compiler written by compiler experts.
Rarely is
> one person good at both.  Even a very good Java designer can create
some
> really horrible business applications, simply because they don't have
a clue
> what a business application needs to do.
>
> And RPG is a business language.  Unlike C, C++ or Java, which can
afford to
> ignore the complexities of application development, RPG has to be
tuned
> ENTIRELY to the job of writing applications, and more importantly, to
> maintaining those applications.  Anything that reduces the ability for
> programmers to maintain their existing applications is a decision that
AT
> THE VERY LEAST requires a whole lot of justification.
>
> To take a language and remove functionality is questionable.  To do it
> without good reason is absurd.  To do it because you think you know
better
> without having actually used the language for what it is intended is
> criminal.
>
>
> > >Turning RPG into Java is a stupid idea.
> >
> > I agree 100%.  Java and RPG IV are still on different
> > continents, functionality-wise, and there are no plans to
> > turn RPG into Java.  If you think RPG is moving in that
> > direction, you have no idea what Java is all about.
>
> I suspect you know very little of what I know or don't know about
Java,
> Hans.  Perhaps you've read some of my articles, or attended some of my
> classes on the subject.  Since I have little knowledge of your Java
> capabilities, I can't comment on them, but I have a commercial
Java-based
> business application on the market.  That's more than most Java
programmers
> can say.
>
> But in any event, it's not my Java skills being discussed here.  It's
my
> opinion that removing the MOVE opcode is a misguided concept.  I've
yet to
> hear one good reason for it's loss.  On the other hand, I can say that
> replacing the MOVE opcode with some C-syntax BIFs is definitely a
backwards
> direction, and I have a feeling many other programmers would agree.
RPG
> isn't about "cool and geeky", it's about getting a job done in a
limited
> time frame with a limited budget.  RPG is the best language in the
world for
> that, and a large part of that capability is the lowly MOVE
instruction.
> But hey, I've been wrong before.  And I could live with it if one of
the
> decision makers could actually tell us lowly programmers why they did
it.
>
>
> > Then I'd like to see why
> > >
> > >     eval b = %editc(%dec(a:%len(b):0):'X')
> > >
> > >is better than
> > >
> > >     MOVE A B
> > >
> > >Really.  Convince me.
> >
> > No.
>
> But of course, we don't get an answer.  We get this "Pay no attention
to the
> man behind the curtain" crap.  I mean, is this "No, it's not better"
or "No,
> I don't have a good reason to remove the opcode" or "No, I'm not going
to
> tell you why because I know better"?
>
> Well, no matter how impressed you are with your own brilliance, when
it
> becomes obvious that programs won't convert to the new and improved
syntax,
> don't be particularly surprised when there's some mean backlash from
the
> existing programming base.
>
> Joe
>
>
>
> _______________________________________________
> 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 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.