Re: [Re: RPGILE V4.3 Gotcha]

Comments in line...

boldt@ca.ibm.com wrote:

> <SNIP>
> I noticed you haven't mentioned PL/I.  Interesting.  PL/I has
> different rules yet again!  It has it's own set of quirks regarding
> decimal arithmetic, yet many people still use it.

You are right, I have never even seen PL/I.  I have no idea what PL/I does.


> <SNIP>

> You do offer an interesting suggestion, though:  Perhaps we should

> have a "CURRENCY" attribute on decimal numeric variables, which
> would ensure that decimal precision never drops below the declared
> number of decimal digits within expressions.  (Basic's 2 decimal
> place currency format seems a bit restrictive.  Not all countries
> use 2 decimal places in their currency.)

That would be nice, then I wouldn't have any problem at all using the Eval.


> I'm like you - I wouldn't do computer programming if I didn't
> enjoy it and wasn't good at it.
>
> Sure, the title of that point was meant to be provocative. But I
> stand by it.  In my humble opinion, too many programmers are too
> complacent about their craft.  It is all too easy these days to
> pick up something new, have some early successes, and think you
> know all about it.

When I program, my objective is to write a program without bugs that
does the objective given to me.  And, so far, I have done it every time.
I always double check my answers on pencil to make sure they are
correct.  I do not think I know everything about any language, I don't
think anyone does.  But I know the things I use.

When I first started programming and started getting into mathematical
formulas, I looked real closely at how math was done.  I studied how
they were stored in the computer, I studied the overflow bit, I studied
2's compliment, I studied multiplication, division, raising to the power of
et al.  The reason I got so into it was because I was doing graphical
programming, and was writing my own 3d engine, and I had to know
how accurately I could depend on my answers.

And when I pick up a new language and started using math I would
look and make sure they were doing it the same way, and they did.

After 5 or 6 languages, I still usually check to make sure they are doing
it the same way.  And so far I haven't run across any problems, not even
with the MULT statement in RPG.

And, when I started using EVAL I did check the manual, as I quoted you,
as I check every command I haven't used before, with no indication of
any difference between how it worked and how the MULT works.  I had
no reason to think it would be any different.  As stated, it seems I have
the first version of the manual, which gave no indication of any change from
every other language I have programmed in, or RPG's own MULT statement.

> You mentioned Perl in your own list of languages.  Do you read
> comp.lang.perl.misc?  I see many people post questions and
> very often the answer is "Did you use -w and use strict?"  A
> beginner can quickly learn enough to write a Perl program, but
> it takes more understanding to appreciate the importance of
> things like "-w" and "use strict".  It's that kind of
> necessary wisdom that's hard.

As I have said, I know a "little bit" of Perl.  I do not consider myself 
proficient
in it.  I have written small programs in it, but didn't understand enough of 
what
I was doing to consider myself learned in that language.  I did start a study
course in it, but never finished it (wound up with my Linux box bombing out
with a crashed motherboard about 3 years ago, and haven't gotten a new
box at home to install linux on.  I did just buy 3 manuals on Linux, one on the
operating system, one on programming in linux and on on C for linux).

> <SNIP>
> Me, I started learning programming in 1976.  And I'm still learning
> programming.  I didn't stop learning when I quit school in 1980.

I am always reading up on programming.  At home I am reading a
box on Linux right now that I just started and is about 3" thick, I got
3 of them to go though.  That is not counting my 80836 Programmer's
Reference Manual I got from 1986 to learn more about Assembly and
how Intel CPUs work.

> Then I take it you haven't yet learned object-oriented programming.
>
> Learning programming is much more than just learning the peculiarities
> of particular programming languages.  Take OOP for instance.  In my
> opinion, no-one schooled in procedural programming can really understand
> object-oriented programming without first feeling like a complete
> idiot.  If you think you know OOP without going through that phase, you
> really don't know OOP.

