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