Re: [Re: RPGILE V4.3 Gotcha]

Of mice and men and sealing wax, of cabbages and kings,

Hans,

boldt@ca.ibm.com wrote:

> Have you tried C++?  Or Java?  (From your comments, I take it you
> haven't done any OOP in Perl.)  All of these OO languages approach
> things slightly differently.  Java and Perl take care of memory
> management for you, but in C++, you have to manage memory yourself.
> Developing GUI interfaces in Java requires extensive use of
> inheritance, whereas Perl experts tend to recommend other styles
> of OO app design.  Java uses single inheritance, C++ and Perl allow
> multiple inheritance.  All of these factors affect application
> design in fundamental ways, making it difficult to transfer skills
> from one OO language to another.

I've done a bit in C++, although not too much as I've yet to get a compiler
for it.  Whenever I get the king's ransom together I'll get the Microsoft
compiler.  From the C++ I've done, yes, you have to be very careful that
you have the memory for the objects, that you allocate it, free it, et al.

And, no, I have not done any OOP in Perl yet, most of what I was doing
there was parsing text, and helping a Perl programmer debug their code.
Java I don't much care for, probably because I haven't found a decent
compiler for it that I like.

Inheritance is something I was using quite a bit in an RPG (Role Playing
Game) I am writing in Delphi, and I find it quite useful, but there are a lot
of things you have to be careful of and understand fully.  In Delphi you also
have to make sure you allocate and free the memory for the object, at
well as create it, initialize it, etc.  It is very close to the OOPs in C in 
that

aspect.

VB, on the other other hand, I understand does not use true objects, and
you don't have to concern yourself with memory, Basic has always done
that pretty much for you.

I could transfer a program between Delphi and VB, but there would be a
lot of changes in how the objects are used.  I really do not consider OOP
as one thing, but a conceptualization that is done in languages.  There is yet
to be a true standard, and I doubt there ever will be one.  Different languages
handle memory so much different in their core that things will always be done
differently.

> There's a lot to OO, and I'm still picking up things myself.
> Yesterday, I thought I understood OO, but then I read a section in
> the book "Advanced Perl Programming", and now I wonder what I know!

I do not consider myself an expert in OOPs, as almost all the programming
I've done in it has been at home working on my own projects.  Even though
the last company I worked for used Delphi, they didn't use the objects much
at all, but mostly just stuck with the Pascal.  I find myself learning things
much differently when I'm doing it for myself, and when I'm getting paid to
do it.  When I'm doing it for myself I take a much more casual approach to
it and try to grasp the entire concept and how it works deep down.  When
I'm getting paid for it then I'm looking at the syntax, rules, how to get it to
do what it needs to do now, not tomorrow.

> That section in that book illustrates the potential for overuse of
> inheritance.  For example, many OO texts use the example of
> employees in a company.  Using inheritance, you could design a base
> class called Employee.  You could then have derived classes called
> Manager and VicePresident, such that a Manager "is a" Employee, and
> a VicePresident "is a" Manager.  But what happens when an employee
> is promoted?  In this case, a better design would use "has a"
> relationships.  For example, an Employee "has a" Role, which could
> be regular employee, manager, or vice-president.  To promote an
> employee, simply assign a new Role to her.

I've found that to be the same case in some code I modified, where they had
inherited a bit too much, and to change anything I had to change their parent,
I wound up taking out a level of inheritance and making one level a bit more
generic.

> Don't feel bad - the book probably was gobblygook!
>
> As some readers here know, I took over development of expressions
> in the RPG IV compiler from two other developers.  They were
> running late in their schedule when they scrapped the existing
> code and wrote a new expression parser, which they were very proud
> of.  When I looked at the code, I was shocked to find the most
> disgusting piece of junk I'd ever seen!  I first thought there was
> no way it could work, it just looked so bad.  Hard to understand,
> which meant that it would be a real pain to maintain and enhance.
> When I challenged them on the code, they said they got the
> algorithm from a book!

Almost all my algorithms I use I have designed myself.  The one notable
exception was a bubble sort I had copied from a book from one language
to another to put into my program.  Since then I have seen how bubble
sorts work, I have seen the input, the out put, I understand the algorithm,
but to this day I can not make heads or tails out of how that routine I typed
in worked, it just did.  I feel if I code something, if another programmer can't
understand it, no matter how complicated, then it is a piece of speggetti code
and
should be tossed.


> IMHO, most books on compiler writing are just too academic with
> too little practical information.  Don't worry about LR parsers,
> even though they're supposed to be more efficient - they can be
> too difficult to understand.  I lean towards the top-down approach,
> typified by the recursive-descent style.  For a reasonably
> understandable discussion on compilers, look at the last chapter of
> "Algorithms + Data Structures = Programs" by Niklaus Wirth, one of
> the classics of CompSci (but now, unfortunately, out of print - I
> still occasionally refer to it).  Once you understand the
> recursive-descent technique, you can apply that understanding to a
> more practical, table-driven approach, like we use in the RPG IV
> compiler.

One of my pet projects is writing an English Language parser for an AI
interface.  That is one of the reasons I was looking at the compiler
book.  And there is a lot of theory out there in paper form, but nothing
concrete (probably because no one's been able to write one that really
works yet).  Maybe the full concept hasn't been achieved, yet, or maybe
computers just aren't fast enough yet.

> Here's what we do:  We use a simple language with operations
> geared towards parsing, such as MATCH, CHOOSE, EMIT, ERROR, etc.
> The syntax is first drawn using syntax charts (AKA railroad
> diagrams).  The syntax productions are then coded using the
> parser instructions, and the parse tables are generated from
> that code.  The parser operations are performed by a simple
> virtual machine which executes the parser instructions.

The syntax charts were my strongest challenge, since the English language
is fairly free flowing.  There are just so many ways of saying the same thing.
"How are you?"  "How you doing?" "You doing okay?"
"How have you been doing?" "How are you doing?" "You doing okay?"
all basically are asking the same question, but the syntax is all different.
I had written a beta for a language parser and it was parsing fine as long
as there were strict syntax rules.  When you relax the syntax rules, though,
things get very tricky.

I am sure it is a lot harder to parse the EVAL statement, then it is to parse
MULT, DIV, MOVE, etc...

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
+---