Of course I know OOP.  I picked it up at the last company I worked at
where they used Delphi.  They didn't use OOPs too much, but I started
looking at it, bought the compiler at home and read the manuals.  Then
I wrote a few programs, logged onto Delphi news groups, downloaded
OPPs (Other People's Programs) and looked at them, etc...

And then I looked at OOPs in C and VBasic and, know what?  They
worked just about the same way.

> The realization that one must pass through through that "complete
> idiot" phase is hard for many people to accept.  We don't like
> feeling like idiots.  Yet, IMHO, it's often necessary to shake off
> old prejudices and beliefs in order to learn and accept new things.

Oh yes,  I definitely felt like a complete idiot with OOPs, Pascal in
Delphi was no problem, but the OOPs had me scratching my head,
because I had never seen it before.  I say if you don't learn something
new every day, it was a wasted day.

> (On the other hand, IMHO, over time, the teaching of OOP will improve to
> make the process less painful.  But then again, the need to teach new
> tricks to us old dogs will decrease as we retire and more and more new
> programmers learn OOP right from the start.)

True.

> But here's what I don't understand with this discussion:  Learning a
> new set of arithmetic rules in a programming language really doesn't
> compare with learning a whole new way of approaching programming or
> a whole new operating system.  Many RPG programmers have made the
> transition to RPG IV with little effort and few complaints.

The only problem I had was there was no indication at all that it was a
"new set of arithmetic rules".

> Here's where I really take offense at your assertions.  You claim that
> we want RPG to be different for no good reason?  You have no idea what
> went into the design for decimal arithmetic.  The fact is, we looked
> at many different sets of rules, and for each, we found cases where the
> rules would cause possibly unexpected results.  Unless we did the
> arithmetic with infinite precision and infinite speed, there was no way
> we could satisfy everyone.  That's the reality of programming language
> design.

Of course, but why did you try to reinvent the wheel and wind up making
it square instead of round?  All the other programming languages way of
dealing with overflow is going to effect me very seldom.  I know about it,
I know how it works, I keep it in the back of my mind as I write my formulas
and it just doesn't effect me.  Maybe one out of 100 or 1000 times am I
going to have to change the way I am doing something because what I am
doing is going to overflow.

RPG's way of doing it, on the other hand, has the potential of affecting me
quite a bit.  Even though now I know about it, every time I write something
I am going to have to start counting decimal places and interger places on
my fingers and toes and then juggle around my equations so that the formulas
will come out right.

I learned a long, long, long time ago to make my variables large enough to hold
my answers or I would get an overflow, and make sure there are no intermediary
results that will go past my variables allotted space, which is perfectly fine.

That is not good enough for RPG, now, because now I am also going to have
to determine the precision, or make absolutely sure that I have the header spec
specified (and even then, I am going to test the heck out of it to make sure it
works 100% as advertised).

> If you think you can design a programming language better, then please
> feel free to do so.

Actually, I once bought a book on compiler design to do just that, but the
book was so full of gobblygook I couldn't' understand a word it was saying.
I don't know if the book was just written horribly or I don't know enough
higher mathematics to understand it.

> <SNIP>
> Look, I've stated before that, sure, we could have made some better
> design choices.  But we have a policy of trying to ensure that a
> working program compiled several years ago will work the same today
> when compiled on a newer release.  We can't go back and arbitrarily
> change the rules, and our customers expect that.

Okay, that I can agree with.  You know, I wouldn't even of thought anything
of it if I didn't already know so many other programing languages that all
did things the same way.

And I can respect this answer, Hans.  This thread would of died a long, long
time ago if that was stated from the beginning instead of RTFM.  "Okay, we
did not make the best design decision there, we've added the fact that you
have to be careful with math in LATER versions of the manual."

This whole thread I think derived from the fact that the first version of the
manual said nothing about the math being any different than the MULT and
DIV statements.

The fact is, it is now in later versions of the manual so people know about it
(and I'm talking about the RPG reference manual under the EVAL section,
not some section on math).  I'm just wondering where the replacement page
for my manual is.  Probably got lost in the mail <g>

Regards,

Jim Langston

+---
| This is the RPG/400 Mailing List!
| To submit a new message, send your mail to RPG400-L@midrange.com.
| To subscribe to this list send email to RPG400-L-SUB@midrange.com.
| To unsubscribe from this list send email to RPG400-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---