I think that Paul has forgotten that his favorite OOP still generates
machine instructions. If C can do it, then it can be done in HLASM. OOP
really boils down into a different type of 'calling' standard other than
our nice and simple R1=>Parmlist, R14=return, R15=branch_to_address.
It's just that HLASM programmers are close enough to machine code that
we 'see' those hundreds (or thousands) of instructions that are used to
call an OOP routine and we are smart enough to know that we don't want
that overhead on every single call. Why do you think that LE enabled
HLASM code is so few and far between. It's the overhead.
The real definition of OOP should be:
"A programming method that 1) reduces code development time, 2) allows
code to be shared with little or no documentation, and 3) allows the
used of less-skilled programmers. This one time savings is then paid
back many thousands of times over the life of the program due to the
inefficiency of the generated code. OOPs promote the 'pay me later' part
of 'pay me now or pay me later'."
Tony Thigpen
Paul Raulerson wrote on 02/06/2018 10:15 PM:
On Feb 6, 2018, at 7:09 PM, Jon Perryman <[email protected]> wrote:
Poster wrote: reflects the poster's lack of knowledge of OOP.
Poster wrote (Yes, many differences. The weakness of my example
kind of proves the larger point: HLASM is not an OOP language.)
This poster and several C programmers here believe OOP is difficult in HLASM.
Very basic objects are extremely simple to implement (a few objects with
methods and private attributes). It would take me less than 5 minutes to code.
Is there a C programmer here who knows assembler well enough to tell us how to
create a few simple objects with methods and private attributes? If you can't
easily do this, then you don't know HLASM as well as you think. Who (C
programmers) knows how to create simple objects in HLASM?
OOP is not rocket science. Most system problems don't need full blown OOP.
There are many examples in z/OS where this simple implementation is all that we
need. It has the benefit that it is very low overhead. In C++, you either have
objects or you don't. If you are writing a large applications in HLASM, then
Inheritance, virtual functions, overloading and ... may become necessary. Each
of these can be handled as needed without much difficulty.
[snip]
Clearly, this is getting silly. Let’s be clear here, you can not write Object
Oriented Programs (OOP) in HLASM. The language does not support Object Oriented
Programming.
You *can* write programs that implement Object Oriented Design (OOD) in HLASM,
but you can do that in just about *any* language. It is much more difficult in
HLASM than other languages, mostly because of “old school” programmers who
scoff at things like data typing. (“I can move any kind of data I want into
that memory area…!”) Well of course they can, but that is not objected
oriented design or programming in HLASM. (shrug)
If you want to argue that, show me an example of an object you have designed in
HLASM, defining the object, the class it defines and what inheritance it has,
as well as the interface and package in whatever form you choose to implement.
I purposely used the more generic terms here, rather than the terms from any
specific language or implementation. Extra points, write a test hardness that
shows us it actually works the way you designed it.
I do not believe you can do it satisfactorily. You can code an OOP language in
HLASM, I will grant, but I hold serious doubts you can do what you claim there.
C - K&R C that is, does not support OOP either. But like almost every other
language, you can implement Object Oriented Design (OOD) in the language.
This is all pretty basic stuff and it is hard to argue with.
Please consider, HLASM is a fantastic platform for writing Bottom Up Design
programs. It is fun to hack away in the weeds and see a really cool result pop
out.
It is also really good for coding detailed low level logic in. Yes of course
you an read a record from a file with HLASM, but it doesn’t really shine in
doing so until you read files with variable length data and dozens of variable
length trailers - all of which require intense fiddling around with the data
which may or may not be properly aligned for more structured access.
It is ideal when you are getting down and really fiddling with hardware -
although that is anything but a common task these days. Even a very clever
person will most likely fail trying to outwit modern mainframe hardware, or out
optimize a high level language. It isn’t good or bad, it just *is*.
It’s like anything else, the right tool for some jobs. And it was written by
very clever people indeed- it is awesome to see and use their work.
However, insisting it is the best tool for every - or even most - jobs is just
being pig headed. Same for implying that HLASM or z/OS is portable. They are
not.
If all you have is a hammer, everything looks like a nail and you neat
yourself silly trying to pound in that screw.
