Re: Web apps on the AS/400

From: Joe Pluta <joepluta@PlutaBrothers.com>

> Leif, I'm going to have to disagree with you here.  Classes and subroutines
> are completely different programming entities.  Subroutine take parameters
> passed to them and do things to those parameters.  Classes, on the other
> hand, have an internal state that they act on in response to messages, and
> that they will communicate to the outside world.  The two concepts -
classes
> and subroutines - can often be used to solve the same programming problems,
> but they are very, very different beasts.

not really. Subroutines can have states too, either by having the state
information
in a parameter passed to them or simply by not deactivating themselves.
Maybe it is because you come from an RPG background that you can't see
this. If you have worked with COBOL you would be used to your subroutines
having state as that is the default. The classical case is a COBOL program
acting as a file I/O handler. The COBOL program encapsulates access to
a "file" which could be either an SQL table, a data area, a "normal" database
file, or stored on another system. You call the "file I/O" handler with an
operation code (a "method"). It does the operation to its internal state
(its opened file) causing communication with the external world. This
is a technique used by COBOL programmer for at least the last 35 years.
The file managed by the COBOL program becomes an object, e.g.
a customer. There is absolutely no conceptual difference here.


>
> Now, when your subroutine is part of a service program that has an internal
> state (like many operating system calls), then yes, it's closer to a class.
> Or even in RPG III, if you just don't set on LR, and call the program
> repeatedly getting different results based on the programs current internal
> state, then it's closer to the class concept.  But the other things that
> make classes so powerful, such as multiple entry points (polymorphism)

multiple entry points have been around in COBOL and FORTRAN for 40 years.
They are actually non-conforming with structured programming, but let that
ride.

> more importantly being able to change the behavior of an object through
> subclassing, are too powerful to be ignored and thought of as just the "1%"
> difference between OO and procedural code.

I'm at a loss why you think that OO is not procedural. The opposite to
procedural is "declarative". In a certain sense SQL in rather declarative,
but not all the way.  Java in particular is as procedural as it gets, like
C++ is,
like assembler is...

Whenever you have things like "if", "while", a = b+5, "try", etc you are
by definition procedural.

>
> We just had a fairly long and enjoyable conversation on JAVA400-L between
> Brad Stone and I on how true OO design makes a simple program incredibly
> powerful.  In this case, we showed how, by changing his design in some ways
> that are counter-intuitive to most procedural programmers, he would be able
> to add the capability for his program to return either XML or HTML by
> changing just one line of code.

this is pure BS. I can do anything in one line of code if that line is
allowed
to draw upon things external to my program.


>  More importantly, he'd be able to add a
> whole new style, say WML or VML, without having to change his program at
> all - just add a new class.

sure, my program is real simple: it consists of a single line:
begin call do_it end

where the new class "do_it" does it (whatever it is).
And, holy macaroni, guess what: I can change do_it to do
something completely different WITHOUT changing my program.


>
> This CAN be done procedurally, using subroutines, but it's almost
> impossible, and it requires reinventing wheels (for example, a dispatcher)
> that are already present in Java.

no new wheels are needed unless you insist on doing it the Java way.
Just do it as we have always done it and nothing new is needed.


>
> Alien, perhaps, but if you can come to terms with BIFs and APIs and
> activation groups, you can manage classes and objects.  I did, and I'm a
20+
> year RPG dinosaur.

I ascribe that that to your innate ability and not to fact that you are a 20+
RPG dinosaur. What I mean is that being a 20+ year dinosaur does not seem
to be a prerequsite to manage things.


Now, don't get me wrong, I would not touch RPG (followed by any numeral)
with a ten-foot pole, and I do agree that Java has excellent qualities and
is the way to go if you can. It is, in fact, a healthy step back towards
sanity
from C++'s excesses. Both C, C++, Ada, and Java are ALGOL-like languages,
and as I've said many a time:
"ALGOL was a significant improvement on all its successors."

I recently wasted $24.95 by buying a book by IBM Java-evangelist
Keith Ruthledge ("The business case for Java"). In it he says:

"If you want to continue to use the programs you already have,
but need to use them on the Web, Java is the answer"
"Java leads to enormous gains in programmer productively. because
Java is an object-oriented programming technology, which means
gains in software reuse and programmer productivity"
[maybe by using some of those "counter-intuitive" techniques
you were referring too]
"Reductions in capital assets [...] will come from using Java."
"Java will change the world"

The world lost a good snake-oil salesman in Keith (or maybe not!).

The way to promote Java is not to claim that it is the holy grail, but
to point out that can be a powerful tool to take its place alongside
with all the other ones to use when the situation and circumstances
warrant it.

Leif




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